How to find out the rev number where a file was deleted?
Hello, 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" to show all revs including the deleting rev (as last shown rev), but that doesn't work. The command fails. Does anybody know, what command I could enter? Thanks! Paul Here my simplified setup: echo a > a; svn add a; svn ci -m "" [lots of other revisions] svn mv a b; svn ci -m "" ## <-- how to find out the rev number of that checkin?? [lots of other revisions] svn log -v "file:///[...]/xx/a...@1" # just a test that the syntax works Console output: svnadmin create xx svn co "file:///[...]/xx" yy Ausgecheckt, Revision 0. cd yy echo a > a svn add a A a svn ci -m "" Hinzufügen a Übertrage Daten . Revision 1 übertragen. echo x > somethingelse svn add somethingelse A somethingelse svn ci -m "somethingelse" --force-log Hinzufügen somethingelse Übertrage Daten . Revision 2 übertragen. svn mv a b A b D a svn ci -m "" Lösche a Hinzufügen b Revision 3 übertragen. echo x >> somethingelse svn ci -m "somethingelse" --force-log Sende somethingelse Übertrage Daten . Revision 4 übertragen. svn up Revision 4. svn log -v "file:///[...]/xx/a...@1" r1 | user | 2010-11-27 00:38:43 +0100 (Sa, 27. Nov 2010) | 1 Zeile Geänderte Pfade: A /a svn log -v -r 1:head "file:///[...]/xx/a...@1" svn: Datei nicht gefunden: Revision 4, Pfad »/a«
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
AW: How to find out the rev number where a file was deleted?
Hi Edward, thanks for having responded. Can I file a feature request for that in the issue tracker, what do you think? @Ryan: Of course with a peg rev I can log that single rev. But the rev number of that rev is that what we are looking for! To find out this rev number, we want to use an earlier peg rev where we know that the file still existed and want to add "-r1:head" as operative revs to see all revs including the rev where the file was deleted. Paul. > -Ursprüngliche Nachricht- > Von: Edward Ned Harvey [mailto:s...@nedharvey.com] > Gesendet: Samstag, 27. November 2010 05:33 > An: svn-u...@web.de; users@subversion.apache.org > Betreff: 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?
> 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
Re: AW: How to find out the rev number where a file was deleted?
On 11/27/10 6:42 AM, Paul Maier wrote: Hi Edward, thanks for having responded. Can I file a feature request for that in the issue tracker, what do you think? @Ryan: Of course with a peg rev I can log that single rev. But the rev number of that rev is that what we are looking for! To find out this rev number, we want to use an earlier peg rev where we know that the file still existed and want to add "-r1:head" as operative revs to see all revs including the rev where the file was deleted. The deletion should show in an 'svn log -v' of the directory where the file was deleted. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! >> thanks for having responded. >> Can I file a feature request for that in the issue tracker, >> what do you think? >> >> @Ryan: Of course with a peg rev I can log that single rev. But the >> rev number of that rev is that what we are looking for! To find out >> this rev number, we want to use an earlier peg rev where we know >> that the file still existed and want to add "-r1:head" as operative >> revs to see all revs including the rev where the file was deleted. >> > The deletion should show in an 'svn log -v' of the directory where the file > was > deleted. That directory was deleted as well. As well, at unknown revision. Multiple times. The question is not that we can work around the issue, the question is, why Subversion can't do this for us? I can add my own case to this list. http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1850347 I can understand that it's not easy to track deletes/copies forward, but tracking history from creation time to deletion(renamind implies deletion) time should be possible IMO. And this should be possible without user's guesswork. It's fairly simple to find correct revision range in repository with 40 commits. In repository with 40,000 commits things became "a bit" scary. -- WBR, Andrey Repin (anrdae...@freemail.ru) 27.11.2010, <22:30> Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
On 11/27/10 3:59 PM, Andrey Repin wrote: Greetings, Les Mikesell! thanks for having responded. Can I file a feature request for that in the issue tracker, what do you think? @Ryan: Of course with a peg rev I can log that single rev. But the rev number of that rev is that what we are looking for! To find out this rev number, we want to use an earlier peg rev where we know that the file still existed and want to add "-r1:head" as operative revs to see all revs including the rev where the file was deleted. The deletion should show in an 'svn log -v' of the directory where the file was deleted. That directory was deleted as well. As well, at unknown revision. Multiple times. The question is not that we can work around the issue, the question is, why Subversion can't do this for us? Because the file doesn't exist in the revision where it was deleted so there's nothing for the log to be about. The change for that rev happened in the directory above. I can understand that it's not easy to track deletes/copies forward, but tracking history from creation time to deletion(renamind implies deletion) time should be possible IMO. It is not that it isn't tracked. It just isn't tracked where you are looking for it. And this should be possible without user's guesswork. It's fairly simple to find correct revision range in repository with 40 commits. In repository with 40,000 commits things became "a bit" scary. Subversion tracks things backwards from a starting point that is either something that exists or a peg revision where it did exist. You can find where things were deleted with a 'log -v' of a directory high enough in the repository to contain the change, then use the previous revision as the peg rev for the thing you want to log from there back while it existed. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! >>> The deletion should show in an 'svn log -v' of the directory where the file >>> was >>> deleted. >> >> That directory was deleted as well. As well, at unknown revision. Multiple >> times. >> >> The question is not that we can work around the issue, the question is, why >> Subversion can't do this for us? > Because the file doesn't exist in the revision where it was deleted so > there's > nothing for the log to be about. That's a flaw, but well, I can live with it as long as there's other ways to get necessary info. > The change for that rev happened in the directory above. I'm looking for directory already, as file history would not show me the necessary data. Dunno why... is it hard to track file from PEG revision to first operative revision and print out the logs for every revision, in which that file were changed, and spit the "not found in rev X" when the file disappear? Why it even think that file could exist in HEAD, when we unambiguously pointed to the specific point in time? >> I can understand that it's not easy to track deletes/copies forward, but >> tracking history from creation time to deletion(renamind implies >> deletion) time should be possible IMO. > It is not that it isn't tracked. It just isn't tracked where you are looking > for it. I'm looking for it at revision 2. [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 svn: '/repos/!svn/bc/35/test' path not found [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (×ò, 02 àïð 2009) | 2 lines Changed paths: A /test A /test/a Test1 r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: A /test/b test 2 r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: R /test/a Test 3 >> And this should be possible without user's guesswork. It's fairly simple to >> find correct revision range in repository with 40 commits. >> In repository with 40,000 commits things became "a bit" scary. > Subversion tracks things backwards from a starting point that is either > something that exists or a peg revision where it did exist. I know. Quite. And if you didn't noticed, I specifically specified (LOL) a PEG revision... With exactly that intent - to get around absence of file in HEAD... > You can find where things were deleted with a 'log -v' of a directory high > enough in the repository to contain the change, then use the previous > revision as the peg rev for the thing you want to log from there back while > it existed. Project contains 40,000 revisions, about 800 files, like eight branches, that was created/deleted/recreated at some point each, and approximately 25 tags denoting "stable" builds. Good luck finding directory LOW enough that allow you to find a file without use of a sophisticated log parser, since revision numbers are not connected to changed files in any way suitable for meaningful grep'ing. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, <5:50> Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
On 11/27/10 9:06 PM, Andrey Repin wrote: The change for that rev happened in the directory above. I'm looking for directory already, as file history would not show me the necessary data. Dunno why... is it hard to track file from PEG revision to first operative revision and print out the logs for every revision, in which that file were changed, and spit the "not found in rev X" when the file disappear? It doesn't track the future of a file, it tracks the history. Start with a peg revision of the revision before the delete and the log will track it back through it's entire history. > Why it even think that file could exist in HEAD, when we unambiguously pointed to the specific point in time? It won't look towards HEAD unless you request that in the revision range for the log, and then it will be impossible. I can understand that it's not easy to track deletes/copies forward, but tracking history from creation time to deletion(renamind implies deletion) time should be possible IMO. Actually, while renaming implies deletion, it is not a loss of history. The log of the renamed file will have it, as will the directories containing the changes to the names. It is not that it isn't tracked. It just isn't tracked where you are looking for it. I'm looking for it at revision 2. [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 svn: '/repos/!svn/bc/35/test' path not found But you are asking it to track the future of that file to a place it doesn't exist. [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (×ò, 02 àïð 2009) | 2 lines Changed paths: A /test A /test/a Test1 r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: A /test/b test 2 r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: R /test/a Test 3 And this should be possible without user's guesswork. It's fairly simple to find correct revision range in repository with 40 commits. In repository with 40,000 commits things became "a bit" scary. Subversion tracks things backwards from a starting point that is either something that exists or a peg revision where it did exist. I know. Quite. And if you didn't noticed, I specifically specified (LOL) a PEG revision... With exactly that intent - to get around absence of file in HEAD... But you can only expect it to track the history and it appeared that you wanted to track the future to HEAD. I guess it could be more polite about giving you the revisions it can find along with the error. You can find where things were deleted with a 'log -v' of a directory high enough in the repository to contain the change, then use the previous revision as the peg rev for the thing you want to log from there back while it existed. Project contains 40,000 revisions, about 800 files, like eight branches, that was created/deleted/recreated at some point each, and approximately 25 tags denoting "stable" builds. The tags should be irrelevant since nothing should change there unless you want to use one as source for a copy back to a branch for changes. If you know the file in question existed in a tag, you can track backwards from there though, or copy into a current revision. Good luck finding directory LOW enough that allow you to find a file without use of a sophisticated log parser, since revision numbers are not connected to changed files in any way suitable for meaningful grep'ing. I'd probably feed the output to an editor or 'less', search for the delete of the path than back up to the revision. There are probably fancier things you could do with the xml output. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! >>> The change for that rev happened in the directory above. >> >> I'm looking for directory already, as file history would not show me the >> necessary data. Dunno why... is it hard to track file from PEG revision to >> first operative revision and print out the logs for every revision, in which >> that file were changed, and spit the "not found in rev X" when the file >> disappear? > It doesn't track the future of a file, it tracks the history. Start with a > peg > revision Wat? It start with HEAD irrelevant to what PEG revision we've specified. And immediately spitting "no such file", although the file is 100% there. > of the revision before the delete and the log will track it back > through it's entire history. >> Why it even think that file could exist in HEAD, when we >> unambiguously pointed to the specific point in time? > It won't look towards HEAD unless you request that in the revision range for > the > log, and then it will be impossible. I specified PEG revision. Documentation clearly states that PEG revision has precedence over operative revision in conflicting names resolution, but for absent files (name conflicting with void) it not seems to be the case. I can understand that it's not easy to track deletes/copies forward, but tracking history from creation time to deletion(renamind implies deletion) time should be possible IMO. > Actually, while renaming implies deletion, it is not a loss of history. Yes, but it's still a deletion. > The log of the renamed file will have it, as will the directories containing > the changes to the names. Unfortunatelly. It only show that file was renamed, but does not show the new name. (Or old name? One of them - see the log below) >>> It is not that it isn't tracked. It just isn't tracked where you are >>> looking >>> for it. >> >> I'm looking for it at revision 2. >> >> [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 >> svn: '/repos/!svn/bc/35/test' path not found > But you are asking it to track the future of that file to a place it doesn't > exist. I beg to differ. I'm asking to 1. Pick the file (directory) /test at revision 2 2. Track it's changes history from revision 0 to HEAD. 3. I'm fully aware that the directory does not exist in HEAD, neither I ask Subversion to look there in first place. (literal meaning of "first place") 4. Quite (un)surprisingly, my intent is to actually find revision, in which the destruction was made. Because, quite (un)surprisingly, I don't know that. See the order of instructions? Do I need to refer to the svnbook chapter discussing PEG and operative revisions, or you can find it yourself? >> [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 >> >> r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (×ò, 02 àïð 2009) | 2 lines >> Changed paths: >> A /test >> A /test/a >> >> Test1 >> >> >> r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (×ò, 02 àïð 2009) | 1 line >> Changed paths: >> A /test/b >> >> test 2 >> >> r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (×ò, 02 àïð 2009) | 1 line >> Changed paths: >> R /test/a >> >> Test 3 >> >> >> And this should be possible without user's guesswork. It's fairly simple to find correct revision range in repository with 40 commits. In repository with 40,000 commits things became "a bit" scary. >> >>> Subversion tracks things backwards from a starting point that is either >>> something that exists or a peg revision where it did exist. >> >> I know. Quite. And if you didn't noticed, I specifically specified (LOL) a >> PEG >> revision... With exactly that intent - to get around absence of file in >> HEAD... > But you can only expect it to track the history and it appeared that you > wanted > to track the future to HEAD. I could have pointed to any other of the revisions between @PEG and HEAD, which will net the very same result - unless I guess it right, the process will not start at all. > I guess it could be more polite about giving you the revisions it can find > along with the error. Nah, it could just obey to @PEG rule. Everything will be simpler. Unless there's absolutely no other way to track the file from @PEG, which i doubt, since you DO can access the file by @PEG, as well as navigate back in time easier, than forward. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, <9:13> Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
Have you considered doing a binary search to find the revision that it was deleted in? svn ls .../t...@2 Exists svn ls .../t...@head No such file in revision 50002 svn ls .../t...@25002 Exists svn ls .../t...@37502 No such file svn ls .../t...@31252 Exists, etc You'll get the revision in at most log2 HEAD iterations - Stephen --- Sent from my Android phone, so random spelling mistakes are a direct result of using swype to type on the screen On 28 Nov 2010 06:30, "Andrey Repin" wrote: Greetings, Les Mikesell! >>> The change for that rev happened in the directory above. >> >> I'm looking for directory alread... Wat? It start with HEAD irrelevant to what PEG revision we've specified. And immediately spitting "no such file", although the file is 100% there. > of the revision before the delete and the log will track it back > through it's entire history. ... I specified PEG revision. Documentation clearly states that PEG revision has precedence over operative revision in conflicting names resolution, but for absent files (name conflicting with void) it not seems to be the case. I can understand that it's not easy to track deletes/copies forward, but tracking history... Yes, but it's still a deletion. > The log of the renamed file will have it, as will the directories containing > the changes to the... Unfortunatelly. It only show that file was renamed, but does not show the new name. (Or old name? One of them - see the log below) >>> It is not that it isn't tracked. It just isn't tracked where you are looking >>> for it. >> >>... I beg to differ. I'm asking to 1. Pick the file (directory) /test at revision 2 2. Track it's changes history from revision 0 to HEAD. 3. I'm fully aware that the directory does not exist in HEAD, neither I ask Subversion to look there in first place. (literal meaning of "first place") 4. Quite (un)surprisingly, my intent is to actually find revision, in which the destruction was made. Because, quite (un)surprisingly, I don't know that. See the order of instructions? Do I need to refer to the svnbook chapter discussing PEG and operative revisions, or you can find it yourself? >> [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 >> ---... I could have pointed to any other of the revisions between @PEG and HEAD, which will net the very same result - unless I guess it right, the process will not start at all. > I guess it could be more polite about giving you the revisions it can find > along with the error... Nah, it could just obey to @PEG rule. Everything will be simpler. Unless there's absolutely no other way to track the file from @PEG, which i doubt, since you DO can access the file by @PEG, as well as navigate back in time easier, than forward. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, <9:13> Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 7:28 AM, Andrey Repin wrote: > Greetings, Les Mikesell! > The change for that rev happened in the directory above. >>> >>> I'm looking for directory already, as file history would not show me the >>> necessary data. Dunno why... is it hard to track file from PEG revision to >>> first operative revision and print out the logs for every revision, in which >>> that file were changed, and spit the "not found in rev X" when the file >>> disappear? > >> It doesn't track the future of a file, it tracks the history. Start with a >> peg >> revision > > Wat? It start with HEAD irrelevant to what PEG revision we've specified. > And immediately spitting "no such file", although the file is 100% there. > >> of the revision before the delete and the log will track it back >> through it's entire history. > >>> Why it even think that file could exist in HEAD, when we >>> unambiguously pointed to the specific point in time? > >> It won't look towards HEAD unless you request that in the revision range for >> the >> log, and then it will be impossible. > > I specified PEG revision. Documentation clearly states that PEG revision has > precedence over operative revision in conflicting names resolution, but for > absent files (name conflicting with void) it not seems to be the case. > > I can understand that it's not easy to track deletes/copies forward, but > tracking history from creation time to deletion(renamind implies > deletion) time should be possible IMO. > >> Actually, while renaming implies deletion, it is not a loss of history. > > Yes, but it's still a deletion. > >> The log of the renamed file will have it, as will the directories containing >> the changes to the names. > > Unfortunatelly. It only show that file was renamed, but does not show the new > name. (Or old name? One of them - see the log below) > It is not that it isn't tracked. It just isn't tracked where you are looking for it. >>> >>> I'm looking for it at revision 2. >>> >>> [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 >>> svn: '/repos/!svn/bc/35/test' path not found > >> But you are asking it to track the future of that file to a place it doesn't >> exist. > > I beg to differ. > I'm asking to > 1. Pick the file (directory) /test at revision 2 > 2. Track it's changes history from revision 0 to HEAD. > 3. I'm fully aware that the directory does not exist in HEAD, neither I ask > Subversion to look there in first place. (literal meaning of "first place") > 4. Quite (un)surprisingly, my intent is to actually find revision, in which > the destruction was made. Because, quite (un)surprisingly, I don't know that. > > See the order of instructions? Do I need to refer to the svnbook chapter > discussing PEG and operative revisions, or you can find it yourself? > >>> [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 >>> >>> r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (Чт, 02 апр 2009) | 2 lines >>> Changed paths: >>> A /test >>> A /test/a >>> >>> Test1 >>> >>> >>> r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (Чт, 02 апр 2009) | 1 line >>> Changed paths: >>> A /test/b >>> >>> test 2 >>> >>> r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (Чт, 02 апр 2009) | 1 line >>> Changed paths: >>> R /test/a >>> >>> Test 3 >>> >>> >>> > And this should be possible without user's guesswork. It's fairly simple > to > find correct revision range in repository with 40 commits. > In repository with 40,000 commits things became "a bit" scary. >>> Subversion tracks things backwards from a starting point that is either something that exists or a peg revision where it did exist. >>> >>> I know. Quite. And if you didn't noticed, I specifically specified (LOL) a >>> PEG >>> revision... With exactly that intent - to get around absence of file in >>> HEAD... > >> But you can only expect it to track the history and it appeared that you >> wanted >> to track the future to HEAD. > > I could have pointed to any other of the revisions between @PEG and HEAD, > which will net the very same result - unless I guess it right, the process > will not start at all. > >> I guess it could be more polite about giving you the revisions it can find >> along with the error. > > Nah, it could just obey to @PEG rule. Everything will be simpler. > Unless there's absolutely no other way to track the file from @PEG, which i > doubt, since you DO can access the file by @PEG, as well as navigate back in > time easier, than forward. FWIW, you do have a point, Andrey (and others), that this is a valid use case (finding the rev in which a file was deleted) which isn't well supported by svn curren
Re: AW: How to find out the rev number where a file was deleted?
[ sorry if I'm repeating; haven't read the whole thread ]
Johan Corveleyn wrote on Sun, Nov 28, 2010 at 10:05:15 +0100:
> FWIW, you do have a point, Andrey (and others), that this is a valid
> use case (finding the rev in which a file was deleted) which isn't
> well supported by svn currently. I think the svn devs are very much
> aware of this, but it just isn't there yet. See also this issue:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3627 - FS API
> support for oldest-to-youngest history traversal
>
> It literally mentions this use case as one of the "high-level user needs":
> " - allowing 'svn log' to fully traverse the entire history of a
> given versioned
> object, both for completeness' sake and to facilitate (for example)
> resurrection
> of deleted items from their most-recently-existing forms."
>
> Unfortunately, according to the current plans, it might be a while
> before this is implemented. On the roadmap, it is listed as being
> dependent on FS-NG ("Flexible Repository Storage"), on the list of
> "most wanted features":
> http://subversion.apache.org/roadmap.html#features-most-wanted.
Just to clarify, this doesn't mean we don't like this feature; it means
a non-trivial bit of work is needed to implement it, because this
question is not easily answerable given the current state/design of
the backends.
There are two related questions here:
* Given p...@rn which exists, what is the largest rM such that
p...@ri and p...@rn are the same node (no adds/replaces/deletes
have occured in or above PATH) for all N≤I≤M?
* What are all the (path,revision) objects that are the same line of
history as a given p...@rn? In other words, what are all the places
p...@rn has been copied to, and all the revisions where those copies
were touched?
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 01:27:28PM +0200, Daniel Shahaf wrote:
> [ sorry if I'm repeating; haven't read the whole thread ]
>
> Johan Corveleyn wrote on Sun, Nov 28, 2010 at 10:05:15 +0100:
> > FWIW, you do have a point, Andrey (and others), that this is a valid
> > use case (finding the rev in which a file was deleted) which isn't
> > well supported by svn currently. I think the svn devs are very much
> > aware of this, but it just isn't there yet. See also this issue:
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3627 - FS API
> > support for oldest-to-youngest history traversal
> >
> > It literally mentions this use case as one of the "high-level user needs":
> > " - allowing 'svn log' to fully traverse the entire history of a
> > given versioned
> > object, both for completeness' sake and to facilitate (for example)
> > resurrection
> > of deleted items from their most-recently-existing forms."
> >
> > Unfortunately, according to the current plans, it might be a while
> > before this is implemented. On the roadmap, it is listed as being
> > dependent on FS-NG ("Flexible Repository Storage"), on the list of
> > "most wanted features":
> > http://subversion.apache.org/roadmap.html#features-most-wanted.
>
> Just to clarify, this doesn't mean we don't like this feature; it means
> a non-trivial bit of work is needed to implement it, because this
> question is not easily answerable given the current state/design of
> the backends.
>
>
> There are two related questions here:
>
> * Given p...@rn which exists, what is the largest rM such that
> p...@ri and p...@rn are the same node (no adds/replaces/deletes
> have occured in or above PATH) for all N≤I≤M?
>
> * What are all the (path,revision) objects that are the same line of
> history as a given p...@rn? In other words, what are all the places
> p...@rn has been copied to, and all the revisions where those copies
> were touched?
Of course, these questions can be answered by a human or a script if given
some time to crawl through the output of svn log. E.g. the trumerge
script does this: http://trumerge.open.collab.net/
The real problem is that we want to be able to answer these questions
very fast, and some design aspects work against this. For instance,
FSFS by design does not allow modifying old revisions. So where do
we store the copy-to information for a given p...@n? The best idea we've
had so far was using an sqlite database. But that's really a hack
around a design that doesn't support all the features we want.
Stefan
Re: AW: How to find out the rev number where a file was deleted?
On 11/28/10 12:28 AM, Andrey Repin wrote: It doesn't track the future of a file, it tracks the history. Start with a peg revision Wat? It start with HEAD irrelevant to what PEG revision we've specified. And immediately spitting "no such file", although the file is 100% there. Yes, if you ask it for HEAD in your range, it has to start there because history only goes backwards. Or it will try to and fail. [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 svn: '/repos/!svn/bc/35/test' path not found But you are asking it to track the future of that file to a place it doesn't exist. I beg to differ. I'm asking to 1. Pick the file (directory) /test at revision 2 2. Track it's changes history from revision 0 to HEAD. But, because subversion tracks a file's history, not it's future even if you think you are asking it to start with rev 0 and go forward, in fact it can only start with the last rev and work backwards. 3. I'm fully aware that the directory does not exist in HEAD, neither I ask Subversion to look there in first place. (literal meaning of "first place") You have asked it to pick the version of /test that existed at revision 2, then get the history of that item in HEAD back to rev 0 and print it out backwards. Or at least that's the only way it can attempt to do what you asked. 4. Quite (un)surprisingly, my intent is to actually find revision, in which the destruction was made. Because, quite (un)surprisingly, I don't know that. I'd like to be able to see the future too - but unfortunately, neither subversion nor I can do that. Nah, it could just obey to @PEG rule. Everything will be simpler. Unless there's absolutely no other way to track the file from @PEG, which i doubt, since you DO can access the file by @PEG, as well as navigate back in time easier, than forward. It does obey @peg, and it can navigate as far as that item existed. If you give it a range where that item exists at the latest rev it will show you the log of its history. If you give it a range where the item doesn't exist it will tell you it doesn't exist because it can only work by finding the highest rev in the range and following history. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100: > The real problem is that we want to be able to answer these questions > very fast, and some design aspects work against this. For instance, > FSFS by design does not allow modifying old revisions. So where do > we store the copy-to information for a given p...@n? copy-to information is immutable (never changes once created), so we could add another hierarchy (parallel to revs/ and revprops/) in which to store that information. Any 'cp f...@n bar' operation would need to create/append a file in that hierarchy. Open question: how to organize $new_hierarchy/16/16384/** to make it efficiently appendable and queryable (and for what queries? "Iterate all copied-to places" is one). Makes sense? > The best idea we've had so far was using an sqlite database. But > that's really a hack around a design that doesn't support all the > features we want. > > Stefan
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf wrote: > Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100: >> The real problem is that we want to be able to answer these questions >> very fast, and some design aspects work against this. For instance, >> FSFS by design does not allow modifying old revisions. So where do >> we store the copy-to information for a given p...@n? > > copy-to information is immutable (never changes once created), so we > could add another hierarchy (parallel to revs/ and revprops/) in which > to store that information. Any 'cp f...@n bar' operation would need to > create/append a file in that hierarchy. > > Open question: how to organize $new_hierarchy/16/16384/** to make it > efficiently appendable and queryable (and for what queries? "Iterate > all copied-to places" is one). > > Makes sense? I'm not sure. But there is another alternative: while we wait for FS-NG (or another solution like you propose), one could implement the "slow" algorithm within the current design. Just automating what a user (or script) currently does when looking for this information, i.e. a binary search. Of course it would be slow, but it would certainly already provide value. At the very least, it saves users a lot of time searching FAQ's and list archives, wondering why this doesn't work, understanding the design limitations, and then finally implementing their own script or doing a one-time manual search. Then, when FS-NG arrives, or someone comes up with a way to index this information, it can be "optimized". I don't know if there would be fundamental problems with that, apart from the fact that someone still needs to implement it of course ... Cheers, -- Johan
Re: AW: How to find out the rev number where a file was deleted?
Johan Corveleyn wrote on Sun, Nov 28, 2010 at 21:20:28 +0100: > On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf > wrote: > > Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100: > >> The real problem is that we want to be able to answer these questions > >> very fast, and some design aspects work against this. For instance, > >> FSFS by design does not allow modifying old revisions. So where do > >> we store the copy-to information for a given p...@n? > > > > copy-to information is immutable (never changes once created), so we > > could add another hierarchy (parallel to revs/ and revprops/) in which > > to store that information. Any 'cp f...@n bar' operation would need to > > create/append a file in that hierarchy. > > > > Open question: how to organize $new_hierarchy/16/16384/** to make it > > efficiently appendable and queryable (and for what queries? "Iterate > > all copied-to places" is one). > > > > Makes sense? > > I'm not sure. But there is another alternative: while we wait for > FS-NG (or another solution like you propose), one could implement the > "slow" algorithm within the current design. Are you advocating to implement it in the core (as an svn_fs_* API) or as a third-party script? The latter is certainly fine, but regarding the former I don't see the point of adding an API that cannot be implemented efficiently at this time. > Just automating what a > user (or script) currently does when looking for this information, > i.e. a binary search. > > Of course it would be slow, but it would certainly already provide > value. At the very least, it saves users a lot of time searching FAQ's > and list archives, wondering why this doesn't work, understanding the > design limitations, and then finally implementing their own script or > doing a one-time manual search. > > Then, when FS-NG arrives, or someone comes up with a way to index this > information, it can be "optimized". > > I don't know if there would be fundamental problems with that, apart > from the fact that someone still needs to implement it of course ... > > Cheers, > -- > Johan
Re: AW: How to find out the rev number where a file was deleted?
On Sun, Nov 28, 2010 at 7:59 AM, Andrey Repin wrote: > Greetings, Les Mikesell! > > >> thanks for having responded. > >> Can I file a feature request for that in the issue tracker, > >> what do you think? > >> > >> @Ryan: Of course with a peg rev I can log that single rev. But the > >> rev number of that rev is that what we are looking for! To find out > >> this rev number, we want to use an earlier peg rev where we know > >> that the file still existed and want to add "-r1:head" as operative > >> revs to see all revs including the rev where the file was deleted. > >> > > > The deletion should show in an 'svn log -v' of the directory where the > file was > > deleted. > > That directory was deleted as well. As well, at unknown revision. Multiple > times. > > The question is not that we can work around the issue, the question is, why > Subversion can't do this for us? I can add my own case to this list. > > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1850347 > > I can understand that it's not easy to track deletes/copies forward, but > tracking history from creation time to deletion(renamind implies > deletion) time should be possible IMO. > And this should be possible without user's guesswork. It's fairly simple to > find correct revision range in repository with 40 commits. > In repository with 40,000 commits things became "a bit" scary Have you tried a combination of 'log -v' and grep? IMHO, that would be the quickest to implement, and simplest to achieve. Cheers, Daniel B.
Re: AW: How to find out the rev number where a file was deleted?
* Stephen Connolly: > Have you considered doing a binary search to find the revision that it was > deleted in? > > svn ls .../t...@2 > Exists > svn ls .../t...@head > No such file in revision 50002 > svn ls .../t...@25002 > Exists > svn ls .../t...@37502 > No such file > svn ls .../t...@31252 > Exists, etc > > You'll get the revision in at most log2 HEAD iterations If the path has been deleted multiple times, the result won't be stable in the sense that you're guaranteed to get the same answer if further (unrelated) commits are made. This could be quite confusing. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
RE: AW: How to find out the rev number where a file was deleted?
> -Original Message- > From: Les Mikesell > On 11/28/10 12:28 AM, Andrey Repin wrote: > > 4. Quite (un)surprisingly, my intent is to actually find revision, > > in which the destruction was made. Because, quite (un)surprisingly, > > I don't know that. > > I'd like to be able to see the future too - but unfortunately, neither > subversion nor I can do that. >From the user's perspective, it's most definitely not the future he's asking Subversion to show, but the past. Thanks for this interesting discussion. I often wondered whether what Andrey is asking was possible and whether there was anything better than my tentative poking at moreless random peg revs in the repo to find the moment a file disappeared, or came into being. Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. What's really needed, I think, is an index on the URL maintained by the server that points to the revision ranges where the node existed. That would allow me to do a lookup on any given URL and quickly see whether it has ever existed, and when precisely; or not at all. Due to copying for branches and tags, there will be an explosion of repo URLs. But maybe there is a way to mitigate this. I can see what Andrey is asking for is currently not supported; okay, I'm sure it'll be there in the future. Thanks again for this very good discussion, which clarifies the situation for me. Michael
RE: AW: How to find out the rev number where a file was deleted?
> From: Johan Corveleyn > I'm not sure. But there is another alternative: while we wait for > FS-NG (or another solution like you propose), one could implement the > "slow" algorithm within the current design. Just automating what a > user (or script) currently does when looking for this information, > i.e. a binary search. > > Of course it would be slow, but it would certainly already provide > value. At the very least, it saves users a lot of time searching FAQ's > and list archives, wondering why this doesn't work, understanding the > design limitations, and then finally implementing their own script or > doing a one-time manual search. > > Then, when FS-NG arrives, or someone comes up with a way to index this > information, it can be "optimized". A binary search requires that you know at least one rev where the file existed. What if you know (from reading some note) that it did exist, but not when? You can still do a search, but in the worst case you will have to look at every single rev in the repo. Michael
Re: AW: How to find out the rev number where a file was deleted?
On 11/29/2010 4:23 AM, Ludwig, Michael wrote: 4. Quite (un)surprisingly, my intent is to actually find revision, in which the destruction was made. Because, quite (un)surprisingly, I don't know that. I'd like to be able to see the future too - but unfortunately, neither subversion nor I can do that. From the user's perspective, it's most definitely not the future he's asking Subversion to show, but the past. Yes he is, because he is identifying the peg rev but wants the log to give the history of HEAD which is in the future as far as anything that could have been written at the time of that rev, and in fact is a place where the item doesn't exist. Thanks for this interesting discussion. I often wondered whether what Andrey is asking was possible and whether there was anything better than my tentative poking at moreless random peg revs in the repo to find the moment a file disappeared, or came into being. Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. Fisheye (a commercial product) does a brute-force extract/index of all the filenames and content in all revs in a repo for quick searches. I'm not sure if there is any equivalent open source program but this is probably the right answer for anyone who needs to do that frequently. If you don't know exactly what you are looking for, you might only remember a piece of content instead of the name. Fisheye can find it either way. What's really needed, I think, is an index on the URL maintained by the server that points to the revision ranges where the node existed. That would allow me to do a lookup on any given URL and quickly see whether it has ever existed, and when precisely; or not at all. There's a big problem here - whether a URL exists or not usually isn't the right answer for things that have been deleted and replaced by something else of the same name. What you usually want is the history of only one of those things - which may track backwards through renames or have been copied from somewhere else. A thing with the same name added later as a replacement may have nothing in common with the item you want. I'm not sure what the right test for this would be other than asking for a log with a rev range and a peg rev to anchor it to one specific version. -- Les Mikesell lesmikes...@gmail.com
RE: AW: How to find out the rev number where a file was deleted?
> -Original Message- > From: Les Mikesell > On 11/29/2010 4:23 AM, Ludwig, Michael wrote: > >>> 4. Quite (un)surprisingly, my intent is to actually find > >>> revision, in which the destruction was made. Because, quite > >>> (un)surprisingly, I don't know that. > >> > >> I'd like to be able to see the future too - but > >> unfortunately, neither subversion nor I can do that. > > > > From the user's perspective, it's most definitely not the > > future he's asking Subversion to show, but the past. > > Yes he is, because he is identifying the peg rev but wants the > log to give the history of HEAD which is in the future as far as > anything that could have been written at the time of that rev, > and in fact is a place where the item doesn't exist. I can see that from the peg rev point of view, HEAD is the future. But I think we can also agree that from the SVN user's perspective, every single existing rev including HEAD is in the past. > > What's really needed, I think, is an index on the URL > > maintained by the server that points to the revision ranges > > where the node existed. That would allow me to do a lookup on > > any given URL and quickly see whether it has ever existed, and > > when precisely; or not at all. > > There's a big problem here - whether a URL exists or not usually > isn't the right answer for things that have been deleted and > replaced by something else of the same name. What you usually > want is the history of only one of those things - which may > track backwards through renames or have been copied from > somewhere else. Yes, there could be several items - several revision ranges - in the index, pointing to several unrelated objects. But is it a big problem? In database speak, we'd indeed have a compound key for *uniquely* identifying an object, with the first part of that compound key being the URL, and the second part the revision. But if we don't know the revision, we simply use the URL alone and receive a list of all the items ever to have appeared at that URL. Which ones we're interested in is then a matter of human decision; but gone is the tedium (or wasteful scanning) of establishing the list in the first place. > A thing with the same name added later as a replacement may have > nothing in common with the item you want. I'm not sure what the > right test for this would be other than asking for a log with a > rev range and a peg rev to anchor it to one specific version. Give me a listing of the things and either require me to specify which one I want or show them all in full detail, depending on the circumstances. In the special case where there is only one item in the list, no further precision is needed. Best, Michael
Re: AW: How to find out the rev number where a file was deleted?
On 11/29/2010 11:45 AM, Ludwig, Michael wrote: I'd like to be able to see the future too - but unfortunately, neither subversion nor I can do that. From the user's perspective, it's most definitely not the future he's asking Subversion to show, but the past. Yes he is, because he is identifying the peg rev but wants the log to give the history of HEAD which is in the future as far as anything that could have been written at the time of that rev, and in fact is a place where the item doesn't exist. I can see that from the peg rev point of view, HEAD is the future. But I think we can also agree that from the SVN user's perspective, every single existing rev including HEAD is in the past. Yes, but from the perspective of getting history where you can only go backwards, you have to specify the right starting point, and a rev where the thing doesn't exist isn't the right place. Yes, there could be several items - several revision ranges - in the index, pointing to several unrelated objects. But is it a big problem? Yes, if you are in the habit of deleting things and adding them back, then wanting one of the deleted versions. In database speak, we'd indeed have a compound key for *uniquely* identifying an object, with the first part of that compound key being the URL, and the second part the revision. But if we don't know the revision, we simply use the URL alone and receive a list of all the items ever to have appeared at that URL. Which ones we're interested in is then a matter of human decision; but gone is the tedium (or wasteful scanning) of establishing the list in the first place. That's a reasonable thing to want, but perhaps not reasonable for the server to deliver. Would you expect your database to find things for you if you renamed or deleted the table holding them? A thing with the same name added later as a replacement may have nothing in common with the item you want. I'm not sure what the right test for this would be other than asking for a log with a rev range and a peg rev to anchor it to one specific version. Give me a listing of the things and either require me to specify which one I want or show them all in full detail, depending on the circumstances. In the special case where there is only one item in the list, no further precision is needed. It's a big order to make that happen through a client-server connection that has no such existing concept and no server side hints to do it efficiently. Maybe the log facility could have another symbolic token to replace HEAD that would mean you wanted it to find the end-of-the-line for the item if it was deleted. I'd be more inclined to want a separate full-text index and search facility instead of building that into the repository, though. It would be nice if someone could build a free version, perhaps using riaksearch as the underlying tool so the exploded index could be distributed over multiple machines. -- Les Mikesell lesmikes...@gmail.com
RE: AW: How to find out the rev number where a file was deleted?
> -Original Message- > From: Les Mikesell > On 11/29/2010 11:45 AM, Ludwig, Michael wrote: > > I can see that from the peg rev point of view, HEAD is the > > future. But I think we can also agree that from the SVN user's > > perspective, every single existing rev including HEAD is in > > the past. > > Yes, but from the perspective of getting history where you can > only go backwards, you have to specify the right starting point, > and a rev where the thing doesn't exist isn't the right place. Certainly. Just imagine you weren't required to specify a revision: svn show svn://server.dev/eins/zwei/drei/vier.txt seq node-id revision status 1 1bca34933 A 1 1bca34975 M 1 1bca34976 M 1 1bca349 111 M 1 1bca349 188 D 2 4941b20 1099 A 2 4941b20 1101 M 2 4941b20 1108 M 2 4941b20 1831 D 3 6e6cdff 18004 A 3 6e6cdff 18014 M The node ID would identify the versioned object. (I don't know anything about what the node ID might look like; the example is just a wild guess.) This sketch certainly has flaws, but is it an unreasonable proposal? Users might find it useful. > > Yes, there could be several items - several revision ranges - > > in the index, pointing to several unrelated objects. But is it > > a big problem? > > Yes, if you are in the habit of deleting things and adding them > back, then wanting one of the deleted versions. You'd read it from the list and identify it by revision. No changes to existing behaviour and functionality. > > In database speak, we'd indeed have a compound key for > > *uniquely* identifying an object, with the first part of that > > compound key being the URL, and the second part the revision. > > But if we don't know the revision, we simply use the URL alone > > and receive a list of all the items ever to have appeared at > > that URL. Which ones we're interested in is then a matter of > > human decision; but gone is the tedium (or wasteful scanning) > > of establishing the list in the first place. > > That's a reasonable thing to want, but perhaps not reasonable > for the server to deliver. Would you expect your database to > find things for you if you renamed or deleted the table holding > them? I wouldn't. But if I had a trigger to log changes made to a table to a log table I'd expect the system to know the table history. That's maybe a bit more aligned with what I might expect from a version control system. > >> A thing with the same name added later as a replacement may > >> have nothing in common with the item you want. I'm not sure > >> what the right test for this would be other than asking for a > >> log with a rev range and a peg rev to anchor it to one > >> specific version. > > > > Give me a listing of the things and either require me to > > specify which one I want or show them all in full detail, > > depending on the circumstances. In the special case where > > there is only one item in the list, no further precision is > > needed. > > It's a big order to make that happen through a client-server > connection that has no such existing concept and no server side > hints to do it efficiently. I agree the server side needs to have the URL index to do it efficiently. Given that index, however, it shouldn't be difficult. I wouldn't redesign the existing set of commands, just provide one in addition that provides the history of a URL. Best, Michael
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! 4. Quite (un)surprisingly, my intent is to actually find revision, in which the destruction was made. Because, quite (un)surprisingly, I don't know that. >>> >>> I'd like to be able to see the future too - but unfortunately, neither >>> subversion nor I can do that. >> >> From the user's perspective, it's most definitely not the future he's >> asking Subversion to show, but the past. > Yes he is, because he is identifying the peg rev but wants the log to > give the history of HEAD which is in the future as far as anything that > could have been written at the time of that rev, and in fact is a place > where the item doesn't exist. As I said, I'm well aware of that. So, even asking, I don't expect it to produce any result at that point. You know, the classic school primer asking you for something extraordinary not to make any sense of it, but to teach you to support your own opinion with arguments. In this case the argument should be "this shit was deleted in rev.X, so it can't be found in HEAD by any means, unless you resurrect it". >> Thanks for this interesting discussion. I often wondered whether what >> Andrey is asking was possible and whether there was anything better than >> my tentative poking at moreless random peg revs in the repo to find the >> moment a file disappeared, or came into being. >> >> Binary search on the 0 to HEAD revision range is a possibility, but it's >> also a rather wasteful workaround. > Fisheye (a commercial product) does a brute-force extract/index of all > the filenames and content in all revs in a repo for quick searches. > I'm not sure if there is any equivalent open source program but this is > probably the right answer for anyone who needs to do that frequently. Sorry, do you mean that we have to pay to cover the lack of functionality in Subversion? And it should remain this way? >> What's really needed, I think, is an index on the URL maintained by the >> server that points to the revision ranges where the node existed. That >> would allow me to do a lookup on any given URL and quickly see whether >> it has ever existed, and when precisely; or not at all. > There's a big problem here - whether a URL exists or not usually isn't > the right answer for things that have been deleted and replaced by > something else of the same name. I strongly suspect that Ludwig had in mind that Subversion could track revisions in which file has been changed in either way. Then no way you could confuse between different files with same URL. -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.11.2010, <16:28> Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/10 5:21 AM, Ludwig, Michael wrote: I can see that from the peg rev point of view, HEAD is the future. But I think we can also agree that from the SVN user's perspective, every single existing rev including HEAD is in the past. Yes, but from the perspective of getting history where you can only go backwards, you have to specify the right starting point, and a rev where the thing doesn't exist isn't the right place. Certainly. Just imagine you weren't required to specify a revision: svn show svn://server.dev/eins/zwei/drei/vier.txt seq node-id revision status 1 1bca34933 A 1 1bca34975 M 1 1bca34976 M 1 1bca349 111 M 1 1bca349 188 D 2 4941b20 1099 A 2 4941b20 1101 M 2 4941b20 1108 M 2 4941b20 1831 D 3 6e6cdff 18004 A 3 6e6cdff 18014 M The node ID would identify the versioned object. (I don't know anything about what the node ID might look like; the example is just a wild guess.) This sketch certainly has flaws, but is it an unreasonable proposal? Users might find it useful. But the name has nothing to do with the versioning of the object. Names appear in the directory containing it. The object itself might have a different name every revision if the modifications are moves. Or the same name might be a different object with deletes followed by adds or copies to the name in question. Subversion only tracks the object itself using the name to identify a starting point. But you can see the names come and go in the history of the directories containing them. Yes, there could be several items - several revision ranges - in the index, pointing to several unrelated objects. But is it a big problem? Yes, if you are in the habit of deleting things and adding them back, then wanting one of the deleted versions. You'd read it from the list and identify it by revision. No changes to existing behaviour and functionality. Where does the client/server protocol have such functionality now? I think it is only in showing a log -v of the directory containing the name. I wouldn't. But if I had a trigger to log changes made to a table to a log table I'd expect the system to know the table history. That's maybe a bit more aligned with what I might expect from a version control system. You have that in the versioning of the directory where the name appears. It's a big order to make that happen through a client-server connection that has no such existing concept and no server side hints to do it efficiently. I agree the server side needs to have the URL index to do it efficiently. Given that index, however, it shouldn't be difficult. I wouldn't redesign the existing set of commands, just provide one in addition that provides the history of a URL. That already exists. A 'log -v' from the top of the repo will show all deletes and adds ever done. The output isn't convenient to feed to grep, etc., though. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/10 7:35 AM, Andrey Repin wrote: Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. Fisheye (a commercial product) does a brute-force extract/index of all the filenames and content in all revs in a repo for quick searches. I'm not sure if there is any equivalent open source program but this is probably the right answer for anyone who needs to do that frequently. Sorry, do you mean that we have to pay to cover the lack of functionality in Subversion? And it should remain this way? Yes, I would not expect fast indexed full-text searches across names and content to ever be a part of the version control system itself. But the functionality to find filename changes is there - just 'log -v' from the top. There's a big problem here - whether a URL exists or not usually isn't the right answer for things that have been deleted and replaced by something else of the same name. I strongly suspect that Ludwig had in mind that Subversion could track revisions in which file has been changed in either way. Then no way you could confuse between different files with same URL. It does track that, but I don't think there is a convenient way to ask for it. Or for the server itself to find it efficiently. -- Les Mikesell lesmikes...@gmail.com
RE: AW: How to find out the rev number where a file was deleted?
> -Original Message- > From: Les Mikesell > On 11/30/10 5:21 AM, Ludwig, Michael wrote: > > > > svn show svn://server.dev/eins/zwei/drei/vier.txt > > > > seq node-id revision status > > 1 1bca34933 A > > 1 1bca34975 M > > 1 1bca34976 M > > 1 1bca349 111 M > > 1 1bca349 188 D > > 2 4941b20 1099 A > > 2 4941b20 1101 M > > 2 4941b20 1108 M > > 2 4941b20 1831 D > > 3 6e6cdff 18004 A > > 3 6e6cdff 18014 M > > > > The node ID would identify the versioned object. (I don't know > > anything about what the node ID might look like; the example > > is just a wild guess.) This sketch certainly has flaws, but is > > it an unreasonable proposal? Users might find it useful. > > But the name has nothing to do with the versioning of the > object. True, but many humans tend to attach meaning to names, to remember them, and to refer to them. For example, names often appear in the contents of other files. They just have a tendency of cropping up here and there. People might find it useful if Subversion had better support for this. > >>> Yes, there could be several items - several revision ranges > >>> - in the index, pointing to several unrelated objects. But > >>> is it a big problem? > >> > >> Yes, if you are in the habit of deleting things and adding > >> them back, then wanting one of the deleted versions. > > > > You'd read it from the list and identify it by revision. No > > changes to existing behaviour and functionality. > > Where does the client/server protocol have such functionality > now? I think it is only in showing a log -v of the directory > containing the name. It doesn't have this functionality right now. You'd have to parse the output of "log -v", yes. It's onerous on both the server and the human. > >> It's a big order to make that happen through a client-server > >> connection that has no such existing concept and no server > >> side hints to do it efficiently. > > > > I agree the server side needs to have the URL index to do it > > efficiently. Given that index, however, it shouldn't be > > difficult. I wouldn't redesign the existing set of commands, > > just provide one in addition that provides the history of a > > URL. > > That already exists. A 'log -v' from the top of the repo will > show all deletes and adds ever done. The output isn't > convenient to feed to grep, etc., though. It would work, somehow. I'm aware of that. I'm just imagining a more convenient feature that also performs better. A lookup instead of a scan. Michael
Re: AW: How to find out the rev number where a file was deleted?
Greetings, Les Mikesell! Binary search on the 0 to HEAD revision range is a possibility, but it's also a rather wasteful workaround. >> >>> Fisheye (a commercial product) does a brute-force extract/index of all >>> the filenames and content in all revs in a repo for quick searches. >>> I'm not sure if there is any equivalent open source program but this is >>> probably the right answer for anyone who needs to do that frequently. >> >> Sorry, do you mean that we have to pay to cover the lack of functionality in >> Subversion? And it should remain this way? > Yes, I would not expect fast indexed full-text searches across names and > content > to ever be a part of the version control system itself. But the > functionality > to find filename changes is there - just 'log -v' from the top. Where you see a reference to full-text search in my quote? I have intentionally omit that part of your reply. >>> There's a big problem here - whether a URL exists or not usually isn't >>> the right answer for things that have been deleted and replaced by >>> something else of the same name. >> >> I strongly suspect that Ludwig had in mind that Subversion could track >> revisions in which file has been changed in either way. >> Then no way you could confuse between different files with same URL. > It does track that, but I don't think there is a convenient way to ask for > it. > Or for the server itself to find it efficiently. It only track it back into the past. There's no sane way to track it forward currently. I see some complications in implementation of this ability, mainly in the controversial way it should work (i.e. alter multiple previous revisions to embed the forward tracking links, or to maintain a parallel base for them). -- WBR, Andrey Repin (anrdae...@freemail.ru) 30.11.2010, <21:10> Sorry for my terrible english...
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/2010 12:04 PM, Ludwig, Michael wrote: But the name has nothing to do with the versioning of the object. True, but many humans tend to attach meaning to names, to remember them, and to refer to them. For example, names often appear in the contents of other files. They just have a tendency of cropping up here and there. People might find it useful if Subversion had better support for this. But when humans use names they have to understand their non-unique nature or face surprises. If there was a Les Mikesell before 1949, it wasn't me. If there are others now, they aren't me either. Subversion represents a matrix of paths and time; different names come and go over time and very often many different names refer to the same thing and the same name may to different things at different times. Where does the client/server protocol have such functionality now? I think it is only in showing a log -v of the directory containing the name. It doesn't have this functionality right now. You'd have to parse the output of "log -v", yes. It's onerous on both the server and the human. Saying you don't like to parse the answer isn't the same as saying it doesn't have the functionality. That already exists. A 'log -v' from the top of the repo will show all deletes and adds ever done. The output isn't convenient to feed to grep, etc., though. It would work, somehow. I'm aware of that. I'm just imagining a more convenient feature that also performs better. A lookup instead of a scan. There are lots of other places I would consider more important than making it easy to find something you deleted on purpose. A handy way to track where something went when you later copied to a tag might be something people would be more likely to want to know frequently - but again, the answer might be large and hard to parse because there's no particular limit to the number of copies that could have been made. And if you did have the name lookup you want, you still have to deal with the issue that in every rev where the name is found it may be some different object. -- Les Mikesell lesmikes...@gmail.com
Re: AW: How to find out the rev number where a file was deleted?
On 11/30/2010 12:19 PM, Andrey Repin wrote:
Yes, I would not expect fast indexed full-text searches across names and content
to ever be a part of the version control system itself. But the functionality
to find filename changes is there - just 'log -v' from the top.
Where you see a reference to full-text search in my quote? I have intentionally
omit that part of your reply.
I think you are asking for a search for the text of a path/filename
across revisions - but maybe that was the way someone else interpreted
the problem. Following an object's path as it may fan out into
different paths/names or be deleted in later revs is a somewhat
different concept and perhaps closer to what you need to convert your
svn log -r 0:head file://${HOME}/trash/repo/f...@3
transparently into
svn log -r 0:4 file://${HOME}/trash/repo/f...@3
But, if you had tagged this version or made similar copies elsewhere or
renamed it, wouldn't you want a forward-following system to track into
the new path(s) as it does going backwards now instead of ending when
one of its names was deleted?
--
Les Mikesell
lesmikes...@gmail.com
RE: AW: How to find out the rev number where a file was deleted?
> -Original Message- > From: Les Mikesell > On 11/30/2010 12:04 PM, Ludwig, Michael wrote: > > True, but many humans tend to attach meaning to names, to > > remember them, and to refer to them. > But when humans use names they have to understand their > non-unique nature or face surprises. If there was a Les > Mikesell before 1949, it wasn't me. If there are others now, > they aren't me either. Subversion represents a matrix of paths > and time; different names come and go over time and very often > many different names refer to the same thing and the same name > may to different things at different times. Exactly. Most humans do understand. For instance, I'm aware that in the place where I live there may be 20 or 50 people with exactly the same name. I understood the non-uniqueness of names back in elementary school. A forteriori, developers do understand. > > It doesn't have this functionality right now. You'd have to > > parse the output of "log -v", yes. It's onerous on both the > > server and the human. > > Saying you don't like to parse the answer isn't the same as > saying it doesn't have the functionality. It provides data that you then have to scan, but it doesn't support the lookup operation I want. > There are lots of other places I would consider more important > than making it easy to find something you deleted on purpose. Sure, there might be more important things. > And if you did have the name lookup you want, you still have to > deal with the issue that in every rev where the name is found it > may be some different object. It is not an issue, Andrey and I mentioned that repeatedly. The revision disambiguates the name and provides identity. Best, Michael
Re: AW: How to find out the rev number where a file was deleted?
On 12/1/2010 6:40 AM, Ludwig, Michael wrote: And if you did have the name lookup you want, you still have to deal with the issue that in every rev where the name is found it may be some different object. It is not an issue, Andrey and I mentioned that repeatedly. I think the functionality he wants is different. The revision disambiguates the name and provides identity. It seems like you are asking for what you would get if you collate the output of: svn ls -r? URL where you cycle the ? through all the revisions. That is, you want every instance where the name appears regardless of the objects referenced by that name. I think Andrey wants something more like: svn log -r0:? u...@peg where the ? is the highest rev where the same object was present at that path. Or at least to find the value of that highest rev. But for me, the question I would want to be able to answer would more likely be "where else was this copied?" as in "what release tags include this file or its descendants?" or "what is its new name after a move in a future rev?" But we all agree that there are things you might want that you can't do easily. The developers here all use an issue tracking system with tickets to discuss the changes being done and always include the ticket number in a certain format in the commit message for every commit - in fact we just added a pre-commit hook to enforce that. And I think the svn revision that completes/closes an issue goes back to the ticket. This doesn't exactly address tracking changes to individual files and objects, but at a higher level it connects the purpose of a change with the work itself and lets you use a better tool to handle the related context, making it less likely that you would need a brute-force search for lost items. -- Les Mikesell lesmikes...@gmail.com
RE: AW: How to find out the rev number where a file was deleted?
> From: Les Mikesell [mailto:lesmikes...@gmail.com] > On 12/1/2010 6:40 AM, Ludwig, Michael wrote: > > > >> And if you did have the name lookup you want, you still have to > >> deal with the issue that in every rev where the name is found it > >> may be some different object. > > > > It is not an issue, Andrey and I mentioned that repeatedly. > > I think the functionality he wants is different. It is. But there was overlap in what we said. > > The revision disambiguates the name and provides identity. > > It seems like you are asking for what you would get if you > collate the > output of: > svn ls -r? URL > where you cycle the ? through all the revisions. > That is, you want every instance where the name appears regardless of > the objects referenced by that name. No, but not entirely dissimilar. I gave an example a couple of messages ago. Best, Michael
