On Sun, 2003-07-13 at 10:07, SteveKing wrote:
> I really can't understand why so many functions and features
> people want get dismissed with "you can do that with scripts
> or manually". This happens IMHO too often.
A program with too many features is difficult to maintain. It's
important to define a core set of functionality and only add features
which fit well within that space. Subversion isn't really about
software distribution (people normally prefer to get software via ftp or
http, not with a version control tool), so svn:tarballs is branching off
into a mostly unrelated area which isn't important to most users.
I don't think it's really necessary for us to show how you could do what
you want with scripts or whatnot. It's sufficient to say that the
feature requires a substantial amount of codce, it doesn't fit into our
functionality space very well, and not very many people want it, so we
don't want to maintain it. We'll never be able to please everyone.
I realize that in your judgement, svn:tarballs nicely complements
svn:externals and thus fits within our functionality pace. But most of
us appear to diagree. svn:externals is already on the edge of our
functionality space, and we might not have it at all if Karl had given
people more of a chance to object to it. And while svn:externals is
about an svn server instructing an svn client to do an svn checkout,
svn:tarballs is about an svn server instructing a client to do something
which isn't Subversion-related at all; once you start introducing that
kind of feature, there's no limit to what the client can be expected to
do. (And the general solution of "let the server tell the client to
execute arbitrary commands" is non-portable and insecure.)
> If I really wanted to use scripts I don't have to use subversion or any
> other version control system: all that could be done with scripts too.
Not very well.
> Just think about any commercial product out there (not
> only version control systems). If for example the famous
> photoshop
Photoshop lives in a different world. It is an application, maintained
by scores of full-time engineers. It can afford to be less maintainable
because it has a huge budget for maintenance. It must attempt to lock
in users by teaching them to use Photoshop features even for tasks which
might be better done elsewhere. It must attempt to sell copies in the
short term even if it makes the product less coherent in the long term.
Our success depends on different parameters. If two users want to do
the same thing in different ways, we are better off forcing one of them
to change their habits in order to avoid feature creep.
> It seems that everything I try and everything I do for subversion gets
> rejected for reasons I just can't understand.
Well, it's nothing personal; our goal is to have the best possible
product, not to make any single contributor happy or unhappy.
It looked like you could have reworked the DLL patch into something
acceptable with enough effort, and that the problem was tricky enough
that one should expect it to take effort to find the right solution.
Greg Stein's belief in scripting wasn't shared by most other developers
and didn't constitute a veto (although CMike's mesage might have been
worrisome in that area).
I was with you on the username fallback patch, but the objections were
valid if not compelling (to me). If a system is fundamentally
misconfigured, it's perhaps unreasonable to expect every tool on the
system to work around the misconfiguration rather than blowing out.
This is really an issue about idioms, though; if it's standard behavior
to fall back to asking, then we should do that. Not being a Windows
person, I don't really know what normal behavior is in that case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 14 00:00:43 2003