On Wed, Mar 26, 2008 at 10:00 AM, Stefan Sperling <stsp_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-26 16:17:16 CET