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

RE: Inheritability of no_mergeinfo

From: Paul Burba <pburba_at_collab.net>
Date: 2007-11-27 17:18:17 CET

> -----Original Message-----
> From: dglasser@gmail.com [mailto:dglasser@gmail.com] On
> Behalf Of David Glasser
> Sent: Monday, November 26, 2007 10:55 PM
> To: Subversion Developers; Paul Burba
> Subject: Inheritability of no_mergeinfo
> Should the dummy "no_mergeinfo" variable in
> mergeinfo-sqlite-index.c have its inheritable flag TRUE or
> FALSE? I think it would be best to be explicit.

Seems it should be TRUE, since no_mergeinfo is used to represent
svn:mergeinfo of "", which, having no ranges, is inherently inheritable.
That said, I don't know that it matters right now what we set it to, I
can't see that we use it anywhere. FWIW I ran merge_tests.py and
merge_authz_tests.py over ra_svn using both TRUE and FALSE and it passed
both ways.

Really the question here is:

"Is there a case where we need empty mergeinfo* '' to have the concept
of inheritability?"

I suppose there is, if we reverse merge a range to a target that would
remove all mergeinfo from that target and the target has a child missing
due to an authz restriction that wasn't missing when the first merge was
performed. But this problem seems closely related to
http://subversion.tigris.org/issues/show_bug.cgi?id=2881 and that is
kinda dead in the water at the moment (at least as far as 1.5 is
concerned). So for now I feel safe in setting no_mergeinfo's
inheritability to TRUE and did that in r28068.

* Until issue #3029 "Prevent mergeinfo with paths mapped to empty
ranges" is resolved we could expand this question to include mergeinfo
with paths mapped to empty ranges, e.g. "/trunk:".

> --dave
> --
> David Glasser | glasser@davidglasser.net |
> http://www.davidglasser.net/

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 27 17:18:27 2007

This is an archived mail posted to the Subversion Dev mailing list.