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_at_1100 gives me the history up to rev. 1100
> > svn log a.txt_at_1185 gives me the history up to rev. 1185
> (which ends at rev 1132, no newer changes)
> > svn log a.txt_at_1186 gives me a file not found error.
> >
> > Question 1:
> > How do I get the complete newer history for a.txt_at_1100?
> >
> > >From the help text I thought
> > svn log a.txt_at_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_at_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_at_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_at_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_at_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_at_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_at_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_at_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_at_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_at_2
could mean.
(1) a.txt_at_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_at_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_at_2 if a.txt_at_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_at_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 ._at_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_at_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
Received on 2012-11-09 13:24:03 CET