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),
or
- 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.
~Neels
#!/bin/bash
## TO MAKE THIS RUN YOUR CUSTOM COMPILED SVN, two simple options:
## 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.
#SVNDIR=/my/svn/trunk
#alias svn=${SVNDIR}/subversion/svn/svn
#alias svnserve=${SVNDIR}/subversion/svnserve/svnserve
#alias svnadmin=${SVNDIR}/subversion/svnadmin/svnadmin
svn --version
REPOS="`pwd`/repos"
URL="file://$REPOS"
rm -rf repos wc
svnadmin create repos
svn co -q ${URL} wc
set -x
cd wc
## ACTUAL TEST
# 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