[PATCH] Eliminate spurious svnmerge-integrated property conflicts

[Raman Gupta]

Sometimes, svnmerge.py will cause spurious conflicts in the merge
memory property. The last step of the action_merge function sets this
property explicitly to the new correct value anyway, so any conflicts
that occurred during the merge are irrelevant.

The patch for this is attached, and all tests still pass. Here is the
log message:

[[[
Prevent spurious conflicts on the merge property when the
source branch contains merge property information for other
branches. Previously, this caused a property conflict (when
-b was not used) because the initial value on the source branch
did not match the initial value on the target branch.

* contrib/client-side/svnmerge.py:
  (action_merge): Before each merge, set the merge property
    explicitly to the initial value of the source branch in
    all cases instead of only when bidirectional merging is
    enabled.

Patch by:  Raman Gupta <rocketraman@...>
Review by: ?
]]]

Cheers,
Raman

Index: svnmerge.py
===================================================================
--- svnmerge.py (revision 21792)
+++ svnmerge.py (working copy)
@@ -1153,14 +1153,12 @@
     old_merge_props = branch_props
     merge_metadata = logs[opts["head-url"]].merge_metadata()
     for start,end in minimal_merge_intervals(revs, phantom_revs):
+        # Set merge props
+        new_merge_props = merge_metadata.get(start-1)
+        if new_merge_props != old_merge_props:
+            set_merge_props(branch_dir, new_merge_props)
+            old_merge_props = new_merge_props
 
-        # Set merge props appropriately if bidirectional support is enabled
-        if opts["bidirectional"]:
-          new_merge_props = merge_metadata.get(start-1)
-          if new_merge_props != old_merge_props:
-              set_merge_props(branch_dir, new_merge_props)
-              old_merge_props = new_merge_props
-
         if not record_only:
             # Do the merge
             svn_command("merge -r %d:%d %s %s" % \

[Daniel Rall-2]

On Fri, 06 Oct 2006, Raman Gupta wrote:

> Sometimes, svnmerge.py will cause spurious conflicts in the merge
> memory property. The last step of the action_merge function sets this
> property explicitly to the new correct value anyway, so any conflicts
> that occurred during the merge are irrelevant.

Raman, thanks for the patch.  Sorry it slipped through the cracks for
so long.  I've written an additional test case for just this problem,
and below provide both your patch (tweaked) and the activation of my
test case for review.  (We might want to rename my test case; can you
think of a better name?)

While I think your patch makes us quite a bit better off than before,
I noticed that it does also clobber any transitive merge info from a
merge source which itself would otherwise attempt to be applied (and
cause a conflict) as part of the merge.  See the ### comment in my
test case to make sense of that mouthful.  ;-)

Also, I noticed that your patch removes one of the two main use cases
for the "--bidirectional" option, the other being the gating of
RevisionLog.merge_metadata().  While I haven't profiled it, I assume
this is so expensive an operation that we need to continue to gate it
(e.g. --bidirectional can't be made the default)?

On an orthogonal note, Michael Haggerty was hoping to make
--bidirectional "sticky".  Did you have any thoughts on that?

Thanks, Dan


...

> Prevent spurious conflicts on the merge property when the
> source branch contains merge property information for other
> branches. Previously, this caused a property conflict (when
> -b was not used) because the initial value on the source branch
> did not match the initial value on the target branch.
>
> * contrib/client-side/svnmerge.py:
>   (action_merge): Before each merge, set the merge property
>     explicitly to the initial value of the source branch in
>     all cases instead of only when bidirectional merging is
>     enabled.

...

Index: svnmerge_test.py
===================================================================
--- svnmerge_test.py (revision 22578)
+++ svnmerge_test.py (working copy)
@@ -1060,20 +1060,14 @@
                     match=r"Committed revision 17")
         os.remove("svnmerge-commit-message.txt")
 
-        ### FIXME: Unfortunately, we're getting a conflict for the
-        ### merge info property in the following svnmerge invocation
-        ### due to Subversion's (reasonable) lack of property value
-        ### merging (which isn't possible without knowing a property's
-        ### MIME type)
-
         # Attempt a merge of changes from test-branch to
-        # testYYY-branch.
-        self.svnmerge("merge -r 16 -S ../test-branch")
-        try:
-            self.launch("svn commit -F svnmerge-commit-message.txt",
-                        match=r"Committed revision 18")
-        except AssertionError:
-            self.assertTrue(os.path.isfile("dir_conflicts.prej"))
+        # testYYY-branch, which causes a property conflict without
+        # machinations by svnmerge.
+        self.svnmerge("merge -r 14,16 -S ../test-branch")
+        self.launch("svn commit -F svnmerge-commit-message.txt",
+                    match=r"Committed revision 18")
+        ### This clobbers the /trunk merge info from r14  :-(
+        self.svnmerge("integrated -S test-branch", match=r"^13-16$")
 
 if __name__ == "__main__":
     # If an existing template repository and working copy for testing
Index: svnmerge.py
===================================================================
--- svnmerge.py (revision 22577)
+++ svnmerge.py (working copy)
@@ -1153,14 +1153,13 @@
     old_merge_props = branch_props
     merge_metadata = logs[opts["source-url"]].merge_metadata()
     for start,end in minimal_merge_intervals(revs, phantom_revs):
+        # Set the merge info property now to avoid a property conflict
+        # from Subversion if WC and merge source values differ.
+        new_merge_props = merge_metadata.get(start - 1)
+        if new_merge_props != old_merge_props:
+            set_merge_props(branch_dir, new_merge_props)
+            old_merge_props = new_merge_props
 
-        # Set merge props appropriately if bidirectional support is enabled
-        if opts["bidirectional"]:
-          new_merge_props = merge_metadata.get(start-1)
-          if new_merge_props != old_merge_props:
-              set_merge_props(branch_dir, new_merge_props)
-              old_merge_props = new_merge_props
-
         if not record_only:
             # Do the merge
             svn_command("merge -r %d:%d %s %s" % \

[Raman Gupta]

Daniel Rall wrote:

> On Fri, 06 Oct 2006, Raman Gupta wrote:
>
>> Sometimes, svnmerge.py will cause spurious conflicts in the merge
>> memory property. The last step of the action_merge function sets this
>> property explicitly to the new correct value anyway, so any conflicts
>> that occurred during the merge are irrelevant.
>
> Raman, thanks for the patch.  Sorry it slipped through the cracks for
> so long.  I've written an additional test case for just this problem,
> and below provide both your patch (tweaked) and the activation of my
> test case for review.  (We might want to rename my test case; can you
> think of a better name?)

Thanks for the extra test case. I don't have any better names yet but
perhaps this discussion will help us come up with one.

> While I think your patch makes us quite a bit better off than before,
> I noticed that it does also clobber any transitive merge info from a
> merge source which itself would otherwise attempt to be applied (and
> cause a conflict) as part of the merge.  See the ### comment in my
> test case to make sense of that mouthful.  ;-)

