Daniel Berlin wrote (subsequently):
> On Thu, 2005-11-03 at 15:38 +0000, Julian Foad wrote:
>>Cost of a feature is not measured in lines of code.
>
> That's a very nice simple statement to make, while ignoring the rest of
> the message i wrote, and what i've written before.
OK. Responding more completely. (I didn't exactly ignore the rest, I just
responded to a part that annoyed me.)
Daniel Berlin wrote:
>
> On Thu, 3 Nov 2005, Greg Hudson wrote:
>
>> I worry that adding an auto-subst of repository roots will not be enough
>> to justify the cost.
>
> How so?
> It's like 20 lines of code.
(This is how I should have responded: "Please try to keep up the high standards
of technical discussion of which you are capable. That comment gives the wrong
impression to inexperienced developers while just annoying the experienced
ones. I know you know that's not the measure of feature cost.")
Subsequently you wrote:
> As i've pointed out, it's a very small cost in:
>
> 1. syntax
That's the most significant factor. Interpreting, say, a "+" character
specially at the beginning of a target path argument is a significant
commitment. It's not a huge commitment, but neither is it a trivial change
that can be thrown in without serious debate.
> 2. code
> 3. maintenance
>
> So where is the real cost of this feature?
The syntax. I agree that costs (2) and probably (3) are small.
> And it saves about 60-80 chars out of 200 on a gcc command line (30-35%).
Yes. That's a significant benefit. On the other hand, we may be able to
provide an addition or an alternative that saves twice as much, at which your
users surely would not sniff.
>> In http://svn.haxx.se/dev/archive-2005-05/1367.shtml I outlined a more
>> complicated proposal which saves significantly more typing. I'm not
>> sure it's a good idea, but I do think we should be aiming higher than
>> just repository root substitution.
>
> Well, we have to start somewhere.
> It's easier to get consensus for something simple that works well, than
> a large scheme.
Yes, that's a fair point. But we also need to satisfy ourselves that the small
feature isn't going to be obsoleted by a larger feature in the near future.
Given that this won't be released (in Subversion 1.4) for a few months, it is
not unreasonable to discuss it for a few days or weeks before jumping into
implementing it. On the other hand, it may be that playing with it is the best
way to get a feel for how well it will serve us in the medium to long term, so
if you'd like to submit a patch now that the basic idea is reasonably well
defined, we could try it out.
I'm sure you appreciate the benefits of Greg Hudson's proposal to refer to
branches, tags, etc. more easily. Your examples:
svn diff
--old=+/branches/gcc-4_0-branch/gcc/file.c
--new file.c
svn diff
--old=+/branches/gcc-4_0-branch/gcc/file.c
--new=+/branches/gcc-3_4-branch/gcc/file.c
... become something like ...
Rule: BRANCH /trunk /branches/gcc-$1-branch
svn diff -r BRANCH#4_0 file.c
svn diff -r BRANCH#4_0:BRANCH#3_4 file.c
Personally, I would be very keen on something like this. We need to develop it
a bit more and see whether "-r" is the right syntax and how it works with other
commands and other combinations of WC and repository targets and how the rules
are stored and found.
My current feeling is about 50-50: if we can reasonably develop a more
comprehensive and shorter method in the same time frame, then we should do
that; if not, then we should implement the repository root substitution with
something like a leading "+".
- 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 17:32:42 2005