You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Gillespie <ep...@pretzelnet.org> on 2002/06/27 21:46:18 UTC
Finding nodes with the same name
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
Re: Finding nodes with the same name
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> svn log wc-root (or repos url) will show ALL revisions in which anything below
> that directory changed, so just 'svn log' should show you where it was
> deleted.
I said that in my original post.
--
Eric Gillespie <*> 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
Re: Finding nodes with the same name
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Jun 27, 2002 at 05:29:13PM -0500, Eric Gillespie wrote:
>
> > Do your log messages say when you removed it, if you can search
> > through a range of them?
>
> The log messages of the old /foo say it. One of the issues here
> is how to get at the old /foo.
svn log wc-root (or repos url) will show ALL revisions in which anything below
that directory changed, so just 'svn log' should show you where it was
deleted.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Finding nodes with the same name
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
cmpilato@collab.net writes:
> I don't think you need to make filesystem changes for this:
Oops -- I meant issue #690, not #745, sorry about that.
> [ which, by the way, I realized a few moments ago has a *really*
> broken current implementation...seems you didn't quite understand
> the svn_repos_node_editor, Karl :-) ]
Remind me to ask you for the details tomorrow... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Eric Gillespie <ep...@pretzelnet.org> writes:
> > > 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 */
> >
> > I like this, and i like having --follow-copies as the default.
>
> Okay. We've been planning something like this since Day One, actually
> (not that you would know that without having hunted it down in long
> ago mails). It will wait until Mike Pilato's done with issue #745, of
> course.
>
> (And "--follow-nodes" is a bad name, Brane's right. Better would be
> --follow-none.)
I don't think you need to make filesystem changes for this:
--follow-copies is currently just the CROSS_COPY_HISTORY flag set to
TRUE in svn_fs_revisions_change().
--follow-nodes is the same, but FALSE.
--follow-paths won't use svn_fs_revisions_changed at all, but will
instead use the new svn_fs_paths_changed() on every revision to
see if that rev/path were modified, irrespective of node revision ID.
Perhaps I should just do this as part of issue 690, since I'm (right
now, actually) dinking around with `svn log' anyway?
[ which, by the way, I realized a few moments ago has a *really*
broken current implementation...seems you didn't quite understand
the svn_repos_node_editor, Karl :-) ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
cmpilato@collab.net writes:
> Please just amend Issue #690, and I'll get to it within a few days
> (barring unforeseen problems).
Oops, didn't see your mail before I replied.
I kind of think they should be separate issues. This feature is
broader than what we're doing in 690; I'd hate for 690 (and therefore
Alpha) to block on unplanned features.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by cm...@collab.net.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > Okay. We've been planning something like this since Day One, actually
>
> Excellent. Is this in Issuezilla? Should i file it if not?
Please just amend Issue #690, and I'll get to it within a few days
(barring unforeseen problems).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Excellent. Is this in Issuezilla? Should i file it if not?
You know, I don't think it is.
Would you? That'd be great. Make it block on issue #690, I guess.
Thanks,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Okay. We've been planning something like this since Day One, actually
Excellent. Is this in Issuezilla? Should i file it if not?
--
Eric Gillespie <*> 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
Re: Finding nodes with the same name
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> > 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 */
>
> I like this, and i like having --follow-copies as the default.
Okay. We've been planning something like this since Day One, actually
(not that you would know that without having hunted it down in long
ago mails). It will wait until Mike Pilato's done with issue #745, of
course.
(And "--follow-nodes" is a bad name, Brane's right. Better would be
--follow-none.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> 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.
Yes, i know.
> So the "at the time I would have revived it" and "now, after already
> screwing up" are negative thinking, bad karma, and all that :-).
Not really. They're part of my example.
> Do your log messages say when you removed it, if you can search
> through a range of them?
The log messages of the old /foo say it. One of the issues here
is how to get at the old /foo.
> > 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.
Sorry, i don't know if i can explain it better. There may be two
unrelated files called /index.html, for example. One was removed
6 months ago. Another was created today. Unlike the first use
case, in this one they are not related. Nevertheless, we may want
to access the history of the first /foo.
> restrictive. If CVS did what SVN does, CVS would be have this
> interface issue too.
I'm well aware, but that is not relevant. CVS doesn't do what svn
does, so it is easier in this use case. Unless an option is added
to svn log, in which case it wouldn't be easier in cvs after all.
Hope i'm not confusing anyone :).
> 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
Yes, i don't really care what the option is called. I just needed
something to refer to it if i was going to describe it.
> 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 */
I like this, and i like having --follow-copies as the default.
--
Eric Gillespie <*> 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
Re: Finding nodes with the same name
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> I like the idea, but I don't understand how you get three different
> cases. --follow-paths is obvious; so's follow-copies; what would
> --follow-nodes do that's different from --follow-copies?
Not follow the copies, nor follow the paths :-).
Perhaps "--follow-none" or "--no-follow" would have been clearer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by Branko Čibej <br...@xbc.nu>.
Eric Gillespie wrote:
><br...@xbc.nu> writes:
>
>>I like the idea, but I don't understand how you get three different
>>cases. --follow-paths is obvious; so's follow-copies; what would
>>--follow-nodes do that's different from --follow-copies?
>>
>>
>
>If i copy foo to bar and run 'svn log bar', --follow-copies (the
>default) shows me for bar and then goes back to the revision of
>foo it was copied from and shows those too. --follow-nodes will
>not go back to the copy.
>
I see. Then the option names aren't chosen very well. An "svn copy"
doesn't create a new node, it creates a new branch of the same node. It
should be --ignore-copies, then, or --branch-only, or something.
--follow-nodes is misleading.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by Eric Gillespie <ep...@pretzelnet.org>.
<br...@xbc.nu> writes:
> I like the idea, but I don't understand how you get three different
> cases. --follow-paths is obvious; so's follow-copies; what would
> --follow-nodes do that's different from --follow-copies?
If i copy foo to bar and run 'svn log bar', --follow-copies (the
default) shows me for bar and then goes back to the revision of
foo it was copied from and shows those too. --follow-nodes will
not go back to the copy.
--
Eric Gillespie <*> 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
Re: Finding nodes with the same name
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>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 */
>
>
I like the idea, but I don't understand how you get three different
cases. --follow-paths is obvious; so's follow-copies; what would
--follow-nodes do that's different from --follow-copies?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Finding nodes with the same name
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@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