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

RE: Resolution of 'svn diff' change?

From: Sander Striker <striker_at_apache.org>
Date: 2003-05-19 12:04:43 CEST

> From: Justin Erenkrantz [mailto:justin@erenkrantz.com]
> Sent: Monday, May 19, 2003 9:42 AM

And we were so close to consensus...

> I just realized that I really like (and rely upon):
> svn diff dir/x dir/y
> meaning dir/x and dir/y relative to the repository (as cached in the wc).
> AIUI, this is now going to be a fatal error.

Hmmm... it probably will give you the diff between dir/x and dir/y ;).

> Is that correct? I'm not really
> clear what the resolution was with that thread as it went off in a million
> tangents. So, pardon my request for clarification.

You go diving head first in that mail archive ;) :)

> IMHO, this is *very* useful when you have local changes that you haven't
> committed and only want a partial 'diff' subset of a directory. I use it as:
> svn diff dir/x dir/y | less
> to review my local changes where dir/z is also modified and I don't want to
> see its diff output (and ignoring it if it is present in the diff makes it too
> hard to review). Am I now going to have to do:
> svn diff dir/x >1
> svn diff dir/y >>1
> less 1
> or
> for i in dir/x dir/y; do svn diff $i | less; done

or, create a small wrapper that does this for you...

> whereas
> svn ci dir/x dir/y
> would still work as expected?

Yes. Well, that depends on your interpretation of expected.

> (Or, will commit reject the iterative case too?)
> I have a hunch that the 'diff' interface should be parallel to the 'commit'
> interface - that is, they should accept the same semantics. (View diff as a
> dry-run of a commit.)

Urf... enter bikeshed.
> If the iterative case is indeed removed as I describe above, then I'm going to
> seriously contemplate vetoing any change to the 'svn diff' interface that
> removes the iterative case.

Not the veto card :(.

"I hereby consider vetoing the painting of any bikeshed purple."

> It's going to be extremely annoying working
> around this when I have lots of local mods in my working copy (which is gonna
> happen more than I'd like to admit - it's a frequent occurrence in
> httpd-land).

And this seems to be the main problem. And until you can work on a local branch,
or, have the ability to mark some changes as to-be-ignored, this will be a problem.
But, we all know that is post-1.0 material.

> Not to mention that this would be a significant regression from
> CVS with no clean alternative proposed by SVN.

I guess I never encounter this because I don't have mixed changesets in one
working copy. Would an --iterative switch help?

> Sorry for the late entry into this thread, but I'm slowly trying to catch up
> on this list after being away. -- justin

*tsk* *tsk* Oh well, I guess we have to blame Sony...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 12:05:37 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.