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

Re: libsvn_wc bug: pristine contents for locally replaced file

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Mon, 18 Jan 2010 00:56:48 +0100

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

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.

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

Received on 2010-01-18 00:57:28 CET

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