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

Re: Mergeinfo inheritance and mixed-rev WCs revisited

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Fri, 25 Jan 2008 15:23:29 -0500

"Paul Burba" <ptburba_at_gmail.com> writes:
> In r28492 I made a change that prohibited inheritance across mixed-rev
> boundaries.

r28942 (I knew which one you meant, no worry).

> Karl questioned the sanity of this change here,
>
> Did you have a chance to think on this some more?
>
> I'm somewhat ambivalent about taking working revisions into account
> when doing mergeinfo inheritance. It is technically correct to do so
> AFAICT, but in practical terms it is a headache whenever we have
> mergeinfo anywhere other than branch roots. Worse I don't think
> preventing inheritance across a mixed-rev path solves anything but
> some far-out edge cases.
>
> Isn't the larger issue about inheritable properties in general? They
> are all fine and good in a WC with consistent working revisions. But
> the moment mixed-revisions enter the picture we have to choose between
> correctness and ease of use no?

I agree with everything you say. But I haven't had much chance to
think about it more, and I think it's okay to leave the code as it is
for the moment -- this is an easy thing to tweak later, and if worse
comes to worst and we have to ship with it too strict (and then relax
later) that's better than the reverse. (Though I'd like to reconsider
it before we ship.) In the meantime, you saw David Glasser's mail
about this, right?:

   http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=134441

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-25 21:42:59 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.