You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels J Hofmeyr <ne...@elego.de> on 2010/01/27 00:20:23 UTC
svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
How does
err = svn_wc__db_base_get_info(&status, NULL,
&revision,
&repos_relpath,
&repos_root_url,
NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL,
eb->db,
local_abspath,
result_pool,
scratch_pool);
differ from
SVN_ERR(svn_wc__db_read_info(&status, NULL,
&revision,
&repos_relpath,
&repos_root_url,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL,
eb->db, local_abspath,
result_pool, scratch_pool));
?
Thanks,
~Neels
Re: WC-NG 3-trees description [was: '@BASE' vs. 'BASE tree']
Posted by Greg Stein <gs...@gmail.com>.
That page looks good.
On the definition of trees, the second para is correct: the path
changes for a renamed node. There will be an NG-WORKING node recording
"moved-away", and another NG-WORKING node recording "moved-here". An
NG-BASE node will be present for the original path, but will not exist
at the new path.
Cheers,
-g
On Mon, Feb 15, 2010 at 09:26, Julian Foad <ju...@btopenworld.com> wrote:
> Any WC-NG folks prepared to comment on this? We should put this
> description in note/wc-ng/... if it's OK.
>
> - Julian
>
> On Tue, 2010-02-09, I (Julian Foad) wrote:
>> Hi, all. I've written up this brief definition of the WC-NG DB trees
>> at
>> <http://subversion.wandisco.com/wiki/index.php/WC-NG_trees_-_defining_BASE_and_WORKING_and_ACTUAL>. Could you all have a look and add to it or just mention to me anything that is worth noting or correcting. After a few rounds I'll move it to an in-tree document.
>>
>> In particular, one question for Greg:
> [...]
>> > > So the wc_db trees are something like
>> > >
>> > > * (the pristine one, known as BASE)
> [...]
>> > > * (the tree-changes, known as WORKING)
> [...]
>> > > * (the on-disk and in-property-storage stuff, known as ACTUAL)
>> > >
>> > > A description of the text-content and properties of any nodes whose
>> > > text-content and/or properties are different from its WORKING version.
>> > > Any node that has no such differences does not appear in this tree.
>> >
>> > Its WORKING node; or if none, then the BASE node.
>>
>> Sorry Greg, I didn't understand your comment there. Could you clarify?
>>
>> > The ACTUAL tree can also record tree conflicts for nodes that exist in
>> > neither WORKING nor BASE.
>
>
>
>
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
Julian Foad wrote:
> Hi, all. I've written up this brief definition of the WC-NG DB trees at
> <http://subversion.wandisco.com/wiki/index.php/WC-NG_trees_-_defining_BASE_and_WORKING_and_ACTUAL>. Could you all have a look and add to it or just mention to me anything that is worth noting or correcting. After a few rounds I'll move it to an in-tree document.
I note that the lower section talks about 'base' as what-I-checked-out, but
when users use @base on the svn commandline, it means 'the pristine of what
will be committed' for locally added/replaced/... nodes. Confusing :)
I would also suggest to list 'pristine' as one of the names *not* to use
instead of the NG-BASE tree (as I said before once) -- we already have
another PRISTINE table, and in the wc.db, 'pristine' now means 'the cached
fulltext content of a file, regardless of which path@rev it is at and
without any metadata'. The NG-BASE references pristines and stores metadata,
so let's not start to confuse them.
~Neels
WC-NG 3-trees description [was: '@BASE' vs. 'BASE tree']
Posted by Julian Foad <ju...@btopenworld.com>.
Any WC-NG folks prepared to comment on this? We should put this
description in note/wc-ng/... if it's OK.
- Julian
On Tue, 2010-02-09, I (Julian Foad) wrote:
> Hi, all. I've written up this brief definition of the WC-NG DB trees
> at
> <http://subversion.wandisco.com/wiki/index.php/WC-NG_trees_-_defining_BASE_and_WORKING_and_ACTUAL>. Could you all have a look and add to it or just mention to me anything that is worth noting or correcting. After a few rounds I'll move it to an in-tree document.
>
> In particular, one question for Greg:
[...]
> > > So the wc_db trees are something like
> > >
> > > * (the pristine one, known as BASE)
[...]
> > > * (the tree-changes, known as WORKING)
[...]
> > > * (the on-disk and in-property-storage stuff, known as ACTUAL)
> > >
> > > A description of the text-content and properties of any nodes whose
> > > text-content and/or properties are different from its WORKING version.
> > > Any node that has no such differences does not appear in this tree.
> >
> > Its WORKING node; or if none, then the BASE node.
>
> Sorry Greg, I didn't understand your comment there. Could you clarify?
>
> > The ACTUAL tree can also record tree conflicts for nodes that exist in
> > neither WORKING nor BASE.
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Julian Foad <ju...@btopenworld.com>.
On Thu, 2010-01-28, Greg Stein wrote:
> On Thu, Jan 28, 2010 at 12:30, Julian Foad <ju...@wandisco.com> wrote:
[...]
> > The big conceptual difference between your wc_db trees and what I think
> > the user's concept of trees should be, is that the wc_db trees are
> > "overlays", whereas the user's notions of "base" and "working" are
> > complete trees, in the sense that for an unmodified file both notions
> > regard the file as existing and having content.
>
> Correct/agreed.
Hi, all. I've written up this brief definition of the WC-NG DB trees at
<http://subversion.wandisco.com/wiki/index.php/WC-NG_trees_-_defining_BASE_and_WORKING_and_ACTUAL>. Could you all have a look and add to it or just mention to me anything that is worth noting or correcting. After a few rounds I'll move it to an in-tree document.
In particular, one question for Greg:
> >...
> > So the wc_db trees are something like
> >
> > * (the pristine one, known as BASE)
> >
> > A cached version of the complete tree that was checked out of the
> > repository. (Well, ish.)
>
> No need to use the term "cached". That is misleading. You have a copy
> of some portion of the repository. Plain and simple.
OK.
> > * (the tree-changes, known as WORKING)
> >
> > A set of tree-changes, describing any nodes added, deleted, moved,
> > copied, replaced, etc. Any node that just has text and/or prop mods, or
> > no mods, does not appear in this tree.
>
> Correct.
>
> > * (the on-disk and in-property-storage stuff, known as ACTUAL)
> >
> > A description of the text-content and properties of any nodes whose
> > text-content and/or properties are different from its WORKING version.
> > Any node that has no such differences does not appear in this tree.
>
> Its WORKING node; or if none, then the BASE node.
Sorry Greg, I didn't understand your comment there. Could you clarify?
> The ACTUAL tree can also record tree conflicts for nodes that exist in
> neither WORKING nor BASE.
- Julian
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jan 28, 2010 at 12:30, Julian Foad <ju...@wandisco.com> wrote:
> Greg Stein wrote:
>...
>> I would also suggest new names for the trees since WORKING has caused
>> us problems, too.
>>
>> PRISTINE might be okay. And something to reference a restructured tree
>> (WORKING is all about add/copy/move/del).
>
> The big conceptual difference between your wc_db trees and what I think
> the user's concept of trees should be, is that the wc_db trees are
> "overlays", whereas the user's notions of "base" and "working" are
> complete trees, in the sense that for an unmodified file both notions
> regard the file as existing and having content.
Correct/agreed.
>...
> So the wc_db trees are something like
>
> * (the pristine one, known as BASE)
>
> A cached version of the complete tree that was checked out of the
> repository. (Well, ish.)
No need to use the term "cached". That is misleading. You have a copy
of some portion of the repository. Plain and simple.
> * (the tree-changes, known as WORKING)
>
> A set of tree-changes, describing any nodes added, deleted, moved,
> copied, replaced, etc. Any node that just has text and/or prop mods, or
> no mods, does not appear in this tree.
Correct.
> * (the on-disk and in-property-storage stuff, known as ACTUAL)
>
> A description of the text-content and properties of any nodes whose
> text-content and/or properties are different from its WORKING version.
> Any node that has no such differences does not appear in this tree.
Its WORKING node; or if none, then the BASE node.
The ACTUAL tree can also record tree conflicts for nodes that exist in
neither WORKING nor BASE.
> Is that anywhere close to accurate for a high-level starter?
Yup.
>...
> but, worryingly, that text goes into some detail that doesn't seem to
> correspond either to the user (command-line) concepts or the wc-ng DB
> concepts. Maybe it corresponds to some WC-1 implementation concepts -
> but I'm not sure it does.
Yah. Could be.
> I think that block of text might have misled some of us into thinking it
> was documentation of the WC-NG concepts.
There is a lot in the document about exploratory concepts. A lot of
stuff that we also ignored, threw out, and simply left behind (e.g.
library concepts and virtual func tables and whatnot). Not surprised
that it could stand for some cleaning.
Cheers,
-g
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Julian Foad <ju...@wandisco.com>.
Greg Stein wrote:
> I didn't see it as "mouthing off" :-)
Phew :-)
> I would also suggest new names for the trees since WORKING has caused
> us problems, too.
>
> PRISTINE might be okay. And something to reference a restructured tree
> (WORKING is all about add/copy/move/del).
The big conceptual difference between your wc_db trees and what I think
the user's concept of trees should be, is that the wc_db trees are
"overlays", whereas the user's notions of "base" and "working" are
complete trees, in the sense that for an unmodified file both notions
regard the file as existing and having content.
(Correct me if I'm wrong - the thing is, I just don't have a very clear
idea of the concepts, and that's preciseley the problem I'm wanting to
solve.)
So the wc_db trees are something like
* (the pristine one, known as BASE)
A cached version of the complete tree that was checked out of the
repository. (Well, ish.)
* (the tree-changes, known as WORKING)
A set of tree-changes, describing any nodes added, deleted, moved,
copied, replaced, etc. Any node that just has text and/or prop mods, or
no mods, does not appear in this tree.
* (the on-disk and in-property-storage stuff, known as ACTUAL)
A description of the text-content and properties of any nodes whose
text-content and/or properties are different from its WORKING version.
Any node that has no such differences does not appear in this tree.
Is that anywhere close to accurate for a high-level starter?
I just went to read notes/wc-ng/design, and found:
[[[
When considering the wc-1.0 design, one finds that there are a lot
of situations where the exact state of the versioned tree isn't
defined. When explicitly considering which trees relate to the
working copy at one time or another, the following trees can be
found:
* BASE: The tree of nodes from the repository, [...]
* WORKING: [...]
* ACTUAL: [...]
]]]
but, worryingly, that text goes into some detail that doesn't seem to
correspond either to the user (command-line) concepts or the wc-ng DB
concepts. Maybe it corresponds to some WC-1 implementation concepts -
but I'm not sure it does.
I think that block of text might have misled some of us into thinking it
was documentation of the WC-NG concepts.
- Julian
> > On Jan 28, 2010 9:57 AM, "Julian Foad" <ju...@btopenworld.com>
> > wrote:
> >
> > ... and if that sounded like me just mouthing off against lack of
> > clear
> > docco, but not helping again, sorry but I'd really like to help.
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Greg Stein <gs...@gmail.com>.
I didn't see it as "mouthing off" :-)
I would also suggest new names for the trees since WORKING has caused us
problems, too.
PRISTINE might be okay. And something to reference a restructured tree
(WORKING is all about add/copy/move/del).
On Jan 28, 2010 9:57 AM, "Julian Foad" <ju...@btopenworld.com> wrote:
... and if that sounded like me just mouthing off against lack of clear
docco, but not helping again, sorry but I'd really like to help.
- Julian
On Thu, 2010-01-28 at 14:51 +0000, Julian Foad wrote:
> On Thu, 2010-01-28 at 15:17 +0100, Neels J...
Re: '@BASE' vs. 'BASE tree' -- was: Re:
svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Julian Foad <ju...@btopenworld.com>.
... and if that sounded like me just mouthing off against lack of clear
docco, but not helping again, sorry but I'd really like to help.
- Julian
On Thu, 2010-01-28 at 14:51 +0000, 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 <ne...@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.
>
> > Until told otherwise, I thought 'svn cat
> > file@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 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.
>
> - 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
>
>
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jan 29, 2010 at 06:59, Julian Foad <ju...@btopenworld.com> wrote:
> Neels J Hofmeyr wrote:
>> 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 ;)
>
> For the first, "Unchanged" could be OK, although since we talk about
> changes so often it might be ambiguous in more contexts than some other
> words would be. ("If the Actual version is unchanged ...", "If the
> Unchanged version has changed ...") "Original" or "Repository" or
> "Checked out" might be better. "Base" might be OK if we decide that's
> what the meaning of the user-level "Base" concept should be.
I have no particular interest in ensuring the names line up, but I
definitely don't want to use the same name when it means something
else to our users.
"Repository" is troublesome because you might be talking about the
server-side trees. "Original", "Checked out", or "Pristine" seem okay.
> For the second, "Schedule" is a bad idea because it has strong and
> specific meanings in WC-1. Greg suggested "Restructured" which sounds
> perfect.
>
> For the third, "Actual" is fine.
Too busy to respond in depth here, but just had a thought: how about
"Edits" to replace the "Actual" name?
Cheers,
-g
Re: '@BASE' vs. 'BASE tree' -- was: Re:
svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Julian Foad <ju...@btopenworld.com>.
Neels J Hofmeyr wrote:
> 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 ;)
For the first, "Unchanged" could be OK, although since we talk about
changes so often it might be ambiguous in more contexts than some other
words would be. ("If the Actual version is unchanged ...", "If the
Unchanged version has changed ...") "Original" or "Repository" or
"Checked out" might be better. "Base" might be OK if we decide that's
what the meaning of the user-level "Base" concept should be.
For the second, "Schedule" is a bad idea because it has strong and
specific meanings in WC-1. Greg suggested "Restructured" which sounds
perfect.
For the third, "Actual" is fine.
- Julian
Re: Taking stock: BASE keyword on the command line
Posted by Neels J Hofmeyr <ne...@elego.de>.
Bert Huijben wrote:
> On Sat, Jan 30, 2010 at 4:14 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
>> Neels J Hofmeyr wrote:
>>> Starting from 'svn help', I see these commands where @BASE is applicable:
[...]
[...]
[...]
> I would like to compare the result to a 1.6.X version, but I don't
> have the time to do that today :(
> (I hope your script can help here)
Sure! Ran it on 1.6.x and looked at the diff -u between trunk and 1.6.x output.
The differences are:
'svn blame file' does not show the locally edited file in 1.6.x, as you
said.
'svn info' has a tiny difference where it doesn't show the Repos UUID in
1.6.x though it did in trunk:
[[[
---- trunk.output
++++ 1.6.x.output
[svn copy -rBASE file copy2_of_file]
[svn info copy2_of_file]
@@ -189,7 +187,6 @@
Name: copy2_of_file
URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/copy2_of_file
Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
-Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
Revision: 4
Node Kind: file
Schedule: add
]]]
'svn log' has a number of differences where it shows one revision earlier
than trunk. I haven't looked at the meaning of this yet. Feel free...
[[[
@@ -305,30 +301,29 @@
this_is_revision_1_of_folder
+ svn log -v file
------------------------------------------------------------------------
-r4 | neels | 2010-01-30 12:43:01 +0100 (Sat, 30 Jan 2010) | 1 line
+r3 | neels | 2010-01-30 12:26:14 +0100 (Sat, 30 Jan 2010) | 1 line
Changed paths:
- D /folder
- M /other_file
+ M /file
+ M /file_with_props
+ A /folder/no,_this_is_revision_3_of_folder
M /other_file_with_props
- D /other_folder/file.r2
- A /other_folder/file.r4
+ A /other_folder/file.r3
-r4
+r3
------------------------------------------------------------------------
-r2 | neels | 2010-01-30 12:42:57 +0100 (Sat, 30 Jan 2010) | 1 line
+r1 | neels | 2010-01-30 12:26:10 +0100 (Sat, 30 Jan 2010) | 1 line
Changed paths:
- M /file_with_props
- A /folder/no,_this_is_revision_2_of_folder
- A /other_file
- A /other_file_with_props
- A /other_folder
- A /other_folder/file.r2
+ A /file
+ A /file_with_props
+ A /folder
+ A /folder/this_is_revision_1_of_folder
+ A /old_state_of_file
-r2
+r1
------------------------------------------------------------------------
+ svn log -v file@BASE
------------------------------------------------------------------------
-r3 | neels | 2010-01-30 12:42:59 +0100 (Sat, 30 Jan 2010) | 1 line
+r3 | neels | 2010-01-30 12:26:14 +0100 (Sat, 30 Jan 2010) | 1 line
Changed paths:
M /file
M /file_with_props
@@ -338,7 +333,7 @@
r3
------------------------------------------------------------------------
-r1 | neels | 2010-01-30 12:42:55 +0100 (Sat, 30 Jan 2010) | 1 line
+r1 | neels | 2010-01-30 12:26:10 +0100 (Sat, 30 Jan 2010) | 1 line
Changed paths:
A /file
A /file_with_props
@@ -352,23 +347,11 @@
------------------------------------------------------------------------
+ svn log -v -rBASE file
------------------------------------------------------------------------
-r4 | neels | 2010-01-30 12:43:01 +0100 (Sat, 30 Jan 2010) | 1 line
-Changed paths:
- D /folder
- M /other_file
- M /other_file_with_props
- D /other_folder/file.r2
- A /other_folder/file.r4
-
-r4
-------------------------------------------------------------------------
]]]
Those are all the differences (ingoring UUID and Date diffs of course).
~Neels
Re: Taking stock: BASE keyword on the command line
Posted by Bert Huijben <be...@vmoo.com>.
On Sat, Jan 30, 2010 at 4:14 AM, Neels J Hofmeyr <ne...@elego.de> wrote:
> Neels J Hofmeyr wrote:
>> Starting from 'svn help', I see these commands where @BASE is applicable:
>>
>> blame (praise, annotate, ann)
>> cat
>> copy (cp)
>> diff (di)
>> export
>> info
>> list (ls)
>> log
>> merge
>> mergeinfo
>> move (mv, rename, ren)
>> propdel (pdel, pd)
>> propedit (pedit, pe)
>> propget (pget, pg)
>> proplist (plist, pl)
>> propset (pset, ps)
>> switch (sw)
>> update (up)
>
>
> DISCLAIMER: I have not tested with mixed-revision working copies.
>
> And the results are... Some are consistent, and some are just *wild* AFAICT.
>
>
>
> These commands interpret @BASE to mean...
> --------------------------+----------------------------
> the pristine of the | "what I checked out":
> copied-here node: |
> --------------------------+----------------------------
> cat | update (but see below)
> copy | (prop*)
> diff | (merge)
> export |
> |
>
>
> These make no difference if BASE is supplied
> or not and always use 'what I checked out'
> --------------------------------------------
> prop*
> merge
>
>
> These don't accept BASE, though 'svn help' lists it.
> ----------------------------------------------------
> switch
> prop* --revprop
> move
>
>
> These are inconsistent in their use of BASE,
> either acting different between -rBASE and
> @BASE and/or being plain wrong. (more below)
> --------------------------------------------
> info
> list
> log
> blame
>
> But what shows in these "inconsistent" ones is a slight tendency to mean
> 'copy-from' when saying -rBASE and 'what I checked out' when saying @BASE,
> within the use of the same command, where @BASE is stronger than -rBASE.
> Though, in many cases this only holds true because -rBASE simply has no
> effect at all, and not providing any revision or keyword selects 'copy-from'
> by default. Read all the details below.
>
>
>
>
> Details:
>
>
> * move
> 'svn help' talks about a --revision option and a BASE keyword, but dude,
> that just makes no sense.
>
>
> * switch
> 'svn help' talks about a --revision option and a BASE keyword, but it
> refuses to accept "BASE".
>
>
> * update
> update just uses the revision number "I checked out" and it is a no-op in an
> up-to-date state. Otherwise it is a special case of a 'time-warp' update,
> i.e. when specifying a folder, all its children are pulled back or forward
> so that they match the folder's current "checked out" revision number.
>
>
> * blame
> 'svn blame file'
> tries to show a 'blame' for the locally modified state.
> So I guess count it as based on the copied-here state.
This behavior is new in 1.7. Before 1.7 we didn't look at the locally
modified version.
> 'svn blame -rBASE file'
> shows the copied-from URL's blame, but at the "checked out" revision, which
> may be newer than the copied-from revision. This is not at all related to
> either of the copied-here or "checked out" nodes' histories.
>
> 'svn blame file@BASE' and
> 'svn blame -rBASE file@BASE'
> both show the blame of the file "I checked out".
>
>
>
> * prop*
> For normal props, using "BASE" makes no difference.
> The BASE keyword is not available for the prop* --revprop commands.
> [[[
> svn: Must specify the revision as a number, a date or 'HEAD' when operating
> on a revision property
> ]]]
>
>
>
> * list
> 'svn list folder' and
> 'svn list -rBASE folder'
> both show the listing of the copied-from URL and Revision (omitting any
> local additions and deletions).
>
> 'svn list folder@BASE' and
> 'svn list -rBASE folder@BASE'
> both show the listing of the URL "I checked out",
> but at the copied-from revision (makes no sense).
>
>
>
> * log
> 'svn log -v file' and
> 'svn log -v -rBASE file'
> both show the log of the copied-here node, but they start at the "checked
> out" revision (going backwards), showing some history that is not related to
> the node, because it happened on the copy-from node *after* the copy-from
> revision.
This used to give some kind of error in 1.6, but the behavior was
changed in the last few weeks.
> 'svn log -v file@BASE'
> 'svn log -v -rBASE file@BASE'
> both show the log of the node "I checked out".
>
> In log, passing -rBASE causes the log to only show the node's log for the
> "checked out" revision number. So 'log -rBASE file@BASE' is empty when the
> "checked out" node had no changes in the "checked out" revision number.
>
>
>
> * info
> 'svn info file'
> shows the complete information:
> The usual info is "what I checked out", and the copied-here node is
> correctly indicated in Copied From URL and Rev.
> Interestingly, Last Changed Rev reflects copied-here, not "what I checked
> out". This could be argued about (not related to @BASE keyword).
> [[[
> + svn info file
> Path: file
> Name: file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Schedule: replace
> Copied From URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
> Copied From Rev: 2
> Last Changed Author: neels
> Last Changed Rev: 2
> Last Changed Date: 2010-01-30 03:47:17 +0100 (Sat, 30 Jan 2010)
> Text Last Updated: 2010-01-30 03:47:23 +0100 (Sat, 30 Jan 2010)
> Checksum: 74caf578c8e8a5a1a206e5ee3a0deacc
> ]]]
This could be an artifact of using entries. For added nodes the
revision doesn't make sense, but the revision is available in
svn_wc_entry_t anyway.
(You won't see a valid revision if you use svn_wc__db_read_info())
I think we can do better here with WC-NG, where we store more details.
In WC-NG we have the common properties (author, last modified, last
changed) available in BASE and WORKING and not just one set which we
try to use for both with limited success..
> 'svn info file@BASE' and
> 'svn info -rBASE file@BASE'
> both show only "what I checked out".
> [[[
> + svn info file@BASE
> Path: file
> Name: file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Last Changed Author: neels
> Last Changed Rev: 3
> Last Changed Date: 2010-01-30 03:47:19 +0100 (Sat, 30 Jan 2010)
> ]]]
> (I was consistently at revision 4 before doing the replace, and I copied
> from revision 2. So this case clearly interprets BASE as 4, meaning "what I
> checked out". The URL is also "what I checked out".)
>
> However,
> 'svn info -rBASE file'
> shows a bad mixture:
> [[[
> + svn info -rBASE file
> Path: other_file
> Name: other_file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Last Changed Author: neels
> Last Changed Rev: 4
> Last Changed Date: 2010-01-30 03:47:21 +0100 (Sat, 30 Jan 2010)
> ]]]
> - Path and Name show the copied-from basename (!?),
> - URL shows the copied-from path, but
> - Revision, Date and Last Changed show the revision number "I checked out",
> referring to the copied-from history (in the future after the copy-from
> rev).
>
>
> Test attached. Note that some lines are good to uncomment/comment to see
> through some cases (e.g. for log and info; should be marked). Most things
> are plain, though.
>
>
> ...phew, what donkey work. XP
Thanks for doing this :)
>
> Now To The Drawing Boards, you guys!
> *ALL OUR "BASE" ARE BELONG TO US!!*
I would like to compare the result to a 1.6.X version, but I don't
have the time to do that today :(
(I hope your script can help here)
Bert
>
> ~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=/path/to/built_subversion_source_tree
> # function svn() { ${SVNDIR}/subversion/svn/svn "$@"; }
> # function svnserve() { ${SVNDIR}/subversion/svnserve/svnserve "$@"; }
> # function svnadmin() { ${SVNDIR}/subversion/svnadmin/svnadmin "$@"; }
>
> set -e
>
> svn --version
> REPOS="`pwd`/repos"
> URL="file://$REPOS"
> rm -rf repos wc
> svnadmin create repos
> cat > repos/hooks/pre-revprop-change <<EOF
> #!/bin/sh
> exit 0;
> EOF
> chmod a+x repos/hooks/pre-revprop-change
>
> 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
> cp file old_state_of_file
> svn add file old_state_of_file
>
> mkdir folder
> echo "r1" > folder/this_is_revision_1_of_folder
> svn add folder
>
> echo file_with_props > file_with_props
> svn add file_with_props
> svn ps prop_r1_on_deleted_file value_r1 file_with_props
> svn ps this_is_rev deleted_r1 file_with_props
>
> svn ci -mr1
> svn up
>
>
>
> echo "r2" > folder/no,_this_is_revision_2_of_folder
> svn add folder/no,_this_is_revision_2_of_folder
>
> svn ps prop_r2_on_deleted_file deleted_r2 file_with_props
> svn ps this_is_rev deleted_r2 file_with_props
>
> echo "r2 for other_file, i.e. the *copied-here* file's history!" > other_file
> svn add other_file
>
> mkdir other_folder
> echo other_folder/file.r2. > other_folder/file.r2
> svn add other_folder
>
> echo other_file_with_props > other_file_with_props
> svn add other_file_with_props
> svn ps prop_r2_on_copied_here_file copied_r2 other_file_with_props
> svn ps this_is_rev copied_r2 other_file_with_props
>
> svn ci -mr2
> svn up
>
> #svn rm folder
>
> echo "r3" > folder/no,_this_is_revision_3_of_folder
> svn add folder/no,_this_is_revision_3_of_folder
>
> echo "r3 for file, i.e. the deleted file's history." > file
> svn ps prop_r3_on_deleted_file deleted_r3 file_with_props
> svn ps this_is_rev deleted_r3 file_with_props
>
>
> svn ps prop_r3_on_deleted_file deleted_r3 file_with_props
> svn ps this_is_rev copied_r3 other_file_with_props
>
> echo other_folder/file.r3. > other_folder/file.r3
> svn add other_folder/file.r3
>
> svn ci -mr3
> svn up
>
> # to test log, remove these changes:
> #echo "r4 for file, i.e. the deleted file's history." > file
> #svn ps prop_r4_on_deleted_file deleted_r4 file_with_props
> #svn ps this_is_rev deleted_r4 file_with_props
>
> svn rm folder
>
> echo "r4 for other_file, i.e. the copied-here file's *later* history!" > other_file
>
> svn rm other_folder/file.r2
> echo other_folder/file.r4. > other_folder/file.r4
> svn add other_folder/file.r4
>
> svn ps prop_r4_on_copied_here_file copied_r4 other_file_with_props
> svn ps this_is_rev copied_r4 other_file_with_props
>
> svn ci -mr4
> svn up
>
> svn rm file
> svn cp ^/other_file@2 file
> echo "now WORKING for file" >> file
>
> svn cp ^/other_folder@2 folder
> echo "now WORKING for folder/file.r2" >> folder/file.r2
> echo new > folder/now_WORKING_for_folder
> svn add folder/now_WORKING_for_folder
>
> svn rm file_with_props
> svn cp ^/other_file_with_props@2 file_with_props
>
> tmp=/tmp/testing_BASE
> mkdir -p "$tmp"
>
> svn st
>
> set +e
>
> svn cat file@BASE
>
> svn copy file@BASE copy_of_file
> cat copy_of_file
> svn st -v copy_of_file
> svn info copy_of_file
>
> svn copy -rBASE file copy2_of_file
> cat copy2_of_file
> svn st -v copy2_of_file
> svn info copy2_of_file
>
> svn diff --old=file@BASE --new=file
> svn diff -rBASE file
>
> svn export file@BASE "$tmp/exported"
> cat "$tmp/exported"
>
> svn info file@BASE
> svn info -rBASE file
> svn info -rBASE file@BASE
> svn info file
>
> echo "folder exists in -r1:2 and does not exist in -r3:4."
> svn list folder
> svn list -rBASE folder
> svn list folder@BASE
> svn list -rBASE folder@BASE
> svn mkdir folder/another_one
> touch folder/unversioned
> svn list folder
> svn rm --force folder/file.r2
> svn list folder
> svn list -rBASE folder
> svn list -rBASE folder@BASE
> svn list folder@BASE
>
> svn log -v file
> svn log -v file@BASE
> svn log -v -rBASE file@BASE
> svn log -v -rBASE file
>
> cat old_state_of_file
> svn merge --accept=postpone -r1:HEAD file old_state_of_file
> svn st old_state_of_file
> cat old_state_of_file
> svn revert old_state_of_file
> cat old_state_of_file
> svn merge --accept=postpone -r1:HEAD file@BASE old_state_of_file
> svn st old_state_of_file
> cat old_state_of_file
> svn revert old_state_of_file
> cat old_state_of_file
> svn merge --accept=postpone -r1:BASE file@BASE old_state_of_file
> svn st old_state_of_file
> cat old_state_of_file
> svn revert old_state_of_file
> cat old_state_of_file
> svn merge --accept=postpone -r1:BASE file old_state_of_file
> svn st old_state_of_file
> cat old_state_of_file
> # don't svn revert old_state_of_file for mergeinfo:
>
> svn mergeinfo file@BASE old_state_of_file
>
> svn proplist file_with_props
> svn proplist file_with_props@BASE
> #svn propedit
>
> svn propget this_is_rev file_with_props
> svn propget this_is_rev file_with_props@BASE
>
> svn propset --revprop -r1 testrevprop value_in_r1
> svn propset --revprop -r2 testrevprop value_in_r2
> svn propdel --revprop -rBASE testrevprop
> svn propset --revprop -rBASE newrevprop new_value
> svn proplist --revprop -r1
> svn proplist --revprop -r2
>
> svn blame file
> svn blame -rBASE file
> svn blame -rBASE file@BASE
> svn blame file@BASE
>
> svn mkdir -m a_new_revision ^/r5
> svn update -rBASE file
> ls -d r5
>
> svn up
> cd r5
> svn switch -rBASE ../folder
> ls
>
>
> 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.'
> + cp file old_state_of_file
> + svn add file old_state_of_file
> A file
> A old_state_of_file
> + mkdir folder
> + echo r1
> + svn add folder
> A folder
> A folder/this_is_revision_1_of_folder
> + echo file_with_props
> + svn add file_with_props
> A file_with_props
> + svn ps prop_r1_on_deleted_file value_r1 file_with_props
> property 'prop_r1_on_deleted_file' set on 'file_with_props'
> + svn ps this_is_rev deleted_r1 file_with_props
> property 'this_is_rev' set on 'file_with_props'
> + svn ci -mr1
> Adding file
> Adding file_with_props
> Adding folder
> Adding folder/this_is_revision_1_of_folder
> Adding old_state_of_file
> Transmitting file data ....
> Committed revision 1.
> + svn up
> At revision 1.
> + echo r2
> + svn add folder/no,_this_is_revision_2_of_folder
> A folder/no,_this_is_revision_2_of_folder
> + svn ps prop_r2_on_deleted_file deleted_r2 file_with_props
> property 'prop_r2_on_deleted_file' set on 'file_with_props'
> + svn ps this_is_rev deleted_r2 file_with_props
> property 'this_is_rev' set on 'file_with_props'
> + echo 'r2 for other_file, i.e. the *copied-here* file'\''s history!'
> + svn add other_file
> A other_file
> + mkdir other_folder
> + echo other_folder/file.r2.
> + svn add other_folder
> A other_folder
> A other_folder/file.r2
> + echo other_file_with_props
> + svn add other_file_with_props
> A other_file_with_props
> + svn ps prop_r2_on_copied_here_file copied_r2 other_file_with_props
> property 'prop_r2_on_copied_here_file' set on 'other_file_with_props'
> + svn ps this_is_rev copied_r2 other_file_with_props
> property 'this_is_rev' set on 'other_file_with_props'
> + svn ci -mr2
> Sending file_with_props
> Adding folder/no,_this_is_revision_2_of_folder
> Adding other_file
> Adding other_file_with_props
> Adding other_folder
> Adding other_folder/file.r2
> Transmitting file data ....
> Committed revision 2.
> + svn up
> At revision 2.
> + echo r3
> + svn add folder/no,_this_is_revision_3_of_folder
> A folder/no,_this_is_revision_3_of_folder
> + echo 'r3 for file, i.e. the deleted file'\''s history.'
> + svn ps prop_r3_on_deleted_file deleted_r3 file_with_props
> property 'prop_r3_on_deleted_file' set on 'file_with_props'
> + svn ps this_is_rev deleted_r3 file_with_props
> property 'this_is_rev' set on 'file_with_props'
> + svn ps prop_r3_on_deleted_file deleted_r3 file_with_props
> property 'prop_r3_on_deleted_file' set on 'file_with_props'
> + svn ps this_is_rev copied_r3 other_file_with_props
> property 'this_is_rev' set on 'other_file_with_props'
> + echo other_folder/file.r3.
> + svn add other_folder/file.r3
> A other_folder/file.r3
> + svn ci -mr3
> Sending file
> Sending file_with_props
> Adding folder/no,_this_is_revision_3_of_folder
> Sending other_file_with_props
> Adding other_folder/file.r3
> Transmitting file data ...
> Committed revision 3.
> + svn up
> At revision 3.
> + svn rm folder
> D folder/no,_this_is_revision_2_of_folder
> D folder/no,_this_is_revision_3_of_folder
> D folder/this_is_revision_1_of_folder
> D folder
> + echo 'r4 for other_file, i.e. the copied-here file'\''s *later* history!'
> + svn rm other_folder/file.r2
> D other_folder/file.r2
> + echo other_folder/file.r4.
> + svn add other_folder/file.r4
> A other_folder/file.r4
> + svn ps prop_r4_on_copied_here_file copied_r4 other_file_with_props
> property 'prop_r4_on_copied_here_file' set on 'other_file_with_props'
> + svn ps this_is_rev copied_r4 other_file_with_props
> property 'this_is_rev' set on 'other_file_with_props'
> + svn ci -mr4
> Deleting folder
> Sending other_file
> Sending other_file_with_props
> Deleting other_folder/file.r2
> Adding other_folder/file.r4
> Transmitting file data ..
> Committed revision 4.
> + svn up
> At revision 4.
> + svn rm file
> D file
> + svn cp '^/other_file@2' file
> A file
> + echo 'now WORKING for file'
> + svn cp '^/other_folder@2' folder
> A folder/file.r2
> Checked out revision 2.
> A folder
> + echo 'now WORKING for folder/file.r2'
> + echo new
> + svn add folder/now_WORKING_for_folder
> A folder/now_WORKING_for_folder
> + svn rm file_with_props
> D file_with_props
> + svn cp '^/other_file_with_props@2' file_with_props
> A file_with_props
> + tmp=/tmp/testing_BASE
> + mkdir -p /tmp/testing_BASE
> + svn st
> R + file
> A + folder
> M + folder/file.r2
> A folder/now_WORKING_for_folder
> R + file_with_props
> + set +e
> + svn cat file@BASE
> r2 for other_file, i.e. the *copied-here* file's history!
> + svn copy file@BASE copy_of_file
> A copy_of_file
> + cat copy_of_file
> r2 for other_file, i.e. the *copied-here* file's history!
> + svn st -v copy_of_file
> A + - 2 neels copy_of_file
> + svn info copy_of_file
> Path: copy_of_file
> Name: copy_of_file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/copy_of_file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Schedule: add
> Copied From URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
> Copied From Rev: 2
> Last Changed Author: neels
> Last Changed Rev: 2
> Last Changed Date: 2010-01-30 03:47:17 +0100 (Sat, 30 Jan 2010)
> Text Last Updated: 2010-01-30 03:47:26 +0100 (Sat, 30 Jan 2010)
> Checksum: 74caf578c8e8a5a1a206e5ee3a0deacc
>
> + svn copy -rBASE file copy2_of_file
> A copy2_of_file
> + cat copy2_of_file
> r2 for other_file, i.e. the *copied-here* file's history!
> + svn st -v copy2_of_file
> A + - 2 neels copy2_of_file
> + svn info copy2_of_file
> Path: copy2_of_file
> Name: copy2_of_file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/copy2_of_file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Schedule: add
> Copied From URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
> Copied From Rev: 2
> Last Changed Author: neels
> Last Changed Rev: 2
> Last Changed Date: 2010-01-30 03:47:17 +0100 (Sat, 30 Jan 2010)
> Text Last Updated: 2010-01-30 03:47:27 +0100 (Sat, 30 Jan 2010)
> Checksum: 74caf578c8e8a5a1a206e5ee3a0deacc
>
> + svn diff --old=file@BASE --new=file
> Index: file
> ===================================================================
> --- file (working copy)
> +++ file (working copy)
> @@ -1 +1,2 @@
> r2 for other_file, i.e. the *copied-here* file's history!
> +now WORKING for file
> + svn diff -rBASE file
> Index: file
> ===================================================================
> --- file (working copy)
> +++ file (working copy)
> @@ -1 +1,2 @@
> r2 for other_file, i.e. the *copied-here* file's history!
> +now WORKING for file
> + svn export file@BASE /tmp/testing_BASE/exported
> Export complete.
> + cat /tmp/testing_BASE/exported
> r2 for other_file, i.e. the *copied-here* file's history!
> + svn info file@BASE
> Path: file
> Name: file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Last Changed Author: neels
> Last Changed Rev: 3
> Last Changed Date: 2010-01-30 03:47:19 +0100 (Sat, 30 Jan 2010)
>
> + svn info -rBASE file
> Path: other_file
> Name: other_file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Last Changed Author: neels
> Last Changed Rev: 4
> Last Changed Date: 2010-01-30 03:47:21 +0100 (Sat, 30 Jan 2010)
>
> + svn info -rBASE file@BASE
> Path: file
> Name: file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Last Changed Author: neels
> Last Changed Rev: 3
> Last Changed Date: 2010-01-30 03:47:19 +0100 (Sat, 30 Jan 2010)
>
> + svn info file
> Path: file
> Name: file
> URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/file
> Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
> Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
> Revision: 4
> Node Kind: file
> Schedule: replace
> Copied From URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
> Copied From Rev: 2
> Last Changed Author: neels
> Last Changed Rev: 2
> Last Changed Date: 2010-01-30 03:47:17 +0100 (Sat, 30 Jan 2010)
> Text Last Updated: 2010-01-30 03:47:23 +0100 (Sat, 30 Jan 2010)
> Checksum: 74caf578c8e8a5a1a206e5ee3a0deacc
>
> + echo 'folder exists in -r1:2 and does not exist in -r3:4.'
> folder exists in -r1:2 and does not exist in -r3:4.
> + svn list folder
> file.r2
> + svn list -rBASE folder
> file.r2
> + svn list folder@BASE
> no,_this_is_revision_2_of_folder
> this_is_revision_1_of_folder
> + svn list -rBASE folder@BASE
> no,_this_is_revision_2_of_folder
> this_is_revision_1_of_folder
> + svn mkdir folder/another_one
> A folder/another_one
> + touch folder/unversioned
> + svn list folder
> file.r2
> + svn rm --force folder/file.r2
> D folder/file.r2
> + svn list folder
> file.r2
> + svn list -rBASE folder
> file.r2
> + svn list -rBASE folder@BASE
> no,_this_is_revision_2_of_folder
> this_is_revision_1_of_folder
> + svn list folder@BASE
> no,_this_is_revision_2_of_folder
> this_is_revision_1_of_folder
> + svn log -v file
> ------------------------------------------------------------------------
> r4 | neels | 2010-01-30 03:47:21 +0100 (Sat, 30 Jan 2010) | 1 line
> Changed paths:
> D /folder
> M /other_file
> M /other_file_with_props
> D /other_folder/file.r2
> A /other_folder/file.r4
>
> r4
> ------------------------------------------------------------------------
> r2 | neels | 2010-01-30 03:47:17 +0100 (Sat, 30 Jan 2010) | 1 line
> Changed paths:
> M /file_with_props
> A /folder/no,_this_is_revision_2_of_folder
> A /other_file
> A /other_file_with_props
> A /other_folder
> A /other_folder/file.r2
>
> r2
> ------------------------------------------------------------------------
> + svn log -v file@BASE
> ------------------------------------------------------------------------
> r3 | neels | 2010-01-30 03:47:19 +0100 (Sat, 30 Jan 2010) | 1 line
> Changed paths:
> M /file
> M /file_with_props
> A /folder/no,_this_is_revision_3_of_folder
> M /other_file_with_props
> A /other_folder/file.r3
>
> r3
> ------------------------------------------------------------------------
> r1 | neels | 2010-01-30 03:47:15 +0100 (Sat, 30 Jan 2010) | 1 line
> Changed paths:
> A /file
> A /file_with_props
> A /folder
> A /folder/this_is_revision_1_of_folder
> A /old_state_of_file
>
> r1
> ------------------------------------------------------------------------
> + svn log -v -rBASE file@BASE
> ------------------------------------------------------------------------
> + svn log -v -rBASE file
> ------------------------------------------------------------------------
> r4 | neels | 2010-01-30 03:47:21 +0100 (Sat, 30 Jan 2010) | 1 line
> Changed paths:
> D /folder
> M /other_file
> M /other_file_with_props
> D /other_folder/file.r2
> A /other_folder/file.r4
>
> r4
> ------------------------------------------------------------------------
> + cat old_state_of_file
> r1 for file, i.e. the deleted file's history.
> + svn merge --accept=postpone -r1:HEAD file old_state_of_file
> --- Merging r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> --- Recording mergeinfo for merge of r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> + svn st old_state_of_file
> MM old_state_of_file
> + cat old_state_of_file
> r3 for file, i.e. the deleted file's history.
> + svn revert old_state_of_file
> Reverted 'old_state_of_file'
> + cat old_state_of_file
> r1 for file, i.e. the deleted file's history.
> + svn merge --accept=postpone -r1:HEAD file@BASE old_state_of_file
> --- Merging r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> --- Recording mergeinfo for merge of r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> + svn st old_state_of_file
> MM old_state_of_file
> + cat old_state_of_file
> r3 for file, i.e. the deleted file's history.
> + svn revert old_state_of_file
> Reverted 'old_state_of_file'
> + cat old_state_of_file
> r1 for file, i.e. the deleted file's history.
> + svn merge --accept=postpone -r1:BASE file@BASE old_state_of_file
> --- Merging r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> --- Recording mergeinfo for merge of r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> + svn st old_state_of_file
> MM old_state_of_file
> + cat old_state_of_file
> r3 for file, i.e. the deleted file's history.
> + svn revert old_state_of_file
> Reverted 'old_state_of_file'
> + cat old_state_of_file
> r1 for file, i.e. the deleted file's history.
> + svn merge --accept=postpone -r1:BASE file old_state_of_file
> --- Merging r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> --- Recording mergeinfo for merge of r2 through r4 into 'old_state_of_file':
> U old_state_of_file
> + svn st old_state_of_file
> MM old_state_of_file
> + cat old_state_of_file
> r3 for file, i.e. the deleted file's history.
> + svn mergeinfo file@BASE old_state_of_file
> r3
> + svn proplist file_with_props
> Properties on 'file_with_props':
> prop_r2_on_copied_here_file
> this_is_rev
> + svn proplist file_with_props@BASE
> Properties on 'file_with_props':
> prop_r2_on_copied_here_file
> this_is_rev
> + svn propget this_is_rev file_with_props
> copied_r2
> + svn propget this_is_rev file_with_props@BASE
> copied_r2
> + svn propset --revprop -r1 testrevprop value_in_r1
> property 'testrevprop' set on repository revision 1
> + svn propset --revprop -r2 testrevprop value_in_r2
> property 'testrevprop' set on repository revision 2
> + svn propdel --revprop -rBASE testrevprop
> subversion/svn/main.c:2244: (apr_err=205000)
> svn: Try 'svn help' for more info
> subversion/svn/propdel-cmd.c:108: (apr_err=205000)
> subversion/svn/props.c:60: (apr_err=205000)
> svn: Must specify the revision as a number, a date or 'HEAD' when operating on a revision property
> + svn propset --revprop -rBASE newrevprop new_value
> subversion/svn/main.c:2244: (apr_err=205000)
> svn: Try 'svn help' for more info
> subversion/svn/propset-cmd.c:121: (apr_err=205000)
> subversion/svn/props.c:60: (apr_err=205000)
> svn: Must specify the revision as a number, a date or 'HEAD' when operating on a revision property
> + svn proplist --revprop -r1
> Unversioned properties on revision 1:
> svn:log
> svn:author
> testrevprop
> svn:date
> + svn proplist --revprop -r2
> Unversioned properties on revision 2:
> svn:log
> svn:author
> testrevprop
> svn:date
> + svn blame file
> - - r2 for other_file, i.e. the *copied-here* file's history!
> - - now WORKING for file
> + svn blame -rBASE file
> 4 neels r4 for other_file, i.e. the copied-here file's *later* history!
> + svn blame -rBASE file@BASE
> 3 neels r3 for file, i.e. the deleted file's history.
> + svn blame file@BASE
> 3 neels r3 for file, i.e. the deleted file's history.
> + svn mkdir -m a_new_revision '^/r5'
>
> Committed revision 5.
> + svn update -rBASE file
> At revision 4.
> + ls -d r5
> ls: cannot access r5: No such file or directory
> + svn up
> A r5
> Updated to revision 5.
> + cd r5
> + svn switch -rBASE ../folder
> subversion/svn/switch-cmd.c:141: (apr_err=125002)
> svn: '../folder' does not appear to be a URL
> + ls
>
>
Taking stock: BASE keyword on the command line
Posted by Neels J Hofmeyr <ne...@elego.de>.
Neels J Hofmeyr wrote:
> Starting from 'svn help', I see these commands where @BASE is applicable:
>
> blame (praise, annotate, ann)
> cat
> copy (cp)
> diff (di)
> export
> info
> list (ls)
> log
> merge
> mergeinfo
> move (mv, rename, ren)
> propdel (pdel, pd)
> propedit (pedit, pe)
> propget (pget, pg)
> proplist (plist, pl)
> propset (pset, ps)
> switch (sw)
> update (up)
DISCLAIMER: I have not tested with mixed-revision working copies.
And the results are... Some are consistent, and some are just *wild* AFAICT.
These commands interpret @BASE to mean...
--------------------------+----------------------------
the pristine of the | "what I checked out":
copied-here node: |
--------------------------+----------------------------
cat | update (but see below)
copy | (prop*)
diff | (merge)
export |
|
These make no difference if BASE is supplied
or not and always use 'what I checked out'
--------------------------------------------
prop*
merge
These don't accept BASE, though 'svn help' lists it.
----------------------------------------------------
switch
prop* --revprop
move
These are inconsistent in their use of BASE,
either acting different between -rBASE and
@BASE and/or being plain wrong. (more below)
--------------------------------------------
info
list
log
blame
But what shows in these "inconsistent" ones is a slight tendency to mean
'copy-from' when saying -rBASE and 'what I checked out' when saying @BASE,
within the use of the same command, where @BASE is stronger than -rBASE.
Though, in many cases this only holds true because -rBASE simply has no
effect at all, and not providing any revision or keyword selects 'copy-from'
by default. Read all the details below.
Details:
* move
'svn help' talks about a --revision option and a BASE keyword, but dude,
that just makes no sense.
* switch
'svn help' talks about a --revision option and a BASE keyword, but it
refuses to accept "BASE".
* update
update just uses the revision number "I checked out" and it is a no-op in an
up-to-date state. Otherwise it is a special case of a 'time-warp' update,
i.e. when specifying a folder, all its children are pulled back or forward
so that they match the folder's current "checked out" revision number.
* blame
'svn blame file'
tries to show a 'blame' for the locally modified state.
So I guess count it as based on the copied-here state.
'svn blame -rBASE file'
shows the copied-from URL's blame, but at the "checked out" revision, which
may be newer than the copied-from revision. This is not at all related to
either of the copied-here or "checked out" nodes' histories.
'svn blame file@BASE' and
'svn blame -rBASE file@BASE'
both show the blame of the file "I checked out".
* prop*
For normal props, using "BASE" makes no difference.
The BASE keyword is not available for the prop* --revprop commands.
[[[
svn: Must specify the revision as a number, a date or 'HEAD' when operating
on a revision property
]]]
* list
'svn list folder' and
'svn list -rBASE folder'
both show the listing of the copied-from URL and Revision (omitting any
local additions and deletions).
'svn list folder@BASE' and
'svn list -rBASE folder@BASE'
both show the listing of the URL "I checked out",
but at the copied-from revision (makes no sense).
* log
'svn log -v file' and
'svn log -v -rBASE file'
both show the log of the copied-here node, but they start at the "checked
out" revision (going backwards), showing some history that is not related to
the node, because it happened on the copy-from node *after* the copy-from
revision.
'svn log -v file@BASE'
'svn log -v -rBASE file@BASE'
both show the log of the node "I checked out".
In log, passing -rBASE causes the log to only show the node's log for the
"checked out" revision number. So 'log -rBASE file@BASE' is empty when the
"checked out" node had no changes in the "checked out" revision number.
* info
'svn info file'
shows the complete information:
The usual info is "what I checked out", and the copied-here node is
correctly indicated in Copied From URL and Rev.
Interestingly, Last Changed Rev reflects copied-here, not "what I checked
out". This could be argued about (not related to @BASE keyword).
[[[
+ svn info file
Path: file
Name: file
URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/file
Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
Revision: 4
Node Kind: file
Schedule: replace
Copied From URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
Copied From Rev: 2
Last Changed Author: neels
Last Changed Rev: 2
Last Changed Date: 2010-01-30 03:47:17 +0100 (Sat, 30 Jan 2010)
Text Last Updated: 2010-01-30 03:47:23 +0100 (Sat, 30 Jan 2010)
Checksum: 74caf578c8e8a5a1a206e5ee3a0deacc
]]]
'svn info file@BASE' and
'svn info -rBASE file@BASE'
both show only "what I checked out".
[[[
+ svn info file@BASE
Path: file
Name: file
URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/file
Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
Revision: 4
Node Kind: file
Last Changed Author: neels
Last Changed Rev: 3
Last Changed Date: 2010-01-30 03:47:19 +0100 (Sat, 30 Jan 2010)
]]]
(I was consistently at revision 4 before doing the replace, and I copied
from revision 2. So this case clearly interprets BASE as 4, meaning "what I
checked out". The URL is also "what I checked out".)
However,
'svn info -rBASE file'
shows a bad mixture:
[[[
+ svn info -rBASE file
Path: other_file
Name: other_file
URL: file:///home/neels/hg/svn/tests/cat_replaced/repos/other_file
Repository Root: file:///home/neels/hg/svn/tests/cat_replaced/repos
Repository UUID: c57cfc0c-0d49-11df-b658-41678fc56d06
Revision: 4
Node Kind: file
Last Changed Author: neels
Last Changed Rev: 4
Last Changed Date: 2010-01-30 03:47:21 +0100 (Sat, 30 Jan 2010)
]]]
- Path and Name show the copied-from basename (!?),
- URL shows the copied-from path, but
- Revision, Date and Last Changed show the revision number "I checked out",
referring to the copied-from history (in the future after the copy-from
rev).
Test attached. Note that some lines are good to uncomment/comment to see
through some cases (e.g. for log and info; should be marked). Most things
are plain, though.
...phew, what donkey work. XP
Now To The Drawing Boards, you guys!
*ALL OUR "BASE" ARE BELONG TO US!!*
~Neels
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
Julian Foad wrote:
> Neels J Hofmeyr wrote:
>> *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?
>
> Correct - that's what I thought. Now that you have pointed out that "cat
> -r BASE" doesn't behave like that - and we don't know how many commands
> do or don't - I might change my mind.
>
> (I keep saying "what about the other commands?". 'cat' and 'diff' are
> important but 'export' and 'merge (from)' and 'copy (from)' and
> 'proplist' and the rest need to agree too.)
Starting from 'svn help', I see these commands where @BASE is applicable:
blame (praise, annotate, ann)
cat
copy (cp)
diff (di)
export
info
list (ls)
log
merge
mergeinfo
move (mv, rename, ren)
propdel (pdel, pd)
propedit (pedit, pe)
propget (pget, pg)
proplist (plist, pl)
propset (pset, ps)
switch (sw)
update (up)
But I'd like to note that it's unlikely that any of these correlate @BASE to
the revert-base. AFAIK 'cat' uses the same API as the other commands to
resolve "@BASE" (which is parsed to svn_opt_revision_base).
As Bert said, only commit and revert so far use the revert-base at all, and
that is not based (argh) on the keyword "@BASE".
Disclaimer: I don't know for sure though, a check wouldn't hurt (except
being quite boring probably).
>
>> In fact, "@BASE" currently means "the to-be-committed node's history's tip".
>> (See attached short test script and output from trunk.)
>
> Would you mind extending your script to test the other commands? As I
Who, me?? ;)
> mentioned before, 'diff' supports both ways and I don't trust 'cat'.
Yes, I wouldn't depend on 'cat' either, but 'cat' was the easiest way to
show what I wanted to show.
Regardless, I think both ways are valid, for all commands in question:
That a user wants to {see the diff against|export|cat|...} the original
revert-base, or that a user wants the to-be-committed-node's "newer base".
<rant>
For example, when looking at your local mods with diff (just diff now), it
*can* be nicer to *not* see a replaced file's "- - -" lines in the diff. But
when you want to see how the replacing file differs from the replaced file,
you specifically want to see the differences between those. You could argue
that when replacing, the two versions shouldn't be structurally similar
anyway -- which I'd question, but even if: What if someone replaced by
accident and wants to see what's going on? Running svn diff on the replaced
and then unmodified file *shows empty* even if the replaced file is
completely different from the replacing file! That is an intuitive
catastrophe for that particular user and "he will break everything in the
wake of the false impression that the two contents are the same". IMHO
having a lot of "- - -" lines for the replaced file is less dangerous and
more accurate. In Bert's opinion (just guessing now!) it's dumb to have the
replaced file involved in the diff. I'm trying to showcase that every
command has this duality and desperately needs clarification anyway.
So I say we definitely need another keyword and then document both of them
properly. Oh, you agreed with that already? Well, then... ;)
</rant>
Next, someone in this room (dev@) will test all the cases and then we decide
whether to add "@ORIG"/"@REVERT" or "@NEWBASE" (or any other names agreed
upon, of course).
~Neels
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Julian Foad <ju...@btopenworld.com>.
Neels J Hofmeyr wrote:
> *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?
Correct - that's what I thought. Now that you have pointed out that "cat
-r BASE" doesn't behave like that - and we don't know how many commands
do or don't - I might change my mind.
(I keep saying "what about the other commands?". 'cat' and 'diff' are
important but 'export' and 'merge (from)' and 'copy (from)' and
'proplist' and the rest need to agree too.)
> In fact, "@BASE" currently means "the to-be-committed node's history's tip".
> (See attached short test script and output from trunk.)
Would you mind extending your script to test the other commands? As I
mentioned before, 'diff' supports both ways and I don't trust 'cat'.
Because 'cat' doesn't work on directory trees, it has not had much
real-world testing for consistency with 'merge' and 'export' and so on -
people would not be so likely to notice any inconsistencies.
- Julian
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
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
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Greg Stein <gs...@gmail.com>.
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.
What do you mean "this". Be explicit... I don't see anything wrong here.
> - 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.
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. So you're talking about a
'delete' followed by a 'copy' into the same location. 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.
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.
Cheers,
-g
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
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 <ne...@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@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
>>
>
Re: '@BASE' vs. 'BASE tree' -- was: Re:
svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Julian Foad <ju...@btopenworld.com>.
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
Re: '@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
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 <ne...@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@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
>
>
Re: '@BASE' vs. 'BASE tree' -- was: Re:
svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Julian Foad <ju...@btopenworld.com>.
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 <ne...@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.
> Until told otherwise, I thought 'svn cat
> file@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 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.
- 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
'@BASE' vs. 'BASE tree' -- was: Re: svn_wc__db_base_get_info()
vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
Greg Stein wrote:
> On Wed, Jan 27, 2010 at 16:51, Neels J Hofmeyr <ne...@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. Until told otherwise, I thought 'svn cat
file@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").
>> (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
Re: svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jan 27, 2010 at 16:51, Neels J Hofmeyr <ne...@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.
>...
>> the WORKING tree, revision will always be SVN_INVALID_REVNUM, and the
>> repos_relpath/root_url will be NULL.
>
> Hadn't seen it that clear yet.
>
> But read_info fills up the revision, repos_relpath and root_url from the
> BASE tree even when a node is present in the WORKING tree, right?
> (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.
> So when read_info returns a non-"empty" revision, repos_relpath or root_url,
> then these values have definitely come from the BASE tree?
Yes.
> Does that mean the two calls that only ask status, revision, repos_relpath
> and root_url, passing NULL for all other return-parameters, are in fact
> perfectly identical?
No. If you have both a BASE node and a WORKING node, then
base_get_info will return data about the BASE node, and read_info will
return NULL values.
If there is no WORKING node, then yes: the two will be equivalent for
those param values.
Cheers,
-g
Re: svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jan 27, 2010 at 18:15, Neels J Hofmeyr <ne...@elego.de> wrote:
>
> Neels J Hofmeyr wrote:
>> So when read_info returns a non-"empty" revision, repos_relpath or root_url,
>> then these values have definitely come from the BASE tree?
>
> I see in the code that that's not the case.
> So the two calls are only identical when there is no WORKING node for that path.
If there is a WORKING node, then *revision WILL be set to
INVALID_REVNUM, and *repos_relpath and *repos_root_url WILL be set to
NULL.
The *only* way you'll get values for those is when there is NOT a
WORKING node. Thus, the values represent information about the BASE
node.
Cheers,
-g
Re: svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
Neels J Hofmeyr wrote:
> So when read_info returns a non-"empty" revision, repos_relpath or root_url,
> then these values have definitely come from the BASE tree?
I see in the code that that's not the case.
So the two calls are only identical when there is no WORKING node for that path.
nm / sorry for bothering again
heh, I tried grokking the comments when the implementation says it all :)
~Neels
> Does that mean the two calls that only ask status, revision, repos_relpath
> and root_url, passing NULL for all other return-parameters, are in fact
> perfectly identical?
>
>> err = svn_wc__db_base_get_info(&status, NULL,
>> &revision,
>> &repos_relpath,
>> &repos_root_url,
>> NULL, NULL, NULL, NULL, NULL, NULL,
>> NULL, NULL, NULL, NULL,
>> eb->db,
>> local_abspath,
>> result_pool,
>> scratch_pool);
>
>> SVN_ERR(svn_wc__db_read_info(&status, NULL,
>> &revision,
>> &repos_relpath,
>> &repos_root_url,
>> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> NULL, NULL, NULL,
>> eb->db, local_abspath,
>> result_pool, scratch_pool))
>
> Thanks!
> ~Neels
>
>
Re: svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Neels J Hofmeyr <ne...@elego.de>.
Greg Stein wrote:
> base_get_info returns information about the BASE tree.
>
> read_info returns information about the WORKING tree, or if a
> specified node is not present in WORKING, then info from the BASE
> tree.
Nice, thanks for the clear info.
> 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 :)
BTW, is that svn_wc__db_pristine? WORKING's BASE? :P
> the WORKING tree, revision will always be SVN_INVALID_REVNUM, and the
> repos_relpath/root_url will be NULL.
Hadn't seen it that clear yet.
But read_info fills up the revision, repos_relpath and root_url from the
BASE tree even when a node is present in the WORKING tree, right?
(read_info's comment sounds like it:
" * The information returned comes from the BASE tree, as possibly modified
* by the WORKING and ACTUAL trees. ")
So when read_info returns a non-"empty" revision, repos_relpath or root_url,
then these values have definitely come from the BASE tree?
Does that mean the two calls that only ask status, revision, repos_relpath
and root_url, passing NULL for all other return-parameters, are in fact
perfectly identical?
> err = svn_wc__db_base_get_info(&status, NULL,
> &revision,
> &repos_relpath,
> &repos_root_url,
> NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL,
> eb->db,
> local_abspath,
> result_pool,
> scratch_pool);
> SVN_ERR(svn_wc__db_read_info(&status, NULL,
> &revision,
> &repos_relpath,
> &repos_root_url,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL,
> eb->db, local_abspath,
> result_pool, scratch_pool))
Thanks!
~Neels
Re: svn_wc__db_base_get_info() vs. svn_wc__db_read_info() ?
Posted by Greg Stein <gs...@gmail.com>.
base_get_info returns information about the BASE tree.
read_info returns information about the WORKING tree, or if a
specified node is not present in WORKING, then info from the BASE
tree.
and recall that BASE == what you checked out from the repository.
WORKING corresponds to added/removed/copied/moved nodes. For nodes in
the WORKING tree, revision will always be SVN_INVALID_REVNUM, and the
repos_relpath/root_url will be NULL.
Cheers,
-g
On Tue, Jan 26, 2010 at 19:20, Neels J Hofmeyr <ne...@elego.de> wrote:
> How does
>
> err = svn_wc__db_base_get_info(&status, NULL,
> &revision,
> &repos_relpath,
> &repos_root_url,
> NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL,
> eb->db,
> local_abspath,
> result_pool,
> scratch_pool);
>
> differ from
>
> SVN_ERR(svn_wc__db_read_info(&status, NULL,
> &revision,
> &repos_relpath,
> &repos_root_url,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL,
> eb->db, local_abspath,
> result_pool, scratch_pool));
>
> ?
>
> Thanks,
> ~Neels
>
>