[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Unusual behaviour of "svn mv" on directories

From: Andy Parkins <andyp_at_leaseline.plus.com>
Date: 2004-02-18 14:26:25 CET

-----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-----

attached mail follows:


http://subversion.tigris.org/issues/show_bug.cgi?id=1748

User sussman changed the following:

                  What |Old value |New value
================================================================================
                    Status|NEW |RESOLVED
--------------------------------------------------------------------------------
                Resolution| |INVALID
--------------------------------------------------------------------------------

------- Additional comments from sussman@tigris.org Tue Feb 17 12:41:46 -0800 2004 -------
Sorry, I don't understand your analysis at all.

First, the reason the commit failed has *nothing* to do with unversioned files.
 It's failing because a directory is out of date: you're trying to commit the
deletion of dir1, but dir1 isn't at the latest revision. That's one of the main
rules of versioned directories in svn: "you can't delete an item which is out
of date."

Second, the unversioned file *did* get copied into renameddir1. I just tried
your script, and after the failed commit, 'svn status' shows:

? testsvn/hooks
? testsvn/conf
? testsvn/db
? testsvn/format
? testsvn/dav
? testsvn/locks
? testsvn/README.txt
D testsvn/dir1
D testsvn/dir1/file1
? testsvn/renameddir1/nonversionedfile
A + testsvn/renameddir1
D + testsvn/renameddir1/file1
A + testsvn/renameddir1/renamedfile1

(As a side note: your script is a bit odd. It's creating a working copy within
the repository! Not a very good thing to do.)

Notice that everything is scheduled as it should be. I don't see anything wrong
here.

I'm closing this issue not because we don't want to help, but because this is
the wrong forum for figuring out whether there's a problem. We don't use the
issuetracker for this purpose. Please bring your problem to the users@ list for
discussion. If, after some discussion, developers are persuaded that you've
found a real bug, we'll ask you to open a specific issue about it. Thanks!

attached mail follows:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 17 February 2004 20:41, sussman@tigris.org wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=1748

[lots of good stuff removed for brevity]

> (As a side note: your script is a bit odd. It's creating a working copy
> within the repository! Not a very good thing to do.)

I don't think it is; i intended that the script be run from some directory
other than the repository. The script ensures it's being run from it's own
base directory with the "cd `dirname $0`" at the beginning.

> I'm closing this issue not because we don't want to help, but because this
> is the wrong forum for figuring out whether there's a problem. We don't

My apologies. I was assuming that the bug tracking here was similar to
mozilla/kde etc; I was also assuming (it seems incorrectly) that I'd actually
found a bug :-)

> use the issuetracker for this purpose. Please bring your problem to the
> users@ list for discussion. If, after some discussion, developers are
> persuaded that you've found a real bug, we'll ask you to open a specific
> issue about it. Thanks!

Will do, thanks for your help.

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)

iD8DBQFAMz3RwQJ9gE9xL20RArPjAKCdegPbGJ1MfznS2O4JusU7D9UlDACffUYj
EUZ6yzr5t1DQxua6WKemjUg=
=4lmM
-----END PGP SIGNATURE-----

attached mail follows:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 17 February 2004 20:41, sussman@tigris.org wrote:

I think I have figured out my problem (in case you are interested :-))

> First, the reason the commit failed has *nothing* to do with unversioned

True.

> files. It's failing because a directory is out of date: you're trying to

True.

> commit the deletion of dir1, but dir1 isn't at the latest revision. That's
> one of the main rules of versioned directories in svn: "you can't delete
> an item which is out of date."

I did know that rule. However, I think the problem is my assumption that an
"svn mv" on a diretories doesn't modify the repository.

When one "svn mv"s a file, the local copy is up to date (the file has moved
and the original is gone), when one "svn mv"s a directory the local copy is
not up to date - the original named directory remains. This strikes me as
odd as the paths given to svn mv are local copy paths not repository paths,
so it's unusual that my local copy is now out of date (especially as no
commit has taken place).

i.e. The general sequence
 * checkout (local copy := repository HEAD)
 * modify local copy (repository unchanged of course)
 * commit (repository brought up to date with local copy)
Is untrue when the modify local copy operation is the renaming of a directory.

I think I will put the problem down to a quirk of svn. Files and directories
are different. Maybe it's worth putting a warning to that effect after an
svn mv of a directory? "Warning: you must run svn update to bring your local
copy up to date"

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)

iD8DBQFAM2TUwQJ9gE9xL20RAgEjAJ9QM1qmvWXsF5ulUAemRr+93CjsOQCgqZvy
h0dWMq+OvtaGRYBTysqwnKs=
=VZNQ
-----END PGP SIGNATURE-----

attached mail follows:


http://subversion.tigris.org/issues/show_bug.cgi?id=1748
                  Issue #:|1748
                  Summary:|Non-versioned resources should move when directories
                          |are renamed
                Component:|subversion
                  Version:|current
                 Platform:|All
                      URL:|
               OS/Version:|All
                   Status:|NEW
        Status whiteboard:|
                 Keywords:|
               Resolution:|
               Issue type:|DEFECT
                 Priority:|P3
             Subcomponent:|cmdline client
              Assigned to:|issues@subversion
              Reported by:|andyp

------- Additional comments from andyp@tigris.org Mon Feb 16 05:32:54 -0800 2004 -------
To explain: run the script below. The error generated is
 
svn: Commit failed (details follow):
svn: Out of date: 'dir1' in transaction '3'
 
I can see why it failed, the non-versioned file remains in its original
location (dir1/nonversionedfile); in an ideal world the non-versioned files
would have moved when the directory was renamed. However at the very least,
the ".svn" directory should have been removed from dir1, if it is truely meant
to be ignored by svn. The problem is that dir1 is left being neither
versioned or not versioned.
 
Even if svn is not going to move the non-versioned files, the least it can do
is leave the directory so that a simple copy (e.g. cp -a dir1/* renameddir1/*)
will not do any damage (i.e. by overwriting the .svn directory in the target)
 
#!/bin/sh
 
REPOS="$HOME/subversion"
 
cd `dirname $0`
pwd
 
echo "Creating repository $REPOS/testsvn"
svnadmin create $REPOS/testsvn
svn co file://$REPOS/testsvn testsvn
cd testsvn
 
echo "Creating a test directory structure..."
svn mkdir dir1
touch dir1/file1; svn add dir1/file1
 
# non-versioned
touch dir1/nonversionedfile
 
echo "Commiting initial dir structure"
svn commit -m "Initial test dir structure created"
 
echo "Altering file1"
date > dir1/file1
svn commit -m "Modified file1"
 
echo "Renaming file1, dir1"
svn mv dir1/file1 dir1/renamedfile1
svn mv dir1 renameddir1 --force
svn commit -m "Renamed file1, dir1"
 
tree -a -L 2
 
# Clean up
echo "Cleaning up. Removing local copy and repository."
cd ..
rm -rf testsvn/
rm -rf $REPOS/testsvn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 18 14:27:18 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.