On Thu, May 1, 2008 at 10:17 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Wed, Mar 26, 2008 at 11:56 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Wed, Mar 26, 2008 at 11:05:29AM -0400, Paul Burba wrote:
> > > Are we also going to require --force to merge into a shallow WC? To
> > > merge when some part of the source and/or destination is inaccessible
> > > due to authz restrictions? If we do it for switched subtrees we
> > > should probably also do it in those other cases (not an objection,
> > > just an observation).
> >
> > This is a good point. I agree that the behaviour of merge should
> > be somewhat consistent across corner cases like this.
>
> Hi Stefan,
>
> I was combing over my TODOs that were put off until a 1.5 RC was out
> and realized I owe you a reply on this...
>
>
> > > > Because I can't really see this being useful except for confusing people
> > > > who want to track which changeset (a.k.a. revision) has been applied
> > > > to which branch, since they might end up finding parts of the change
> > > > set on one branch and other parts of the changeset on another branch.
> > >
> > > Again, as has always happened without ending civilization as we know it ;-)
> >
> > Also true. Maybe the question is how much guidance towards best
> > practices Subversion should provide vs. how much flexibilty it
> > should provide as a tool, with the potential of causing harm if
> > used incorrectly?
>
> I agree that it is helpful for Subversion to gently encourage best
> practices, but I don't think is a case where it is warranted. If a
> user is merging to a target with switched subtree's then isn't it safe
> to assume they switched those subtrees for a reason? I'm not
> convinced this is a situation that someone is likely to accidentally
> find themselves in by accident.
>
>
> > > > And let's not even start thinking about someone merging a changeset
> > > > into a working copy with more than one of its directories all being
> > > > switched to entirely different branches -- that's insanity.
> > >
> > > Wait, what is insane, that someone might have a reason to do this? Or
> > > that we allow it without --force? If the latter, then how exactly is
> > > merging to a target with 2+ switched subtrees significantly more
> > > insane that a target with 1 switched subtree?
> >
> > I assumed you would have to look at 2+ mergeinfo properties on
> > 2+ branches to sort out for which paths the merged revision was
> > applied on which branch, and for which it wasn't.
>
> Yes, but that seems only a marginal increase in difficulty over the 1
> switched child case. I mean once you unwittingly (?) merge to a
> target with switched subtree(s), commit that merge, then decide you
> want to "clean up the resulting mess"...isn't the basic problem the
> same regardless of how many subtrees were swtiched? More switched
> subtrees is more work yes, but I don't see how it is fundamentally
> more problematic than just one.
>
>
> > But there may be a better way to deal with this, without having
> > to manually reconstruct what merges did actually happen. I don't
> > have that much experience with the merge-tracking functionality yet.
> >
> > How would you resolve such a crazy merge situation, if your goal
> > was to make sure that the merged revision was applied consistently
> > across all the branches
>
> By "branches" do you mean "switched subtrees"?
>
>
> > affected by the merge?
> > Simply repeat the merge from the root directory of all branches?
>
> I'm not 100% sure what you mean here, is this following about right?
>
> 1) Merge -rX:Y SOURCEURL to wc target BRANCH (for simplicity let's say
> BRANCH has no explicit or inheritable mergeinfo at the start).
>
> 2) BRANCH has switched subtrees SST1, SST2, SST3.
>
> 3) Don't bother doing a diff, or stat, or pg svn:mergeinfo or anything
> that would alert us to the fact that a lot of mergeinfo has been
> created, just commit.
>
> 4) Oops! Didn't realize that BRANCH had switched subtrees! SST1,
> SST2, and SST3's immediate working copy parents have explicit
> mergeinfo with non-inheritable ranges describing X:Y. SST1, SST2, and
> SST3 also have explicit mergeinfo describing X:Y (without any
> non-inheritable ranges) as do any siblings of the switched subtrees.
> So the merge hasn't been fully applied to BRANCH, but this is actually
> what we wanted. How do we fix this?
>
> If this is what you mean, then your suggestion to repeat the merge is
> correct, but it only need be repeated once:
>
> 1) Either unswitch SST1, SST2, and SST3 or just checkout a new working
> copy BRANCH
>
> 2) Repeat the merge of -rX:Y SOURCEURL to BRANCH. The now present
> subtrees will be merged to, the rest of the merge is not repeated.
> The non-inheritable ranges in the explicit mergeinfo on the subtrees
> parents is now inheritable, so elides to BRANCH, leaving us with
> mergeinfo only on BRANCH...
>
> ...this is how it's *supposed* to work. Of course it's broken and the
> reverse merge doesn't work and to add insult to injury the resulting
> mergeinfo (there should be none in this example) is incorrect :-(
> I've added issue #3187 which has a detailed example. Working on a fix
> right now.
>
>
> > How would you resolve such a crazy merge situation, if your goal
> > was to make sure that the merged revision was applied to only one
> > of the branches?
>
> Not exactly sure what you mean here, could you elaborate a little? Do
> we want to merge a revision to only one of the switched subtrees? If
> that is what you mean then we should just target that subtree directly
> with the merge no?
>
>
> > Simply merge the reverse diff of the merged rev
> > from the root directory of all branches, and merge the rev again
> > into the root directory of the desired branch?
> >
> > Will merge-tracking handle the two cases above gracefully without
> > further manual work? If so, requiring --force is indeed a bit
> > overkill, since it is easy to recover from accidental merges.
>
> Once issue #3187 is fixed and backported it should.
Hi Stefan,
A quick update:
Issue #3187 was fixed and backported and is part of 1.5.0 RC5. There
was also a second problem (issue #3188) where mergeinfo on the
switched subtrees was not eliding to the repository. This was fixed
on trunk but unfortunately didn't get enough votes to make it into
1.5.0 RC5. What does this mean for 1.5.0 RC5? Basically, if you
accidentally merge to a target with switched subtrees and immediately
reverse the merge, then the mergeinfo is correct, but you might end up
with explicit mergeinfo on the switched subtrees that wasn't there
prior to the first merge.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-05 19:02:07 CEST