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
