On Mar 30, 2007, at 16:15, Pavel Ivashkov wrote:
> I have a (probably P3) issue, need to confirm it before posting a
> bug.
>
> Steps to reproduce:
> * in any clean working copy
> * schedule a file (foo) for addition (now in status A added)
> * manually delete the file (now in status ! missing)
> * try to update the file (svn up foo)
>
> Error:
> svn: Can't copy '.svn\text-base\foo.svn-base' to '.svn\tmp
> \foo.tmp.tmp':
> The system cannot find the file specified.
>
> It seems that Subversion doesn't track the file after it have been
> scheduled for addition and relies on the user version.
>
> Checking the code for file status handling you can see
> svn_wc_status_missing: under v.c., but is missing
>
> So I guess, if this file is controlled then it has to be recoverable
> in this situation, i.e. the update command should restore the file
> in working copy.
>
> Is it a known behaviour, or there is already an issue in tracker (I
> cannot find such myself)?
I don't think I would consider this a bug; for me, this is a user error.
When you "svn add", you have not yet added the file, and it is not
yet under Subversion control; you have merely scheduled the file for
addition, scheduled it to be under Subversion control at the next
commit. Manually removing the file before you've committed,
therefore, is just like removing the file without having added it at
all -- it's gone. And revert doesn't work, because revert only works
on things which are in the repository, things which are under
Subversion control, which your added-but-not-committed file never was.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Mar 31 07:51:14 2007