Yes, I should have been clear in my patch description about that. I
think that the ability of svnmerge.py to carry-through this transitive
merge data has been an accidental side-effect of the implementation
rather than a designed-in feature, and so I've never really trusted
it. I tend to want to specifically add merge relationships between
branches rather than have them carry over implicitly.

For example, most of the time, in my workflow at least, the
"transitive" merge information is actually cruft that doesn't make
sense e.g. I end up with merge info about one release branch on
another release branch because they share the trunk as ancestor, and
bidirectionally merge with the trunk also. So the patch I submitted
actually improves this situation for me by eliminating the carry-over
of those values.

If keeping transitive merge data is important to people, perhaps what
is needed is a discussion of the transitive use cases people wish to
support, and then a specific implementation to achieve the
requirements, perhaps enabled by use of a "--transitive" flag.

> Also, I noticed that your patch removes one of the two main use cases
> for the "--bidirectional" option, the other being the gating of
> RevisionLog.merge_metadata().  While I haven't profiled it, I assume
> this is so expensive an operation that we need to continue to gate it
> (e.g. --bidirectional can't be made the default)?

I'd be +1 on making bidirectional the default but we've discussed
other solutions in the past that could obviate the decision -- e.g.
the config pickle for setting options and Michael's suggestion also.

> On an orthogonal note, Michael Haggerty was hoping to make
> --bidirectional "sticky".  Did you have any thoughts on that?

I definitely like the idea :-) Just to throw out a couple of
implementations -- we could prefix the merge property range with a "b"
to indicate bidirectional stickiness. Or we could have a second
property to store this info (though I like this one less as it
destroys the all-in-one-place nature of the merge property).

Cheers,
Raman

[Raman Gupta]

Raman Gupta wrote:
> Daniel Rall wrote:

>> On an orthogonal note, Michael Haggerty was hoping to make
>> --bidirectional "sticky".  Did you have any thoughts on that?
>
> I definitely like the idea :-) Just to throw out a couple of
> implementations -- we could prefix the merge property range with a "b"
> to indicate bidirectional stickiness. Or we could have a second
> property to store this info (though I like this one less as it
> destroys the all-in-one-place nature of the merge property).

Or what about just checking if the head of the source branch has merge
info for the target, and if it does, enabling the bidirectional flag
automatically?  From a performance perspective this adds one more
remote call for every merge but that's acceptable IMHO...

Cheers,
Raman

[Giovanni Bajo]

Raman Gupta wrote:

> Or what about just checking if the head of the source branch has merge
> info for the target, and if it does, enabling the bidirectional flag
> automatically?  From a performance perspective this adds one more
> remote call for every merge but that's acceptable IMHO...

+1!!!
--
Giovanni Bajo

[Daniel Rall-2]

On Thu, 07 Dec 2006, Giovanni Bajo wrote:

> Raman Gupta wrote:
>
> >Or what about just checking if the head of the source branch has merge
> >info for the target, and if it does, enabling the bidirectional flag
> >automatically?  From a performance perspective this adds one more
> >remote call for every merge but that's acceptable IMHO...
>
> +1!!!

Sounds good to me, Raman.  +1

[Daniel Rall-2]

On Tue, 05 Dec 2006, Raman Gupta wrote:

> Daniel Rall wrote:
> > On Fri, 06 Oct 2006, Raman Gupta wrote:
> >
> >> Sometimes, svnmerge.py will cause spurious conflicts in the merge
> >> memory property. The last step of the action_merge function sets this
> >> property explicitly to the new correct value anyway, so any conflicts
> >> that occurred during the merge are irrelevant.
...

> > While I think your patch makes us quite a bit better off than before,
> > I noticed that it does also clobber any transitive merge info from a
> > merge source which itself would otherwise attempt to be applied (and
> > cause a conflict) as part of the merge.  See the ### comment in my
> > test case to make sense of that mouthful.  ;-)
>
> Yes, I should have been clear in my patch description about that. I
> think that the ability of svnmerge.py to carry-through this transitive
> merge data has been an accidental side-effect of the implementation
> rather than a designed-in feature, and so I've never really trusted
> it. I tend to want to specifically add merge relationships between
> branches rather than have them carry over implicitly.

Let me start off by saying that I've never personally used the
svnmerge.py's transitive merge info.  However, some of my customers
are trying to use it -- they expect to be able to do graph-like
merging, rather than just the linear merging that I've personally been
doing with svnmerge.py (e.g. to keep Subversion's merge-tracking
branch up to date with its trunk).

That said, I consider transitive merge info an *essential* part of
merge tracking, and have implemented support for it as well as
possible given Subversion's architecture on the merge-tracking branch.

> For example, most of the time, in my workflow at least, the
> "transitive" merge information is actually cruft that doesn't make
> sense e.g. I end up with merge info about one release branch on
> another release branch because they share the trunk as ancestor, and
> bidirectionally merge with the trunk also. So the patch I submitted
> actually improves this situation for me by eliminating the carry-over
> of those values.

The usefulness of the transitive merge info depends on your branching
model.  It sounds like your merge model is very linear.  (I typically
use this model myself.)  Consider this circular merging model:

