On 2/6/07, Daniel Rall <dlr@collab.net> wrote:
> On Tue, 06 Feb 2007, Malcolm Rowe wrote:
>
> > On Tue, Feb 06, 2007 at 03:50:17PM +0100, Henner Zeller wrote:
> > > >I'm not that familiar with the code myself, but I'm surprised that we
> > > >unconditionally remove the contents without checking them first
> > >
> > > Well its good to do so because the tmp/ area might have some old files
> > > being lying around that we don't want to keep (hence the name tmp/).
> > > Instead of looking for these files, the whole tmp/ is just removed
> > > completely and rebuild.
> > >
> >
> > Okay, that does make sense. I see that we only recreate the tmp/ area
> > after we run the log for the wc, which will presumably fail if there are
> > files referenced in the log that don't exist in tmp/ (because tmp/
> > itself doesn't exist).
Exactly. This is the problem I was referring to. The problem is that
successful execution of the log file doesn't guarantee we did the
right thing if the tmp area doesn't exist: we ignore ENOENT, so, we
can't assume successful completion was really successful, can we?
If those files referenced in the logs don't exist *and* we execute the
log, is the end result guaranteed to be a consistent (known) state? Or
can we end up with a modified working copy admin area which is missing
the files in the working copy?
> I'm in favor of this patch. It passes the test suite; I'll be
> committing it later today unless any other issues with it are raised.
Do we know for certain this is a change for the better? Our working
copy isn't known for its stability as it is, so, I'm all in favor of
changing it, but I'd like it to be a sure change on the side of
stability...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 6 21:39:43 2007