> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: Friday, January 11, 2008 1:25 PM
> To: Paul Burba
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Mergeinfo and added paths
>
> Paul, did this train of thought arrive at any particularly
> interesting stations?
Mike,
Beyond the fact that inherited or explicit mergeinfo can describe merge
sources that don't actually exist, no, I haven't found any real problems
(e.g. cases where we can't merge, merge the wrong thing, don't merge
something we want to merge).
As I mentioned I did come across this
http://subversion.tigris.org/issues/show_bug.cgi?id=3067 while thinking
about the problem, but it's only vaguely related (and I have a simple
fix that covers the most likely cases where #3067 will occur anyhow).
After some more thought I think we simply have to live with this
situation given our existing impementation. Particularly as regards
inherited mergeinfo. If we merge -r3:10 to PATH, and some subtree gets
added under PATH in r7, it's not like we are going to add explicit
mergeinfo only for 7-10 to that subtree. We'd quickly be up to our
necks in explicit mergeinfo every time a subtree is added.
Even if we elected to solve only* the more offensive situation where a
path has explicit mergeinfo that refers to a non-existant source, there
are problems. Sure, we could tweak the mergeinfo to strip the offending
range(s), but once we do, that explicit mergeinfo is never going to
elide and over time we build up more an more explicit mergeinfo
(something I think most folks object to if recent IRC conversations are
any indication). Plus, to get an added path into such as state requires
quite a contrived setup, I'm not sure anyone is really going to face
this. And if they do, so what? As I said above, I can't find any
situations where anything breaks because of this.
* I find it really hard to justify addressing this second case while
ignoring the first. That would mean we are treating inherited mergeinfo
as fundamentally different from explict mergeinfo, and I don't see that
there is any real difference.
Paul
> Paul Burba wrote:
> > Hi All,
> >
> > Something occurred to me while working on some of our
> outstanding MT
> > issues this week that troubles me a bit. We (thanks to cmpilato's
> > merge source normalization code) go to significant effort to keep
> > mergeinfo normalized. For example, if path 'branch1/A/D/G/rho' has
> > mergeinfo of
> >
> > trunk/A/D/G/rho:4-7
> > branch2/A/D/G/rho:12
> >
> > then 'trunk/A/D/G/rho' and 'branch2/A/D/G/rho' both better
> well exist
> > at
> > r3-7 and r12 respectively.
> >
> > But when a merge adds subtrees we can end up with paths that either
> > inherit mergeinfo or have explicit mergeinfo with paths that don't
> > exist. Consider a standard greek tree with the following changes:
> >
> > r2 - Copy 'A' to 'A_COPY'
> > r3 - Text mod to 'A/D/H/psi'
> > r4 - Text mod to 'A/D/G/rho'
> > r5 - Text mod to 'A/B/E/beta'
> > r6 - Text mod to 'A/D/H/omega'
> > r7 - Add file 'A/D/H/nu'
> > r8 - Text mode to file 'A/D/H/nu'
> >
> > Now merge a range to 'A_COPY' that starts before 'nu' was added:
> >
> >> svn merge %url77%/A merge_tests-77\A_COPY -r2:8
> > --- Merging r3 through r8 into 'merge_tests-77\A_COPY':
> > U merge_tests-77\A_COPY\B\E\beta
> > U merge_tests-77\A_COPY\D\G\rho
> > A merge_tests-77\A_COPY\D\H\nu
> > U merge_tests-77\A_COPY\D\H\omega
> > U merge_tests-77\A_COPY\D\H\psi
> >
> >
> > We get the mergeinfo on A_COPY we expect. But now 'nu' is
> effectively
> > inheriting '/A/D/H/nu:3-8', even though 'A/D/H/nu' doesn't
> even exist
> > until r7.
> >
> >> svn pl -vR merge_tests-77
> > Properties on 'merge_tests-77\A_COPY':
> > svn:mergeinfo : /A:3-8
> >
> >
> > Now do a reverse merge targeted on 'A_COPY/D/H/nu'
> >
> >> svn merge %url77%/A/D/H/nu merge_tests-77\A_COPY\D\H\nu -c-8
> > --- Reverse-merging r8 into 'merge_tests-77\A_COPY\D\H\nu':
> > U merge_tests-77\A_COPY\D\H\nu
> >
> >
> > Now we get explicit mergeinfo on 'nu' that is again "misleading".
> >
> >> svn pl -vR merge_tests-77
> > Properties on 'merge_tests-77\A_COPY':
> > svn:mergeinfo : /A:3-8
> > Properties on 'merge_tests-77\A_COPY\D\H\nu':
> > svn:mergeinfo : /A/D/H/nu:3-7 <-- nu doesn't exist at r3-6
> >
> > Now to be clear, I haven't found any problems caused by
> this behavior
> > (though http://subversion.tigris.org/issues/show_bug.cgi?id=3067 is
> > tangentially related). I only wonder if this might cause
> us problems
> > in some scenarios on trunk or in the various 1.5 targeted
> branches we
> > are working on? Anyone thought about this particular issue much?
> >
> > Paul
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> > For additional commands, e-mail: dev-help_at_subversion.tigris.org
> >
>
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed
> Development On Demand
---------------------------------------------------------------------
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-11 20:10:43 CET