On Fri, 2004-08-27 at 05:35, Ulrich Eckhardt wrote:
> Simon Large wrote:
> > If I rename a folder in the repository, svn cat seems unable to traverse
> > the rename to get old revisions. This shows up in TortoiseSVN (where I
> > originally reported the problem) when I try to do a visual diff, for which
> > TSVN needs access to both revisions.
>
> If you rename from 'Foo' to 'Bar' at revision X, revisions < X don't contain a
> 'Bar', which is why you can't 'svn cat' it.
Actually, this is one of the new features in svn 1.1. If you run 'svn
cat -r X-1 Bar', then the client should be able to trace the rename, and
discover the older name (Foo) in revision X, and cat that instead. It
certainly works in the commandline client.
> > Using TSVN 1.1.0 RC1, which is built on SVN 1.1.0 RC2.
... so it seems odd that TSVN based on svn 1.1 isn't doing it. Are we
sure about this?
For example, in ancient days,
/trunk/subversion/libsvn_wc/update_editor.c used to be named
'get_editor.c'. If you browse r100 of svn's own repository, you can see
that yourself:
$ svn ls -r100
http://svn.collab.net/repos/svn/trunk/subversion/libsvn_wc
If you're using an svn 1.0 client, it's unable to figure out the old
name of the file:
$ cd subversion/libsvn_wc
$ $ ~/svn-1.0 cat -r100 update_editor.c
[...]
path not found
But not so with a 1.1 client:
$ svn cat -r100 update_editor.c
/*
* get_editor.c : routines for update and checkout
*
[...]
So what is TSVN doing differently? Perhaps it's invoking the
svn_client_cat() command on a URL, rather than a working file? That
might explain it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 27 17:24:58 2004