Hi Daniel!
Do I understand you correctly:
You have a post-1.5 solution in mind solving all merge tracking
problems discussed lately?
I would be very interested into understanding that,
since at the moment I basically don't understand you at all
(but of course, I am no expert on that matter at all,
so this is very likely my fault).
> On Sat, 01 Dec 2007, Blair Zajac wrote:
>
>> Ben Collins-Sussman wrote:
>>> On Nov 30, 2007 4:23 PM, Blair Zajac <blair@orcaware.com> wrote:
>>>
>>>> It just works. I mean, you still can get conflicts when you merge back
>>>> and you
>>>> resolve those just as you normally would.
>>>>
>>>> Thinking about it, I guess you might have to redo conflict resolution
>>>> again when
>>>> you merge changes back to trunk.
>>> Yeah, I wouldn't categorize that as 'just works'. Why should a user
>>> have to resolve the same conflicts twice? That's an indication that
>>> there are some changes *not* being tracked that should be.
>
> What svnmerge.py does is calculate "merged", "blocked", "phantom", and
> "reflected" revisions, and subtract those from the list of revisions requested
> for merge (see the contrib/client-side/svnmerge/svnmerge.py:action_merge()
> function). Issue #2897 is about proper handling of "reflected" revisions;
> that is, revisions from the merge source which carry mergeinfo from the merge
> target as their payload.
>
> There are two potential flavors of reflected revisions:
>
> a) "Merging revisions", which themselves also carry mergeinfo.
> b) "Merged revisions", which carry no mergeinfo (a leaf node in a merge DAG).
You define that "reflected revisions" are revisions "which carry mergeinfo",
but according your definition of b) that kind of "reflected revisions",
have no mergeinfo, which seems to be a contradiction.
> In Subversion's core Merge Tracking, we've decided that (a) requires
> additional parents in the DAG to properly represent,
The DAG you are talking about, how exactly it is defined
in terms of the current mergeinfo scheme?
What exactly to you want to change in the current mergeinfo schmele
to add support for "additional parents in the DAG"?
> and currently punt by
> repeating merges in this case for the sake of correctness. The plan has
> been to address this post-1.5. (b) is what Kamesh has been working on, and
> is something that needs to be addressed before releasing 1.5. Without (a),
> we're still in *much* better shape than in pre-1.5 releases; you can avoid
> specifying revision ranges when performing merges, and the only repeated
> merges you hit are when performing cyclic merging (M -> F -> M).
>
> svnmerge.py makes no distinction between these two types of reflected
> revisions, instead filtering out both (a) and (b), which can miss merging
> changes when pushing a branch which has been kept in sync with a mainline back
> into that mainline.
You seem to have a "post-1.5" approach in mind.
How exactly does this approach handle the case described in
http://svn.haxx.se/dev/archive-2007-11/1265.shtml ?
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 2 22:27:19 2007