www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Schmiedehausen <henn...@apache.org>
Subject Re: Zone for scm experiments (Was: Subversion vs other source control systems)
Date Thu, 10 Apr 2008 15:04:17 GMT
Santiago Gala schrieb:
> El jue, 10-04-2008 a las 09:31 +0200, Henning Schmiedehausen escribió:

>> IMHO there will be no non-svn commits (yet?). This will be strictly one 
>> way from svn -> git. Putting commits back into SVN will be IMHO by 
>> applying patches.
> I am committing using "git svn dcommit" already. I don't think it is
> easy to notice, actually, unless I start using git "style" for commit
> messages, which I actually did yesterday:

These are svn commits in disguise AFAIK. So you use the git frontend but 
it actually commits using SVN in the back. What I meant is, that there 
is no automatic replication happening from the mirrored git tree to the 
subversion repository but the syncing happens through the client.

> (I applied a patch sent by Dave Johnson to the list, and I thought that
> the convention of adding Author:/Signed-off-by: headers is a good idea
> and we already have had comments on this line:
> http://markmail.org/message/fphkuo3txveiczog and even old times
> templates for acknowledgement of patches.

that is fine, but this is a project decision, I see no reason to dictate 
any foundation wide policy. PMCs are happy using their own schemes or no 
scheme at all.

> Basically git svn can deal with subversion commits if the history is
> kept linear and no merges are done. This is what actually forces
> continuous rebases, even for your private branches, to keep them updated
> re: the subversion trunk.

This is something that almost surely will not fly. I anticipate that the 
number of merges will skyrocket with svn 1.5 when it will be much easier 
to merge (Karl Fogel's words ... :-) ) than it is with the current SVN. 
Also, linear history (as I understand it) is something that we have 
because there is a history reluctance to branch and merge (which IMHO 
comes from our CVS history).

As I wrote before, I see git mainly as an "add on" for offline commits 
and local work. SVN is here to stay for a while.

> I like a lot the ability of doing diffs between versions of branches,
> having options for move/copy detection and color differences. Where git
> really shines is for code review or patch integration, IMO.

Can you explain the code review part a bit? I had some exposure to 
Crucible lately and I don't see how code review benefits from git. But 
then again, I might just be thick. :-)

	Best regards

View raw message