[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: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 29 Jan 2010 11:11:51 +0000

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

Thanks for the full explanation of what you were thinking. That is a
sane option.

I'm not 100% sure which way I really want the "@BASE" notation to go.
Before making up my mind I'd like to catalogue the current behaviour of
all client commands and see if there is a clear majority.

- Julian
Received on 2010-01-29 12:12:34 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.