[cross-posted from users@]
>>> jrepenning@collab.net 07/25/03 01:32PM >>>
>Well, I think I'd start by checking out a fresh, new working copy,
>and see what sort of state it's in. Then you can make your changes
>as necessary. The problems here seem to be limited to the particular
>WC.
>
>But you've still got the more fundamental problem: it's not working
>to "self-commit" a script if it has keywords to expand. I don't
>think that's going to go away. Checking to see whether the file's
>writable might be done, but it would only allow SVN to refuse the
>checkin, which ain't necessarily what you had in mind!
Ok - I'm back in business. The trick was "fresh working copy." I checked out a new WC from the repository to another directory. The daily.sh in the WC was the HEAD version of the script, but the .svn/text-base version (of the new WC) matched the checksum that the 1st WC expected in the .svn/entries file. I copied text-base/daily.sh.svn-base from the new WC to the same location in the old WC, and tried the commit. Worked just fine.
=== Problem Recap
1 - I have a shell script that I use to back up a bunch of different working copies to my repository at the end of the day
2 - This script had the $Id$ keyword tag embedded in a comment
3 - After setting svn propset svn:keywords "Id" on the script I called it to commit itself to the repository.
4 - svn committed the script to the repository (the new WC has the expanded $Id$ tag embedded)
5 - After the commit succeeded, svn changed the .svn/entries file to have the checksum information for the checked-in version of the script (which has the $Id$ tag, though not expanded since the repository stores the tag info in the props)
6 - Then svn tried to replace the current WC version with the repository version + expanded tag - **this failed** (script was in use at the time and could not be overwritten - but this was not the real problem)
7 - svn failed, notified the bonehead user, and quit
8 - svn never copied the repository version to .svn/text-base, but left the prior version of the script (now revision HEAD - 2) THIS was the real problem - the .svn/entries file had the checksum for the HEAD - 1 copy, but .svn/text-base had the version of the file prior to that on the drive
=== A Fix that Worked but will Probably Give Jack Heartburn
9 - check out a new WC in another location
10 - copy the (repository version) file from .svn/text-base/ in the new WC to the .svn/text-base in the old WC
11 - check in the changed file in the old WC
12 - do the happy dance (all is now well)
=== Thoughts / Questions
- Another thing that might have worked (for svn) would be to "export" the version of the file that it thinks should be in text-base/ (HEAD -1) from the repository. That copy has the checksum that it is looking for from the entries file, but it doesn't tell the bonehead user why or how something went wrong
A - Should svn handle the move-previous-to-text-base before trying to do keyword expansion (since that might fail)?
B - Should svn cleanup be able to recognize / handle the situation when a checkin hasn't completed moving files around, and implement (or suggest) some strategy to get the .svn directory back in shape?
C - Attempting to obtain a write-lock on a file that will be updated (with keyword expansion, revert, or update) will change the "last-modified" date, even if no revisions are made, wont it?
C(1) - Even if the "last-modified" date changed when attempting a write-lock on a file, would this be a better indication that the keyword-expansion would succeed? (i.e., wouldn't svn have to hold that write lock through the whole commit process - not a great idea!)
D - Should this (ability to corrupt a WC this way) be added as an issue?
Ok - that's probably enough trouble stirred up for now... Thanks for all the great work on Subversion, everyone, and thanks for all the help Jack!
--Cedric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 25 21:54:51 2003