incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject Re: Subversion vs other source control systems
Date Tue, 19 Feb 2008 23:40:38 GMT

El mar, 19-02-2008 a las 22:29 +0100, Endre Stølsvik escribió:
> Upayavira wrote:
> > Justin put it very well in a related thread elsewhere (permission
> > sought):
> [ CHOP interesting adamant view from Justin ]
> (Where is "elsewhere", btw?)

the discussion spread to a private list outside here. We should move
this kind of discussion to a different public list, I guess it is mostly
out of scope in general@incubator (except in the "what is the apache
way", probably) I will try to post a followup in community, again.

> What I find strange in all this is the view that ALL projects at Apache 
> would have to change to OtherSCM if one project would want that..

I also find it strange. I guess it spreads from the fact that subversion
(or old cvs) can only preserve history easily when moving inside the
same repository.

I made an experiment, which I will publish in a blog entry, where I
"pulled" from repo2 into repo1 for two git repos. This is easy and
works, provided that there are no name collisions that are not supposed
to be merged together. If I have a hypothetical podling1 repo and
another hypothetical targetTLP1 repo, I could (say on graduation) do:

cd podling1
git-branch to_target1
git-checkout to_target1
mkdir target-tree
git mv * target-tree #"*" does not work but you get the idea...
git-commit -a -m "this is for targetTLP after graduation"
cd ../targetTLP1
git-branch merge_podling1
git-checkout merge_podling1
git-pull ../podling1 #it could be a remote repo too
git commit -a -m "merged podling1 in targettree"
gitk --all #to view the merged repos, it has a new "tree" in target-tree

And proceed moving code around or merging as appropriate. (Not sure how
would hg or bzr handle this use case). I don't know how this would work
in practice, there is a need to experiment this kind of things to find
corner cases and problems. But I think, as you comment in the following
paragraph, that it buys us lots of extra flexibility and scalability.

> Indeed, I find the decision to use one single SVN repo for the entire 
> organization's source pretty strange. I'd believe that one repo for 
> every TLP, for example, would be great (AFAIK, TLP-promotion can be 
> handled too with history preserved). This would help in every single 
> aspect in regard to the volume of source and activity, could use 
> multiple servers etc - and incidentally using another SCM for a 
> particular project wouldn't be that big a deal anymore. The only 
> downside I see is a slight bit more configuration management, and that 
> copying/moving a file from one repo to another would not keep history 
> that well. How often does this happen, though?

Actually, if you try the above as I have done with a couple of small
repos, it keeps the whole history, including moves, committer info, etc.
Typically modern SCM (this includes subversion FWIK) don't "version
files", but rather "store graphs of commits/changesets". This means that
pulling a commit from a different repository will go pulling parent
commits up to the first common commit or, lacking it, to the root of the


>    However, I'm no SVN expert, so I can easily have misunderstood 
> everything.
> Endre.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message