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

Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Fri, 29 Jan 2010 00:24:45 +0100

Julian Foad wrote:
> On Thu, 2010-01-28 at 15:17 +0100, Neels J Hofmeyr wrote:
>> Greg Stein wrote:
>>> On Wed, Jan 27, 2010 at 16:51, Neels J Hofmeyr <neels_at_elego.de> wrote:
>>>> Greg Stein wrote:
>>>> ...
>>>>> and recall that BASE == what you checked out from the repository.
>>>>> WORKING corresponds to added/removed/copied/moved nodes. For nodes in
>>>> Yes, I learnt this from Bert last week, and also that the current *@BASE*
>>>> commandline keyword refers to the "copy_from" of the *WORKING* tree for all
>>>> the add-with-history schedules :)
>>> I don't think it is advisable to try to make any correlation between
>>> the cmdline markers and the names that we use internally for the
>>> trees.
>> I agree, but of course, anyone new to the subject of svn_wc will
>> automatically have the association '@BASE' <-> 'BASE tree' popping up.
>> They're even both in all-caps.
>>
>> From our discussion on 'svn cat' behaviour (with Julian and Bert), I know
>> that @BASE does not always mean 'exactly what was checked out', but I think,
>> and it seems Julian agrees, that most users would expect @BASE to actually
>> mean strictly the BASE tree info.
>
> Oof - try not to say it this way round. I basically know what you mean,
> but the WC-NG "BASE tree" concept is the new one, and users do not have
> that as their point of reference.

Yes, that was an ill way to put it...
I was just using the wc-ng reference to point out which info I meant.
I meant to say:
I think most users would expect @BASE to actually mean strictly what was
checked out, not reflecting any possible copy_from schedules in the working
copy.

>
>> Until told otherwise, I thought 'svn cat
>> file_at_BASE' was buggy in that respect and tried to fix it :/
>>
>> It seems a little unfortunate to have this "naming ambiguity". But there we
>> go. Need to keep the current behavior. We can only add new keywords...
>>
>> For the record:
>> "@BASE" == svn_opt_revision_base
>> is NOT ALWAYS the same as
>> "BASE tree" == svn_wc__db_base_get_info
>>
>> (although they are the same when there is no 'new' history in the WORKING tree)
>>
>> I humbly suggested "@ORIG" to represent the "BASE tree". Any comments on
>> actually implementing that? I'm not sure if it is really needed by people,
>> but it may help to explain what "@BASE" is (as opposed to "@ORIG").
>
> It sounds like you are suggesting a new keyword to represent a concept
> that the user already has and already has a keyword for ("@BASE").
>
> At least we need to figure out whether the existing "@BASE" keyword
> should mean "the thing I checked out" (I think it should) and any
> deviation from that should be treated as a bug. Only if we decide that
> the users really need an extra concept - being, I assume, "the thing you
> checked out, unless this is a copy, in which case the thing you copied"
> - would we need a new revision keyword.
>
> That discussion is entirely separate from WC-NG concerns.

I'm trying to say: Independently from wc-ng or its naming, I think that the
commandline keyword "@BASE" should mean "the thing I checked out".

But using 'svn cat' and 'svn diff', I see that "@BASE" currently means
"the thing you checked out, unless this is a copy, in which case the thing
you copied". (!!!)

So I'd agree with your comment that we should change "@BASE" to mean "the
thing I checked out", but Bert pointed out to me that that would break some
use cases some people already depend on.

Furthermore, if I was being naming-purist, I would change "@BASE", and then
I'd introduce a new keyword for those people who depend on "the thing you
checked out, unless this is a copy, in which case the thing you copied". But
then we would technically change the API in a very confusing way, and yada
yada. Although if everyone agrees, I'd do it :)

On the other hand, it might be good to introduce a new keyword that always
represents "the thing I checked out", regardless of copy_from schedules.
Then we'd still have the gruesome naming inconsistency between "@BASE" and
the "BASE-tree" -- when there is a "BASE tree", sometimes getting "@BASE"
from the "WORKING tree" just seems odd; I'm not supposed to make such
associations, sorry :) --, but this would probably cause much less trouble.

>
> I agree that naming the WC-NG concepts with the same names as the
> user-level concepts has turned out to be confusing because of the way
> the concepts only partially match up, so it is worth considering
> renaming the WC-NG concepts, uncomfortable though that would be for
> those working on them.

I'd call them the Unchanged tree, the Schedule tree, and the Actual tree.
And just to be wild, I'd not make them all-caps ;)

~Neels

>
> - Julian
>
>
>>>> (read_info's comment sounds like it:
>>>> " * The information returned comes from the BASE tree, as possibly modified
>>>> * by the WORKING and ACTUAL trees. ")
>>> Sounds like the comment could/should be improved.
>> +1
>> That could probably save us some amount of IRC and mail traffic :)
>>
>> ~Neels
>
>

Received on 2010-01-29 01:08:12 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.