1. Init branch B from A.
2. Init branch A from C.
3. Merge changes from A -> B.
4. Init branch C from B.
5. Merge changes from B -> C (which currently fails due to a property
conflict without Raman's patch).
6. Merge changes from branch C back into A.  This should really skip
the merge of the change merged into C from B in step #5, because it
originated in A, and thus needn't be merged because it's already in A.

> If keeping transitive merge data is important to people, perhaps what
> is needed is a discussion of the transitive use cases people wish to
> support, and then a specific implementation to achieve the
> requirements, perhaps enabled by use of a "--transitive" flag.

Is it even possible to implement this model with svnmerge.py, or will
dir prop conflicts from Subversion's 'merge' operation always impede
it?  How the --source option to 'merge' currently avoid these property
conflicts?

[Blair Zajac]

Daniel Rall wrote:

> On Tue, 05 Dec 2006, Raman Gupta wrote:
>
>> Daniel Rall wrote:
>>> On Fri, 06 Oct 2006, Raman Gupta wrote:
>>>
>>>> Sometimes, svnmerge.py will cause spurious conflicts in the merge
>>>> memory property. The last step of the action_merge function sets this
>>>> property explicitly to the new correct value anyway, so any conflicts
>>>> that occurred during the merge are irrelevant.
> ...
>>> While I think your patch makes us quite a bit better off than before,
>>> I noticed that it does also clobber any transitive merge info from a
>>> merge source which itself would otherwise attempt to be applied (and
>>> cause a conflict) as part of the merge.  See the ### comment in my
>>> test case to make sense of that mouthful.  ;-)
>> Yes, I should have been clear in my patch description about that. I
>> think that the ability of svnmerge.py to carry-through this transitive
>> merge data has been an accidental side-effect of the implementation
>> rather than a designed-in feature, and so I've never really trusted
>> it. I tend to want to specifically add merge relationships between
>> branches rather than have them carry over implicitly.
>
> Let me start off by saying that I've never personally used the
> svnmerge.py's transitive merge info.  However, some of my customers
> are trying to use it -- they expect to be able to do graph-like
> merging, rather than just the linear merging that I've personally been
> doing with svnmerge.py (e.g. to keep Subversion's merge-tracking
> branch up to date with its trunk).
>
> That said, I consider transitive merge info an *essential* part of
> merge tracking, and have implemented support for it as well as
> possible given Subversion's architecture on the merge-tracking branch.

I agree.  I think svnmerge.py should keep this support, and I could use it also,
if it didn't get merge conflicts.

Regards,
Blair

