You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Chris Hecker <ch...@d6.com> on 2003/06/26 07:20:18 UTC
svn diff on renamed files
Like an idiot, I typed up a huge email before looking at the issues
list. Anyway, 1093 covers a fair bit of this, but it seems like there are
some issues and ideas mentioned in this mail that I didn't see in the bug
report, so I figured it has some value and I'd send it instead of deleting
it.
----------
Hopefully I'm not making some total newbie mistake here, although if I am
that's good because it means what I want is possible. :)
I have a file that has a number of revisions as old.txt, and then it gets
renamed to new.txt and gets some more revisions. I've got an up-to-date
repository, so I have new.txt in my directory. I want to diff two earlier
versions of the file, before the rename, or do a diff across the
rename. It looks like I have to use an absolute URL to do this?
That's really, uh, tedious. First, it means you have to know exactly when
the file got renamed or you get bogus diffs, since svn diff assumes an
empty file if you specify a revision before the file existed (in other
words, old.txt renamed to new.txt at r5, then svn diff -r2:7 new.txt gives
the complete new.txt at r7, not the diff between foo@2 and bar@7). Knowing
means scrolling through a log of the file's entire history looking for the
A ... (from ...) line, and there might be multiple ones, and you have to
keep track of which versions were which names to do a correct
diff. Second, it means you have to use the full URL even if you've got an
up to date working copy and you want to compare the current wc file against
a previous version, and so you need to know it, so you need to run svn info
and figure it out, etc. diff also seems to not want to diff urls and wc
files, since it prints out a TBD warning, meaning it's currently impossible
to diff a pre-rename version of a file against the wc (without cat'ing the
old file to a temp), unless I'm missing something.
I suggest three things (that aren't that well thought out, but here goes
anyway):
1. Fixing diff so it tracks renames on the file, so -r2:7 new.txt works
like you'd expect (meaning you didn't have to know the file was renamed 6
times before you joined the company 18000 versions ago). Log already sort
of works this way (although not completely, because you can't svn log -r3:4
new.txt if it didn't exist before r4, but it works if you just svn log
new.txt), in fact you have to use svn log -v file.txt to even figure out
the file was renamed as far as I can tell.
2. Making a symbol for URL-to-the-current-wc-directory (like the symbols
for HEAD, PREV, etc.), so I can just say REP_URL/foo.txt (or whatever) to
specify the full path. This would just get the Url: from info and use it,
nothing fancy, just a shorthand. You should also be able to do
REP_URL/../../blah/other.txt and have it work too, although that's less
important (and there's some ambiguity about whether you mean the Url from
this directory or the blah directory). This, incidentally, would also help
clean up the svn:externals "modules" url problem from the FAQ, since it
would just do the right thing for your current directory regardless of
which repository it's from.
3. If there's an @ symbol on a non-full-url'd file name, still look for it
at that revision number in the repository. In other words, old.txt is not
in my wc, but old.txt@3 makes total sense contextually, even though there's
no old.txt in my wc. This would save a lot of typing.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by kf...@collab.net.
Chris Hecker <ch...@d6.com> writes:
> Obviously getting 1 fixes this particular case for 2, but this one
> seems dead simple and I'm assuming there are other reasons to want to
> access the current directory in the repository. Same answer for
> this...
Yeah, I thought so too. But then I tried to come up with one and I
couldn't (I mean, one that wouldn't be satisfied by just referring to
the working copy path.)
> > > > 3. If there's an @ symbol on a non-full-url'd file name, still look
> > > > for it at that revision number in the repository. In other words,
> > > > old.txt is not in my wc, but old.txt@3 makes total sense
> > > > contextually, even though there's no old.txt in my wc. This would
> > > > save a lot of typing.
> >Or: if we have (2), is (3) really necessary :-) ?
>
> I think 3 is the "better" feature than 2, so picking one I'd pick 3
> (say that sentence 5 times fast :).
I did, and included the part about "5 times fast" for good measure :-) !
> They're both just handy UI
> shortcuts, and accomplish the same thing, but not vital.
>
> As we both say, getting 1 would alleviate the need for 2 and 3 for
> this specific problem, but I've been using svn for all of 2 days, so I
> don't have a good feel for other situations in which they'd be
> desirable and how often you need to type the full url.
I think one of these would be useful, but personally would put them in
the Post-1.0 bucket right now. You could file an enhancement request
and put it in that milestone... Or if you wait to wait till you've
been using Subversion longer and see how you feel then, that works
too.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Chris Hecker <ch...@d6.com>.
>(Issue 1093 isn't about that, though, it's about guessing the URL from
>just the working copy path, and Philip's comments there explain why
>this practise is at least questionable.)
1093 seems to be about diffing around a rename (like my original bug), and
the comments thread drifts a bit, or am I misreading?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Chris Hecker <ch...@d6.com>.
>I was testing a rename. It appears we can get diffs for a rename like
>this
> svn mv old/foo new/foo
>but not for a rename like this
> svn mv foo/old foo/new
Ah, sorry, I missed your directory change in your post (I just saw the
identical filename). Anyway, glad you repro'd it.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Philip Martin <ph...@codematters.co.uk>.
Chris Hecker <ch...@d6.com> writes:
>>Hmm, this works as I expect
>>as does this
>>and this
>
> Yes, but you weren't testing across renames, which was the point of
> the thread.
I was testing a rename. It appears we can get diffs for a rename like
this
svn mv old/foo new/foo
but not for a rename like this
svn mv foo/old foo/new
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Chris Hecker <ch...@d6.com>.
>Hmm, this works as I expect
>as does this
>and this
Yes, but you weren't testing across renames, which was the point of the
thread. It's asking for versions of the new file at the old version, as
you can see in this log. Let me know if you can't repro it:
c:\checker\dev\icfp\ignoreme>cat > old.txt
this is old
c:\checker\dev\icfp\ignoreme>svn add old.txt
A old.txt
c:\checker\dev\icfp\ignoreme>svn ci -m "ignore me"
Adding ignoreme\old.txt
Transmitting file data .
Committed revision 108.
c:\checker\dev\icfp\ignoreme>cat > old.txt
slightly newer
c:\checker\dev\icfp\ignoreme>svn ci -m "ignore me"
Sending ignoreme\old.txt
Transmitting file data .
Committed revision 109.
c:\checker\dev\icfp\ignoreme>cat > old.txt
even newer
c:\checker\dev\icfp\ignoreme>svn ci -m "ignore me"
Sending ignoreme\old.txt
Transmitting file data .
Committed revision 110.
c:\checker\dev\icfp\ignoreme>svn ren old.txt new.txt
A new.txt
D old.txt
c:\checker\dev\icfp\ignoreme>svn ci -m "ignore me"
Adding ignoreme\new.txt
Deleting ignoreme\old.txt
Committed revision 111.
c:\checker\dev\icfp\ignoreme>cat > new.txt
the new stuff
c:\checker\dev\icfp\ignoreme>svn ci -m "ignore me"
Sending ignoreme\new.txt
Transmitting file data .
Committed revision 112.
c:\checker\dev\icfp\ignoreme>svn diff --old
https://blah/svn/icfp/2003/trunk/ignoreme/old.txt@109 --new
https://blah/svn/icfp/2003/trunk/ignoreme/new.txt@HEAD
svn: RA layer request failed
svn: PROPFIND request failed on
'/svn/icfp/!svn/bc/109/2003/trunk/ignoreme/new.txt'
svn: PROPFIND of '/svn/icfp/!svn/bc/109/2003/trunk/ignoreme/new.txt': 404
Not Found (https://blah)
c:\checker\dev\icfp\ignoreme>svn diff -r109:HEAD --old
https://blah/svn/icfp/2003/trunk/ignoreme/old.txt --new
https://blah/svn/icfp/2003/trunk/ignoreme/new.txt
svn: RA layer request failed
svn: PROPFIND request failed on
'/svn/icfp/!svn/bc/109/2003/trunk/ignoreme/new.txt'
svn: PROPFIND of '/svn/icfp/!svn/bc/109/2003/trunk/ignoreme/new.txt': 404
Not Found (https://blah)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> Chris Hecker <ch...@d6.com> writes:
>> Hmm, when I wrote my original mail I figured there was actually some
>> way to do the svn diff, it was just inconvenient. Now it's seems that
>> you just can't do the diff at all, even with full paths to the
>> repository:
>>
>> svn diff --old url/old.txt@4 --new url/new.txt@HEAD
>>
>> doesn't work (or any of the other combos I tried...it keeps looking
>> for new.txt@4 for some reason). Am I missing something? Bug 1093 is
>> marked as post-1.0, which seems like a bad idea since this really
>> limits the utility of being able to rename files in the first place,
>> which is a big selling point of svn relative to cvs. It seems like
>> the --old --new args are just broken to diff?
>>
>> Or am I missing the magic syntax (in addition to a clue)?
>
> I think your syntax is right, judging from 'svn help diff' -- Philip
> Martin will correct me if wrong. I think it's a known bug that not
> everything promised by the syntax is actually delivered yet.
Hmm, this works as I expect
svn diff -r4149:HEAD \
--old http://svn.collab.net/repos/svn/trunk/tools/dev/ \
--new http://svn.collab.net/repos/svn/trunk/tools/client-side/ \
bash_completion
as does this
svn diff -r4149:HEAD \
--old http://svn.collab.net/repos/svn/trunk/tools/dev/bash_completion \
--new http://svn.collab.net/repos/svn/trunk/tools/client-side/bash_completion
and this
svn diff \
--old \
http://svn.collab.net/repos/svn/trunk/tools/dev/bash_completion@4149 \
--new \
http://svn.collab.net/repos/svn/trunk/tools/client-side/bash_completion@HEAD
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by kf...@collab.net.
Chris Hecker <ch...@d6.com> writes:
> Hmm, when I wrote my original mail I figured there was actually some
> way to do the svn diff, it was just inconvenient. Now it's seems that
> you just can't do the diff at all, even with full paths to the
> repository:
>
> svn diff --old url/old.txt@4 --new url/new.txt@HEAD
>
> doesn't work (or any of the other combos I tried...it keeps looking
> for new.txt@4 for some reason). Am I missing something? Bug 1093 is
> marked as post-1.0, which seems like a bad idea since this really
> limits the utility of being able to rename files in the first place,
> which is a big selling point of svn relative to cvs. It seems like
> the --old --new args are just broken to diff?
>
> Or am I missing the magic syntax (in addition to a clue)?
I think your syntax is right, judging from 'svn help diff' -- Philip
Martin will correct me if wrong. I think it's a known bug that not
everything promised by the syntax is actually delivered yet.
(Issue 1093 isn't about that, though, it's about guessing the URL from
just the working copy path, and Philip's comments there explain why
this practise is at least questionable.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Chris Hecker <ch...@d6.com>.
Hmm, when I wrote my original mail I figured there was actually some way to
do the svn diff, it was just inconvenient. Now it's seems that you just
can't do the diff at all, even with full paths to the repository:
svn diff --old url/old.txt@4 --new url/new.txt@HEAD
doesn't work (or any of the other combos I tried...it keeps looking for
new.txt@4 for some reason). Am I missing something? Bug 1093 is marked as
post-1.0, which seems like a bad idea since this really limits the utility
of being able to rename files in the first place, which is a big selling
point of svn relative to cvs. It seems like the --old --new args are just
broken to diff?
Or am I missing the magic syntax (in addition to a clue)?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Chris Hecker <ch...@d6.com>.
>Yup. This appears to be the same as newly-filed issue #1375; I had
>thought there was an older issue about essentially the same thing, but
>now I can't seem to find it. (Maybe someone else remembers which one?)
That one is the 1093 pseudo-dupe. Is there another issue related?
> > > 2. Making a symbol for URL-to-the-current-wc-directory (like the
> > > symbols for HEAD, PREV, etc.), so I can just say REP_URL/foo.txt (or
> > > whatever) to specify the full path. This would just get the Url:
> > > from info and use it, nothing fancy, just a shorthand. <snip>
>If (1) is fixed, what use did you have in mind for (2)?
Obviously getting 1 fixes this particular case for 2, but this one seems
dead simple and I'm assuming there are other reasons to want to access the
current directory in the repository. Same answer for this...
> > > 3. If there's an @ symbol on a non-full-url'd file name, still look
> > > for it at that revision number in the repository. In other words,
> > > old.txt is not in my wc, but old.txt@3 makes total sense
> > > contextually, even though there's no old.txt in my wc. This would
> > > save a lot of typing.
>Or: if we have (2), is (3) really necessary :-) ?
I think 3 is the "better" feature than 2, so picking one I'd pick 3 (say
that sentence 5 times fast :). They're both just handy UI shortcuts, and
accomplish the same thing, but not vital.
As we both say, getting 1 would alleviate the need for 2 and 3 for this
specific problem, but I've been using svn for all of 2 days, so I don't
have a good feel for other situations in which they'd be desirable and how
often you need to type the full url.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by kf...@collab.net.
Chris Hecker <ch...@d6.com> writes:
> > 1. Fixing diff so it tracks renames on the file, so -r2:7 new.txt
> > works like you'd expect (meaning you didn't have to know the file
> > was renamed 6 times before you joined the company 18000 versions
> > ago). <snip>
Yup. This appears to be the same as newly-filed issue #1375; I had
thought there was an older issue about essentially the same thing, but
now I can't seem to find it. (Maybe someone else remembers which one?)
Suspect that Mike Pilato may have more to say about this; he's been
working on some fs schema changes that will help us deal with copies
and renames better. A node will know what path it was created at, and
keep track of its successors; at the very worst, this would allow us
to go back to the origin and trace forward, though that seems clumsy
and Mike may have a better plan in mind.
> > 2. Making a symbol for URL-to-the-current-wc-directory (like the
> > symbols for HEAD, PREV, etc.), so I can just say REP_URL/foo.txt (or
> > whatever) to specify the full path. This would just get the Url:
> > from info and use it, nothing fancy, just a shorthand. <snip>
If (1) is fixed, what use did you have in mind for (2)?
> > 3. If there's an @ symbol on a non-full-url'd file name, still look
> > for it at that revision number in the repository. In other words,
> > old.txt is not in my wc, but old.txt@3 makes total sense
> > contextually, even though there's no old.txt in my wc. This would
> > save a lot of typing.
Or: if we have (2), is (3) really necessary :-) ?
(I'm just trying to boil this down to the minimal feature set that
solves all the problems. Don't have an opinion as to whether these
improvements should be pre- or post-1.0 yet.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by Chris Hecker <ch...@d6.com>.
>:-) Can you send just the parts that aren't covered in 1093? Either
>one person filters (you), or everyone else filters...
Actually, I was kinda being hyperbolic, the mail's not that long and most
of it is valuable, if I do say so myself. :) Here's the [shortened]
suggestions part, if you want the rationale for any of them, read the whole
mail, which I've conveniently put at the bottom of this message:
>1. Fixing diff so it tracks renames on the file, so -r2:7 new.txt works
>like you'd expect (meaning you didn't have to know the file was renamed 6
>times before you joined the company 18000 versions ago). <snip>
>
>2. Making a symbol for URL-to-the-current-wc-directory (like the symbols
>for HEAD, PREV, etc.), so I can just say REP_URL/foo.txt (or whatever) to
>specify the full path. This would just get the Url: from info and use it,
>nothing fancy, just a shorthand. <snip>
>
>3. If there's an @ symbol on a non-full-url'd file name, still look for
>it at that revision number in the repository. In other words, old.txt is
>not in my wc, but old.txt@3 makes total sense contextually, even though
>there's no old.txt in my wc. This would save a lot of typing.
Chris
-------------
>Date: Thu, 26 Jun 2003 00:20:18 -0700
>To: dev@subversion.tigris.org
>From: Chris Hecker <ch...@d6.com>
>Subject: svn diff on renamed files
>
>
>
>Like an idiot, I typed up a huge email before looking at the issues
>list. Anyway, 1093 covers a fair bit of this, but it seems like there are
>some issues and ideas mentioned in this mail that I didn't see in the bug
>report, so I figured it has some value and I'd send it instead of deleting it.
>
>
>----------
>
>
>Hopefully I'm not making some total newbie mistake here, although if I am
>that's good because it means what I want is possible. :)
>
>
>I have a file that has a number of revisions as old.txt, and then it gets
>renamed to new.txt and gets some more revisions. I've got an up-to-date
>repository, so I have new.txt in my directory. I want to diff two earlier
>versions of the file, before the rename, or do a diff across the
>rename. It looks like I have to use an absolute URL to do this?
>
>
>That's really, uh, tedious. First, it means you have to know exactly when
>the file got renamed or you get bogus diffs, since svn diff assumes an
>empty file if you specify a revision before the file existed (in other
>words, old.txt renamed to new.txt at r5, then svn diff -r2:7 new.txt gives
>the complete new.txt at r7, not the diff between foo@2 and
>bar@7). Knowing means scrolling through a log of the file's entire
>history looking for the A ... (from ...) line, and there might be multiple
>ones, and you have to keep track of which versions were which names to do
>a correct diff. Second, it means you have to use the full URL even if
>you've got an up to date working copy and you want to compare the current
>wc file against a previous version, and so you need to know it, so you
>need to run svn info and figure it out, etc. diff also seems to not want
>to diff urls and wc files, since it prints out a TBD warning, meaning it's
>currently impossible to diff a pre-rename version of a file against the wc
>(without cat'ing the old file to a temp), unless I'm missing something.
>
>
>I suggest three things (that aren't that well thought out, but here goes
>anyway):
>
>
>1. Fixing diff so it tracks renames on the file, so -r2:7 new.txt works
>like you'd expect (meaning you didn't have to know the file was renamed 6
>times before you joined the company 18000 versions ago). Log already sort
>of works this way (although not completely, because you can't svn log
>-r3:4 new.txt if it didn't exist before r4, but it works if you just svn
>log new.txt), in fact you have to use svn log -v file.txt to even figure
>out the file was renamed as far as I can tell.
>
>
>2. Making a symbol for URL-to-the-current-wc-directory (like the symbols
>for HEAD, PREV, etc.), so I can just say REP_URL/foo.txt (or whatever) to
>specify the full path. This would just get the Url: from info and use it,
>nothing fancy, just a shorthand. You should also be able to do
>REP_URL/../../blah/other.txt and have it work too, although that's less
>important (and there's some ambiguity about whether you mean the Url from
>this directory or the blah directory). This, incidentally, would also
>help clean up the svn:externals "modules" url problem from the FAQ, since
>it would just do the right thing for your current directory regardless of
>which repository it's from.
>
>
>3. If there's an @ symbol on a non-full-url'd file name, still look for
>it at that revision number in the repository. In other words, old.txt is
>not in my wc, but old.txt@3 makes total sense contextually, even though
>there's no old.txt in my wc. This would save a lot of typing.
>
>
>Chris
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff on renamed files
Posted by kf...@collab.net.
Chris Hecker <ch...@d6.com> writes:
> Like an idiot, I typed up a huge email before looking at the issues
> list. Anyway, 1093 covers a fair bit of this, but it seems like there
> are some issues and ideas mentioned in this mail that I didn't see in
> the bug report, so I figured it has some value and I'd send it instead
> of deleting it.
:-) Can you send just the parts that aren't covered in 1093? Either
one person filters (you), or everyone else filters...
No obligation, of course. I'm just pointing out that many people
won't be motivated to read a huge mail that starts off by admitting
that most of its content is already in an issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org