Eric Gillespie <epg@pretzelnet.org> writes:
> I have a file, /foo. A few weeks ago, i removed it. Today, i
> brought it back. In CVS, it just pulls it out of the Attic. So
> when i run 'cvs log', i see all the revisions. In svn, the new
> /foo is unrelated to the original. I know now that i should have
> run 'svn cp -r XXX /foo /foo' to revive it. But there are two
> problems: 1) at the time i would have revived it, i did not know
> what revision to give to svn cp; 2) now, after already screwing
> up, i don't know how to get at the history of the old /foo, even
> if i knew a revision to latch onto (svn log -r XXX /foo would only
> show me that particular log entry).
First of all, it's not too late. It doesn't matter what way you've
solved or failed to solve the problem -- this is a revision control
system, the old foo is still there, and anything that would have
retrieved/copied it yesterday will still work today.
So the "at the time I would have revived it" and "now, after already
screwing up" are negative thinking, bad karma, and all that :-).
Do your log messages say when you removed it, if you can search
through a range of them?
> But there are a other ways to get here. Maybe this /foo and the
> old /foo *aren't* related, but nevertheless i want the old history.
> I point this out so that when thinking about this problem people
> won't assume that you should always svn cp -r; not necessarily.
I don't understand what this means.
> So now i can 'svn up -r 79 foo' and run svn log. My first reaction
> upon seeing this is that it's yet another thing that's harder in
> svn than in cvs.
CVS doesn't version directories nor directory tree modifications.
Because it doesn't have the *possibility* of the same path referring
to different objects, the problem of disambiguation doesn't exist for
CVS. That doesn't mean we're harder, it just means CVS is more
restrictive. If CVS did what SVN does, CVS would be have this
interface issue too.
> Why can't log do that for me? 'svn log --all-revisions foo' would
> go through every single revision in the repo (just like log -v /),
> but only print the entry where 'path == /foo'. It should probably
> be a client-side operation; no need for the server to run the
> search.
When we run "svn log PATH", there are two styles of history following
we could do.
1. We could follow through renames (that is, if PATH was a copy
from elsewhere at some point, we follow through and start
showing logs on <elsewhere>, and so on).
2. We could strictly show the logs for PATH, wherever such logs
exist, no matter what PATH refers to, ignoring copies.
I agree we should offer both 1 and 2. Whether a "--all-revisions"
flag is the best interface, I'm not sure; at least the name of the
flag is misleading, because log is *always* operating on a revision
range, and if you want "all revisions", you would specify that range.
I prefer:
svn log --follow-copies /* this one is the default */
svn log --follow-paths /* like your "--all-revisions" */
svn log --follow-nodes /* means "none of the above", just stop
at node creation */
Or there may be a better solution we're not thinking of? Let's see
what others have to say, yeah.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 28 00:03:03 2002