You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2008/03/26 15:05:29 UTC
Re: merging into partly switch working copies (was: Re: Merge where a target is missing - skip or tree conflict?)
On Wed, Mar 26, 2008 at 10:00 AM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Mar 25, 2008 at 07:03:43PM +0000, Julian Foad wrote:
> > For perhaps the most complex related behaviour, consider a switched
> > sub-tree in the WC. This is handled, I think, a bit like a missing target
> > within its parent directory in that the sub-tree that's not being touched
> > shall have this fact recorded with explicit mergeinfo. As well as that, the
> > changes to be merged into that sub-tree are made within the switched
> > location. Therefore all of the merge source is applied somewhere, but
> > different parts of it are applied within different destination branches. No
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > "skipped" notification is printed, so this isn't actually a case in
> > question.
>
> Wait a minute... Isn't this behaviour a tiny bit insane?
Hi Stefan,
Putting aside any judgments of sanity, keep in mind that Subversion
has *always* allowed this behavior when merging to a target with
switched subtrees. The only difference is that now we have mergeinfo
being set (and at least it is being set to reflect the changes made).
Again, maybe this should have been "fixed" a long time ago, but I
don't recall seeing a lot of people complaining. Possibly because the
user population merging into a situation like this is very small?
> Shouldn't we forbid merging into partly switched working copies
> altogether unless --force is present?
Does this really buy us that much?
"Ok, I can't merge to this target because I have switched subtrees.
Hmmm, I'm was always able to do that before. Oh, I need to use
--force now. Ok then, I'll use force, because I'm one of those insane
people who need to do this!"
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).
> 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 ;-)
> 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?
> 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.
> Please enlighten me if there is a legitimate use case that supports
> the described behaviour.
Heh, I have little idea why anyone would actually want to do
this...but I didn't take a survey.
> Otherwise I might end up filing an issue
> for this, because it scares me... IMHO stuff like this should require
> --force so people doing this are made aware that they should really
> know what they are doing.
I don't think requiring --force is really going to save them from themselves.
Now all my ranting aside, if enough folks think that --force (or some
other option) should have been required all along to permit a merge
into a target with switched subtrees, then let's do it. I'm just not
one of those people.
Paul
P.S. I think this whole topic gets to a larger issue that has been
bothering me. Specifically, do we want to make svn merge less
flexible than it has been in the past now that we have to deal with
svn:mergeinfo, e.g. make it more (restricted) like svnmerge.py or svn
merge --reintegrate. Or do we want to allow all the potentially
"insane" things we've allowed it to do in the past and DTRT within the
context an inheritable svn:mergeinfo property forces on us?
If I had a dollar for every time someone jokingly(?) said in IRC, "we
should only allow merges to the roots of branches, which are up to
date, with no local mods", then I'd be retired and skiing in Utah
right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merging into partly switch working copies (was: Re: Merge
where a target is missing - skip or tree conflict?)
Posted by Stefan Sperling <st...@elego.de>.
On Mon, May 05, 2008 at 01:01:48PM -0400, Paul Burba wrote:
> On Thu, May 1, 2008 at 10:17 AM, Paul Burba <pt...@gmail.com> wrote:
> > On Wed, Mar 26, 2008 at 11:56 AM, Stefan Sperling <st...@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
Re: merging into partly switch working copies (was: Re: Merge where a target is missing - skip or tree conflict?)
Posted by Paul Burba <pt...@gmail.com>.
On Thu, May 1, 2008 at 10:17 AM, Paul Burba <pt...@gmail.com> wrote:
> On Wed, Mar 26, 2008 at 11:56 AM, Stefan Sperling <st...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merging into partly switch working copies (was: Re: Merge where a target is missing - skip or tree conflict?)
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Mar 26, 2008 at 11:56 AM, Stefan Sperling <st...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: merging into partly switch working copies (was: Re: Merge
where a target is missing - skip or tree conflict?)
Posted by Stefan Sperling <st...@elego.de>.
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.
> > 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?
> > 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.
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 affected by the merge?
Simply repeat the merge from the root directory of all branches?
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? 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.
> > 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.
> > Please enlighten me if there is a legitimate use case that supports
> > the described behaviour.
>
> Heh, I have little idea why anyone would actually want to do
> this...but I didn't take a survey.
:)
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner