You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Peter Hercek <pe...@syncad.com> on 2004/10/06 17:29:45 UTC
url search pegged to revision at BASE; documentation bug
Hi all,
I already posted about this, but nobody responded.
So I'm trying a luck again since it itches my mind :)
Version 1.1 introduces peg version at BASE for cat
diff, blame, switch, merge, update, proplist, propget
commands.
It probably does not make sense for add, co, cleanup,
ci, delete, export, help, import, info, mkdir, move,
resolved, revert, status since they do not have any
BASE to take the pegged revision from or do not
have revision switch at all.
I'm not sure how it is with propdel, propedit and propset.
Does anybody know?
Log command stays as it was (ie the path is searched
in a revision specified by -r argument instead of being
pegged to BASE). I'm not sure whether it was intended.
Is this intentional? If yes, what is the reasoning for
having two different ways for locating objects in the
repository for commands which share these properties:
* do have meanigfull -r argument
* do have BASE
BTW, svn help move reports that move command can
use -r argument, but it looks like it is not applicable.
Peter.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: url search pegged to revision at BASE; documentation bug
Posted by Peter Hercek <pe...@syncad.com>.
Hi Ben,
Thanks for the answer. I try to clarify the meaning of my post
a little more.
----- Original Message -----
From: "Ben Collins-Sussman" <su...@collab.net>
To: "Peter Hercek" <pe...@syncad.com>
Cc: <us...@subversion.tigris.org>
Sent: Wednesday, October 06, 2004 21:02
Subject: Re: url search pegged to revision at BASE; documentation bug
> On Oct 6, 2004, at 12:29 PM, Peter Hercek wrote:
> >
> > I'm not sure how it is with propdel, propedit and propset.
> > Does anybody know?
>
> These prop commands affect the WC only, and do not talk to the server.
> There's no "history tracing" involved, so I don't see how a "peg" would
> make any sense.
Property related commands can work with repository URLs directly.
In the case they modify the repository, they must work with unversioned
properties. I checked proplist and propget and found that they are pegged.
I did not check the commands, which modify the repository since it does
not work by default (I think some priviledges must be enabled to modify
unversioned properties, like svn:log). Here is the example of my test with
proplist on a data which have been moved from svn://svn/trunk/simwrap
to svn://svn/trunk/src/simwrap in our source tree somewhere around revision
25000. The properties have been defined just after the move:
1 % pwd
/cygdrive/c/src/simwrap
2 % svn info wrapper.h |grep -E '(URL|Revision)'
URL: svn://svn/trunk/src/simwrap/wrapper.h
Revision: 28847
3 % svn proplist wrapper.h
Properties on 'wrapper.h':
svn:mime-type
svn:eol-style
4 % svn proplist -r 24000 wrapper.h
5 % svn list -r 24000 svn://svn/trunk/src/simwrap
svn: URL 'svn://svn/trunk/src/simwrap' non-existent in that revision
6 % svn list -r 26000 svn://svn/trunk/src/simwrap |grep wrapper.h
wrapper.h
7 % svn proplist -r 24000 svn://svn/trunk/src/simwrap/wrapper.h
svn: Unknown node kind for 'svn://svn/trunk/src/simwrap/wrapper.h'
8 % svn proplist -r 24000 svn://svn/trunk/simwrap/wrapper.h
9 %
The point is that the command number 4 did not print error that the
object does not exist at that revision, so the starting search point
was probably correctly pegged to BASE. I think the behavior of
proplist is logical. Propget behaves similarly.
> >
> > Log command stays as it was (ie the path is searched
> > in a revision specified by -r argument instead of being
> > pegged to BASE). I'm not sure whether it was intended.
> > Is this intentional? If yes, what is the reasoning for
> > having two different ways for locating objects in the
> > repository for commands which share these properties:
> > * do have meanigfull -r argument
> > * do have BASE
>
> 'svn log' has always been pegged at BASE. I don't understand what
> you're asking.
In that case, this would indicate a bug in svn log command (or my
deep misunderstanding of the whole pegging feature); notice the
differences in behavior of log and diff comamnds:
10 % svn diff -r 23000:24000 wrapper.h |grep Index
Index: wrapper.h
11 % svn log -r 23000:24000 wrapper.h
svn: File not found: revision 24000, path '/trunk/src/simwrap/wrapper.h'
12 % svn log -r 23000:24000 svn://svn/trunk/src/simwrap/wrapper.h@28847
svn: File not found: revision 24000, path '/trunk/src/simwrap/wrapper.h@28847'
13 % svn log -r 23000:24000 svn://svn/trunk/simwrap/wrapper.h
------------------------------------------------------------------------
r23455 | hagop | 2003-11-12 12:53:18 -0500 (Wed, 12 Nov 2003) | 2 lines
some preparation work for merging PM Thread and LLW Thread on UNIX systems
------------------------------------------------------------------------
14 % svn diff -r 23000:24000 svn://svn/trunk/src/simwrap/wrapper.h |grep Index
Index: wrapper.h
15 % svn diff -r 23000:24000 svn://svn/trunk/simwrap/wrapper.h |grep Index
svn: File not found: revision 28852, path '/trunk/simwrap/wrapper.h'
16 % svn diff -r 23000:24000 svn://svn/trunk/simwrap/wrapper.h@24000 |grep Index
Index: wrapper.h
17 %
Remarks:
* command 11: should have succeeded if the search would start
from a revision pegged to base
* command 12: explicit peging does not work for log (but it
works for diff)
* command 14: huh, this diff command should not succeed;
the file wrapper.h did not exits in svn://svn/trunk/src/simwrap in the
range of revisions 23000:24000 (it was in svn://svn/trunk/simwrap);
it should not have been found since I specified URL; so there was
no BASE to take into account
* command 15: huh, huh; how it is possible it figured out the BASE,
when I specified URL only; and provided that it should have, then
command 5 should have succeeded too; compare also with the
results from command 11
* command 16: explicit pegging works with diff (conatrary to log as
shown in command 12)
In general, I like the peging feature, but it is too inconstistent across
commands.
Thanks,
Peter.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: url search pegged to revision at BASE; documentation bug
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 6, 2004, at 12:29 PM, Peter Hercek wrote:
>
> I'm not sure how it is with propdel, propedit and propset.
> Does anybody know?
These prop commands affect the WC only, and do not talk to the server.
There's no "history tracing" involved, so I don't see how a "peg" would
make any sense.
>
> Log command stays as it was (ie the path is searched
> in a revision specified by -r argument instead of being
> pegged to BASE). I'm not sure whether it was intended.
> Is this intentional? If yes, what is the reasoning for
> having two different ways for locating objects in the
> repository for commands which share these properties:
> * do have meanigfull -r argument
> * do have BASE
'svn log' has always been pegged at BASE. I don't understand what
you're asking.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org