[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 13:55:44 +0100

Greg Stein wrote:
> On Thu, Jan 28, 2010 at 21:25, Neels J Hofmeyr <neels_at_elego.de> wrote:
>> 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.

[pulling the lower replies to the top, because they are more relevant to
this thread, and replying to Greg below]

[Greg Stein wrote:]
> Now... all that said. Let look at the phrase "the BASE is the pristine
> version of the to-be-added node or tree," ... that's just wrong. The
> BASE is untouched by adds, deletes, etc. As Julian mentioned, there is
> some stuff in wc-ng/design that appears to be descriptive of wc-1
> terms rather than what we've come to concretely as wc-ng concepts.

<elated>Aaaaah!</elated> Now that's what I was asking about. Thanks. :D
That's exactly the sentence that really twisted my facts over. So, just to
make ultimately sure:

 The BASE tree always reflects "the node I checked out", or rephrased "the
 state that remains after 'svn revert'".

 Specifically, if a node is one or more of locally
  - deleted
  - added, copied- or moved-here
 then the BASE tree *still* reflects the same. It has no node if the node
 did not exist in the checkout, and it still has the old history even if
 the node is locally replaced-with-history (rephrased: BASE tree still
 has the old history even if the node was locally deleted and then another
 node was locally copied- or moved-here onto the same path).

Now that that has been clarified -- in this thread, this question remains:

*Talking about commandline keywords. Nothing to do with wc-ng:*

It looks to me like Julian thinks "@BASE" currently means "the thing I
checked out", and I always thought the same. Julian, would you like to
confirm / dismiss my impression of what you think?

In fact, "@BASE" currently means "the to-be-committed node's history's tip".
(See attached short test script and output from trunk.)

I still think "@BASE" *should* have meant "the thing I checked out, no
exceptions", and that we should somehow address that, e.g. with a new
keyword that helps distinct between our different notions of "@BASE".

I'm still unsure whether
 - the current meaning of the "@BASE" keyword should be changed so that it
means "the thing I checked out" and a new keyword should be introduced to
mean "the to-be-committed node's history" (e.g. "@NEWBASE" or something),
 - whether "@BASE" should be left the way it is and a new keyword should be
introduced to mean "the thing I checked out" (e.g. "@ORIG", "@REVERT", ...).

The nice thing about changing the current meaning of "@BASE" is that it
would then nicely correlate to what the "BASE tree" is. Not that that's
necessary, but it would sure be nice for wc-ng-newbie hackers.

The not-so-nice to catastrophic thing about changing "@BASE" is that we'd
change the API for any *-with-history cases. We'd have to deal with changing
the meaning of svn_opt_revision_base for those cases. Hairy. But if most
people always thought svn_opt_revision_base means "strictly the thing I
checked out" anyway, then this change would fix more things than it would break.

I'd love to see everyone's opinion(s) on this.

[ now back to more direct replies to Greg ]

>> 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.
> What do you mean "this". Be explicit... I don't see anything wrong here.

I put a big pointer at the sentence's beginning. You picked up that sentence
later on.

>> - 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?
> Still in the BASE tree.

(Sorry got mixed up with that 'add' there. Of course a simple add has no
BASE node.)

> An 'add' just creates WORKING nodes. A "replace-with-history" is a
> fucked-up name. Never ever say "with-history". I say there is no such
> thing. It is a *copy*. Plain and simple.

It's not *that* plain. "Replace-with-history" is more than just a copy, it
is exactly "a copy *or move* onto a *locally* *deleted* node". What's a good
term for that? Hm, maybe:

$ svn help status | grep history
    Fourth column: Scheduled commit will contain addition-with-history
      ' ' no history scheduled with commit
      '+' history scheduled with commit

Exactly. <stubborn>So as long as that says 'with-history' I'll continue to
use that term to describe an 'R +' status.</stubborn> :P

> So you're talking about a
> 'delete' followed by a 'copy' into the same location.

Yes, but an *uncommitted* delete! ... and copy or a *move* ;)
(If we're being editor-v2 compliant in our discussion.)

> Information for
> the revert is still sitting in the BASE tree.
>> - 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"?
> BASE is always what you checked out.
> I think what might be throwing you off is that the repository has a
> set of children X. In the working copy, you could have a *subset* of
> those children named Y because you've *excluded* some children.

I don't think I'm confused about that... Locally excluded children are
svn_wc__db_status_excluded, and nodes known but not sent by the repository
are svn_wc__db_status_absent, and neither may have a WORKING node, right?

Thanks again, and never mind the slight heatedness of some of my comments.
At least I didn't swear like you did ;)
Truth is, I very much appreciate your explanations.



## 1. Adjust your PATH to point at your custom installed location:
## export PATH="$HOME/prefix/svn-trunk/bin:$PATH"
## OR
## 2. Uncomment the four lines below to use aliases into your
## built source tree. The next line is the only line you should
## need to adjust.
#alias svn=${SVNDIR}/subversion/svn/svn
#alias svnserve=${SVNDIR}/subversion/svnserve/svnserve
#alias svnadmin=${SVNDIR}/subversion/svnadmin/svnadmin

svn --version
rm -rf repos wc
svnadmin create repos

svn co -q ${URL} wc

set -x
cd wc


# make a file that is locally replaced...
echo "r1 for file, i.e. the deleted file's history." > file
echo "r1 for other-file, i.e. the *copied-here* file's history!" > other-file
svn add file other-file
svn ci -mm

svn rm file
svn cp ^/other-file_at_1 file
echo "now WORKING for file" >> file

# ...and 'svn cat' that file.
svn st
svn cat file_at_BASE
svn diff --old=file_at_BASE --new=file

svn, version 1.7.0 (dev build)
   compiled Jan 26 2010, 22:16:34

Copyright (C) 2010 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

+ cd wc
+ echo 'r1 for file, i.e. the deleted file'\''s history.'
+ echo 'r1 for other-file, i.e. the *copied-here* file'\''s history!'
+ svn add file other-file
A file
A other-file
+ svn ci -mm
Adding file
Adding other-file
Transmitting file data ..
Committed revision 1.
+ svn rm file
D file
+ svn cp '^/other-file_at_1' file
A file
+ echo 'now WORKING for file'
+ svn st
R + file
+ svn cat file_at_BASE
r1 for other-file, i.e. the *copied-here* file's history!
+ svn diff --old=file_at_BASE --new=file
Index: file
--- file (working copy)
+++ file (working copy)
@@ -1 +1,2 @@
 r1 for other-file, i.e. the *copied-here* file's history!
+now WORKING for file

Received on 2010-01-29 13:56:30 CET

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