Commit failed when wc contains files not under version control

[Jennifer Kesterson <Je...@jpl.nasa.gov>]

Hi,

Yesterday, one of our users tried to rename (svn move) a directory in 
her working copy.  This directory contains several subdirectories.

When she ran 'svn status' at the start, it reported three files not 
yet under version control (an ? was in the first column of the status 
output).  She proceeded with 'svn move <old_dir_name> 
<new_dir_name>'.  The output shows that the new directory name is 
scheduled for addition, and that the old name and its contents are 
scheduled for deletion.  Strangely, it did not report that the 
contents are also scheduled for addition in the new directory.

Anyway, when she tried to commit, it failed:

	svn:  Item '<path_to_directory' is out of date


On a hunch, I suggested that she first add the unrecognized files not 
yet under version control to the repository, then try 'svn move' 
again.  When she did that, the commit was successful.

So, my question is:  Before a user renames a directory in the wc and 
commits, must all contents of the directory *always* be under version 
control?  Are there any other requirements necessary for this commit to work?

Thanks,
Jen


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Commit failed when wc contains files not under version control

[Bob Proulx <bo...@proulx.com>]

Jennifer Kesterson wrote:
> When she ran 'svn status' at the start, it reported three files not 
> yet under version control (an ? was in the first column of the status 
> output).

That will be a problem specifically because subversion will try really
hard not to lose any user data.  Because the old directory is going
away those files will have to go away too.  But since they are no
under version control this would mean a loss of user data.  Because
subversion is designed to avoid loss of data it complains.

> She proceeded with 'svn move <old_dir_name> <new_dir_name>'.  The
> output shows that the new directory name is scheduled for addition,
> and that the old name and its contents are scheduled for deletion.
> Strangely, it did not report that the contents are also scheduled
> for addition in the new directory.

Subversion does not know anything about those unversioned files listed
with a '?'.  They were not versioned in the old directory.  It
shouldn't add them automatically to the new directory.  Subversion
does not want to delete them.

> On a hunch, I suggested that she first add the unrecognized files not 
> yet under version control to the repository, then try 'svn move' 
> again.  When she did that, the commit was successful.

Alternatively you could have moved or removed those files so that svn
status was clean.  Then there should not have been any conflict.  If
you really want those files in the directory then they can be moved
back after the operation is complete.

> So, my question is:  Before a user renames a directory in the wc and 
> commits, must all contents of the directory *always* be under version 
> control?

I believe so yes.

> Are there any other requirements necessary for this commit to 
> work?

Not that I know about.  But just think about it from a possible loss
of user data point of view and I think you will agree that the
behavior makes sense.

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org