>
>> For example, most of the time, in my workflow at least, the
>> "transitive" merge information is actually cruft that doesn't make
>> sense e.g. I end up with merge info about one release branch on
>> another release branch because they share the trunk as ancestor, and
>> bidirectionally merge with the trunk also. So the patch I submitted
>> actually improves this situation for me by eliminating the carry-over
>> of those values.
>
> The usefulness of the transitive merge info depends on your branching
> model.  It sounds like your merge model is very linear.  (I typically
> use this model myself.)  Consider this circular merging model:
>
> 1. Init branch B from A.
> 2. Init branch A from C.
> 3. Merge changes from A -> B.
> 4. Init branch C from B.
> 5. Merge changes from B -> C (which currently fails due to a property
> conflict without Raman's patch).
> 6. Merge changes from branch C back into A.  This should really skip
> the merge of the change merged into C from B in step #5, because it
> originated in A, and thus needn't be merged because it's already in A.
>
>> If keeping transitive merge data is important to people, perhaps what
>> is needed is a discussion of the transitive use cases people wish to
>> support, and then a specific implementation to achieve the
>> requirements, perhaps enabled by use of a "--transitive" flag.

I think we should support this out of the box without any additional flags.  If
you are proposing to remove merge information that may be useful later on, then
I am definitely a -1 on that, since you will have thrown away information that
you may not be able to easily recover.

Regards,
Blair

[Raman Gupta]

Daniel Rall wrote:

> Let me start off by saying that I've never personally used the
> svnmerge.py's transitive merge info.  However, some of my customers
> are trying to use it -- they expect to be able to do graph-like
> merging, rather than just the linear merging that I've personally been
> doing with svnmerge.py (e.g. to keep Subversion's merge-tracking
> branch up to date with its trunk).
>
> That said, I consider transitive merge info an *essential* part of
> merge tracking, and have implemented support for it as well as
> possible given Subversion's architecture on the merge-tracking branch.
>
>> For example, most of the time, in my workflow at least, the
>> "transitive" merge information is actually cruft that doesn't make
>> sense e.g. I end up with merge info about one release branch on
>> another release branch because they share the trunk as ancestor, and
>> bidirectionally merge with the trunk also. So the patch I submitted
>> actually improves this situation for me by eliminating the carry-over
>> of those values.
>
> The usefulness of the transitive merge info depends on your branching
> model.  It sounds like your merge model is very linear.  (I typically
> use this model myself.)  Consider this circular merging model:
>
> 1. Init branch B from A.
> 2. Init branch A from C.
> 3. Merge changes from A -> B.
> 4. Init branch C from B.
> 5. Merge changes from B -> C (which currently fails due to a property
> conflict without Raman's patch).
> 6. Merge changes from branch C back into A.  This should really skip
> the merge of the change merged into C from B in step #5, because it
> originated in A, and thus needn't be merged because it's already in A.

Yikes! This merge model is too complicated for me but I think its
because my background is cvs/subversion, so I'm not used to being able
to easily do this type of thing. Perhaps if the tool handled this for
me, I'd find some reason to use it. To help kick-start my thinking
process, could someone provide some uses cases for doing this type of
graph merging? For example, for the linear model there are the use
cases of feature branches or release branches. What are some use cases
for graph-based merging? This is not a challenge -- I'm sure there are
many use cases, but I just want to know what some of them are.

>> If keeping transitive merge data is important to people, perhaps what
>> is needed is a discussion of the transitive use cases people wish to
>> support, and then a specific implementation to achieve the
>> requirements, perhaps enabled by use of a "--transitive" flag.
>
> Is it even possible to implement this model with svnmerge.py, or will
> dir prop conflicts from Subversion's 'merge' operation always impede
> it?  How the --source option to 'merge' currently avoid these property
> conflicts?

Anything is possible -- worst case, we would just have to write the
algorithms to "merge" the merge memory (meta-merge!) as part of
svnmerge.py. I think to implement full support for transitive merging,
instead of the half-baked implementation accident it is now (IMHO),
that, or something similar, is what would have to be done.

BTW, I'm in the process of a major move so I'm going to be out of
touch for a few days...

Cheers,
Raman

[Daniel Rall-2]

On Fri, 08 Dec 2006, Blair Zajac wrote:

> Daniel Rall wrote:

>> Raman Gupta wrote:
...

> >Let me start off by saying that I've never personally used the
> >svnmerge.py's transitive merge info.  However, some of my customers
> >are trying to use it -- they expect to be able to do graph-like
> >merging, rather than just the linear merging that I've personally been
> >doing with svnmerge.py (e.g. to keep Subversion's merge-tracking
> >branch up to date with its trunk).
> >
> >That said, I consider transitive merge info an *essential* part of
> >merge tracking, and have implemented support for it as well as
> >possible given Subversion's architecture on the merge-tracking branch.
>
> I agree.  I think svnmerge.py should keep this support, and I could use it
> also, if it didn't get merge conflicts.

...

> >The usefulness of the transitive merge info depends on your branching
> >model.  It sounds like your merge model is very linear.  (I typically
> >use this model myself.)  Consider this circular merging model:
> >
> >1. Init branch B from A.
> >2. Init branch A from C.
> >3. Merge changes from A -> B.
> >4. Init branch C from B.
> >5. Merge changes from B -> C (which currently fails due to a property
> >conflict without Raman's patch).
> >6. Merge changes from branch C back into A.  This should really skip
> >the merge of the change merged into C from B in step #5, because it
> >originated in A, and thus needn't be merged because it's already in A.
> >
> >>If keeping transitive merge data is important to people, perhaps what
> >>is needed is a discussion of the transitive use cases people wish to
> >>support, and then a specific implementation to achieve the
> >>requirements, perhaps enabled by use of a "--transitive" flag.
>
> I think we should support this out of the box without any additional
> flags. If you are proposing to remove merge information that may be
> useful later on, then I am definitely a -1 on that, since you will
> have thrown away information that you may not be able to easily
> recover.

I also want intrinsic support for transitive merge info (without use
of additional flags).  However, for the case described above, it would
be nice if svnmerge.py worked *at all*.  At least for such a case, I'm
definitely in favor of something along the lines of Raman's patch.

Given that this use case currently blows up, how are folks using
svnmerge.py to merge changes, which themselves contain merge info,
into a branch without triggering a property conflict?  Is this even
feasible today with svnmerge.py?

[Daniel Rall-2]

On Fri, 08 Dec 2006, Raman Gupta wrote:

> Daniel Rall wrote:
...

> > The usefulness of the transitive merge info depends on your branching
> > model.  It sounds like your merge model is very linear.  (I typically
> > use this model myself.)  Consider this circular merging model:
> >
> > 1. Init branch B from A.
> > 2. Init branch A from C.
> > 3. Merge changes from A -> B.
> > 4. Init branch C from B.
> > 5. Merge changes from B -> C (which currently fails due to a property
> > conflict without Raman's patch).
> > 6. Merge changes from branch C back into A.  This should really skip
> > the merge of the change merged into C from B in step #5, because it
> > originated in A, and thus needn't be merged because it's already in A.
>
> Yikes! This merge model is too complicated for me but I think its
> because my background is cvs/subversion, so I'm not used to being able
> to easily do this type of thing. Perhaps if the tool handled this for
> me, I'd find some reason to use it.

Apparently graph-like merging is well-supported by established tools
like ClearCase.  I assume AccuRev, and anything else which boasts good
merge tracking, also support this style of merge tracking.

But the above case isn't really graph-like, it's more like a
multi-tier, linear merging model.

> To help kick-start my thinking
> process, could someone provide some uses cases for doing this type of
> graph merging? For example, for the linear model there are the use
> cases of feature branches or release branches. What are some use cases
> for graph-based merging? This is not a challenge -- I'm sure there are
> many use cases, but I just want to know what some of them are.

I've asked my co-worker, Auke, to describe our customer use cases in
more depth.  I believe they're using it to port changes across very
long-lived (10+ years) active code streams, where (I'm assuming) each
new generation of code stream branches off the previous most recent
stream.  When a bug is fixed in one of these streams, it must be
ported back across all other active streams.  Performing the porting
by branch by branch, from "most recent" to "oldest" stream,
step-by-step back through time, seems like the best way to go about
this.  You can read more about this user's habits here:

http://subversion.tigris.org/merge-tracking/summit-survey.html#medical-systems

I occasionally use a model like the above case (which was reported by
Auke originally) myself in larger scale distributed development
projects to decouple the construction of several distinct major
features.  This model puts off a lot of the integration costs until
nearer RC time (when it's time to pay the piper ;), but if the
features really don't overlap much, it can over good savings by
decoupling development teams (kinda the opposite of continuous
integration).  I'll try to describe that model here:

I have a branch targeted for release (A).  It contains changes to
several major sub-systems, each of which get feature branches (B is
one such branch).  With each sub-system, there is a distinct set of
individual changes which take place, each segregated onto its own
branch (C).  C may want updates from B, and B may want updates from C.
Either B will need C (and all other C-type branches rolled into it),
before being merged back into A, or all C-type branches will be merged
directly into A.  Either way, the model is related to the use case
described above.

> >> If keeping transitive merge data is important to people, perhaps what
> >> is needed is a discussion of the transitive use cases people wish to
> >> support, and then a specific implementation to achieve the
> >> requirements, perhaps enabled by use of a "--transitive" flag.
> >
> > Is it even possible to implement this model with svnmerge.py, or will
> > dir prop conflicts from Subversion's 'merge' operation always impede
> > it?  How the --source option to 'merge' currently avoid these property
> > conflicts?
>
> Anything is possible -- worst case, we would just have to write the
> algorithms to "merge" the merge memory (meta-merge!) as part of
> svnmerge.py. I think to implement full support for transitive merging,
> instead of the half-baked implementation accident it is now (IMHO),
> that, or something similar, is what would have to be done.

I did this in Subversion's core on the merge-tracking branch, but it
would be difficult to do in a robust fashion outside of Subversion,
since you'd need to avoid having 'svn merge' merge those directory
properties (or possibly do something after the property conflict
occurs to resolve it).

See combine_forked_mergeinfo_props() in libsvn_wc/props.c
<http://svn.collab.net/repos/svn/branches/merge-tracking/subversion/libsvn_wc/props.c>.

How were you thinking of pulling this off?


> BTW, I'm in the process of a major move so I'm going to be out of
> touch for a few days...

Thanks for the heads-up, and good luck with the move.

- Dan

[Jack Repenning-2]

On Tue Dec 5 07:48:26 PST 2006, Raman Gupta wrote:

> If keeping transitive merge data is important to people, perhaps what
> is needed is a discussion of the transitive use cases people wish to
> support, and then a specific implementation to achieve the
> requirements, perhaps enabled by use of a "--transitive" flag.

This whole "transitive merge info" business is kind of a pet project  
of mine, that I've been thinking about and working on for well over  
ten years, so if I get too wordy, feel free to slap me down ;-)  Let  
me start (and maybe even stop, at least as far as this message is  
concerned) with some concrete examples, real-world situations I've  
actually been in.

Limited-distribution product: In this situation, we had an internal  
product with a small number of customers--half a dozen.  The product  
was of substantial size: 100k lines of C, a client/server  
configuration with two or three distinct clients (I will use "client"  
to mean "process that depends on the server," while I will use  
"customer" to mean "team within the company that uses the product.")  
Each customer had their own server, and the customers were not  
software people.  The product was successful (i.e., people used it  
every day), and it evolved quite rapidly (new releases to some  
customer or other every week or so), and each customer had unique  
requirements.  We ended up boxed into maintaining parallel versions  
of what was only roughly the same product, sharing as much code as we  
could, generalizing the idiosyncratic requirements whenever possible,  
parameterizing and modularizing and configuring and otherwise  
limiting the variations as much as we could, but still we ended up  
with half a dozen parallel versions of something that was maybe 80%  
common and 20% custom.  The need for transitive merge tracking arises  
like this: when a problem is discovered in the common code, the  
particular customer who first encounters it is pretty much random.  
At any moment in time, it may or may not be convenient for other  
customers to receive the fix.  Worse than that: some customers would  
actually reject some fixes, because they violate one of their  
idiosyncratic requirements, or at any rate need to be moderated to  
fit their idiosyncrasies.  One concrete example of how messy that  
could get: we had a "fairness doctrine" in the server, that ensured  
that multiple concurrent clients didn't interfere in ways that  
starved one or another unfairly.  But one customer felt "fair" meant  
"equal time for all," while another wanted "in case of a tie, one  
designated client always wins."  A bug fix that improved the "one  
always wins" behavior might make the latter happy, while explicitly  
violating the former.  Key properties of this situation that forced  
us into wanting "transitive merge info":
  - several branches of development
  - proceeding in parallel without any expectation of eventual  
convergence
  - changes might originate in any of the versions
  - changes might propagate to the other versions in any arbitrary order
  - sometimes changes propagate identically, sometimes with tweaks,  
and sometimes we needed to record that a change was positively  
rejected and should never be applied

Database system: I once worked for a major relational database system  
vendor.  A peculiarity of the database business is that customers  
become extraordinarily wedded to the version of the DB they're  
using.  Major releases are allowed/expected to be incompatible, which  
means both that a dump/load of the data is/may be needed, and also  
that your APIs may change incompatibly.  A corollary to this is that  
some customers don't want to upgrade to a new version ... often  
customers with a lot of money to spend.  But the still want change in  
their product, not only bug fixes but even major enhancements of  
various sorts.  At the time I was there, we had four major versions  
in circulation.  The "center of gravity" (number of customers using  
it, or put another way number of dollars coming in for support  
contracts) tended to lag about 1.5 major versions behind the main  
release stream, so we had two or three versions under active, major  
enhancement and support, as well as one or two on "life support."  
Each version had some unique property to distinguish it: physical  
storage format, or highly parallel code, or object-relational  
support, or data replication, and the unique features involved a lot  
of unique code, of course, but there was also a huge majority of the  
code that was shared (and some of the support work on older versions  
consisted of back-porting stuff originally created for newer  
version).  So, once again, we had essentially eternal parallel  
development, with a rich mixture of unique stuff, shared stuff,  
weirdly semi-shared/semi-tweaked stuff, and some notable mixture of  
categorically-not-to-be-shared stuff.

Linux: Things in the Linux world are, perhaps, a bit more  
"cathedralesque" these days than they once were, but if you think  
back, say, to the days "pre-Red Hat," the model went something like  
this: while there was certainly always a very clear definition to  
"the most official Linux in the world" (answer: whatever Linux has),  
the community dynamics included a rich exchange of work at somewhat-
less-than-Linus levels of officialdom.  There was ample room for  
hobbyists with no more interest than to build their own single site,  
and willing to take a useful feature from some other hobbyist,  
acknowledging that it might have some flaws or limitations that were  
actually keeping it from the One True Linux, "but what the heck, it  
works for me."  Maybe that's still true, maybe the commercially-
viable, "I don't WANT to understand it, I just want someone to yell  
at if it fails" style is a pure addition.  Anyway, particularly in  
the hobbyist arena, we once again see those now-familiar indicia:  
multiple branches, no real expectation that they'll converge to one,  
on-going change freely interchanged among them, and a distinct  
requirement to accept some changes, modify others, and explicitly  
reject yet others.

So those are my cases.  As you can see, they really reduce down to  
one abstract case, which is handy because it means we only need one  
implementation to address them all!



-==-
Jack Repenning
Director, Software Product Architecture
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: [phone]
raindance: 844.7461
aim: jackrepenning
skype: jrepenning

[Alan Barrett]

On Fri, 08 Dec 2006, Raman Gupta wrote:
> > Consider this circular merging model:
>
> could someone provide some uses cases for doing this type of
> graph merging?

The use case I described on 14 July 2006 had three
branches with circular merging.  The archives at
http://www.orcaware.com/pipermail/svnmerge/ seem to be missing the month
of July, and parts of June and August, so I can't point to an archived
copy of my message.  Here's the message again:

--------

If you have two branches, A and B, and if you merge A -> B and B -> A,
then svnmerge.py with the --bidirectional flag can handle it.  But if
you have three branches, A, B, and C, and if you merge A -> B, B -> C,
and C -> A, then svnmerge.py can't handle it.  It would be nice if
somebody could fix that (sorry, it won't be me).

Use case:

    I have a project with three branches, "dev", "test", and "prod".
    Usually, the development team commits changes to the dev branch,
    then merges to the test branch.  The testing team tests the changes,
    then merges to the prod branch.  The production team updates the
    production system from the prod branch.  svnmerge handles all this
    just fine.

    Occasionally, changes are made on the production system, and
    committed to the prod branch.  It would be nice if svnmerge could
    help with merging those changes back to the dev branch.

I attach a script to demonstrate the problem.   [script deleted from
this copy]

--apb (Alan Barrett)

[Auke Jilderda]

Daniel, Raman,

sorry for the slow response but as promised here is a description of the
model.  It is a multi-tier, linear model of forward propagating fixes:

    The basic model is having multiple major release branches, each
    branched off of its predecessor.  Fixes are forward propagated to
    subsequent releases in chronological order; they are never
    propagated back in time.

    Minor release branches are branched off of a major release branch.
    Fixes on minor releases are propagated to the corresponding major
    release and from there onwards in the basic approach.  Fixes on
    minor release are not propagated to other minor releases (neither to
    older or newer minor releases nor to minor releases on other major
    releases).

    Customer specifics are actively kept on an absolute minimum but when
    needed, they reside on a customer specific branch.  Customer
    specific branches are branched off of minor releases.  Fixes that
    are accepted into the main product are propagated to the
    corresponding minor release, then on to the corresponding major
    release, and onwards in the basic approach.  Fixes that are not
    accepted into the main product are not propagated to any minor or
    major release and sometimes are propagated to a corresponding
    customer specific branch on a later release.

    Things (should) that never happen:
    - Propagating 'back in time'.  Hence, in reverse chronological
      order.
    - A fix is propagated from one minor release to the next on the same
      major release.
    - A fix is propagated from one minor release to another on a
      different major release.

    Summarising, this is a strictly linear merging model of forward
    propagating fixes.  The transitive merge information is needed to be
    able to verify that fixes have been propagated to all subsequent
    releases.

I sent you a PDF off-list summarising the same in three pictures.  Please
don't hesitate if you want more detail or have questions on this model.


Auke

On 09 December 2006 04:48, Daniel Rall wrote:

>
> ...
> But the above case isn't really graph-like, it's more like a
> multi-tier, linear merging model.
>
> I've asked my co-worker, Auke, to describe our customer use cases in
> more depth.  I believe they're using it to port changes across very
> long-lived (10+ years) active code streams, where (I'm assuming) each
> new generation of code stream branches off the previous most recent
> stream.  When a bug is fixed in one of these streams, it must be
> ported back across all other active streams.  Performing the porting
> by branch by branch, from "most recent" to "oldest" stream,
> step-by-step back through time, seems like the best way to go about
> this.  You can read more about this user's habits here:
>
>

http://subversion.tigris.org/merge-tracking/summit-survey.html#medical-systems
> ...

[Auke Jilderda]

Raman,

have you pursued the implementation of supporting merge tracking across more
than two branches (optionally with even providing transitive merge tracking
information)?

To support merge tracking across more than two branches, I (as layman w.r.t.
the implementation) see four possible solutions: (a) prepend the path to the
key of the versioned property, (b) not propagate the versioned property, (c)
enable the init sub command to manually specify the name of the property
used, or (d) automatically merge the versioned property's value.

Option (d) seems the most elegant (and is what Daniel is doing on Subversion's
merge-tracking branch) but would require that the Subversion command-line
client (as driven by svnmerge.py) to allow not merging a
directory's "svnmerge-integrated" property while merging other properties and
the contents of that directory.  The command-line client doesn't currently
allow this; it might be doable at the Subversion C API level but Daniel tells
me that that would probably require quite a bit of work.  Option (a) isn't
backwards compatible but would be the easiest to hack in. Option (c) would
require the user to name the property for every subsequent invocation of
svnmerge.py which would be a nuisance to put it mildly. Option (b) isn't
feasible; it has the same problem as described for option (d).

Would it be feasible and interesting to have a modified svnmerge.py that
implements option (a) for those who don't mind not being backwards compatible
but need to be able to merge across multiple branches?  It seems the quickest
solution to bridge the time until 1.5 arrives even though it may not be
useful to some of the current users of svnmerge.py that need to maintain
their merge tracking information already built up.


Auke

On Wednesday 13 December 2006 13:44, Auke Jilderda wrote:

> Daniel, Raman,
>
> sorry for the slow response but as promised here is a description of the
> model.  It is a multi-tier, linear model of forward propagating fixes:
>
>     The basic model is having multiple major release branches, each
>     branched off of its predecessor.  Fixes are forward propagated to
>     subsequent releases in chronological order; they are never
>     propagated back in time.
>
>     Minor release branches are branched off of a major release branch.
>     Fixes on minor releases are propagated to the corresponding major
>     release and from there onwards in the basic approach.  Fixes on
>     minor release are not propagated to other minor releases (neither to
>     older or newer minor releases nor to minor releases on other major
>     releases).
>
>     Customer specifics are actively kept on an absolute minimum but when
>     needed, they reside on a customer specific branch.  Customer
>     specific branches are branched off of minor releases.  Fixes that
>     are accepted into the main product are propagated to the
>     corresponding minor release, then on to the corresponding major
>     release, and onwards in the basic approach.  Fixes that are not
>     accepted into the main product are not propagated to any minor or
>     major release and sometimes are propagated to a corresponding
>     customer specific branch on a later release.
>
>     Things (should) that never happen:
>     - Propagating 'back in time'.  Hence, in reverse chronological
>       order.
>     - A fix is propagated from one minor release to the next on the same
>       major release.
>     - A fix is propagated from one minor release to another on a
>       different major release.
>
>     Summarising, this is a strictly linear merging model of forward
>     propagating fixes.  The transitive merge information is needed to be
>     able to verify that fixes have been propagated to all subsequent
>     releases.
>
> I sent you a PDF off-list summarising the same in three pictures.  Please
> don't hesitate if you want more detail or have questions on this model.
>
>
> Auke

[Raman Gupta]

Auke Jilderda wrote:
> Raman,
>
> have you pursued the implementation of supporting merge tracking across more
> than two branches (optionally with even providing transitive merge tracking
> information)?

Not yet, I've been busy getting my life in order after having moved
back to Canada (my home and native land!) from the USA. What do you
mean exactly by "across more than two branches"?  Svnmerge.py already
supports merge tracking with more than one source via the -S (source)
switch -- just not transitively all that well.

> To support merge tracking across more than two branches, I (as layman w.r.t.
> the implementation) see four possible solutions: (a) prepend the path to the
> key of the versioned property, (b) not propagate the versioned property, (c)
> enable the init sub command to manually specify the name of the property
> used, or (d) automatically merge the versioned property's value.

Unless I am misunderstanding you, a) is already implemented (sort of,
the path is prepended to the revision value, not the versioned
property key) -- I think this was even part of Archie's original
non-python version.

> Option (d) seems the most elegant (and is what Daniel is doing on Subversion's
> merge-tracking branch) but would require that the Subversion command-line
> client (as driven by svnmerge.py) to allow not merging a
> directory's "svnmerge-integrated" property while merging other properties and
> the contents of that directory.  The command-line client doesn't currently
> allow this; it might be doable at the Subversion C API level but Daniel tells
> me that that would probably require quite a bit of work.  Option (a) isn't
> backwards compatible but would be the easiest to hack in. Option (c) would
> require the user to name the property for every subsequent invocation of
> svnmerge.py which would be a nuisance to put it mildly. Option (b) isn't
> feasible; it has the same problem as described for option (d).

Option d) should really be implemented in addition to the existing
option a) and this could maybe somewhat support transitive merging (at
least better than currently). I don't even think it would be that
complicated to merge the property manually with a little bit of
python-fu i.e. svnmerge.py would use the information on both branches
to explicitly set the property after the merge, whilst ignoring any
merges/conflicts produced by svn's merge algorithm by reverting the
property merge.

Though I'd still like to see a good use case for transitive merging --
I looked through the PDF you sent and I don't think the scenario it
describes is a transitive merging use case -- in fact I think its
pretty vanilla uni-directional merging from older branches to newer
branches. Your summary was this:

>     Summarising, this is a strictly linear merging model of forward
>     propagating fixes.  The transitive merge information is needed to be
>     able to verify that fixes have been propagated to all subsequent
>     releases.

I would set up a script that executes svnmerge.py avail on each branch
going forward in time with the prior older branch as the -S (source)
argument, and aggregates the result into some sort of consolidated
report of available revisions to be forward propagated. This would
give you your verification in one command, without any transitive
support in svnmerge.py.

Since svnmerge.py also supports bidirectional merging, you could even
support both forward and backwards propagating fixes simultaneously.

However, transitive support might be useful in your scenario if you
wanted to support the occasional "skipping" of a branch with later
application of that skipped revision. In this case, it would be needed
so that when the skipped revision was applied later, svnmerge.py would
understand that it had already been merged into the next branch
forward in time.

> Would it be feasible and interesting to have a modified svnmerge.py that
> implements option (a) for those who don't mind not being backwards compatible
> but need to be able to merge across multiple branches?  It seems the quickest
> solution to bridge the time until 1.5 arrives even though it may not be
> useful to some of the current users of svnmerge.py that need to maintain
> their merge tracking information already built up.

If you just want to merge across multiple branches without the
transitive information, svnmerge.py does this already. If my patch is
applied (the one that kicked off this round of discussion about
transitive merging), then it will even do so without conflicts in the
svnmerge-integrated property.

Cheers,
Raman

[Auke Jilderda]

On Wednesday 14 February 2007 09:56, Raman Gupta wrote:
>
> Not yet, I've been busy getting my life in order after having moved
> back to Canada (my home and native land!) from the USA. What do you
> mean exactly by "across more than two branches"?  Svnmerge.py already
> supports merge tracking with more than one source via the -S (source)
> switch -- just not transitively all that well.

I mean the way as in the use case  as I described in a recent post [1]: When
you copy a change set from branch A to B and then from B to C, the latter
copy will generate a conflict on the property used for merge tracking. This
is because svnmerge.py uses the same key for that versioned property on every
branch.

> Unless I am misunderstanding you, a) is already implemented (sort of,
> the path is prepended to the revision value, not the versioned
> property key) -- I think this was even part of Archie's original
> non-python version.

You misunderstood: the problem is that the versioned property key is the same
so the svn client raises a conflict.

> Option d) should really be implemented in addition to the existing
> option a) and this could maybe somewhat support transitive merging (at
> least better than currently). I don't even think it would be that
> complicated to merge the property manually with a little bit of
> python-fu i.e. svnmerge.py would use the information on both branches
> to explicitly set the property after the merge, whilst ignoring any
> merges/conflicts produced by svn's merge algorithm by reverting the
> property merge.

Yes, that would solve the issue.

> Though I'd still like to see a good use case for transitive merging --
> I looked through the PDF you sent and I don't think the scenario it
> describes is a transitive merging use case -- in fact I think its
> pretty vanilla uni-directional merging from older branches to newer
> branches. Your summary was this:
> >     Summarising, this is a strictly linear merging model of forward
> >     propagating fixes.  The transitive merge information is needed to be
> >     able to verify that fixes have been propagated to all subsequent
> >     releases.

Um, how do you define "transitive merging"?

To be able to use svnmerge.py, we need to be able to merge from A to B, from B
to C, and so on.  Transitive merge information would be nice to have but not
essential.

> I would set up a script that executes svnmerge.py avail on each branch
> going forward in time with the prior older branch as the -S (source)
> argument, and aggregates the result into some sort of consolidated
> report of available revisions to be forward propagated. This would
> give you your verification in one command, without any transitive
> support in svnmerge.py.
>
> Since svnmerge.py also supports bidirectional merging, you could even
> support both forward and backwards propagating fixes simultaneously.
>
> However, transitive support might be useful in your scenario if you
> wanted to support the occasional "skipping" of a branch with later
> application of that skipped revision. In this case, it would be needed
> so that when the skipped revision was applied later, svnmerge.py would
> understand that it had already been merged into the next branch
> forward in time.
>
> If you just want to merge across multiple branches without the
> transitive information, svnmerge.py does this already. If my patch is
> applied (the one that kicked off this round of discussion about
> transitive merging), then it will even do so without conflicts in the
> svnmerge-integrated property.

Ah ok, I got slightly lost in the technical details earlier in this thread: to
the best of my understanding, your patch would avoid the conflict on the
versioned property but flushes transitive merge information.  But does this
mean that the value it is set to is still correct?  (That is, need not be
transitive but at least define exactly what revisions from what branch have
been merged on this branch.)

Also, has the patch been accepted into svnmerge.py or is there a place where I
can get svnmerge.py with your patch to take this out for a spin?


Auke

 1. http://www.orcaware.com/pipermail/svnmerge/2006-December/000790.html

[Raman Gupta]

Auke Jilderda wrote:
> On Wednesday 14 February 2007 09:56, Raman Gupta wrote:
>> What do you mean exactly by "across more than two branches"?
>
> I mean the way as in the use case  as I described in a recent post [1]: When
> you copy a change set from branch A to B and then from B to C, the latter
> copy will generate a conflict on the property used for merge tracking. This
> is because svnmerge.py uses the same key for that versioned property on every
> branch.

For this use case, my patch should resolve the issue you are having
with property conflicts, without any loss of information:

http://article.gmane.org/gmane.comp.version-control.subversion.svnmerge.devel/309/match=svnmerge+spurious

(The post doesn't seem to be in the orcaware archives for some reason).

>> Option d) should really be implemented in addition to the existing
>> option a) and this could maybe somewhat support transitive merging (at
>> least better than currently). I don't even think it would be that
>> complicated to merge the property manually with a little bit of
>> python-fu i.e. svnmerge.py would use the information on both branches
>> to explicitly set the property after the merge, whilst ignoring any
>> merges/conflicts produced by svn's merge algorithm by reverting the
>> property merge.
>
> Yes, that would solve the issue.

