----- Original Message ---- > From: Pedro F. Giffuni <[email protected]> > To: [email protected] > Sent: Wed, July 20, 2011 12:30:47 AM > Subject: Re: single repository status > > FWIW; > > When merging the branches most of the CWS information will be > lost anyways .. won't it? I have seen other projects using > subversion that take a snapshot and eventually update stuff > from trunk, but when the project is finished and merged back > the branch history is not viewable from the trunk, the > commit message is normally the only trace left. >
SVN keeps the branches in the history and they will always be available even if not visible in the current global revision. Tools like TortoiseSVN provide Revision Graphs that will map it out and make it easy to view and access the various branches in the history. This is also why SVN advocates using URLs with Peg Revisions for certain functionality - e.g. svn:externals - which keeps the URL locked to a given portion of the repository history. And it allows you to re-use branch names for different tasks if desired. Of course, that is supposing that you delete the branch when it has been fully re-integrated; which if you are using merge tracking and "svn merge --reintegrate" you will need to do. One of Subversions goals is to not lose anything, period - including history. So while there is still considerable work going on per merges (see info on SVN 1.7), the history of the branches is never lost unless you explicitly dump the repository, edit the dump, and reload it - which for most is not worth the time & effort - but then, SVN didn't lose the information as you explicitly deleted it outside of SVN. ----- Original Message ---- > From: Michael Stahl <[email protected]> > i think the problem is that Hg/git/otherDSCMs and SVN have fundamentally > different data models for representing branching/merging; the fact that > so far nobody has come up with a conversion tool that handles merges > well suggests to me that it's not an easy problem to solve. I think there are several issues at play. SVN historically (pre-SVN 1.5) did not do anything for tracking merges; so you had to track it all in the logs and that was project/repository dependent - even developer dependent. So that aspect makes it really hard to do merge tracking in conversion tools when there is no information to use - at least, moving from SVN to other things. I don't know about Hg/git/etc. The fundamental issue is that the conversion tools need to be able to process all the information - all the meta data, etc - stored by the tool being converted from, and then be able to apply it appropriately to the tool being converted to. While non-trivial, that is simply mapping the various pieces of information between the tools when that information is available. cvs2svn could certainly write the merge tracking to SVN in the SVN Dump Files it generated if it understood the information and could do so in a useful manner; but then it also needs to be able to track the revision numbers well enough to be able to apply them in the produced dump file - also non-trivial. So at least for SVN, I think the issue is more that it is non-trivial work and the feature have not been around quite long enough that people implementing the conversion tools have had time to integrate them properly, and perhaps there has also not been enough demand for it yet either. I'm not sure CVS did much in way of merge tracking, so that might play into it as well as most converting to SVN/git/hg/etc are converting from CVS, not one of the others where merge tracking is more prevalent or even assumed. As always, $0.02 Ben
