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