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.
> > > If such a merge happened to be committed by accident I don't think
> > > anyone would enjoy cleaning up the resulting mess.
> >
> > Again, the same mess that has always existed. Except now there is
> > explicit mergeinfo on the switched subtree that tells us exactly what
> > we need to reverse merge to revert the accidental(?) changes. I see
> > this as an improvement in the situation.
>
> See questions above.
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-01 16:18:04 CEST