1 |
On Sun, Nov 2, 2008 at 12:38 AM, Fabian Groffen <grobian@g.o> wrote: |
2 |
> On 01-11-2008 17:28:47 -0700, Alec Warner wrote: |
3 |
>> On Sat, Nov 1, 2008 at 4:51 PM, Donnie Berkholz <dberkholz@g.o> wrote: |
4 |
>> > 3. Updating utilities, mainly repoman on the dev side, and rsync scripts |
5 |
>> > on the backend; and |
6 |
>> |
7 |
>> I will probably volunteer myself for #3 repoman.... |
8 |
> |
9 |
> Also talk to Ali Polatel/alip/hawking who said at some point he'd redo |
10 |
> repoman's SVN support with native python svn functions, instead of exec |
11 |
> calls and output parsing. Are there native python git functions? |
12 |
|
13 |
There is GitPython. |
14 |
|
15 |
> |
16 |
> I don't know if echangelog is already git aware, but if it isn't, I |
17 |
> guess it's a showstopper too. |
18 |
|
19 |
I would rather unperl this too; the git patches for echangelog are |
20 |
hella old. Asssuming GitPython doesn't suck someone should probably |
21 |
attempt a rewrite here as well. |
22 |
|
23 |
> |
24 |
> And how about Portage itself? It currently only knows about rsync, cvs |
25 |
> and svn, but probably should get extended with git support as well to |
26 |
> facilitate devs. |
27 |
> |
28 |
|
29 |
Since when does portage care what you are using? Are you referring to |
30 |
emerge --sync or something else? |
31 |
|
32 |
>> > Here's progress so far: |
33 |
>> > |
34 |
>> > 1. Working on it |
35 |
>> > 2. Draft at <http://dev.gentoo.org/~dberkholz/master_plan.txt>. Thoughts? |
36 |
>> > 3. Should be fairly straightforward. Patches welcome! |
37 |
> |
38 |
> With some experience, I don't think it's that straightforward at all. |
39 |
> Repoman currently needs to figure out what files have changed, or were |
40 |
> added/removed. It checks if the ChangeLog was correctly updated, for |
41 |
> instance, and then explicitly commits the files that were modified or |
42 |
> added. Since with Git there is not going to be header expansion, a |
43 |
> shortcut can be made equal to the case where no expanded files are |
44 |
> modified, and hence Manifest can be commited directly. |
45 |
> Probably repoman should git add all modified files that it is going to |
46 |
> git commit afterwards or something. |
47 |
> |
48 |
> The fast way to get repoman with git support is to just add another |
49 |
> block of 'if vcs == "git":' everywhere some vcs interaction is |
50 |
> necessary. The long way uses an object oriented approach with |
51 |
> implementations of certain requirements. That said, I think Alec is the |
52 |
> one :) |
53 |
|
54 |
Don't put too much faith in me; I am typically bad at finishing |
55 |
projects and I would appreciate help from others ;p |
56 |
|
57 |
> |
58 |
>> > 4. Could use some discussion. For example, do we provide |
59 |
>> > backwards-compat CVS for a while, or do we just provide a git testing |
60 |
>> > server for a while and switch things over all at once? |
61 |
> |
62 |
> After your testdrive for a month or so, shadowing the CVS tree, I think |
63 |
> you can big-bang into Git, since for our regular users nothing should |
64 |
> change. Rsync just stays the same, the generation is just different, |
65 |
> but with minimal differences to update the git checkout instead of the |
66 |
> cvs checkout. Developers should switch, should have a Portage that |
67 |
> supports updating a git tree, and learn how to add/remove files and |
68 |
> directories with git. Anon-cvs for gentoo-x86 can just be migrated to |
69 |
> git, right? |
70 |
> |
71 |
> |
72 |
> -- |
73 |
> Fabian Groffen |
74 |
> Gentoo on a different level |
75 |
> |
76 |
> |