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
post.
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
> 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 15:26:47 2006