On Oct 1, 2007, at 06:52, Brian Erickson wrote:
> I had this problem with two different users. I just tried to
> encapsulate it here for illustration purposes.
>
> First, the file was not modified. Only it's properties.
>
> Second, I know exactly why svn can't find the file, I deleted it! So,
> the question is, why is subversion looking for a file that it knows
> has
> been deleted.
>
> Third, I would at least expect svn to behave consistently. If I
> run the
> test twice, I would expect to get the same answer. Anyway svn revert
> just says the working copy is locked and to run svn cleanup. Svn
> cleanup fails because it can't find a deleted file.
>
> FYI, if user 2 (junk2 folder) makes a modification to the file. Then,
> when user 1 (junk1 folder) does an update it works, and brings the
> file
> back. Finally, when user 1 (junk1 folder) commits, the file is deleted
> from subversion but not from the hard drive. User 1 is left with an
> unversioned file.
>
> At best, to a new user like me, this behavior is very confusing.
If a local file has modifications, but an svn update would delete
that file, then Subversion will instead change it to an unversioned
file when you update. Subversion deliberately will not delete local
files that have modifications. To do so would be to permanently
delete your unique work, which is something Subversion strives not to
do.
If you're saying the file contents was not in fact modified, but only
its properties, then maybe Subversion behavior could be changed here.
>> -----Original Message-----
>> From: Srilakshmanan, Lakshman
>> [mailto:lakshman.srilakshmanan@police.vic.gov.au]
>> Sent: Sunday, September 30, 2007 9:20 PM
>> To: Matt Sickler
>> Cc: Brian Erickson; users@subversion.tigris.org; John Gourlay
>> Subject: RE: Svn update failed
>>
>> I found the message helpful enough; with a little bit of
>> thought to the problem :)
>>
>> It would be next to impossible if not impossible for a tool
>> to contain every permutation, combination of the problem and
>> analyse an individuals issue and provide a detail description
>> on what caused the error.
>>
>> I believe this is called AI -- Artificial Intelligence and it
>> is still in its infancy :)
>>
>> -----Original Message-----
>> From: Matt Sickler [mailto:crazyfordynamite@gmail.com]
>> Sent: Monday, 1 October 2007 10:55 AM
>> To: Srilakshmanan, Lakshman
>> Cc: Brian Erickson; users@subversion.tigris.org; John Gourlay
>> Subject: Re: Svn update failed
>>
>> Exactly right, but this error message isnt very helpful
>> pointing that out.
>>
>> On 9/30/07, Srilakshmanan, Lakshman
>> <lakshman.srilakshmanan@police.vic.gov.au> wrote:
>>> Hi Brian,
>>>
>>> Firstly, when I get a message like "The system cannot find
>> the file
>>> specified." I would try to understand WHY ?
>>>
>>> I would run "svn status" and that would quickly show that
>> test.txt in
>>> junk1 is "scheduled" for a delete.
>>> I cannot commit this scheduled delete as it has already changed in
>>> Subversion. I would probably "svn revert" this file in junk1. "svn
>>> update" the file to bring it to the current revision. "svn
>> delete" the
>>
>>> file and then "svn commit" it.
>>>
>>> Allowing for a delete to be committed, when it is not the current
>>> revision is probably unwise.
>>>
>>> Thanks
>>> Lakshman
>>> -----Original Message-----
>>> From: Brian Erickson [mailto:erickson@BAUERCONTROLS.com]
>>> Sent: Friday, 28 September 2007 11:39 PM
>>> To: users@subversion.tigris.org
>>> Cc: John Gourlay
>>> Subject: Svn update failed
>>>
>>> If I execute the following (attached as a txt file):
>>> c:
>>> cd \
>>> md c:\junk1
>>> md c:\junk2
>>> svn co http://snidely/svn/test junk1
>>> svn co http://snidely/svn/test junk2
>>> cd junk1
>>> svn del test.txt
>>> cd \junk2
>>> svn propset svn:keywords Id test.txt
>>> svn -mkeywords commit
>>> cd \junk1
>>> svn update
>>>
>>> The svn update gives:
>>> U test.txt
>>> svn: In directory '.'
>>> svn: Error processing command 'set-timestamp' in '.'
>>> svn: Can't set access time of 'test.txt': The system cannot
>> find the
>>> file specified.
>>>
>>> Try to commit the delete and you get
>>> C:\junk1>svn commit
>>> svn: Working copy 'C:\junk1' locked
>>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
>>> details)
>>>
>>> Then clean up says:
>>> C:\junk1>svn cleanup
>>> svn: In directory '.'
>>> svn: Error processing command 'set-timestamp' in '.'
>>> svn: Can't set access time of 'test.txt': The system cannot
>> find the
>>> file specified.
>>>
>>> Now it gets weird...
>>> Delete the junk1 and junk2 folders and re-run the test.
>> All is well.
>>> Now, from the junk1 folder, commit the change. Then re-add the
>>> test.txt file and commit the add.
>>> Now, delete the junk1 and junk2 folders and start over.
>> The problem
>>> is back.
>>>
>>> Can anyone tell me what's going on?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 2 00:38:52 2007