[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: Chris Hecker <checker_at_d6.com>
Date: 2003-06-27 19:41:49 CEST

>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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 27 19:42:46 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.