[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Commit failed - working copy fatally ill

From: Jan Hendrik <jan.hendrik_at_bigfoot.com>
Date: 2004-04-26 15:25:06 CEST

Concerning Commit failed - working copy fatall
Jan Hendrik wrote on 24 Apr 2004, 12:09, at least in part:

> Hi all out there!
> SVN local: svn-win32-1.1-dev-9226;
> SVN server: SVN 1.0.1;
> TortoiseSVN 1.0.3, built against Subversion 1.0.1 (dev build);
> Apache 2.0.48;
> Win2000 SP2

Could it be that in the course of a commit the TMP folders within
the .SVN administrative area are removed and only recreated after
the commit is (nearly) perfect?

As there had not been any suggestions on my posting below I
continued playing around with a _copy_ of the corrupted part of the
working copy and comparing it with a fresh checkout I found it
lacked all the TMP folders and the .SVN folders were not hidden
either. Random checks of the other parts of the working copy
showed the .SVN folders hidden and with a TMP folder below.

After copying the TMP folders over from the fresh checkout, setting
the .SVN folders to "hidden", removing both the two added files and
the respective "schedule=add" entries in the entries file I could
update successfully again. The errors never said anything about
missing TMP folders.

Though occasionally I do a "find" for "tmp" I can positively say that
I haven't done so recently. Nor did I fiddle with the "hidden"

Jan Hendrik

> Using TSVN (thus local experimental version of SVN probably
> irrelevant for the case) I committed a subtree of my working copy via
> http://: 2 files added, 2 files modified, all HTML stuff.
> I noticed that after actual transmit (TSVN: "sending content") there
> was a long delay while I expected the new revision being printed in
> the progress dialog. Finally an error popped up. Sorry, I did not
> notice what it said, but clicked it away. It 'looked' like a 'cannot
> connect to server' though. Now what happened further:
> - clean up working copy (through TSVN);
> - repeat commit with TSVN; commit fails for added file already is in
> repository; - clean up working copy again; - shut down Apache and run
> recover on repos; Apache restarted; shift to command line client; -
> run update and get the error
> C:\>svn up d:\internet\artbooks\artbooks
> svn: REPORT request failed on '/svn/repos1/!svn/vcc/default'
> svn: File not found: transaction 'c8', path
> '/trunk/internet/Artbooks/artbooks/28191_e.htm'
> This is an old file, not even modified now.
> Remembering a problem in February when update would not add 2
> new files to my working copy I went to the entries files and found the
> line 'incomplete="true"'. My intention had been to add just this!
> Removing this line allowed to run update with the result "At revision
> 361". But still cannot commit because the added files already are in
> the repository. Doublechecked this by checking out another working
> copy which had both the two added files and the two modifications.
> Also the post-commit hook had obviously started as there is an entry
> for start time in the log file it creates and an incremental dump file
> of zero length. (post-commit.bat attached below for reference.)
> Looking once more into entries I also removed the blocks of the
> two new files saying 'schedule="add"', added 'incomplete="true"'
> again, moved the two new files out of the working copy and run svn
> update again: same error as before. Deleting the "incomplete" line
> again makes update a success, but without me getting back the new
> files from the repository.
> Since this happened to the master repository used for uploading to the
> server I cannot just make a fresh checkout and go on. The hoster does
> not allow rsync, so FTP upload depends on timestamps and would
> consider the new checkout as "all files changed since the timestamp is
> different" and upload everything anew. A big NO-NO with 70-80MB over
> dial-up. Besides this upload would change all timestamps to upload
> time and - as long as, from my point of view, SVN is too dump to
> update timestamps in the .svn area - render the working copy to a
> waiting copy on any update/commit as it would diff every file again
> and again.
> Anything else I can do to save the working copy?
> TIA - Jan Hendrik
> ====================================
> post-commit.bat:
> @echo off
> set repo=%1
> set rev=%2
> set log="D:\tmp\dump\post-commit.log"
> set err="D:\tmp\dump\post-commit-err.log"
> set dump_file="D:\tmp\dump\repos1_incremental.r%rev%"
> set svnadmin="E:\PRG\Tools\Subversion\bin\svnadmin.exe"
> ( echo
> ======================================================================
> == echo Start commit %repo% r%rev% date /t time /t ) >> %log%
> set dump_cmd=start /B /BELOWNORMAL %svnadmin% dump %repo% -r %rev%
> --incremental (%dump_cmd% > %dump_file%) && echo "incrementally dumped
> revision %rev% to %dump_file%" >> %log%
> ( echo End commit
> date /t
> time /t ) >> %log%
> ---------------------------------------
> Freedom quote:
> Capitalism is not an 'ism.'
> It is closer to being the opposite of an 'ism,'
> because it is simply the freedom of ordinary people
> to make whatever economic transactions they can mutually agree
> to.
> -- Thomas Sowell
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For
> additional commands, e-mail: users-help@subversion.tigris.org

Freedom quote:

     If some among you fear taking a stand
     because you are afraid of reprisals
     from customers, clients, or even government,
     recognize that you are just feeding the crocodile
     hoping he'll eat you last.
                -- Ronald Reagan

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 26 15:24:06 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.