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

Re: [PATCH] remove obsolete FAQ entry

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 15 Aug 2008 01:16:46 +0100

On Fri, 2008-08-15 at 02:08 +0200, Stefan Sperling wrote:
> did I get this right and the FAQ entry patched out below
> was hopelessly outdated?
> Note that the issue it is referring to was closed in 2004.

Yes, I think you're quite right! Certainly, "svn diff" etc. does follow
the history back.

But isn't there an entry for the FAQ in a list of contents at the
beginning of faq.html that you should also remove?

- Julian

> [[[
>
> * www/faq.html
> (no-copy-history): Remove, today's clients can follow copy-from
> information transparently.
>
> ]]]
>
> Or should the entry be retained and refer people to the chapter
> about peg revisions in the Subverison book?
> http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html
> Sounds like that might still apply here, but I'm not sure.
>
> Stefan
>
>
> Index: www/faq.html
> ===================================================================
> --- www/faq.html (revision 32474)
> +++ www/faq.html (working copy)
> @@ -2859,60 +2859,6 @@
>
> </div>
>
> -
> -<div class="h3" id="no-copy-history" title="no-copy-history">
> -<h3>I'm trying to look at an old version of my
> - file, but svn says something about "path not found". What's going
> - on?</h3>
> -
> -<p>A nice feature of Subversion is that the repository understands
> -copies and renames, and preserves the historical connections. For
> -example, if you copy <tt>/trunk</tt> to <tt>/branches/mybranch</tt>,
> -then the repository understands that every file in the branch has a
> -"predecessor" in the trunk. Running <tt>svn log --verbose</tt> will
> -show you the historical copy, so you can see the rename:</p>
> -
> -<pre>
> -r7932 | joe | 2003-12-03 17:54:02 -0600 (Wed, 03 Dec 2003) | 1 line
> -Changed paths:
> - A /branches/mybranch (from /trunk:7931)
> -</pre>
> -
> -<p>Unfortunately, while the repository is aware of copies and renames,
> -almost all the svn client subcommands are <b>not</b> aware. Commands
> -like <tt>svn diff</tt>, <tt>svn merge</tt>, and <tt>svn cat</tt> ought
> -to understand and follow renames, but don't yet do this. It's
> -scheduled as post-1.0 feature, currently <a
> -href="http://subversion.tigris.org/issues/show_bug.cgi?id=1093">issue
> -#1093</a>. For example, if you ask <tt>svn diff</tt> to compare two
> -earlier versions of <tt>/branches/mybranch/foo.c</tt>, the command
> -will not automatically understand that the task actually requires
> -comparing two versions of <tt>/trunk/foo.c</tt>, due to the rename.
> -Instead, you'll see an error about how the branch-path doesn't exist
> -in the earlier revisions.</p>
> -
> -<p>The workaround for all problems of this sort is to do the legwork
> -yourself. That is: <i>you</i> need to be aware of any renamed paths,
> -discover them yourself using <tt>svn log -v</tt>, and then provide
> -them explicitly to the svn client. For example, instead of
> -running</p>
> -
> -<pre>
> -$ svn diff -r 1000:2000 http://host/repos/branches/mybranch/foo.c
> -svn: Filesystem has no item
> -svn: '/branches/mybranch/fooc..c' not found in the repository at revision 1000
> -</pre>
> -
> -...you would instead run
> -
> -<pre>
> -$ svn diff -r1000:2000 http://host/repos/trunk/foo.c
> -...
> -</pre>
> -
> -</div>
> -
> -
> <div class="h3" id="digest-auth" title="digest-auth">
> <h3>Why doesn't HTTP Digest auth work?</h3>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-15 02:17:06 CEST

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

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