On Mon, 10 Jul 2006 22:52:20 +0530, Daniel Berlin <dberlin@dberlin.org>
wrote:
> Daniel Berlin wrote:
>> Kamesh Jayachandran wrote:
>>> Daniel Rall wrote:
[snip]
>>> Why not recording the reverse merges?
[snip]
> Reverse merges should probably be recorded somewhere.
My personal opinion is that a reverse merge should effectively only remove
one or more revisions from the existing merge-info.
What purpose does it serve (even reporting wise) to record the history of
a reverse merge (like 50-47)? I think it would only complicate our
calculation of future merges with no apparent benefit. The probable
questions that the user is going to ask to a merge-tracking system are:
- What revisions of what branch do I have in this branch?
- What are the pending revisions to bring a given branch in sync with
another given branch?
- What are the changesets (revisions) that came from branch1 to
branch2?
I can't imagine him asking:
- What revisions did I unmerge given a particular source and target?
I cant imagine it because, it does not solve any real life problem
AFAICT.
Having said that, reverse merge is only a theoretical problem. It does not
manifest in real life. Or should I say we could avoid it if our
forward-merge implementation is intelligent enough.
Let me explain:
There are two scenarios possible at the time a reverse merge happens wrt a
given source.
1) There is a merge history (due to either an earlier merge or cp) from
the source branch into the target.
In this case, we only have to remove the appropriate revisions
from the target mergeinfo.
2) There is no merge history whatsover between the source and the target.
Imagine this case in a little bit of detail: Two codes bases for
totally different tools (which have no historical relationships), and the
user deems it necessary to take a diffset from the first codebase to apply
to the second codebase. This is as good as applying a patch of a changeset
from the first codebase into the second codebase. This IMHO does NOT count
as a reverse merge (not even a merge - in the literal sense).
> Blocking revisions from future merges (which seems to be your usecase)
> is a completely different beast entirely.
Agree.
[snip]
Regards,
Madan.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 11 10:34:02 2006