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

Re: svn diff on renamed files

From: <kfogel_at_collab.net>
Date: 2003-06-27 17:10:19 CEST

Chris Hecker <checker@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
Received on Fri Jun 27 17:59:26 2003

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.