[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 23:30:01 CEST

Chris Hecker <checker@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


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 28 00:19:23 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.