Neels J Hofmeyr wrote:
> Bert Huijben wrote:
> > 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.
I always thought (and still think) that, from the user's point of view,
"base" always meant "the version that my local changes are based on",
also being "the version that somebody else would get if they check out
the same revision number that I checked out". That is like Neels' "ORIG"
descibed above. The "-r BASE" revision keyword always means that. The
other kind of base becomes relevant to the user only in some forms of
the "diff" command, and is never accessed by name.
As Neels shows, there are of course two concepts that we can call
"bases": in the implementation, we call that one the "revert
base" ("ORIG" above) and we could call the other one the "copy-from"
base. The way I think about the current implementation is that the
revert base is found in the place called "revert-base" if that exists,
else in the place called "base". The "copy-from" base is always found in
the place called "base". I always thought that that scheme was a little
ugly but good enough to achieve its purpose. However I didn't realize
there was disagreement about the meaning and purpose of the bases.
- Julian
Received on 2010-01-18 11:54:59 CET