[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Implicit keep-alive after reintegrate merge

From: Mark Mielke <mark_at_mark.mielke.cc>
Date: Fri, 20 Jan 2012 06:20:27 -0500

On 01/20/2012 05:40 AM, Daniel Shahaf wrote:
> Sure, here it is:
>
> 12:37:24 @danielsh | wayita: reintegrate?
> ..
> 12:37:25 wayita | danielsh: If you want to know why --reintegrate is necessary, see http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3C20110720124721.GA7557@ted.stsp.name%3E
>
> Sorry for not including the link originally --- I was tired and couldn't
> recall how to recompute it.

Heh. I'm too tired to comprehend that email. I will try tomorrow.
However, I do wish to mention that I have looked at this problem in the
past and I have yet to understand why Subversion seems to have a
particular problem that requires --reintegrate whereas other solutions
such as ClearCase do not seem to have this problem.

In ClearCase, it comes down to the following key points:

1) Most recent common ancestor. Discovered by tracking back merge arrows
and branches to their branch off points until it reaches a common point.
2) The diff of the most recent common ancestor to the target version to
the target version is merged with the diff of the most recent common
ancestor to the source version to come up with the target.
3) In the special case where the most recent common ancestor is exactly
equivalent (byte for byte for files, directory entry for directory entry
for directories), a "trivial merge" is performed which means that the
content can be copied from the source version over top of the target
version with no merge effort required.
4) After completing a merge, a merge arrow is drawn.
5) A branch is a branch. "cleartool merge" doesn't need to treat one
direction special compared to the opposite direction beyond flipping
which version is the source and which version is the target. There are
higher level operations on top that presume a direction ("cleartool
deliver" sends from the private branch to the integration branch,
"cleartool rebase" sends from the integration branch to the private
branch), but these high level operations are implemented using
"cleartool merge" underneath, and "cleartool merge" is unaware of these
higher level conventions. It doesn't need to know about them.

I know that ClearCase does exactly the above because we reproduce it and
manipulate it and various non-standard ways to make it do exactly what
we want.

I know that Subversion has these limitations compared to ClearCase:

1) Merge tracking is done at a commit level rather than at a per file or
directory level. This means more complex analysis as the per commit
information is "lossy" compared to what ClearCase is able to achieve.
However, I think the information is still mostly available - it just
requires some effort to extract.
2) Branch off points are mysteriously hidden. Captured within the
underlying repository but not exposed to the client? I think I saw some
discussion about making this information available to the client but I
didn't follow the conclusion of this?

Putting all of the above together - I don't understand why --reintegrate
is required. Maybe I'm just ignorant. :-)

-- 
Mark Mielke<mark_at_mielke.cc>
Received on 2012-01-20 12:21:03 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.