On Mon, May 05, 2008 at 01:01:48PM -0400, Paul Burba wrote:
> 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...
Heh, it took me a while to figure out what this thread had been
about :)
Also, glad you bumped it a second time, somehow I didn't notice the
mail you sent on 1st of May.
> > > 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.
Agreed.
> > > 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.
Yes, it's the same core problem, of course.
> > > 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"?
Yes.
> > I'm not 100% sure what you mean here, is this following about right?
Your description matches the scenario I had in mind.
> > ...this is how it's *supposed* to work.
Nice, I really like it!
> > 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.
Doh!
I know you (and others) have been working very hard on making this work.
Respect. Getting this to work properly is really not trivial.
> 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.
Sounds great. Too bad it didn't get enough votes, if I hadn't overlooked
this I probably would have at least tried to vote :/
Well, it's such a corner case that mainly affects crazy people who
switch their working copies all over the place, so we can also fix this
properly in 1.5.1, I guess. (*whisper* Let's get 1.5 out already,
please.)
Thanks for taking the time to answer my questions, you just really
helped me understand merge tracking a bit better :)
--
Stefan Sperling http://stsp.name | PGP: 0xF59D25F0
Work: elego Software Solutions GmbH - www.elego.de
Gustav-Meyer-Allee 25, 13355 Berlin, Germany
Geschäftsführer Olaf Wagner, HRB 77719
- application/pgp-signature attachment: stored
Received on 2008-05-06 10:28:18 CEST