incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <>
Subject Re: single repository status
Date Wed, 20 Jul 2011 13:21:25 GMT
----- Original Message ----

> From: Pedro F. Giffuni <>
> To:
> Sent: Wed, July 20, 2011 12:30:47 AM
> Subject: Re: single repository status
> 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 <>
> 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


View raw message