Re: libsvn_wc bug: pristine contents for locally replaced file

Bert Huijben wrote:
>
>> -----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.

I had a slightly wrong concept of BASE. So BASE is the original state of the
*new* file. I was thinking of, say, ORIG, meaning the state in the original
unmodified working copy. In most cases BASE == ORIG, except in a replace (in
that ORIG would be the BASE of the file that was deleted in the replace),
and in a non-replacing add with history (in that ORIG would be empty).

So if I call svn_wc__get_pristine_contents() on a locally replaced file
without history, I should get an empty stream (no history => BASE empty) --
that should be fixed.

'svn cat file_at_BASE', locally replaced without history, will then print
nothing, and with history already prints the most recent contents of that
history.

If 'cat' were to print what I call ORIG, it would need another keyword other
than BASE, e.g. "ORIG". Not that I'm keen on implementing that.

IMHO a little awkward from a user's intuition point of view (the user being
me), but good to know.

> 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

I do agree.
Thanks,
~Neels

> loose ends and the wc_db api can give you the right status easily, if you
> ask it the right question.