You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andy Parkins <an...@leaseline.plus.com> on 2004/02/18 13:26:25 UTC
Unusual behaviour of "svn mv" on directories
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I posted the attached message to the issue tracking system and got a very kind
response from sussman@tigris.org who pointed out that I was in the wrong
place and that I should bring my query here. So here I am :-)
I've also attached further messages I sent to give context.
My question is: does "svn mv" of a directory alter the repository? If not -
why do I need to run "svn update" after "svn mv" of a directory?
Andy
- --
Andy Parkins
Technical Director email: andyp@leaseline.plus.com
Leaseline Systems Limited tel: +44 (0)151 652 5551
Unit 31, Price Street Business Centre fax: +44 (0)151 652 9983
Birkenhead, CH41 4JQ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAM2gBwQJ9gE9xL20RAsdRAJ473cOQDWXQwhlC9Mahd2JiKarbUQCfQDCF
FeY0Hj2TNuh5teEKUweNlE0=
=zODF
-----END PGP SIGNATURE-----
Re: Unusual behaviour of "svn mv" on directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-02-18 at 11:02, Andy Parkins wrote:
> > Yes there is, run 'svn st -v'. Look at the local revnums. :-)
>
> This really is marvellous fun :-) You are quite right (of course).. and I
> accept fully what you say. I think my only remaining quibble, then, is that
> the output of "svn update" didn't tell me that it had deleted my local
> revision 1 of dir A.
'svn up' didn't delete anything in your scenario. All it did was bump
every local revnum to HEAD, even if there were no actual changes to
apply. And that's enough to allow the schedule-deletion of A to be
accepted when you commit.
> What a tough time you guys have.
Versioning directories is hard. Let's go shopping.
> Sterling work though. Your responses and
> work are all very much appreciated.
Cheers!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unusual behaviour of "svn mv" on directories
Posted by Andy Parkins <an...@leaseline.plus.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 18 February 2004 16:39, Ben Collins-Sussman wrote:
> > There is no difference between the two "svn status" outputs.
>
> Yes there is, run 'svn st -v'. Look at the local revnums. :-)
This really is marvellous fun :-) You are quite right (of course).. and I
accept fully what you say. I think my only remaining quibble, then, is that
the output of "svn update" didn't tell me that it had deleted my local
revision 1 of dir A. Thinking about it however, it is probably very
difficult to implement that, as it doesn't fit into any of the categories
shown in "svn status --help".
What a tough time you guys have. Sterling work though. Your responses and
work are all very much appreciated.
Andy
- --
Andy Parkins
Technical Director email: andyp@leaseline.plus.com
Leaseline Systems Limited tel: +44 (0)151 652 5551
Unit 31, Price Street Business Centre fax: +44 (0)151 652 9983
Birkenhead, CH41 4JQ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAM5qrwQJ9gE9xL20RAlWhAKDUOq1c72/wwdFXhQdNLfEJCCkrDQCfZTOD
pvVk25dZzmRUBSTNMueh02M=
=kXlG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unusual behaviour of "svn mv" on directories
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-02-18 at 10:16, Andy Parkins wrote:
> Compare:
> $ svn mkdir A; svn commit -m ""
Your working copy is still at local rev 0, and A is at local rev 1.
> $ svn mv A B; svn commit -m ""
This creates revision 2. After the commit, B is at local rev 2. The
reason you were allowed to remove A is because at the time of the
commit, it was at local rev 1, which was equal to HEAD.
> with:
> $ svn mkdir A; svn commit -m ""
Again, A is now at local rev 1.
> $ touch A/versionedfile; svn add A/versionedfile; svn commit -m ""
And now you've created revision 2. But in your working copy, A is still
at local rev 1, and versionedfile is at local rev 2.
> $ svn mv A B; svn commit -m ""
This will fail, because you're trying to delete A, and your local rev of
A is no longer equal to HEAD.
> There is no difference between the two "svn status" outputs.
Yes there is, run 'svn st -v'. Look at the local revnums. :-)
> My bug report/feature request is therefore: whatever "svn update" is doing
> (which in this case is not its stated function of bringing the local copy up
> to date with the repository); can "svn mv"/"svn rm" not do that as well?
No, because after a commit completes, svn only bumps the local revisions
of things that actually got committed. In your second case, only
'versionedfile' gets bumped to local rev 2, not its parent directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unusual behaviour of "svn mv" on directories
Posted by Andy Parkins <an...@leaseline.plus.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 18 February 2004 15:42, Ben Collins-Sussman wrote:
> Instead, 'svn mv A B' is *exactly* the same as if you had run 'svn cp A
> B; svn rm A'. When you do this in the working copy, you get a double
> scheduling: B is new, scheduled for addition-with-history, and A is
> scheduled for deletion. When you commit, the exact same thing happens
> in the repository: B is created as a new object, copied from A, and
> then A is deleted.
AH HA! Got it now. Thank you.
> So what you're seeing in your recipe is a failure when you attempt to
> commit the deletion of A. In your case, A is an out-of-date directory.
>
> Hope this makes things clearer.
It does indeed. Unfortunately it brings me back to a variation on my original
bug report (which was wrong):
Compare:
$ svn mkdir A; svn commit -m ""
$ svn mv A B; svn commit -m ""
with:
$ svn mkdir A; svn commit -m ""
$ touch A/versionedfile; svn add A/versionedfile; svn commit -m ""
$ svn mv A B; svn commit -m ""
The second case fails with:
Deleting A
svn: Commit failed (details follow):
svn: Out of date: 'A' in transaction '3'
It can be made to complete however, with:
$ svn status
D A
D A/versionedfile
A + B
$ svn update
At revision 2.
$ svn status
D A
D A/versionedfile
A + B
$ svn commit -m ""
There is no difference between the two "svn status" outputs. "svn update"
reported no changes. Yet, after "svn update" the A directory is gone (good)
and so the svn commit can complete.
My bug report/feature request is therefore: whatever "svn update" is doing
(which in this case is not its stated function of bringing the local copy up
to date with the repository); can "svn mv"/"svn rm" not do that as well?
This only shows up for directories. Files behave as expected "svn mv A B"
when A and B are files, leaves the local copy with no A.
Andy
- --
Andy Parkins
Technical Director email: andyp@leaseline.plus.com
Leaseline Systems Limited tel: +44 (0)151 652 5551
Unit 31, Price Street Business Centre fax: +44 (0)151 652 9983
Birkenhead, CH41 4JQ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAM4/hwQJ9gE9xL20RAjGiAJ9ujj17xGL7BDlySoS18NcMMYcAnACeJJAV
D4tuUYV1vkhkJn/zZFd0UgI=
=mBjH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unusual behaviour of "svn mv" on directories
Posted by Ben Collins-Sussman <su...@collab.net>.
Andy Parkins wrote:
> My question is: does "svn mv" of a directory alter the repository? If not -
> why do I need to run "svn update" after "svn mv" of a directory?
And here's a clear answer to your question: neither the Subversion
repository nor the Subversion working-copy have an "atomic move", which
is what you're expecting.
Instead, 'svn mv A B' is *exactly* the same as if you had run 'svn cp A
B; svn rm A'. When you do this in the working copy, you get a double
scheduling: B is new, scheduled for addition-with-history, and A is
scheduled for deletion. When you commit, the exact same thing happens
in the repository: B is created as a new object, copied from A, and
then A is deleted.
So what you're seeing in your recipe is a failure when you attempt to
commit the deletion of A. In your case, A is an out-of-date directory.
Hope this makes things clearer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org