> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: zondag 17 januari 2010 23:39
> To: Bert Huijben
> Cc: 'Neels J Hofmeyr'; dev_at_subversion.apache.org; 'Bert Huijben'
> Subject: Re: libsvn_wc bug: pristine contents for locally replaced file
>
> On Sun, Jan 17, 2010 at 11:14:58PM +0100, Bert Huijben wrote:
> > If you want to fix this behavior, you would have to check the exact
> status
> > information to determine that you are exactly in the replacement
> without
> > history case.
> >
> > This is one of the hardest statuses to detect with WC-NG (which was
> easy as
> > entries), but luckily we don't need it any more for the processing in
> the
> > three tree storage model with a SHA-1 based pristine store. There we
> store a
> > hash in BASE and in WORKING.
>
> So... you're saying we should wait with fixing this until the wc-ng
> pristine store has been implemented?
I'm not sure if it needs fixing. It probably needs a better explanation on
what @BASE is and isn't.
Currently @BASE is the 'previous' version of the node that will be
committed. For added and replaced nodes with history there is no @BASE.
(There is just a copy of the file that was there before the new node was
added to allow reverting to the unmodified state)
And telling that the .svn-base file doesn't exist (1.6 and trunk behavior)
doesn't look like te right way to tell the user that. But I don't think that
presenting a completely unrelated file (the deleted one) is the right answer
either.
But even if we decide that showing the original file would be an answer, we
should always be explicit about the status and not rely on whether a file
exists or doesn't exist. The old working copy library has too much of those
loose ends and the wc_db api can give you the right status easily, if you
ask it the right question.
Bert
>
> Stefan
Received on 2010-01-18 00:02:37 CET