RE: How to find out the rev number where a file was deleted?
> From: svn-u...@web.de [mailto:svn-u...@web.de] > > I would appreciate advice for how to find out the rev number where a file > was deleted or moved. > > I expected this command: > svn log -v -r 1:head "file:///[...]/xx/a...@1" Yeah. This is annoying. Once a file is deleted, I can't svn log it anymore. Even if I specify a rev where the file existed. [u...@machine ~]# mkdir trash [u...@machine ~]# cd trash/ [u...@machine trash]# mkdir repo [u...@machine trash]# svnadmin create repo [u...@machine trash]# mkdir working [u...@machine trash]# svn co file:///home/user/trash/repo working Checked out revision 0. [u...@machine trash]# cd working/ [u...@machine working]# [u...@machine working]# [u...@machine working]# [u...@machine working]# touch foo [u...@machine working]# svn add foo A foo [u...@machine working]# svn commit -m 'first commit' foo Adding foo Transmitting file data . Committed revision 1. [u...@machine working]# echo "a" > foo [u...@machine working]# svn commit -m 'second commit' foo Sendingfoo Transmitting file data . Committed revision 2. [u...@machine working]# svn log foo r2 | user | 2010-11-26 23:25:59 -0500 (Fri, 26 Nov 2010) | 1 line second commit r1 | user | 2010-11-26 23:25:46 -0500 (Fri, 26 Nov 2010) | 1 line first commit Here's the important part: [u...@machine working]# svn rm foo D foo [u...@machine working]# svn commit -m 'deleted' foo Deleting foo Committed revision 3. [u...@machine working]# svn log foo svn: 'foo' is not under version control [u...@machine working]# ls .svn/ [u...@machine working]# svn log -r 2 foo svn: 'foo' is not under version control [u...@machine working]# svn log -r 1 foo svn: 'foo' is not under version control [u...@machine working]# svn --version svn, version 1.6.2 (r37639) compiled May 11 2009, 11:51:14
Re: How to find out the rev number where a file was deleted?
On Nov 26, 2010, at 22:33, Edward Ned Harvey wrote: > Yeah. This is annoying. Once a file is deleted, I can't svn log it > anymore. Even if I specify a rev where the file existed. Certainly not if you use an operative revision. You would need to use a peg revision for that. The book explains the difference between the two. http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
RE: How to find out the rev number where a file was deleted?
> From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > > Certainly not if you use an operative revision. You would need to use a peg > revision for that. The book explains the difference between the two. > > http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html This does explain something I didn't already know ... but it seems to just clarify and add credibility to Paul's original question. He wants to see the history, including the rev where the file was deleted. Now that I'm using the correct operative & peg revisions ... I can see the history of a file, including all the modifications etc, but cannot get the rev where it was deleted. Complete details follow, but this is the relevant part. A file named foo was deleted in rev 4. It seems, if I svn log f...@3, and I specify -r 0:head, then I should get the complete history of that file, even for revs higher than 3. [u...@machine wc]# svn log -v -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 4, path '/foo' [u...@machine wc]# svn log -v -r 0:3 file://${HOME}/trash/repo/f...@3 r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: A /foo added [ *snip*] Here are the complete details: [u...@machine ~]# mkdir $HOME/trash [u...@machine ~]# cd $HOME/trash [u...@machine trash]# mkdir repo [u...@machine trash]# svnadmin create repo [u...@machine trash]# mkdir wc [u...@machine trash]# svn co file://${HOME}/trash/repo wc Checked out revision 0. [u...@machine trash]# cd wc [u...@machine wc]# touch foo [u...@machine wc]# svn add foo A foo [u...@machine wc]# svn commit -m 'added' foo Adding foo Transmitting file data . Committed revision 1. [u...@machine wc]# echo "a" > foo [u...@machine wc]# svn commit -m 'changed a' foo Sendingfoo Transmitting file data . Committed revision 2. [u...@machine wc]# echo "b" > foo [u...@machine wc]# svn commit -m 'changed b' foo Sendingfoo Transmitting file data . Committed revision 3. [u...@machine wc]# svn rm foo D foo [u...@machine wc]# svn commit -m 'deleted' foo Deleting foo Committed revision 4. [u...@machine wc]# svn log -v f...@2 svn: 'foo' is not under version control [u...@machine wc]# svn log -v file://${HOME}/trash/repo/f...@2 r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: M /foo changed a r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: A /foo added [u...@machine wc]# svn log -v file://${HOME}/trash/repo/f...@3 r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: M /foo changed b r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: M /foo changed a r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: A /foo added [u...@machine wc]# svn log -v file://${HOME}/trash/repo/f...@4 svn: File not found: revision 4, path '/foo' [u...@machine wc]# svn log -v -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 4, path '/foo' [u...@machine wc]# svn log -v -r 0:3 file://${HOME}/trash/repo/f...@3 r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: A /foo added r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: M /foo changed a r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line Changed paths: M /foo changed b
RE: How to find out the rev number where a file was deleted?
> From: Edward Ned Harvey [mailto:s...@nedharvey.com] > > Complete details follow, but this is the relevant part. A file named foo > was deleted in rev 4. It seems, if I svn log f...@3, and I specify -r > 0:head, then I should get the complete history of that file, even for revs > higher than 3. Now this is effed up. :-) It works if I resurrect the file, but only if I resurrect it with the same name as before. [r...@filer wc]# svn cp file://${HOME}/trash/repo/f...@3 goo A goo [r...@filer wc]# svn commit -m 'resurected and renamed' Adding goo Committed revision 5. [r...@filer wc]# svn log goo r5 | root | 2010-11-27 08:27:33 -0500 (Sat, 27 Nov 2010) | 1 line resurected and renamed r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line changed b r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line changed a r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line added [r...@filer wc]# svn log -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 5, path '/foo' [r...@filer wc]# svn mv goo foo A foo D goo [r...@filer wc]# svn commit -m 'renamed back to original' Adding foo Deleting goo Committed revision 6. [r...@filer wc]# svn log -r 0:head file://${HOME}/trash/repo/f...@3 r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line added r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line changed a r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line changed b r5 | root | 2010-11-27 08:27:33 -0500 (Sat, 27 Nov 2010) | 1 line resurected and renamed r6 | root | 2010-11-27 08:28:44 -0500 (Sat, 27 Nov 2010) | 1 line renamed back to original
Re: How to find out the rev number where a file was deleted?
On 11/27/10 7:31 AM, Edward Ned Harvey wrote: From: Edward Ned Harvey [mailto:s...@nedharvey.com] Complete details follow, but this is the relevant part. A file named foo was deleted in rev 4. It seems, if I svn log f...@3, and I specify -r 0:head, then I should get the complete history of that file, even for revs higher than 3. Now this is effed up. :-) It works if I resurrect the file, but only if I resurrect it with the same name as before. [r...@filer wc]# svn cp file://${HOME}/trash/repo/f...@3 goo A goo [r...@filer wc]# svn commit -m 'resurected and renamed' Adding goo Committed revision 5. [r...@filer wc]# svn log goo r5 | root | 2010-11-27 08:27:33 -0500 (Sat, 27 Nov 2010) | 1 line resurected and renamed r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line changed b r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line changed a r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line added [r...@filer wc]# svn log -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 5, path '/foo' [r...@filer wc]# svn mv goo foo A foo D goo [r...@filer wc]# svn commit -m 'renamed back to original' Adding foo Deleting goo Committed revision 6. [r...@filer wc]# svn log -r 0:head file://${HOME}/trash/repo/f...@3 r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line added r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line changed a r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line changed b r5 | root | 2010-11-27 08:27:33 -0500 (Sat, 27 Nov 2010) | 1 line resurected and renamed r6 | root | 2010-11-27 08:28:44 -0500 (Sat, 27 Nov 2010) | 1 line renamed back to original I think a delete doesn't appear in a file's history - the file just no longer appears in subsequent revisions. However a delete is a change in the containing directory. Does 'svn log -v' on the directory above show the changes in the way they happened? -- Les Mikesell lesmikes...@gmail.com
RE: How to find out the rev number where a file was deleted?
> From: Les Mikesell [mailto:lesmikes...@gmail.com] > > I think a delete doesn't appear in a file's history - the file just no longer > appears in subsequent revisions. However a delete is a change in the > containing > directory. Does 'svn log -v' on the directory above show the changes in the > way > they happened? Right, the age-old point, "rm isn't a file operation. It's an operation on the directory that contains the file." This seems to suggest the answer to Paul's question is ... You can't svn log a file and find the rev where the file was deleted. This is confirmed below ... but it still doesn't explain the weird behavior... Still, this should at least produce some results: (as long as foo existed in rev 3) svn log -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 5, path '/foo' It makes no sense for svn to complain about what's in rev 5. My query doesn't care about rev 5. Important to note below ... The rev where the file was deleted is not shown. This confirms "rm is not a file operation." And this does work, as long as the file was resurrected with the same name: svn log -r 0:head file://${HOME}/trash/repo/f...@3 r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line added r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line changed a r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line changed b r5 | root | 2010-11-27 08:27:33 -0500 (Sat, 27 Nov 2010) | 1 line resurected and renamed r6 | root | 2010-11-27 08:28:44 -0500 (Sat, 27 Nov 2010) | 1 line renamed back to original
Re: How to find out the rev number where a file was deleted?
On 11/27/2010 2:56 PM, Edward Ned Harvey wrote: From: Les Mikesell [mailto:lesmikes...@gmail.com] I think a delete doesn't appear in a file's history - the file just no longer appears in subsequent revisions. However a delete is a change in the containing directory. Does 'svn log -v' on the directory above show the changes in the way they happened? Right, the age-old point, "rm isn't a file operation. It's an operation on the directory that contains the file." This seems to suggest the answer to Paul's question is ... You can't svn log a file and find the rev where the file was deleted. This is confirmed below ... but it still doesn't explain the weird behavior... Still, this should at least produce some results: (as long as foo existed in rev 3) svn log -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 5, path '/foo' It makes no sense for svn to complain about what's in rev 5. My query doesn't care about rev 5. I think the principle was covered in another response, but the only way you can get history is to start from the highest rev and follow backwards, and you are asking it to start from head, which is impossible. Important to note below ... The rev where the file was deleted is not shown. This confirms "rm is not a file operation." And this does work, as long as the file was resurrected with the same name: svn log -r 0:head file://${HOME}/trash/repo/f...@3 r1 | root | 2010-11-27 08:12:20 -0500 (Sat, 27 Nov 2010) | 1 line added r2 | root | 2010-11-27 08:12:32 -0500 (Sat, 27 Nov 2010) | 1 line changed a r3 | root | 2010-11-27 08:12:45 -0500 (Sat, 27 Nov 2010) | 1 line changed b r5 | root | 2010-11-27 08:27:33 -0500 (Sat, 27 Nov 2010) | 1 line resurected and renamed r6 | root | 2010-11-27 08:28:44 -0500 (Sat, 27 Nov 2010) | 1 line renamed back to original In this case the file does exist in head, and you wouldn't have to specify the peg revision at all. Subversion can track the 'copy-from' backwards and knows it is that same item. But the name isn't what ties them together. You could just as easily have copied to a different name in head and asked for the log with the new name there and you'd get the same history. -- Les Mikesell lesmikes...@gmail.com
Re: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! >> Still, this should at least produce some results: (as long as foo existed >> in rev 3) >> svn log -r 0:head file://${HOME}/trash/repo/f...@3 >> svn: File not found: revision 5, path '/foo' >> It makes no sense for svn to complain about what's in rev 5. My query >> doesn't care about rev 5. > I think the principle was covered in another response, but the only way > you can get history is to start from the highest rev and follow > backwards, and you are asking it to start from head, which is impossible. Impossible within current realization of storage backend. But sensible from user's viewpoint and scheduled to be resolved in future. I'd ask you to stop giving out your own opinion under mask of absolute truth. -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.11.2010, <16:36> Sorry for my terrible english...
Re: How to find out the rev number where a file was deleted?
On 11/30/2010 7:39 AM, Andrey Repin wrote: Greetings, Les Mikesell! Still, this should at least produce some results: (as long as foo existed in rev 3) svn log -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 5, path '/foo' It makes no sense for svn to complain about what's in rev 5. My query doesn't care about rev 5. I think the principle was covered in another response, but the only way you can get history is to start from the highest rev and follow backwards, and you are asking it to start from head, which is impossible. Impossible within current realization of storage backend. But sensible from user's viewpoint and scheduled to be resolved in future. I'd ask you to stop giving out your own opinion under mask of absolute truth. I'm admittedly not an expert, but I don't understand exactly how this can be resolved to work the way you want when the names of objects are only loosely connected to the objects themselves. That is, a path and revision in peg revision form uniquely identifies an object, and that object has a certain amount of history. However that same path at any other revision may be an entirely different object with a different history or may not exist at all. If subversion starts to track the 'copy-to' info so you can follow revisions in the forward direction, you can end up with many different descendants with different paths, but it's not clear that would make it any easier to find the dead ends of deletions. I can see that subversion could, with some extra work on the server side, track down the end of the line in the future of f...@3 by examining every subsequent revision when you ask for: svn log -r 0:head file://${HOME}/trash/repo/f...@3 But what should it do if a different object with the same name but a different history has been copied into head where you are really asking it to start giving history? Also, when you copy a directory in subversion, you expect it to bring along all of the history of that directory and the objects under it. If you want it to remember that a deleted object once lived under a certain path, when that path is copied, would you also want it to think that the deleted object was once under this new copied path? -- Les Mikesell lesmikes...@gmail.com
Re: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! Still, this should at least produce some results: (as long as foo existed in rev 3) svn log -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 5, path '/foo' It makes no sense for svn to complain about what's in rev 5. My query doesn't care about rev 5. >> >>> I think the principle was covered in another response, but the only way >>> you can get history is to start from the highest rev and follow >>> backwards, and you are asking it to start from head, which is impossible. >> >> Impossible within current realization of storage backend. But sensible from >> user's viewpoint and scheduled to be resolved in future. >> I'd ask you to stop giving out your own opinion under mask of absolute truth. > I'm admittedly not an expert, but I don't understand exactly how this > can be resolved to work the way you want when the names of objects are > only loosely connected to the objects themselves. This is not a problem at all. The simplest solution I can imagine is to maintain a table revision|URL|action|previous_revision|previous_URL Walking this table back and forth is as quick as any usual database operation. And some new command could be added to svn program to give result similar to status command, but including revision numbers. Something like A 5 /trunk/frontend/fig1.php MM 7 /trunk/frontend/fig1.php M 8 /trunk/frontend/fig1.php D 26 /trunk/frontend/fig1.php A 57 /trunk/frontend/f-o.php R 58 /trunk/frontend/fig1.php C 59 /branch/xxx/frontend/fig1.php GM 77 /trunk/frontend/fig1.php (Yes, there's a reference to the moment file has been Copied, but that's only made for reference, to give investigator an idea of what could've been done to the file, and where to look. As you can see, the file was merGed back to the trunk in my example, but no mention if it was edited in between 59 and 77 - you'd have to run another track for that file in branch to discover that) > That is, a path and revision in peg revision form uniquely identifies an > object, and that object has a certain amount of history. > However that same path at any other revision may be an entirely different > object with a different history or may not exist at all. If subversion > starts to track the 'copy-to' info so you can follow revisions in the > forward direction, you can end up with many different descendants with > different paths, but it's not clear that would make it any easier to find > the dead ends of deletions. If it start to branch, each of these files will have it's own tracking onward from the branching point. Nothing wrong with it. Or do you concerned with tracking request output? It's not a problem either. As long as URL wasn't renamed/deleted, it should keep giving out the mainline. You're right that u...@peg form an unique identity, but making a mistake thinking about URL across whole range of history. As you pointed out, URL alone isn't enough to identify the file. But that's not a problem, because Subversion wouldn't be working over whole repository, only with each revision it know of, sequentially. > I can see that subversion could, with some extra work on the server > side, track down the end of the line in the future of f...@3 by examining > every subsequent revision when you ask for: > svn log -r 0:head file://${HOME}/trash/repo/f...@3 > But what should it do if a different object with the same name but a > different history has been copied into head where you are really asking > it to start giving history? If it'd be implemented right, Subversion would not see these files at all. It'd simply NOT look into HEAD in first place. > Also, when you copy a directory in subversion, you expect it to bring > along all of the history of that directory and the objects under it. If > you want it to remember that a deleted object once lived under a certain > path, when that path is copied, would you also want it to think that the > deleted object was once under this new copied path? You asking a question that has no meaning. Subversion copy copies current state. Deleted files do not present in it. I don't see any problem. Or clarify your question. (provide use-case?) -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.11.2010, <21:22> Sorry for my terrible english...
Re: How to find out the rev number where a file was deleted?
On 11/30/2010 12:58 PM, Andrey Repin wrote: Greetings, Les Mikesell! Still, this should at least produce some results: (as long as foo existed in rev 3) svn log -r 0:head file://${HOME}/trash/repo/f...@3 svn: File not found: revision 5, path '/foo' It makes no sense for svn to complain about what's in rev 5. My query doesn't care about rev 5. I think the principle was covered in another response, but the only way you can get history is to start from the highest rev and follow backwards, and you are asking it to start from head, which is impossible. Impossible within current realization of storage backend. But sensible from user's viewpoint and scheduled to be resolved in future. I'd ask you to stop giving out your own opinion under mask of absolute truth. I'm admittedly not an expert, but I don't understand exactly how this can be resolved to work the way you want when the names of objects are only loosely connected to the objects themselves. This is not a problem at all. The simplest solution I can imagine is to maintain a table revision|URL|action|previous_revision|previous_URL Walking this table back and forth is as quick as any usual database operation. What database operation is fast when it has to follow recursive self-references in the same table? Each time you copy a high level directory (typical for users that tag frequently) you'd have to have an entry for every path below it. When you follow forward, you'll explode out a tree of new paths. And some new command could be added to svn program to give result similar to status command, but including revision numbers. Something like A 5 /trunk/frontend/fig1.php MM 7 /trunk/frontend/fig1.php M 8 /trunk/frontend/fig1.php D 26 /trunk/frontend/fig1.php A 57 /trunk/frontend/f-o.php R 58 /trunk/frontend/fig1.php C 59 /branch/xxx/frontend/fig1.php GM 77 /trunk/frontend/fig1.php And how should this look if every operation is a move/rename? Or copies followed by different renames out each branch? If it start to branch, each of these files will have it's own tracking onward from the branching point. Nothing wrong with it. Or do you concerned with tracking request output? It's not a problem either. As long as URL wasn't renamed/deleted, it should keep giving out the mainline. But that's the point. Things are copied and moved regularly. And renamed temporarily and then back. You're right that u...@peg form an unique identity, but making a mistake thinking about URL across whole range of history. As you pointed out, URL alone isn't enough to identify the file. But that's not a problem, because Subversion wouldn't be working over whole repository, only with each revision it know of, sequentially. There's only one way back through history but no limit to future branches if you want it to look forward. I can see that subversion could, with some extra work on the server side, track down the end of the line in the future of f...@3 by examining every subsequent revision when you ask for: svn log -r 0:head file://${HOME}/trash/repo/f...@3 But what should it do if a different object with the same name but a different history has been copied into head where you are really asking it to start giving history? If it'd be implemented right, Subversion would not see these files at all. It'd simply NOT look into HEAD in first place. It only looks in head because that command asks it for the history of head. If you are asking it to follow the object forward for as long as it existed in that path the server could probably figure that out with some brute force although even there things would be messy if you renamed it, then renamed it back some revisions later. Or maybe made many copies, one of which was eventually copied back. -- Les Mikesell lesmikes...@gmail.com
Re: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! >> Still, this should at least produce some results: (as long as foo >> existed >> in rev 3) >> svn log -r 0:head file://${HOME}/trash/repo/f...@3 >> svn: File not found: revision 5, path '/foo' >> It makes no sense for svn to complain about what's in rev 5. My query >> doesn't care about rev 5. > I think the principle was covered in another response, but the only way > you can get history is to start from the highest rev and follow > backwards, and you are asking it to start from head, which is impossible. Impossible within current realization of storage backend. But sensible from user's viewpoint and scheduled to be resolved in future. I'd ask you to stop giving out your own opinion under mask of absolute truth. >> >>> I'm admittedly not an expert, but I don't understand exactly how this >>> can be resolved to work the way you want when the names of objects are >>> only loosely connected to the objects themselves. >> >> This is not a problem at all. >> The simplest solution I can imagine is to maintain a table >> revision|URL|action|previous_revision|previous_URL >> >> Walking this table back and forth is as quick as any usual database >> operation. > What database operation is fast when it has to follow recursive > self-references in the same table? SELECT operation, even on a multitude of arguments, is relatively fast. Hell, even UNION JOIN over a NetFlow data is just about a few seconds. > Each time you copy a high level directory (typical for users that tag > frequently) you'd have to have an entry for every path below it. When you > follow forward, you'll explode out a tree of new paths. Not a problem, really. This is strictly server-side operation, means it is done on a fast backend, not affected by network issues. Doubt it could be slower than real-time walking on a graph with 6k points. >> And some new command could be added to svn program to give result similar to >> status command, but including revision numbers. >> Something like >> A 5 /trunk/frontend/fig1.php >> MM 7 /trunk/frontend/fig1.php >> M 8 /trunk/frontend/fig1.php >> D 26 /trunk/frontend/fig1.php >> A 57 /trunk/frontend/f-o.php >> R 58 /trunk/frontend/fig1.php >> C 59 /branch/xxx/frontend/fig1.php >> GM 77 /trunk/frontend/fig1.php > And how should this look if every operation is a move/rename? Or copies > followed by different renames out each branch? I specifically mentioned this moment it in the part you striped from quote. >> If it start to branch, each of these files will have it's own tracking onward >> from the branching point. Nothing wrong with it. Or do you concerned with >> tracking request output? It's not a problem either. As long as URL wasn't >> renamed/deleted, it should keep giving out the mainline. > But that's the point. Things are copied and moved regularly. And > renamed temporarily and then back. Nota a concern. Mainline go on and at some point die (if at all), giving all sort of hints, as to where to look further, in process. If you REALLY want to see if the file was moved back instead of merging, you'd run a new trace from one of the branching points. >> You're right that u...@peg form an unique identity, but making a mistake >> thinking about URL across whole range of history. As you pointed out, URL >> alone isn't enough to identify the file. But that's not a problem, because >> Subversion wouldn't be working over whole repository, only with each revision >> it know of, sequentially. > There's only one way back through history but no limit to future > branches if you want it to look forward. There CURRENTLY only one way - back. This is a deficiency of current backend realization. And amount of future branches is not a problem at all, if you stop banging your head over it. >>> I can see that subversion could, with some extra work on the server >>> side, track down the end of the line in the future of f...@3 by examining >>> every subsequent revision when you ask for: >>> svn log -r 0:head file://${HOME}/trash/repo/f...@3 >>> But what should it do if a different object with the same name but a >>> different history has been copied into head where you are really asking >>> it to start giving history? >> >> If it'd be implemented right, Subversion would not see these files at all. >> It'd simply NOT look into HEAD in first place. > It only looks in head because that command asks it for the history of > head. No. Really, I see this as pointless discussion. You absolutely don't hear my arguments. P.S. Please don't use "reply to all" in reply to my posts. It's not a big problem deleting a few more messages from my inbox, still it's disturbing. TIA. -- WBR, Andrey Repin (anrdae...@freemail.ru) 01.12.2010, <14:07> Sorry for my terrible english...
Re: How to find out the rev number where a file was deleted?
On 12/1/10 5:30 AM, Andrey Repin wrote: What database operation is fast when it has to follow recursive self-references in the same table? SELECT operation, even on a multitude of arguments, is relatively fast. Hell, even UNION JOIN over a NetFlow data is just about a few seconds. You miss the point that you have to join the table with another field in the same table. This is not going to be fast. Nota a concern. Mainline go on and at some point die (if at all), giving all sort of hints, as to where to look further, in process. It might. Or a file could be moved in every revision. svn log -r 0:head file://${HOME}/trash/repo/f...@3 It only looks in head because that command asks it for the history of head. No. Really, I see this as pointless discussion. You absolutely don't hear my arguments. Same from this side... P.S. Please don't use "reply to all" in reply to my posts. It's not a big problem deleting a few more messages from my inbox, still it's disturbing. TIA. That's the way mailing lists have always worked. Unless the Reply-To: header is set to go back to the list, you have to use reply-all to get one to go to the list. This list doesn't set it, but you can set it yourself if you want to control where replies go. -- Les Mikesell lesmikes...@gmail.com