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 [EMAIL PROTECTED] (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 history. Regards Santiago > However, I'm no SVN expert, so I can easily have misunderstood > everything. > > Endre. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
