Daniel,
I did say in my last mail:
> I'm not saying we shouldn't do the "+" thing, I'm just asking for more concrete data.
And you are giving more data. Thank you. You sound very frustrated - which I
can understand - but you seem to think I am arguing against this feature and
I'm not. I'm just questioning it. I wasn't immediately and totally convinced
that this feature is needed in the form suggested, but I'm much more convinced
after reading your and other people's feedback.
Daniel Berlin wrote:
> On Thu, 2005-11-03 at 03:59 +0000, Julian Foad wrote:
>
>>Daniel Berlin wrote:
>>
>>>Ignoring the question of what character would substitute repository
>>>root, would anyone be opposed to having such a substitution.
>>
>>Not sure. May I ask to see a couple of realistic use cases?
>
> Uh, right now, to diff the gcc 4.0 branch against a working copy file,
> one has to type
> svn diff
> --old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new file.c
>
> To diff 3.4 against 4.0
> svn diff
> --old=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new=svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch/gcc/file.c
>
> You can make it roughly as long as it was in cvs if you remove the
> "svn+ssh://gcc.gnu.org/svn/gcc" part
>
> Heck, it even fits on one line then
> svn diff
> --old=+/branches/gcc-4_0-branch/gcc/file.c
> --new=+/branches/gcc-3_4-branch/gcc/file.c
>
> That is all my users want. To not have to type twice or three times as
> much text as they did in cvs just to do diffs
OK. That's a reasonable request and justification.
>>Are my examples above the sort of thing you mean?
>> If so, and a user is
>>commonly diffing between +/trunk/gcc and +/branches/1.0.x/gcc, then wouldn't
>>he/she prefer to substitute those with an environment variable or other method
>>of further abbreviation, thus obviating the need for abbreviation of just the
>>repository root?
>
> No.
> Why?
Because it's shorter, of course. Instead of your
svn diff
--old=+/branches/gcc-4_0-branch/gcc/file.c
--new=+/branches/gcc-3_4-branch/gcc/file.c
you could just type
svn diff --old=$GCC_4_0/file.c --new=$GCC_3_4/file.c
If the user does diffs between those branches frequently, then the shorter form
is beneficial.
Now, I understand that this gets unwieldy if you have as many different
branches active as you (plural) do. I didn't know you worked like that; thanks
for explaining. So, I accept that you might not find that env-vars suggestion
of much benefit.
> People are used to the repository root being abbreviated if they used
> cvs. [...] We claim to be better than cvs, [...]
OK, so this is what we call a "CVS parity" issue. Making Subversion no worse
than CVS is a fairly strong reason to do this.
> Some of these people have 20 branches of gcc checked out (most people
> have 4 or 5), remote repos. We still support the 3.4 line and the 4.0
> line. So realistically, you want to find diffs against 3.3 onwards.
> That's 16 environment variables right now.
If they have the branches of interest checked out, the quickest thing, if it
worked, would be to request diffs among the checked-out working copies:
svn diff --old=branches/gcc-4_0-branch/gcc/file.c
--new=branches/gcc-3_4-branch/gcc/file.c
No "+" syntax is needed there. Unfortunately this is not supported by
Subversion yet:
svn: Sorry, svn_client_diff3 was called in a way that is not yet supported
svn: Only diffs between a path's text-base and its working files are
supported at this time
However, a non-Subversion diff can be used, even more easily:
diff branches/gcc-4_0-branch/gcc/file.c
branches/gcc-3_4-branch/gcc/file.c
Would this be a useful practice, at least in the meantime before the desired
feature is implemented? Would it be useful to enhance Subversion to support
that mode of local diffs?
Of course I understand that if the user has local modifications in their WC,
then that WC-WC diff is not the same as a repos-repos diff.
> It's not like this is a hard feature to implement, or particularly
> burdensome on maintenance or syntax.
Indeed, and it seems likely that it will soon get implemented. Nevertheless I
am finding this discussion useful in building up an idea of the contexts in
which it will most commonly be used, which is helpful for determining what the
exact requirements, limits and future extensions of the feature might be. Yes,
I know, "it's a simple enough idea so just do it". But a little extra thought
and discussion always helps.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 3 06:20:14 2005