Greg Stein wrote: > On Thu, Jan 28, 2010 at 21:25, Neels J Hofmeyr <ne...@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-f...@1 file
echo "now WORKING for file" >> file
# ...and 'svn cat' that file.
svn st
svn cat f...@base
svn diff --old=f...@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-f...@1' file A file + echo 'now WORKING for file' + svn st R + file + svn cat f...@base r1 for other-file, i.e. the *copied-here* file's history! + svn diff --old=f...@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
signature.asc
Description: OpenPGP digital signature
