You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Victoria Muntean <vi...@gmail.com> on 2009/04/20 08:47:35 UTC
@REV vs -r REV
I discovered that @REV and -r REV, when used in 'svn cat', produce
different results.
I admit I thought that @REV is synonym of '-r REV' were the same
thing, just different syntax.
What is the explanation of their differences ?
Do they behave differently in other svn commands, or only in 'svn cat' ?
Thanks
Viki
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1821354
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 20, 2009, at 03:47, Victoria Muntean wrote:
> I discovered that @REV and -r REV, when used in 'svn cat', produce
> different results.
> I admit I thought that @REV is synonym of '-r REV' were the same
> thing, just different syntax.
>
> What is the explanation of their differences ?
> Do they behave differently in other svn commands, or only in 'svn
> cat' ?
The difference between @REV (peg revision) and -rREV (operative
revision) is explained in the book:
http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1842339
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Matthew Pounsett <ma...@conundrum.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 20-Apr-2009, at 05:23, Bert Huijben wrote:
>> The command
> svn cat http://server/url/file@123 -r 64
>
> looks at the url http://server/url/file as it was in revision 123,
> and then
> looks at the history of the specified file to retrieve revision 64
> of that
> file. (That file could be copied between r64 and r123)
>
> svn cat http://server/url/file -r 64
>
> looks at the url http://server/url/file in the latest revision
> (HEAD), and
> then looks at this file.. and traces the file back to r64.
>
> svn cat http://server/url/file@64
> is actually svn cat http://server/url/file@64 -r 64, as the -r command
> defaults to the operational revision specified with the @64 syntax.
The reason why this is important is that http://server/url/file@123
and http://server/url/file@64 have the same path, but MAY be different
files unconnected by history.
For example,
% svn info file | grep URL
URL: http://server/url/file
% svn update
At revision 75.
% svn rm http://server/url/file
Committed revision 76.
% svn update
D file
Updated to revision 76.
% svn copy http://server/url/photo http://server/url/file
Committed revision 77.
% svn update
A file
% svn info file | grep URL
URL: http://server/url/file
Now assume some time passes and we make it to revision 123.
References to http://server/url/file@123 will not have a shared
history with http://server/url/file@64 because that file got deleted
at revision 76, and a new file was created at the same path by copying http://server/url/photo
.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)
iEYEARECAAYFAknsgAMACgkQmFeRJ0tjIxFOoQCbBwDGgfiYEzsfTMOGuwkecHmw
dyYAnRHfHMDWIv3B9+Q7uqIqoAw2nnqR
=0TTe
-----END PGP SIGNATURE-----
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1825243
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: @REV vs -r REV
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Victoria Muntean [mailto:vikimun@gmail.com]
> Sent: maandag 20 april 2009 10:48
> To: users@subversion.tigris.org
> Subject: @REV vs -r REV
>
> I discovered that @REV and -r REV, when used in 'svn cat', produce
> different results.
> I admit I thought that @REV is synonym of '-r REV' were the same
> thing, just different syntax.
>
> What is the explanation of their differences ?
> Do they behave differently in other svn commands, or only in 'svn cat' ?
The command
svn cat http://server/url/file@123 -r 64
looks at the url http://server/url/file as it was in revision 123, and then
looks at the history of the specified file to retrieve revision 64 of that
file. (That file could be copied between r64 and r123)
svn cat http://server/url/file -r 64
looks at the url http://server/url/file in the latest revision (HEAD), and
then looks at this file.. and traces the file back to r64.
svn cat http://server/url/file@64
is actually svn cat http://server/url/file@64 -r 64, as the -r command
defaults to the operational revision specified with the @64 syntax.
This behavior is (or at least should be) the same for all commands that
operate on urls. (The @ syntax on local paths is translated to the url of
the path)
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1821763
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: @REV vs -r REV
Posted by Giulio T <gi...@uk.linedata.com>.
> Greetings, Giulio T!
>
> >> >> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 25
>
> >> >> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 23
> >> >>
>
> > To me it seems obvious that svn can't find the file. You're
> asking for
> > a revision (with the -r option) that is past the peg revision
> > (specified by the @). It's like saying, what did you look like when
> > you were 20 if you consider yourself 15 now?
>
> Comparing SVN to yourself is not going to help well, unless
> you've been resurrected already :)
>
> > Or maybe I got the idea of operation and peg revisions
> completely wrong.
>
> If you take a closer look at the script attached to my
> previous post, you'll see that file1@1 and file1@2 is a two
> different files.
> Completely different.
>
> If you want translation of my construction to "normal
> english", it would read
> svn cat "Show me
> -r HEAD current content
> file://repos/file1@1 of the file that originating
> from /file1 in revision 1
I think this is where you get it wrong. I think a better "translation" would be
svn cat -> show me
-r HEAD -> current content
file//repos/file@1 -> of the file as it WAS in revision 1
But there isn't a "current content" (i.e. revision 25) in revision 1. It doesn't make sens. Well not to me at least.
It looks like the problem is becuase file1 in revision 22 is not the same as in HEAD (because of the delete and copy). If you look at the Subversion Book there is an explenation of the peg revision algorithm that explains very well why that command failed (I have the book for svn 1.4)
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1858250
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: @REV vs -r REV
Posted by Bert Huijben <rh...@sharpsvn.net>.
[Sorry; second mail.. back to the list now]
> -----Original Message-----
> From: Andrey Repin [mailto:anrdaemon{_AT_}freemail.ru]
> Sent: woensdag 22 april 2009 12:04
> To: Giulio T; users@subversion.tigris.org
> Subject: Re: @REV vs -r REV
>
> Greetings, Giulio T!
>
> >> >> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 25
>
> >> >> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 23
> >> >>
>
> > To me it seems obvious that svn can't find the file. You're asking for a
> > revision (with the -r option) that is past the peg revision (specified
by
> > the @). It's like saying, what did you look like when you were 20 if you
> > consider yourself 15 now?
>
> Comparing SVN to yourself is not going to help well, unless you've been
> resurrected already :)
>
> > Or maybe I got the idea of operation and peg revisions completely wrong.
>
> If you take a closer look at the script attached to my previous post,
you'll
> see that file1@1 and file1@2 is a two different files.
> Completely different.
>
> If you want translation of my construction to "normal english", it would
read
> svn cat "Show me
> -r HEAD current content
> file://repos/file1@1 of the file that originating from /file1 in
> revision 1
>
> Because SVN, unlike CVS, *DO* track file renames, it SHOULD find it... but
it
> couldn't...
Subversion tracks the old names of files (where was this path copied from),
but currently it can't answer the question to what was this file renamed.
There are some ideas on adding this forward tracking for file copies and
moves, but I don't think somebody is actively working on integrating this
support right now. (Please correct me if I'm wrong).
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1858183
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: @REV vs -r REV
Posted by Bert Huijben <rh...@sharpsvn.net>.
> -----Original Message-----
> From: Andrey Repin [mailto:anrdaemon@freemail.ru]
> Sent: woensdag 22 april 2009 12:04
> To: Giulio T; users@subversion.tigris.org
> Subject: Re: @REV vs -r REV
>
> Greetings, Giulio T!
>
> >> >> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 25
>
> >> >> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 23
> >> >>
>
> > To me it seems obvious that svn can't find the file. You're asking for a
> > revision (with the -r option) that is past the peg revision (specified
by
> > the @). It's like saying, what did you look like when you were 20 if you
> > consider yourself 15 now?
>
> Comparing SVN to yourself is not going to help well, unless you've been
> resurrected already :)
>
> > Or maybe I got the idea of operation and peg revisions completely wrong.
>
> If you take a closer look at the script attached to my previous post,
you'll
> see that file1@1 and file1@2 is a two different files.
> Completely different.
>
> If you want translation of my construction to "normal english", it would
read
> svn cat "Show me
> -r HEAD current content
> file://repos/file1@1 of the file that originating from /file1 in
> revision 1
>
> Because SVN, unlike CVS, *DO* track file renames, it SHOULD find it... but
it
> couldn't...
Subversion tracks the old names of files (where was this path copied from),
but currently it can't answer the question to what was this file renamed.
There are some ideas on adding this forward tracking for file copies and
moves, but I don't think somebody is actively working on integrating this
support right now. (Please correct me if I'm wrong).
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1858175
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, David Weintraub!
> All this talk of -r<rev> vs. @<rev> reminds me of something the
> ClearCase people referred to as "Evil Twins".
> In ClearCase parlance, Evil Twins are two different files in two
> different revisions that share the same directory name and file name,
> but have no history in common. It looks like we're getting the same
> problem in Subversion.
In my example case it's not a problem by itself, just a difficulty in
tracking.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 23.04.2009, <3:48>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1868182
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: @REV vs -r REV
Posted by Bob Archer <bo...@amsi.com>.
> It does point out that Subversion does need a term to describe this
> type of namespace overlap, but obviously we can't use Evil Twin
> because the ClearCase people have that.
> Any others?
Twisted Sisters
Dueling Banjos
Gwazi
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1866240
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: @REV vs -r REV
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: David Weintraub [mailto:qazwart@gmail.com]
> Sent: Wednesday, April 22, 2009 10:01 PM
> To: Stephen Connolly
> Cc: users@subversion.tigris.org
> Subject: Re: @REV vs -r REV
>
> > 2009/4/22 David Weintraub <qa...@gmail.com>
> >
> > All this talk of -r<rev> vs. @<rev> reminds me of something the
> > ClearCase people referred to as "Evil Twins".
>
> On Wed, Apr 22, 2009 at 12:32 PM, Stephen Connolly
> <st...@gmail.com> wrote:
> > You can get similar issues with Accurev... where they refer to one
> version
> > as being "stranded" or "overlapped"
>
> Nah, I like Evil Twin better than "overlapped". Evil Twin sounds more
> ominous, and makes my job sound much more dangerous than staring at a
[snip]
>
> Suggestions:
>
> * It's the Ghost of Files Past.
> * That file has been Zombietized.
> * It's a D'FUA (Pronouced Di-fu-a) (Developer "Fouled" Up Again)
>
Evil Twin instantly reminded me of the Hammer House of Horror film,
Twins of Evil, where the (rather busty) Maria and Madeleine Collinson
put on a memorable performance!
So if you want ominous, perhaps the Beast in the Cellar would refer to
the stranded file, or just refer to it as an Undead file (ready to be
resurrected from its grave, by a fearless svn admin)(zombie doesn't
quite have the correct ring to it, and is used for too many other
computing terms)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1878881
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by David Weintraub <qa...@gmail.com>.
> 2009/4/22 David Weintraub <qa...@gmail.com>
>
> All this talk of -r<rev> vs. @<rev> reminds me of something the
> ClearCase people referred to as "Evil Twins".
On Wed, Apr 22, 2009 at 12:32 PM, Stephen Connolly
<st...@gmail.com> wrote:
> You can get similar issues with Accurev... where they refer to one version
> as being "stranded" or "overlapped"
Nah, I like Evil Twin better than "overlapped". Evil Twin sounds more
ominous, and makes my job sound much more dangerous than staring at a
monitor and waiting for someone to mess up. Maybe you could even
finagle a raise out of it.
It does point out that Subversion does need a term to describe this
type of namespace overlap, but obviously we can't use Evil Twin
because the ClearCase people have that.
Suggestions:
* It's the Ghost of Files Past.
* That file has been Zombietized.
* It's a D'FUA (Pronouced Di-fu-a) (Developer "Fouled" Up Again)
Any others?
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1865915
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Stephen Connolly <st...@gmail.com>.
You can get similar issues with Accurev... where they refer to one version
as being "stranded" or "overlapped"
2009/4/22 David Weintraub <qa...@gmail.com>
> All this talk of -r<rev> vs. @<rev> reminds me of something the
> ClearCase people referred to as "Evil Twins".
>
> In ClearCase parlance, Evil Twins are two different files in two
> different revisions that share the same directory name and file name,
> but have no history in common. It looks like we're getting the same
> problem in Subversion.
>
> For example:
>
> Create a new repository and add a directory called foo with a file
> called foobar.txt. Commit your changes.
>
> Your repository looks like this:
>
> foo/foobar.txt
>
> Now create a directory called bar that is a sibling of foo and move
> the file foobar.txt to the bar directory and rename it barfoo.txt.
> Commit your changes.
>
> Your repository looks like this:
>
> foo/
> bar/barfoo.txt
>
> Now create a new file called foobar.txt under the foo directory.
> Commit your changes. Your repository will now look like this:
>
> foo/foobar.txt
> bar/barfoo.txt
>
> To our mortal eyes, we assume that foo/foobar.txt in Rev 1 of the
> repository is an ancestor of foo/foobar.txt in Rev 3 of the
> repository. However, this is not true, and Subversion knows this.
>
> If I do a log on foo/foobar.txt, I don't see that there was a file
> called foo/foobar.txt in Rev 1 of the repository, and doing a diff
> between the working copy and revision 1 doesn't work:
>
> $ svn diff -r1 foo/foobar.txt
> svn: Unable to find repository location for foobar.txt in revision 1.
>
> If, however, I do this:
>
> $ svn diff -r1 foo/foobar.txt@1
> ================================================
> --- foobar.txt (revision 1)
> +++ foobar.txt (working copy)
> - This is a file
> + This is a different file from before
>
> This works because I am now specifying not the file, but the file of
> the same name that was there at revision 1 of the repository.
>
> ClearCase administrators dreaded Evil Twins because they caused so
> much confusion with users. In fact, some sites went so far as to
> design triggers (hooks in Subversion) that would actually prevent you
> from creating Evil Twins. I believe this is why many version control
> systems to this day still do not deal with directory versioning.
>
> --
> David Weintraub
> qazwart@gmail.com
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1862442
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1862773
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Les Mikesell <le...@gmail.com>.
David Weintraub wrote:
>
>
> foo/
> bar/barfoo.txt
>
> Now create a new file called foobar.txt under the foo directory.
> Commit your changes. Your repository will now look like this:
>
> foo/foobar.txt
> bar/barfoo.txt
>
> To our mortal eyes, we assume that foo/foobar.txt in Rev 1 of the
> repository is an ancestor of foo/foobar.txt in Rev 3 of the
> repository. However, this is not true, and Subversion knows this.
Even worse. From a mortal's point of view, the contents of the newly
created foo/foobar.txt may in fact have come directly from
bar/barfoo.txt with associated ancestry through perfectly normal mortal
means of duplicating contents (cut/paste, etc.). However, if you don't
go through the proper steps of subversions's required procedure,
subversion doesn't know this.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1862619
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by David Weintraub <qa...@gmail.com>.
All this talk of -r<rev> vs. @<rev> reminds me of something the
ClearCase people referred to as "Evil Twins".
In ClearCase parlance, Evil Twins are two different files in two
different revisions that share the same directory name and file name,
but have no history in common. It looks like we're getting the same
problem in Subversion.
For example:
Create a new repository and add a directory called foo with a file
called foobar.txt. Commit your changes.
Your repository looks like this:
foo/foobar.txt
Now create a directory called bar that is a sibling of foo and move
the file foobar.txt to the bar directory and rename it barfoo.txt.
Commit your changes.
Your repository looks like this:
foo/
bar/barfoo.txt
Now create a new file called foobar.txt under the foo directory.
Commit your changes. Your repository will now look like this:
foo/foobar.txt
bar/barfoo.txt
To our mortal eyes, we assume that foo/foobar.txt in Rev 1 of the
repository is an ancestor of foo/foobar.txt in Rev 3 of the
repository. However, this is not true, and Subversion knows this.
If I do a log on foo/foobar.txt, I don't see that there was a file
called foo/foobar.txt in Rev 1 of the repository, and doing a diff
between the working copy and revision 1 doesn't work:
$ svn diff -r1 foo/foobar.txt
svn: Unable to find repository location for foobar.txt in revision 1.
If, however, I do this:
$ svn diff -r1 foo/foobar.txt@1
================================================
--- foobar.txt (revision 1)
+++ foobar.txt (working copy)
- This is a file
+ This is a different file from before
This works because I am now specifying not the file, but the file of
the same name that was there at revision 1 of the repository.
ClearCase administrators dreaded Evil Twins because they caused so
much confusion with users. In fact, some sites went so far as to
design triggers (hooks in Subversion) that would actually prevent you
from creating Evil Twins. I believe this is why many version control
systems to this day still do not deal with directory versioning.
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1862442
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Zing!
> Thanks for the script.sh, I understand now. For your script, subversion
> COULD in theory return what you are looking for: the contents of file2@4,
> but the current algorithm can't (it's explained in the peg rev section of
> the book).
> But, things get complicated very easily. If you then do:
> $ svn cp file://$repos/file1@1 file3
> $ svn ci -m 'Commit 5'
> Now what answer would you expect when you run:
> $ svn cat -rHEAD file://$repos/file1@1
Yes, I though about that the other day...
No immediate solutions, though... too tired right now.
> Both file2@5 and file3@5, have lines of history back to file1@1. You just
> can't pick one of the two and show that, although I suppose you could
> display both, but I rather not think about trying to support that. :)
Well, right, but still, there could be more transparent log for
copying-moving.
And more transparently accessible. I'll think about it, when I get time.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 23.04.2009, <3:45>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1868183
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Zing <zi...@fastmail.fm>.
On Wed, 22 Apr 2009, Andrey Repin wrote:
> Greetings, Giulio T!
>
> >> >> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 25
>
> >> >> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
> >> >> svn: Unable to find repository location for
> >> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 23
> >> >>
>
> > To me it seems obvious that svn can't find the file. You're asking for a
> > revision (with the -r option) that is past the peg revision (specified by
> > the @). It's like saying, what did you look like when you were 20 if you
> > consider yourself 15 now?
>
> Comparing SVN to yourself is not going to help well, unless you've been
> resurrected already :)
>
> > Or maybe I got the idea of operation and peg revisions completely wrong.
>
> If you take a closer look at the script attached to my previous post, you'll
> see that file1@1 and file1@2 is a two different files.
> Completely different.
>
> If you want translation of my construction to "normal english", it would read
> svn cat "Show me
> -r HEAD current content
> file://repos/file1@1 of the file that originating from /file1 in revision 1
>
> Because SVN, unlike CVS, *DO* track file renames, it SHOULD find it... but it
> couldn't...
Thanks for the script.sh, I understand now. For your script, subversion
COULD in theory return what you are looking for: the contents of file2@4,
but the current algorithm can't (it's explained in the peg rev section of
the book).
But, things get complicated very easily. If you then do:
$ svn cp file://$repos/file1@1 file3
$ svn ci -m 'Commit 5'
Now what answer would you expect when you run:
$ svn cat -rHEAD file://$repos/file1@1
Both file2@5 and file3@5, have lines of history back to file1@1. You just
can't pick one of the two and show that, although I suppose you could
display both, but I rather not think about trying to support that. :)
Hope that helps.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1861780
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Giulio T!
>> >> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
>> >> svn: Unable to find repository location for
>> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 25
>> >> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
>> >> svn: Unable to find repository location for
>> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 23
>> >>
> To me it seems obvious that svn can't find the file. You're asking for a
> revision (with the -r option) that is past the peg revision (specified by
> the @). It's like saying, what did you look like when you were 20 if you
> consider yourself 15 now?
Comparing SVN to yourself is not going to help well, unless you've been
resurrected already :)
> Or maybe I got the idea of operation and peg revisions completely wrong.
If you take a closer look at the script attached to my previous post, you'll
see that file1@1 and file1@2 is a two different files.
Completely different.
If you want translation of my construction to "normal english", it would read
svn cat "Show me
-r HEAD current content
file://repos/file1@1 of the file that originating from /file1 in revision 1
Because SVN, unlike CVS, *DO* track file renames, it SHOULD find it... but it
couldn't...
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 22.04.2009, <13:56>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1858160
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: @REV vs -r REV
Posted by Giulio T <gi...@uk.linedata.com>.
> >> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
> >> svn: Unable to find repository location for
> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 25
> >> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
> >> svn: Unable to find repository location for
> >> 'http://svn.darkdragon/repos/trunk/file1' in revision 23
> >>
To me it seems obvious that svn can't find the file. You're asking for a revision (with the -r option) that is past the peg revision (specified by the @). It's like saying, what did you look like when you were 20 if you consider yourself 15 now?
Or maybe I got the idea of operation and peg revisions completely wrong.
Giulio
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1857455
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Zing Zing Shishak!
> On Tue, 21 Apr 2009, Andrey Repin wrote:
>> However, I just found an issue...
>>
>> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
>> svn: Unable to find repository location for 'http://svn.darkdragon/repos/trunk/file1' in revision 25
>>
>> I know it's there...
>>
>> I've copied it myself... by my own hands.
>>
>> []$svn cat -r 24 http://svn.darkdragon/repos/trunk/file1@22
>> sdkjsgkjahj
>>
>> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
>> svn: Unable to find repository location for 'http://svn.darkdragon/repos/trunk/file1' in revision 23
>>
>> []$svn cat -r 22 http://svn.darkdragon/repos/trunk/file1@22 (initial import)
>> sdkjsgkjahj
>>
>> And
>>
>> []$svn cat -r 22 http://svn.darkdragon/repos/trunk/file2@25
>> sdkjsgkjahj
>>
>>
>> Why SVN can't see it in @25? And how can I discover, what's happened to it?
> The above is pretty obscure to follow without access to your repository.
> Please post a reproduction recipe of the problem. That would help clear
> up the confusion.
Reproduction recipe is at beginning of my post. You just stripped it
before answering.
Nevermind, here you go. See attach. However, adjust repository location first.
> On your end, running "svn log -v" may help you diagnose what you're
> seeing, especially at r25.
Right, it's there.
Question remains, why SVN can't track it for simple cat purpose, and painting
image of nonexistent entity instead?
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 22.04.2009, <2:42>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1850347
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Zing Zing Shishak <sh...@alum.rpi.edu>.
On Tue, 21 Apr 2009, Andrey Repin wrote:
> However, I just found an issue...
>
> []$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
> svn: Unable to find repository location for 'http://svn.darkdragon/repos/trunk/file1' in revision 25
>
> I know it's there...
>
> I've copied it myself... by my own hands.
>
> []$svn cat -r 24 http://svn.darkdragon/repos/trunk/file1@22
> sdkjsgkjahj
>
> []$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
> svn: Unable to find repository location for 'http://svn.darkdragon/repos/trunk/file1' in revision 23
>
> []$svn cat -r 22 http://svn.darkdragon/repos/trunk/file1@22 (initial import)
> sdkjsgkjahj
>
> And
>
> []$svn cat -r 22 http://svn.darkdragon/repos/trunk/file2@25
> sdkjsgkjahj
>
>
> Why SVN can't see it in @25? And how can I discover, what's happened to it?
The above is pretty obscure to follow without access to your repository.
Please post a reproduction recipe of the problem. That would help clear
up the confusion.
On your end, running "svn log -v" may help you diagnose what you're
seeing, especially at r25.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1848057
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: @REV vs -r REV
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Victoria Muntean!
> I discovered that @REV and -r REV, when used in 'svn cat', produce
> different results.
> I admit I thought that @REV is synonym of '-r REV' were the same
> thing, just different syntax.
Not always synonym. In most basic operations it is, but imagine situation
Rev 1: add file1
Rev 2: remove file1, add file1
Rev 3: remove file1, copy file1@1
Rev 4: rename file1 file2, copy file1@2 file1
A bit messy operations, you see.
We have two files in @HEAD, and if you trace them back in time, you'll see
that:
file1, despite being in repository at every point, in fact originating
from @2, was killed in @3 and resurrected in @4.
The file2 was first known as file1@1, killed in @2, resurrected in @3, again
killed in @4 but before the kill it was copied as file2.
> What is the explanation of their differences ?
> Do they behave differently in other svn commands, or only in 'svn cat' ?
The @PEG syntax is, basically, points to the object ancestry. It's that
dimension, which differentiate SVN filesystem from regular filesystem.
However, I just found an issue...
[]$svn cat -r HEAD http://svn.darkdragon/repos/trunk/file1@22
svn: Unable to find repository location for 'http://svn.darkdragon/repos/trunk/file1' in revision 25
I know it's there...
I've copied it myself... by my own hands.
[]$svn cat -r 24 http://svn.darkdragon/repos/trunk/file1@22
sdkjsgkjahj
[]$svn cat -r 23 http://svn.darkdragon/repos/trunk/file1@22
svn: Unable to find repository location for 'http://svn.darkdragon/repos/trunk/file1' in revision 23
[]$svn cat -r 22 http://svn.darkdragon/repos/trunk/file1@22 (initial import)
sdkjsgkjahj
And
[]$svn cat -r 22 http://svn.darkdragon/repos/trunk/file2@25
sdkjsgkjahj
Why SVN can't see it in @25? And how can I discover, what's happened to it?
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 21.04.2009, <2:25>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1832317
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].