Read a little more carefully. User 1 made no modifications to the file.
User 1 just deleted a file using the 'svn delete' command. Then user 1
did an 'svn update' and the file magically appeared (I see no use for
this behavior). Then User 1 did a commit which leaves the un-modified
file hanging around as an un-versioned file.
As far as the changing just the properties goes. I don't know how to
recover from a situation where every command I type tells me to run 'svn
cleanup' but when I do, it fails. So, I just delete the entire working
copy and start over.
Brian
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
> Sent: Monday, October 01, 2007 6:37 PM
> To: Brian Erickson
> Cc: Srilakshmanan, Lakshman; Matt Sickler;
> users@subversion.tigris.org; John Gourlay
> Subject: Re: Svn update failed
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 2 13:23:41 2007