On Thu, Aug 13, 2009 at 7:24 PM, Julian Foad <julianfoad_at_btopenworld.com>wrote:
> On Thu, 2009-08-13, Bill Tutt wrote: > Move, you mentioned move. You're
> giving me a headache flashback.
>
>
> Hi Bill. Thanks for the thought input...
> > i.e. The directory heirarchy changing dependant case:
> > A\a.cs A\B\C\c.cs
> >
> > mv A\B B
> > mv A B\A
> >
> > This ends up with B\A\a.cs and B\C\c.cs.
> >
> > Regardless of whether not you can submit such a thing in one
> > changeset, a non-operational merge would need to deal with the
> > problem. (i.e. not allowing it in the general changeset case doesn't
> > prevent it from the non-operational merge case)
>
>
> Yes, OK...
> > or the substantially less annoying and fairly simple dependant rename
> > case:
> >
> > mv a.cs temp.cs
> > mv b.cs a.cs
> > mv temp.cs b.cs
>
>
> which swaps a.cs with b.cs, and is equivalent to (and let's say the current
> revision is 3)
>
> del a.cs
> del b.cs
> copy <URL of a.cs>@3 b.cs
> copy <URL of b.cs>@3 a.cs
>
>
> > Both of the above cases also suffer from the problem of needing to
> > disallow not including all of the pending moves in a submission.
>
>
> <parsing double-negatives>... <done>
>
To rephrase and clarify:
Dependant rename set: A set of rename operations that require the operations
to execute in a specific order in the WC so that all file contents end up
with the correct path and contents. There are three possible cases here:
File dependant rename example:
mv a.cs -> b.cs
mv b.cs -> a.cs
Directory dependant rename example:
mv A -> B
mv B -> A
Directory hierarchy changing rename example:
A\B\C are directories that contain files:
mv A\B -> B
mv A -> B\A
If Subversion did not allow the replace mechanism with these types of moves:
All of the pending moves in a dependent rename set that was NOT "Directory
hierarchy changing" would need to be submitted at the same time.
"Directory hierarchy changing" renames do not have to be submitted
simultaneously, however allowing them seems like a very bad idea when
balanced with a typical version control end user concept of: A given
changeset should always be buildalbe. You would be submitting a tree
structure that never actually occurred in the working copy. *shivers*
The code necessary to unwind only part of a "directory hierarchy changing"
rename when you have other pending renames in the same submission that
interact with the "directory hirarchy changing" rename isn't particulary
pretty or cheap. (It's that fun two pass rename algorthim dreamt up by the
author of arch.) I'd recommend only implementing that code for 'svn
revert'/''svn merge' if you ever write that code at all.
> In Subversion, currently, as you know, you are allowed to commit just
> one half of the moves. Let's examine what happens if you do. Note that
> the selection of what to include in the commit is done by path, not by
> "object identity". If in your latter case we choose to commit just
> "a.cs", the result would be:
>
> r4:
> a.cs is replaced with a copy of b.cs_at_3
> b.cs is unaffected
>
> I agree that there is a usability benefit in disallowing this partial
> commit, but I don't see that it causes any particularly bad or
> surprising result. You can still commit the other half (b.cs) later and
> get the intended end result:
>
r5:
> a.cs is unaffected
> b.cs is replaced with a copy of a.cs_at_3
>
> The WC remembered that b.cs should be a copy of a.cs_at_3. If instead it
> had remembered it as "a copy of head revision of a.cs", this second
> commit would be effectively a no-op because a.cs_at_HEAD was at this time
> already the same as b.cs, and that would not be the intended end result.
>
>
You're correct with replace only doing a paritial commit of the file
dependant rename set is fairly harmless. Odd and wrong, but fairly harmless.
> As part of "true renames" support, we will probably want to change the
> semantics of moves and copies to say "a copy of head revision of ..."
> rather than a specific revision number. Then we will have to watch out
> for this split commit, and probably disallow it.
>
Why would you ever want to say "a copy of head revision of ..."? You want to
generate conflicts appropriately when you make your submission. If
the file/directory was renamed behind your back you need to reverify the
user's desire to maintain the same destination path.
>
> > (Esp. of directories, but disallowing it entirely always seemed like a
> > good idea to me.) If you allow partial pending move submissions then
> > you're submitting a tree state you haven't built yet.
>
>
> Yes, but that's true of any kind of partial commit where you make WC modifications
> in one order and then commit the pieces in another order.
> You feel this is particularly bad in the case of splitting a move. I
> think we all agree it's worse and not a good idea, but I don't
> understand whether you have some special viewpoint that makes you feel
> it's so terrible or such a headache.
>
>
My big fear is users accidentally submitting a tree structure change that
wasn't the shape of their WC (for each dependant rename set) at time of
submission. That seems like a black hole of badness and its not particulary
hard to check for. i.e. If something is always a bad idea why not prevent
the user from accidently hanging themselves?
Not submitting all renames in a file dependant rename set is certainly odd,
but substantially less scary to me than not submitting all renames in a
directory dependant rename set.
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383695
Received on 2009-08-15 02:35:04 CEST