I can't confirm this is a bug, but I suspect it might be.
First of all, the Subversion 1.1 release notes have this item:
-- cut here --
Client follows renames (new client feature)
Subversion makes a lot of noise about the way branches (copies) of
files and directories maintain historical connections to their source,
but in Subversion 1.0 only 'svn log' actually follows that history,
not 'svn diff', 'svn merge', 'svn list', or 'svn cat'.
This problem (issue 1093) is now fixed in Subversion 1.1. All client
subcommands now transparently trace backwards through renames when
examining older versions of files and directories.
-- cut here --
It seems to me that this could be a failure of "svn up" to follow
rename history.
(Unfortunately, looking at issue 1093 does not help at all.)
Here is a simple reproduction script:
-- cut here --
#!/bin/bash
set -ev
svnadmin create repos
svn co file://`pwd`/repos wc
cd wc
svn mkdir foo
touch foo/file
svn add foo/file
svn ci -m ""
svn up
svn mv foo bar
svn ci -m ""
svn up
rm bar/file
svn up -r1 bar/file
# says "restored file" but shows "D" status.
# and the file does is NOT restored...
rm bar/file
-- cut here --
If one skips the "rm bar/file" it will not say "restored file" but it
will still delete the file (at least when i tried it, using ubuntu's
svn 1.2.3).
Finally, I guess the workaround would be:
(cd .. && svn cat -r1 file://`pwd`/repos/foo/file_at_1 > wc/bar/file)
But that's quite horrible...
HTH,
-ed
On 10/4/06, Jens Seidel <jensseidel@users.sf.net> wrote:
> Hi,
>
> can someone please confim that this is a bug, so that it can be fixed?
>
> On Thu, Sep 28, 2006 at 02:33:20PM +0200, Jens Seidel wrote:
> > I noticed a strange behaviour in subclipse (see also
> > http://subclipse.tigris.org/servlets/ReadMsg?list=users&msgNo=8105)
> > which is a least partially reproducable in svn 1.3.0 and 1.4.0.
> >
> > If I call
> > $ svn up -r <rev> <file>
> > in a directory which contained in the past a file (there is no file with the
> > name currently in the archive) I'm able to restore this deleted file for one
> > revision but not for another one (no failure, just nothing happens).
> >
> > I renamed project/ into src/ in r298, deleted "file" in it in r694 and can
> > restore src/file with
> > $ svn up -r 298 file
> > but not with
> > $ svn up -r 297 file
> >
> > It seems the current path name is not followed back in the revision history.
> >
> > src/file@298 is the same file as project/file@297
> >
> > Since this is not related to the fact that move=copy+delete (the history is
> > unique even after multiple copy operations) I think this is a bug. Is this
> > problem already known?
> >
> > Jens
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 4 16:59:41 2006