You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Niemann, Hartmut" <ha...@siemens.com> on 2012/11/08 15:15:49 UTC
Two questions about svn log of a deleted file
Hello!
(This is TortoiseSVN's command line client
svn, version 1.7.7 (r1393599)
compiled Oct 8 2012, 18:39:05,
belonging to
TortoiseSVN 1.7.10, Build 23359 - 32 Bit , 2012/10/08 11:46:26
on Windows XP, if that makes a difference)
I deleted a file a.txt in revision 1186.
svn log a.txt
gives
svn: E160013: File not found: revision 1197, path '/...
which is not surprising.
But what is the canonical way of getting the latest log of this file?
svn log a.txt@1100 gives me the history up to rev. 1100
svn log a.txt@1185 gives me the history up to rev. 1185 (which ends at rev 1132, no newer changes)
svn log a.txt@1186 gives me a file not found error.
Question 1:
How do I get the complete newer history for a.txt@1100?
>From the help text I thought
svn log a.txt@1100 -r HEAD:1 or something like that shoud do it, but
as the file is not present in HEAD I get a file not found error for all
-r parameters involving HEAD that I tried.
Question 2:
Tortoise SVN has a log view where all files changed in a revision,
including this deleted one, are shown. (At the moment I do not need to know
how this can be done with command line svn.)
I can get a log for this file from there, but this log stops at revision 1132.
Is my observation correct that the log information for a file
does not include it's deletion?
Is this a good idea? Or am I missing something?
How would one answer the question "when was file a.txt deleted, which
was present in revision 1100 and is missing now"?
I would expect that the lifecycle of a file in subversion starts with it's
addition and stops with it's deletion, and that the full log includes both,
but this does not seem to be the case?
Thank you for your time.
Hartmut
Mit freundlichen Grüßen
Dr. Hartmut Niemann
Siemens AG
Infrastructure & Cities Sector
Rail Systems Division
Locomotives and Components
IC RL LOC EN LE 8
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264
Fax: +49 9131 7-26254
mailto:hartmut.niemann@siemens.com
Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
AW: Two questions about svn log of a deleted file
Posted by "Niemann, Hartmut" <ha...@siemens.com>.
Hello Stefan,
thank you for your answer, thinks are slowly getting clear.
> >
> > I deleted a file a.txt in revision 1186.
> >
[...]
> >
> > svn log a.txt@1100 gives me the history up to rev. 1100
> > svn log a.txt@1185 gives me the history up to rev. 1185
> (which ends at rev 1132, no newer changes)
> > svn log a.txt@1186 gives me a file not found error.
> >
> > Question 1:
> > How do I get the complete newer history for a.txt@1100?
> >
> > >From the help text I thought
> > svn log a.txt@1100 -r HEAD:1 or something like that shoud do it, but
> > as the file is not present in HEAD I get a file not found
> error for all
> > -r parameters involving HEAD that I tried.
>
> This is because the default peg revision is HEAD with such an
> invocation. See
> http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
> (I'm just mentioning this for completeness -- given what you're saying
> above you seem to understand this already.)
Ok, after reading the fine print there, it seems like
Operating revision newer than peg revision is supported only in the sense
that the operation will only succeed if the object at operating revision
was already on this spot at the peg revision, and will fail otherwise.
Good to know.
I did some more tests, and it looks like svn log with a peg revision
works for elements in the working copy only if they are present in the
current working copy.
If I understand the cited pages,
svn log a.txt@1185 (that means: the object that had the name a.txt in revision 1185)
should give me the history of that file up to revision 1185
But if a.txt is currently not present in the directory, svn does not find it:
D:\PRJ>svn log a.txt@1100
svn: E155010: The node 'D:\PRJ\a.txt' was not found.
If I specify the server-side path
svn log https://server.company.com/repos/xy/trunk/directory/A.txt@1100
it works as expected.
If I update the directory to revision 1100, svn log of the file succeeds.
***************************************************************************************
A test with a scratch repository shows that you need a.txt *now* to get information on
a.txt that once existed:
D:\PRJ\svntest\wc>touch a.txt
D:\PRJ\svntest\wc>svn add a.txt
A a.txt
D:\PRJ\svntest\wc>svn commit -m "make a"
Adding a.txt
Transmitting file data .
Committed revision 2.
D:\PRJ\svntest\wc>svn mv a.txt b.txt
A b.txt
D a.txt
D:\PRJ\svntest\wc>svn commit -m "moved a to b"
Deleting a.txt
Adding b.txt
Committed revision 3.
D:\PRJ\svntest\wc>svn update
Updating '.':
At revision 3.
D:\PRJ\svntest\wc>svn log
------------------------------------------------------------------------
r3 | e09nemh0 | 2012-11-09 11:40:21 +0100 (Fr, 09 Nov 2012) | 1 line
moved a to b
------------------------------------------------------------------------
r2 | e09nemh0 | 2012-11-09 11:39:31 +0100 (Fr, 09 Nov 2012) | 1 line
make a
------------------------------------------------------------------------
r1 | e09nemh0 | 2012-11-09 11:38:02 +0100 (Fr, 09 Nov 2012) | 1 line
Imported folder structure
------------------------------------------------------------------------
D:\PRJ\svntest\wc>svn log b.txt@2
svn: E160013: File not found: revision 2, path '/trunk/b.txt'
# find out where the repository is
D:\PRJ\svntest\wc>svn info b.txt
[...]
URL: file:///D:/PRJ/svntest/repo/trunk/b.txt
[...]
D:\PRJ\svntest\wc>svn log a.txt
svn: E155010: The node 'D:\PRJ\svntest\wc\a.txt' was not found.
D:\PRJ\svntest\wc>svn log a.txt@2
svn: E155010: The node 'D:\PRJ\svntest\wc\a.txt' was not found.
D:\PRJ\svntest\wc>svn log file:///D:/PRJ/svntest/repo/trunk/a.txt@2
------------------------------------------------------------------------
r2 | e09nemh0 | 2012-11-09 11:39:31 +0100 (Fr, 09 Nov 2012) | 1 line
make a
------------------------------------------------------------------------
D:\PRJ\svntest\wc>touch a.txt
D:\PRJ\svntest\wc>svn add a.txt
A a.txt
D:\PRJ\svntest\wc>svn commit -m "recreate a"
Adding a.txt
Transmitting file data .
Committed revision 4.
D:\PRJ\svntest\wc>svn update
Updating '.':
At revision 4.
D:\PRJ\svntest\wc>svn log a.txt
------------------------------------------------------------------------
r4 | e09nemh0 | 2012-11-09 11:42:35 +0100 (Fr, 09 Nov 2012) | 1 line
recreate a
------------------------------------------------------------------------
D:\PRJ\svntest\wc>svn log a.txt@2
------------------------------------------------------------------------
r2 | e09nemh0 | 2012-11-09 11:39:31 +0100 (Fr, 09 Nov 2012) | 1 line
make a
------------------------------------------------------------------------
D:\PRJ\svntest\wc>svn log b.txt
------------------------------------------------------------------------
r3 | e09nemh0 | 2012-11-09 11:40:21 +0100 (Fr, 09 Nov 2012) | 1 line
moved a to b
------------------------------------------------------------------------
r2 | e09nemh0 | 2012-11-09 11:39:31 +0100 (Fr, 09 Nov 2012) | 1 line
make a
------------------------------------------------------------------------
D:\PRJ\svntest\wc>svn log a.txt@2 -r HEAD
svn: E195012: Unable to find repository location for 'file:///D:/PRJ/svntest/repo/trunk/a.txt' in revision 4
***************************************************************************************
So, if a file has been deleted, I seem to be able to address it via workingcopyname@peg
*only* if a file under version control with that name exists in the working copy.
It doesn't have to be related in any way.
Does that make sense?
I find two different interpretations of what <workingcopyroot>/directory/a.txt@2
could mean.
(1) a.txt@2 is the object, that was in the ancestor of the current directory at revision 2.
It does not matter how the current directory was called then.
(2) a.txt@2 is the object that was in a directory 'directory' and was called a.txt at revision 2.
It *does* matter whether the current directory has been replaced since.
And subversion seems to have a third one, because it is only able to locate a.txt@2 if a.txt@HEAD
exists. But why?
Should I rely on server-side URLs only for things that have been moved/deleted?
IMHO interpretation (2) is in line with server-side URLs, i.e. subversion, if called with
somefile@peg, should always take the literal pathname (wc root + path from root to element + elementname)
and should not even check whether a local element with this name exists, because it should not matter at all.
Or am I mistaken?
***********************************************************
On a side note, I found out that
you seem to be unable to use peg revisions on the current directory.
D:\PRJ\DPS\projects\X4platform\TMP>svn log @1000
svn: E125001: '@1000' is just a peg revision. Maybe try '@1000@' instead?
D:\PRJ\DPS\projects\X4platform\TMP>svn log .@1000
svn: E125001: '@1000' is just a peg revision. Maybe try '@1000@' instead?
D:\PRJ\DPS\projects\X4platform\TMP>svn log ./@1000
svn: E125001: '@1000' is just a peg revision. Maybe try '@1000@' instead?
D:\PRJ\DPS\projects\X4platform\TMP>svn log ../TMP@1000
------------------------------------------------------------------------
r880 | e09swas0 | 2012-05-15 09:44:30 +0200 (Di, 15 Mai 2012) | 1 line
[.. stuff deleted]
Is this intentional? I thought it would make as much sense to use a peg revison
on the current directory '.' or './' as it makes on any other directory.
>
> > Question 2:
[...]
> > Is my observation correct that the log information for a file
> > does not include it's deletion?
>
> Yes, a deletion of a node is an operation on the node's parent because
> of the way Subversion's repository is structured.
[...]
> >
> > How would one answer the question "when was file a.txt
> deleted, which
> > was present in revision 1100 and is missing now"?
>
> The current answer isn't very satisfying.
> It is to run 'svn log -v' on a parent directory which has not
> been deleted
> yet and search the log output for the filename. In the
> extreme case this
> means running svn log on the repository root and searching
> all revisions.
Actually, that is perfectly fine with me, but it should be documented,
that you get information on a deleted file only by questioning the directory where it used to be.
At least for newcomers, this is not obvious.
And if someday the metadata storage is changend to work better forward in time
than it seems to be now (where the book says it does not contain all needed
information to track forward), the file deletion information should be added as well.
With best regards
Hartmut Niemann
Re: Two questions about svn log of a deleted file
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 08, 2012 at 03:15:49PM +0100, Niemann, Hartmut wrote:
> Hello!
>
> (This is TortoiseSVN's command line client
> svn, version 1.7.7 (r1393599)
> compiled Oct 8 2012, 18:39:05,
> belonging to
> TortoiseSVN 1.7.10, Build 23359 - 32 Bit , 2012/10/08 11:46:26
> on Windows XP, if that makes a difference)
>
> I deleted a file a.txt in revision 1186.
>
> svn log a.txt
> gives
> svn: E160013: File not found: revision 1197, path '/...
> which is not surprising.
>
> But what is the canonical way of getting the latest log of this file?
>
> svn log a.txt@1100 gives me the history up to rev. 1100
> svn log a.txt@1185 gives me the history up to rev. 1185 (which ends at rev 1132, no newer changes)
> svn log a.txt@1186 gives me a file not found error.
>
> Question 1:
> How do I get the complete newer history for a.txt@1100?
>
> >From the help text I thought
> svn log a.txt@1100 -r HEAD:1 or something like that shoud do it, but
> as the file is not present in HEAD I get a file not found error for all
> -r parameters involving HEAD that I tried.
This is because the default peg revision is HEAD with such an
invocation. See http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
(I'm just mentioning this for completeness -- given what you're saying
above you seem to understand this already.)
> Question 2:
> Tortoise SVN has a log view where all files changed in a revision,
> including this deleted one, are shown. (At the moment I do not need to know
> how this can be done with command line svn.)
> I can get a log for this file from there, but this log stops at revision 1132.
>
> Is my observation correct that the log information for a file
> does not include it's deletion?
Yes, a deletion of a node is an operation on the node's parent because
of the way Subversion's repository is structured.
Recall that files and directories are both versioned explicitly, and
that the list of children is one versioned component of a directory.
> Is this a good idea? Or am I missing something?
>
> How would one answer the question "when was file a.txt deleted, which
> was present in revision 1100 and is missing now"?
The current answer isn't very satisfying.
It is to run 'svn log -v' on a parent directory which has not been deleted
yet and search the log output for the filename. In the extreme case this
means running svn log on the repository root and searching all revisions.
In my opinion, the best answer is currently using TortoiseSVN's log
search feature and search for the name of the deleted file, simply
because it is faster.
In Subversion 1.8, 'svn log' will have a roughly similar feature.
It will allow filtering log messages based on search patterns matching
log message attributes and contents, including the list of changed paths
if the -v option is given. So in Subversion 1.8 you'll be able to run
something like 'svn log -v --search "a.txt" ^/trunk' which will only show
log messages which contain "a.txt" somewhere. This is still suboptimal
because it doesn't directly answer the question of when a.txt was deleted.
But at least you'll have a shorter list of log message to plough through.
And maybe the list can be made shorter by using a more precise search pattern.