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

Wait a minute, I just read this again:

notes/wc-ng/design
[[[
 * BASE: The tree of nodes from the repository, against which local changes
     are made. Also known as "pristine". Each node is as it was in the
     repository at a particular revision and URL, as recorded per node in
     the WC metadata. A directory node in the BASE tree knows something
     about the children it had in the repository (### details?), but its set
     of children in the WC is independent of that. In a node or tree
[---> HERE ^^^^^^^ ]
     scheduled for replacement the BASE is the pristine version of the
     to-be-added node or tree, not of the deleted one. For a node that is
     scheduled for add without history, there is no BASE node.
]]]

Er, what? I thought that was different in the BASE *tree*. Is this really
true? Then all I said about the BASE tree is probably wrong.

- Where is the information for a 'revert' in case of (a) an add and of (b) a
replace-with-history (going to be) in wc-ng?

- In the same line, does base_shadowed == TRUE mean that the BASE tree now
reflects the to-be-committed node's history and no longer "what I checked out"?

Thanks,
~Neels

Neels J Hofmeyr wrote:
> 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
>>
>