Madan U Sreenivasan wrote:
> Hi,
>
> (Apologize for the loong subject line)
>
> I encountered this problem while trying to figure out eliding for a
> problem mentioned by dlr on irc. Thought could share my thoughts with you
> all for your views.
>
> Introduction:
> -------------------
>
> Assuming the following structure:
> /trunk
> /branches/branch1
> /branches/branch2
>
> With /trunk changes getting merged into /branches/branch1, and
> /branches/branch1 changes getting merged into /branches/branch2.
>
> If a revision X (say), was a result of a merge of revisions Y-Z from
> /trunk into /branches1. Say, we merge X into /branches/branch2. The
> mergeinfo for /branches/branch2 would contain:
>
> /branches/branch1: X
> /trunk: Y-Z
>
> Now, reverting X from /branches/branch2, would effectively mean a revert
> of the changes /trunk: Y-Z from the /branches/merge2 mergeinfo. But with
> the current mergeinfo format, we can't deduce that /branches/branch1:Z ==
> /trunk: Y-Z.
Yes you can, actually.
> I say this because:
> /branches/branch1:20 is equivalent to /trunk:18-19
Trying to determine which branch revisions are really the same as some
other revision in another part of the tree is a very hard problem, and
not something you are going to solve by mucking slightly with the mergeinfo.
>
> Proposal:
> --------------
>
> Now how do we represent this info in mergeinfo so that we could
> remove indirect mergeranges when we revert a particular revision. This is
> possible if we have a mergeinfo representation like:
> /trunk: 18-19=20
>
> If we had this information, anytime we revert a particular revision, we
> could check for the rangelists with an '=' and see if the current revision
> matches/is-a-superset-of the RHS of the '='. If so, we could confidently
> remove the whole rangelist entry.
How do i put this gently:
No.
You really don't want to go down this path.
Complicating the mergeinfo format to represent this is not worth it.
You can actually get the information you need just by looking at the
mergeinfo diffs as they have changed through history. You will then be
able to deduce that the mergeinfo added /branches/branch1 and /trunk at
the same time, and that they are really equivalent.
Even if you couldn't, the number of times reverse merges are performed
is not worth extending the mergeinfo format just to handle super-special
weird corner cases that don't occur often in practice.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 20:38:32 2006