On Sun, Nov 2, 2008 at 12:38 AM, Fabian Groffen <grobian@g.o> wrote:
> On 01-11-2008 17:28:47 -0700, Alec Warner wrote:
>> On Sat, Nov 1, 2008 at 4:51 PM, Donnie Berkholz <dberkholz@g.o> wrote:
>> > 3. Updating utilities, mainly repoman on the dev side, and rsync scripts
>> >   on the backend; and
>>
>> I will probably volunteer myself for #3 repoman....
>
> Also talk to Ali Polatel/alip/hawking who said at some point he'd redo
> repoman's SVN support with native python svn functions, instead of exec
> calls and output parsing.  Are there native python git functions?

There is GitPython.

>
> I don't know if echangelog is already git aware, but if it isn't, I
> guess it's a showstopper too.

I would rather unperl this too; the git patches for echangelog are
hella old.  Asssuming GitPython doesn't suck someone should probably
attempt a rewrite here as well.

>
> And how about Portage itself?  It currently only knows about rsync, cvs
> and svn, but probably should get extended with git support as well to
> facilitate devs.
>

Since when does portage care what you are using?  Are you referring to
emerge --sync or something else?

>> > Here's progress so far:
>> >
>> > 1. Working on it
>> > 2. Draft at <http://dev.gentoo.org/~dberkholz/master_plan.txt>. Thoughts?
>> > 3. Should be fairly straightforward. Patches welcome!
>
> With some experience, I don't think it's that straightforward at all.
> Repoman currently needs to figure out what files have changed, or were
> added/removed.  It checks if the ChangeLog was correctly updated, for
> instance, and then explicitly commits the files that were modified or
> added.  Since with Git there is not going to be header expansion, a
> shortcut can be made equal to the case where no expanded files are
> modified, and hence Manifest can be commited directly.
> Probably repoman should git add all modified files that it is going to
> git commit afterwards or something.
>
> The fast way to get repoman with git support is to just add another
> block of 'if vcs == "git":' everywhere some vcs interaction is
> necessary.  The long way uses an object oriented approach with
> implementations of certain requirements.  That said, I think Alec is the
> one :)

Don't put too much faith in me; I am typically bad at finishing
projects and I would appreciate help from others ;p

>
>> > 4. Could use some discussion. For example, do we provide
>> >   backwards-compat CVS for a while, or do we just provide a git testing
>> >   server for a while and switch things over all at once?
>
> After your testdrive for a month or so, shadowing the CVS tree, I think
> you can big-bang into Git, since for our regular users nothing should
> change.  Rsync just stays the same, the generation is just different,
> but with minimal differences to update the git checkout instead of the
> cvs checkout.  Developers should switch, should have a Portage that
> supports updating a git tree, and learn how to add/remove files and
> directories with git.  Anon-cvs for gentoo-x86 can just be migrated to
> git, right?
>
>
> --
> Fabian Groffen
> Gentoo on a different level
>
>