On Sun, Nov 2, 2008 at 12:38 AM, Fabian Groffen <email@example.com> wrote:
> On 01-11-2008 17:28:47 -0700, Alec Warner wrote:
>> On Sat, Nov 1, 2008 at 4:51 PM, Donnie Berkholz <firstname.lastname@example.org> 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