www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: Zone for scm experiments (Was: Subversion vs other source control systems)
Date Thu, 10 Apr 2008 16:48:51 GMT
El jue, 10-04-2008 a las 17:04 +0200, Henning Schmiedehausen escribió:
> 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.

Ok, I see your point (I was not seeing it). While we have a svn master,
all commits will be "svn commits". I don't think we want to complicate
the setup to have automated syncing beyond a svn commit hook to "git svn
rebase" the "trunk" or "git-svn" branch.

what "git svn dcommit" does is actually take all commits from the
"git-svn" sync point on and commit them to subversion, one at a time,
while rebasing the set. I don't think we want to go beyond this while
svn is "da master".

> > (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.

Well, I'm not sure. Actually recently Henri (not sure) pointed to the
old CVS template, which included, as a policy, the Submitted-by: Headers
to ensure code provenance. This could easily be made into a policy
similar to the "tick box" in JIRA to accept the license. So, to comment
on what you said: "I see a reason: creating an audit trail" I'm much
more comfortable with a header in svn commits than with a tick box in a
proprietary tool which I can't use offline.

> > 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).

If svn is better at merging it might even happen git-svn will learn
quickly to do merge dcommits too, I bet. I would write this code if
git-svn was not uncommented perl using an insane subversion API.

> 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.

Cool. I have no problems if we use webdav/fsfs to store the patch
sets. :P

> [,,,]
> > 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. :-)

(I'm not sure what Crucible is, but if it needs a server does not work
for me in my bus going back home. I spend 25% of my working time
commuting, and I have no car, so I actually work there.)

An invented task, on the fly: see how are we evolving re: dependency of
gmodules.com in shindig. You can see similar "what if" or "audit"
questions all the time in the incubator. Or just, how many dependencies
on such and such modules/api do we have? who introduced them? how is it
evolving? ...

# find how many dependencies on gmodules.com on shindig and assess
git clone git://github.com/sgala/apache-incubator-shindig.git
git grep gmodules.com | wc -l
4 #ok, not many 
git grep -l gmodules.com | xargs gedit

# find who removed them and when
git log --color --stat -M -p -Sgmodules.com #use less /gmodules.com ...
# if you like UIs use gitk with the search to do the same
# how many commits touched them?
git log --stat -M -p -Sgmodules.com | egrep  ^commit | wc -l


While doing that use a stopwatch and measure times. When you finish,
please, do the same with subversion and the web browsing tools. Try it
while the bus/train goes home, offline or using a slow GPRS connection.

This kind of things was what I was meaning. It is a great set of tools
to study and manage code.


> 	Best regards
> 		Henning
Santiago Gala

View raw message