On Wed, Nov 25, 2009 at 6:01 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> > In short: The branch is "dead" because the changes you made in your
>> > branch revisions /branch:rA,B,C,etc. are not all contained in the reintegrate
>> > commit to trunk, rX. Subversion does not know that, semantically, /trunk:rX
>> > is the same as /branch:rA,B,C, etc. and already contained in the branch.
>>
>> Or, in other words, the svn:mergeinfo cannot store all merge information
>> properly. The problem is that the mergeinfos on trunk and on the branch
>> don't tell *when* the respective merges have been made, but the decision
>> how to merge depends on this information.
The problem here is not with merge tracking. It does record
everything that is needed. Merge tracking was implemented on top of
Subversion's existing merge algorithms and that is where the
deficiency lies, or really even in the repository itself. To do a
proper bi-directional merge Subversion would have to know what part of
a commit was from a merge and what part was from conflict resolution.
The latter needs to be merged back on the bi-directional merge.
Subversion does not have that level of granularity, but it is not
because of the merge tracking design.
That said, what is the big deal with specifying --reintegrate? It
turns out Subversion did have a merge algorithm that does work
properly and specifying --reintegrate just lets it know to apply it.
>> Actually the latter is the reason why I don't push the use of git
>> for us; I've done too many single-file merges in cvsnt; on the other
>> hand there is no reason why files or directories should be the
>> mergeable unit.
>>
>> svn: Well, why is the mergeinfo on the directory instead of on the
>> individual files?
>
> It can be on files, not only on directories.
>
> If you have lots of files (and subdirectories) with mergeinfo on them
> performance will drop, because Subversion has to work out which
> path/revision touples were merged, for every element with mergeinfo on it.
> That's why most people only have mergeinfo at the branch root,
> and for many cases that's sufficient.
>
> That's a big problem with the design IMO, it doesn't scale well.
> The performance problem is exacerbated by lots of network round-trips
> that happen while the client is calculating mergeinfo.
I do not believe this is true with the current trunk or 1.6.6 code.
These issues were resolved.
>> Information about merges is actually ancestry
>> information, as the ancestry graph of a file determines how and
>> what to merge. (git does that on a whole-tree basis.) And a file
>
> This is true for git but not for Subversion.
> I see how merging in theory affects ancestry, but it does not
> affect the concept of ancestry that Subversion uses.
>
> Ancestry in Subversion is defined by things like parent revisions
> and copyfrom information. Merging is something that applies edits
> or tree changes made to one subtree of the repository to another
> subtree of the repository. It does not affect ancestry, except that
> it can create copyfrom information (but I think the way copies are
> merged is wrong, the copyfrom information should point to the
> corresponding copy source within the merge target, not to the copy
> source in the merge source).
It is worth pointing out that Subversion implemented these features
without breaking compatibility with older releases and the millions of
users and probably petabytes of data being stored in SVN repositories.
Obviously if we started from scratch and optimized for merge this
could be better, but it would suck for the users that had to spend
weeks converting their repositories and upgrading all their tools etc.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424449
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-26 00:16:49 CET