Mikkel Kirkgaard Nielsen wrote:
> Lübbe Onken <l.onken <at> rac.de> writes:
>
>> the files that are causing trouble are files which are created by the
>> compiler. It may be that the compiler generated files are detected as
>> 'missing' at some point, because they are deleted and overwritten.
>
> But still TSVN/SVN shouldn't autonomously detect and react on such a change. I
> would expect to be able to do just anything with the WC files and then be able
> to do a commit/status without any issues comparing/commiting the changes since
> the last update.
That depends. Some changes are too severe for Subversion to recover from
(if e.g. something changed inside an .svn dir - that's Subversions
private area where no one else has business).
If you e.g. delete 'file' in a working copy, then add another file as
'File', then for Subversion that means that 'file' is missing, and
'File' is new. You see, Subversion is case-sensitive, while the windows
file system is not.
>> TortoiseSVN also tries to fix/prevent upper/lowercase filename changes on
>> the client side, which the CL client doesn't. Perhaps its a combination of
>> the two.
>
> Hm, ok, when and how? Does it revert obvius renames back to rep name? Or move
> to the new name of WC?
It does so when you start the commit dialog. Just before you see the
list of changed files. The correction is done by checking any 'missing'
files (files that Subversion has versioned, but are not found on disk)
and checking if there's a file with the same name but different in case
(e.g. file and FILE). It then corrects the case of the filename back to
what Subversion has under version control.
>> If I understand you correctly, your repository is intact, only the working
>> copy is FUBAR? So you should be able to check out and do this again? Without
>> a reproduction recipe we probably can't help you much.
>
> Yeps, everything was okay in repository. Only the WC in which some changes were
*was* ok? Does that mean it isn't anymore?
> made had gone bad, and as mentioned we could do a new checkout and commit
> without any problems. I can see that the my co-worker experiencing this had
> done a server side delete of some of the temp files ~, .obj, .tds with the same
> basename, after the WC had been last updated, maybe that could trigger
> something.
That could only affect Subversion, if one or more of those files were in
use when you did the update. Subversion tries to delete such files on an
update (they're deleted in the repository, so it has to be deleted in
the working copy too). If those files are locked by other apps, it can't
delete them cleanly. But I think even then you'll just get an error and
it shouldn't corrupt the working copy.
>> Did you rename any files/folders in the path without committing the rename,
>> before the WC was corrupted?
>
> As far as I have been told no renaming had been done in the WC prior to these
> corruptions.
Did you merge some changes from another branch? There's an issue in the
Subversion issuetracker where a merge can corrupt a working copy under
some very special circumstances.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon May 22 18:33:27 2006