Re: How to backup a running script? and how to recover out-of-sync file?

At 2:52 PM -0500 7/25/03, Cedric Williams wrote:
>=== A Fix that Worked but will Probably Give Jack Heartburn

You got that right! But I'm glad you're back in business.

>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

Why not copy the changed file into the new WC, and check in and happy
dance, without the unauthorized brain surgery on the text base?

>A - Should svn handle the move-previous-to-text-base before trying
>to do keyword expansion (since that might fail)?

Well, that's not a "move-previous", in the context of commit, that's
a "move-new": by the time the commit dust settles, the text base
should be identical to the working file. In particular for this
case, it should have the new version of the keyword expansions. So
if we suppose it were to be made before keyword expansion, then we'd
also have to suppose that the keyword expansion would be applied to
it, independently--seems suboptimal.

>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?

Perhaps. An RFE to that effect would certainly not be unreasonable.

>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?

Beats me. I don't think we've demonstrated yet that this even
happens. If you can provide a reproduction recipe that shows that it
does happen, that would be interesting. It would be tacky to diddle
the modtime just for commiting a file (without expanding keywords);
that would, e.g., force unnecessary rebuilds in the WC.

>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!)

You've lost me. Your problem was that Windows (on behalf of the
shell) had the write lock long before any Subversion code got a
chance to run, and held it until long after the last svn action had
flickered and died. Svn never got the lock; Windows blocked it. so
what's all this questioning about svn holding it?

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org