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).
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.
So, that's the problem. How to solve it? I'm not sure. Ben C-S
and i discussed this at lenght in the IRC channel, but without
conclusion. What i originally was expecting, and what Ben suggested
at one point, is an option to svn log that will find all the
revisions of anything named /foo and give me that. Something like
'svn log --all-revisions foo'.
Another idea is a new command, or an option to the mythical 'svn
ls': 'svn ls --all-nodes /foo'. I don't even know what the output
of this command should be. Show the revision it was created?
Removed? Both? I don't like this as much as the option to 'svn
log'.
What Ben originally suggested is 'svn log -v /', and search for
the deleted revision of the relevant file. It works, but i'll
explain in a second why i don't think it is the answer.
-------------------------------------------------------------------------------
130 svn-test% svn log -v http://svn-test.progeny.com/repo/ | grep -2 'D test/foo'
rev 80: epg | Thu, 27 Jun 2002 15:42:41 -0500 | 2 lines
Changed paths:
D test/foo
Now remove it.
-------------------------------------------------------------------------------
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. My second reaction is why should i do this?
Shouldn't the program do this? Isn't this why we have computers in
the first place?
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.
Ben says yeah, but why build grep into svn? Just use grep. Well,
aside from what i'm sure all the Windows wankers have to say about
that, our conversation degenerated into ranting against lusers.
Suffice it to say that the people i work with, while otherwise
intelligent (and long-time unix people, to boot), don't get along
with cvs very well. We talked about how often files get committed
with conflict markers, as an example.
It all comes down to usability. So i'm posting this message first
to start a discussion, and second to propose the new option to 'svn
log'. I'd prefer the new option. But someone else may have a
better solution.
--
Eric Gillespie, Jr. <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 27 23:46:49 2002