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

Re: svn commit: rev 7592 - in trunk/subversion: include libsvn_wc

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-11-02 19:32:15 CET

kfogel@tigris.org writes:

> Author: kfogel
> Date: Fri Oct 31 16:41:46 2003
> New Revision: 7592
> Modified:
> trunk/subversion/include/svn_error_codes.h
> trunk/subversion/libsvn_wc/log.c
> trunk/subversion/libsvn_wc/log.h
> Log:
> Reduce the potential for un-cleanup-able working copies:
> When running 'svn cleanup', if the first command in a log file throws
> an error, then just remove the log file and clean out the rest of that
> .svn/ area. See issue #1581 for an example of how this helps.

Should this detection of first command failure be used differently?
There are two possibilities:

1. During normal operation, the first command failure could cause the
   log file to be removed. Then the working copy would not remain
   locked and there would be no need to run cleanup at all. Of course
   this would mean that the log file would not be available for

2. How robust is this first command failure? Is it possible for a log
   file to run part way though, and then fail in such a way that
   subsequent attempts to run it will fail on the first command? It
   might be more robust if the first command failure were detected
   during normal operation and, rather than removing the log file,
   some positive indication of first command failure could be written
   into the working copy. Cleanup could then use this positive
   indication of first command failure when deciding to remove the log

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 2 19:32:53 2003

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

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