[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: recovering a deleted file

From: Benjamin Pflugmann <benjamin-svn-usr_at_pflugmann.de>
Date: 2003-11-01 06:57:03 CET

Hi!

Some explanations why you get the messages you got (Ben already
covered how you get what you want).

On Wed 2003-10-29 at 18:17:59 -0800, you wrote
[...]
> I did a svn delete on a bunch of files and then commit from the top
> level, making version 3. Then in the subdirectory I said
> $ svn log survival-internal.Rd
> Skipped survival-internal.Rd

There exists no survival-internal.Rd in your WC (working copy), so
there is nothing to display. Not sure, why it says "skipped" instead
of an error, but that isn't really relevant to your concern.

> I was hoping this would show me the history. Then
> $ echo $REPOS
> file:///usr/local/var/subversion/survivalrds/trunk
> $ svn log $REPOS/man/survival-internal.Rd
> svn: Filesystem has no item
> svn: file not found: revision '3', path
> '/survivalrds/trunk/man/survival-internal.Rd'

Well, as it says: The command you issued means "go to the HEAD (here:
revision 3), look for a file named man/survival-internal.Rd and show
me the log for it".

There is no such file in revision 3, because you deleted it
beforehand. Therefore the error message you got.

> $ svn log -r 1:3 $REPOS/man/survival-internal.Rd
> svn: Filesystem has no item
> svn: file not found: revision '3', path
> '/survivalrds/trunk/man/survival-internal.Rd'

Principially the same thing. Without looking at the code, I presume
this is implement like the above: "go to the second revision (here:
3), look for a file named man/survival-internal.Rd and show me the log
for it, but additionally trace the file back to revision 1, too".

> $ svn log -r 1:2 $REPOS/man/survival-internal.Rd
> ------------------------------------------------------------------------
> rev 1: ross | 2003-10-28 16:44:30 -0800 (Tue, 28 Oct 2003) | 5 lines
[...]
>
> Is that the way it's supposed to be?

Yes.

> I suppose there's some argument for blowing off deleted files, but
> I'd think at least -r 1:3 would work.

Yes, there is some argument for "svn log" being intelligent and trying
to find the file in earlier revisions then the one you specified. But
you should see that this is a bad idea, if you remember that the
storage basically contains snapshot in time (called revisions) of your
directory tree. That means that the storage hierarchy is like (much
simplified)

  revision/path/file

That means, it is cheap to look for a file in a specific revision
(like "ls 3/my/file" in a shell for a normal fs), but it is expensive
to look for a file without knowing the revision (like "ls */my/file").

Aside from that, if 2/my/foo is a different one than 1/my/foo (i.e. it
got deleted and recreated as a different file), it is not obvious
which file you want (though, yes, one could take some convention, like
the latest one or such).

> Then I tried update to get the file:
> $ svn update -r 2 survival-internal.Rd
> svn: warning: svn_wc_is_wc_root: 'survival-internal.Rd' is not a
> versioned resource

Again, there is such file in your WC, how should Subversion know which
file you mean? (Remember, that survival-internal.Rd could come from a
different repository than the directory you are in and the URL that
identifies that repository is taken from the WC entry for that file,
but you have no such a file.)

You probably meant to so something like "put the survival-internal.Rd
from revision 2 in my WC" and the svn speak for that is something like:

  $ svn copy -r2 $REPOS/man/survival-internal.Rd .
  (I think, it's untested)

[If you come from a CVS background where an update would have worked:
Well, the reason why this works easily with CVS is the same reason why
CVS is has problems with renames and similar stuff: it's hierarchy is
more my/path/revision than revision/my/path.]

> $ svn update -r 2 $REPOS/man/survival-internal.Rd
> svn: Path is not a working copy directory
> svn: 'file:///usr/local/var/subversion/survivalrds/trunk/man' is not a
> working copy

Well, update only works on a WC, and so specifying an URL doesn't make
too much sense. You had the right idea here, just used the wrong
command (update instead of copy).

> How come neither of those worked?

I hope my explanations were helpful somehow.

Although some of the things you tried look intuitive on the first
sight, it becomes obvious that they couldn't work, if you consider
that a revision control system is a filesystem that has an additional
component, namely the time scale (here called revisions) and the
syntax has to be consistent for this requirement.

In other words: If some of the things you tried were made to work,
some other, quite normal operations would become awkward to write.

That said, of course, there are also cases in the user interface, that
are less than perfect, and could use some improvement.

> Oh, I also tried co, but it created a directory..

Subversion (currently) doesn't allow to "checkout" to work without a
containing directory, because the ".svn" directory (the administrative
area) has to be stored somewhere. Son't know if/how it is possible to
tell svn to checkout in the existing WC.

Oh, and if any of the explanations sounded to basic/obvious, please
don't be offended. I simply didn't know which knowledge I may
presume. And in case much of it was new to you, I recommend reading
the svn book:

  http://svnbook.red-bean.com/

which covers most of what I said and a lot more.

Bye,

        Benjamin.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 1 07:01:33 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.