On Thu, Aug 13, 2009 at 7:24 PM, Julian Foad <firstname.lastname@example.org>
Hi Bill. Thanks for the thought input...
On Thu, 2009-08-13, Bill Tutt wrote:
> Move, you mentioned move. You're giving me a headache flashback.
> 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)
which swaps a.cs with b.cs, and is equivalent to (and let's say the
> or the substantially less annoying and fairly simple dependant rename
> mv a.cs temp.cs
> mv b.cs a.cs
> mv temp.cs b.cs
current revision is 3)
copy <URL of a.cs>@3 b.cs
copy <URL of b.cs>@3 a.cs
<parsing double-negatives>... <done>
> Both of the above cases also suffer from the problem of needing to
> disallow not including all of the pending moves in a submission.
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:
a.cs is replaced with a copy of b.cs@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:
a.cs is unaffected
b.cs is replaced with a copy of a.cs@3
The WC remembered that b.cs should be a copy of a.cs@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@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.
Yes, but that's true of any kind of partial commit where you make WC
> (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.
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.