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

Re: [PATCH] merge-tracking first merge being revert does not record 'svn:mergeinfo'

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-07-11 15:27:47 CEST

While trying to fix merge_tests.py:simple_property_merges, I came across
this case.
Extended the case exhibited by this testcase as mentioned in my earlier
Apart from theory I don't have any strong case to track that kind of
reverse mergeinfo.

With regards
Kamesh Jayachandran

Madan U Sreenivasan wrote:
> 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
> 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 15:26:47 2006

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.