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