You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pavel Ivashkov <fu...@gmx.net> on 2007/03/30 21:15:48 UTC
Failed to update missing (!) added (A) files
Hello all,
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)?
--
Pavel mailto:fuurin@gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Failed to update missing (!) added (A) files
Posted by Pavel Ivashkov <fu...@gmx.net>.
Hello all,
Filed as issue #2767
http://subversion.tigris.org/issues/show_bug.cgi?id=2767
--
Pavel mailto:fuurin@gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re[2]: Failed to update missing (!) added (A) files
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 31, 2007, at 12:45, Pavel Ivashkov wrote:
> From the user's point of view there is an issue too, I think. When
> you open a folder and see missed (!) file, you would like to restore
> it. You can run 'svn up' to get latest version from repository or
> you can run 'svn revert' to restore base version. For sheduled files
> the former gives you the error in subject, and the latter just
> removes record from metadata, no file restored, not what user had
> expected.
Well, if you've scheduled a file for addition, then "svn revert"
undoes that scheduling. So that should be exactly what the user expects.
> You cannot tell from its status whether the missed file is
> in repository or only scheduled for addition.
That is however true. It may be worth considering whether there
should be a different status indication in this case (though I'm not
convinced there should be).
> I would like Subverstion developers to (eventually) clarify their
> position on this matter. The scheduled for addition files currently
> are not controlled, so in my opinion it is incorrect to treat them
> evenly with other controlled files when they get deleted in working
> copy. Either provide some sort of control, or modify indication
> (extend status information) and handle the error properly (provide
> distinguished error code and pretty message).
--
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
Re[2]: Failed to update missing (!) added (A) files
Posted by Pavel Ivashkov <fu...@gmx.net>.
Hello Eric,
>> > * 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)
ME> The real issue is that you can replace "manually delete" with any 3rd
ME> party tool that is not svn-metadata aware and likes to delete or move
ME> things around. There are all sorts of nasty things you get to run into
ME> in these scenarios.
You are right Eric, I got this issue while investigating for
integration of Subversion with another tool. So it is not the user
but the tool that misbehaves.
From the user's point of view there is an issue too, I think. When
you open a folder and see missed (!) file, you would like to restore
it. You can run 'svn up' to get latest version from repository or
you can run 'svn revert' to restore base version. For sheduled files
the former gives you the error in subject, and the latter just
removes record from metadata, no file restored, not what user had
expected. You cannot tell from its status whether the missed file is
in repository or only scheduled for addition.
I would like Subverstion developers to (eventually) clarify their
position on this matter. The scheduled for addition files currently
are not controlled, so in my opinion it is incorrect to treat them
evenly with other controlled files when they get deleted in working
copy. Either provide some sort of control, or modify indication
(extend status information) and handle the error properly (provide
distinguished error code and pretty message).
--
Pavel mailto:fuurin@gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re[2]: Failed to update missing (!) added (A) files
Posted by Pavel Ivashkov <fu...@gmx.net>.
Hello Jeff,
I think posting here description of the tool's behavior will not add
any useful information to this thread. I just want to repeat my
statement if you missed it: the scheduled for addition files
currently are not controlled. And I'm pointing here only to files,
not directories.
The issue arose because when you manually delete (A - scheduled for
addition) file, Subversion marks it in status missed (!). And
documentation (source code too) states that missed files _are
controlled_. Do you see the inconsistency here?
From here you get two issues when user tries to get back her missed
file: a) svn update, or b) svn revert - both lead to unexpected
behavior from Subversion in my opinion.
--
Pavel mailto:fuurin@gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Failed to update missing (!) added (A) files
Posted by "Miller, Eric" <Er...@amd.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007a@ryandesign.com]
> Subject: Re: Failed to update missing (!) added (A) files
>
> 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)
>
> I don't think I would consider this a bug; for me, this is a user
error.
I can somewhat agree here - update implies contacting the repository for
changes. You have not submitted any changes and therefore cannot
update.
There is still a bug here though. If you play around with the scenario
enough you'll find that the metadata still tracks the directory as
"added" even though it no longer exists. I forget the exact details,
but it can get in an annoying state.
The real issue is that you can replace "manually delete" with any 3rd
party tool that is not svn-metadata aware and likes to delete or move
things around. There are all sorts of nasty things you get to run into
in these scenarios.
FWIW I did file bugs against some of this behavior -
http://subversion.tigris.org/issues/show_bug.cgi?id=2737
http://subversion.tigris.org/issues/show_bug.cgi?id=2741
But they don't exactly match yours.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Failed to update missing (!) added (A) files
Posted by Ryan Schmidt <su...@ryandesign.com>.
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