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 <stsp_at_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
- application/pgp-signature attachment: stored
Received on 2008-03-26 16:55:41 CET