My patch is a MUCH simpler solution that I'm pretty sure also resolves
your issue. See below for my description of the use case for which we
would need to implement the above option.

>> Though I'd still like to see a good use case for transitive merging --
>> I looked through the PDF you sent and I don't think the scenario it
>> describes is a transitive merging use case -- in fact I think its
>> pretty vanilla uni-directional merging from older branches to newer
>> branches. Your summary was this:
>>>     Summarising, this is a strictly linear merging model of forward
>>>     propagating fixes.  The transitive merge information is needed to be
>>>     able to verify that fixes have been propagated to all subsequent
>>>     releases.
>
> Um, how do you define "transitive merging"?

I think I see the confusion. My definition of transitive merging
supports this use case:

- There exists branch A, B, and C, and functionality F1, F2, F3
- A merge of F1 and F2 occurs from branch A to B
- A merge of F1 and F2 occurs from branch A to C
- A merge of F1, F2, and F3 occurs from branch B to C
    - F1 and F2 are ignored, and F3 is merged

I think you are defining transitive merging this way:

- There exists branch A, B, and C, and functionality F1, F2
- A merge of F1 and F2 occurs from A to B
- A merge of F1 and F2 occurs from B to C

To me, the above is certainly "transitive", but it reduces to simple
uni-directional merging for each branch pair -- branch C does not have
to be aware of the existence of branch A in any way. The patch I
submitted should allow the above case without any property conflicts,
and without losing any information relating to each branch pair. It
will NOT, however, allow the situation I defined as transitive merging
without further work to implement what you described as option d).

Does that clear things up?

> To be able to use svnmerge.py, we need to be able to merge from A to B, from B
> to C, and so on.  Transitive merge information would be nice to have but not
> essential.
>
>> I would set up a script that executes svnmerge.py avail on each branch
>> going forward in time with the prior older branch as the -S (source)
>> argument, and aggregates the result into some sort of consolidated
>> report of available revisions to be forward propagated. This would
>> give you your verification in one command, without any transitive
>> support in svnmerge.py.
>>
>> Since svnmerge.py also supports bidirectional merging, you could even
>> support both forward and backwards propagating fixes simultaneously.
>>
>> However, transitive support might be useful in your scenario if you
>> wanted to support the occasional "skipping" of a branch with later
>> application of that skipped revision. In this case, it would be needed
>> so that when the skipped revision was applied later, svnmerge.py would
>> understand that it had already been merged into the next branch
>> forward in time.
>>
>> If you just want to merge across multiple branches without the
>> transitive information, svnmerge.py does this already. If my patch is
>> applied (the one that kicked off this round of discussion about
>> transitive merging), then it will even do so without conflicts in the
>> svnmerge-integrated property.
>
> Ah ok, I got slightly lost in the technical details earlier in this thread: to
> the best of my understanding, your patch would avoid the conflict on the
> versioned property but flushes transitive merge information.  But does this
> mean that the value it is set to is still correct?  (That is, need not be
> transitive but at least define exactly what revisions from what branch have
> been merged on this branch.)

Yes correct. The value it keeps will be correct. The "transitive"
information that is flushed will be unrelated to the branch pair being
merged. It is kind of bogus information in my opinion, since in the
A,B,C case above, branch C was never initialized for merging with A,
and so therefore any merge information from A to C doesn't really mean
anything (without proper implementation of Option d).

My patch, in the course of eliminating the property conflict, does
remove the merge information from C on A. However, in your use case,
it is enough to know which revs from B have been merged into C
(regardless of whether they originally came from A or not), and my
patch does not remove that.

> Also, has the patch been accepted into svnmerge.py or is there a place where I
> can get svnmerge.py with your patch to take this out for a spin?

No it has not yet been accepted. This thread is the discussion thread
for the patch, which started last October :-)  You can get the patch
from the URL above.

Cheers,
Raman

[Patrick Oor]

Raman Gupta wrote on 02/14/2007 07:10:39 PM:

> For this use case, my patch should resolve the issue you are having
> with property conflicts, without any loss of information:
>
> http://article.gmane.org/gmane.comp.version-control.subversion.
> svnmerge.devel/309/match=svnmerge+spurious

I have applied this patch and run a simple test. The result was OK:
indeed, the patch solves the simple transitive merging case described
below.

> I think you are defining transitive merging this way:
>
> - There exists branch A, B, and C, and functionality F1, F2
> - A merge of F1 and F2 occurs from A to B
> - A merge of F1 and F2 occurs from B to C
...
> > Also, has the patch been accepted into svnmerge.py or is there a
> place where I
> > can get svnmerge.py with your patch to take this out for a spin?
>
> No it has not yet been accepted. This thread is the discussion thread
> for the patch, which started last October :-)  You can get the patch
> from the URL above.

I hope the patch will be accepted soon. Is not there any expectation
of when this can happen? It is certainly a useful patch for us.

Take care,
--
Patrick Oor, C & S, Philips Medical Systems, Best, The Netherlands
e-mail: patrick.oor@..., phone: [phone]

[Auke Jilderda]

On Wednesday 14 February 2007 19:10, Raman Gupta wrote:
>
> For this use case, my patch should resolve the issue you are having
> with property conflicts, without any loss of information:
> ...

Excellent.

> I think I see the confusion.
> ...
> Does that clear things up?

Certainly, thanks.  Always good to make sure what exactly we're talking about.

> Yes correct. The value it keeps will be correct.
> ...

Yes, testing confirms this.

> ...
> My patch, in the course of eliminating the property conflict, does
> remove the merge information from C on A. However, in your use case,
> it is enough to know which revs from B have been merged into C
> (regardless of whether they originally came from A or not), and my
> patch does not remove that.

Understood.

Thanks for your help!  With your patch, we can move forward for our use case
until the 1.5 arrives which will probably address all of this.


Auke