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

Re: optimizing and extending for $

From: Tom Lord <lord_at_regexps.com>
Date: 2002-10-14 08:18:37 CEST

> What Greg is objecting to, I think, is the idea that A's monetary
> valuation of a feature F should influence the other developers in
> prioritizing F.

I think that's too abstract. You have to look at it on a case by case
basis.

In the case of optimization, I think it's completely predictable that
the "ideal" svn, many years out, has lots of swappable modules
providing various performance/size/complexity/admin-cost trade-offs.
That's just a good thing to do that the architecture is designed for.

I think that specific area is ripe for commercialization. People can
pay a premium to get their favorite sweet spots optimized first; that
premium can fund, i dunno -- maybe a democratic or anarchic
community. Whatever. The community, at the very least, gets the
benefit of all of that optimization work that would eventually be
needed anyway.

A sort of non-sequitor: it didn't occur to me until last night, but
getting an svn repository to host an arch repository should be utterly
trivial -- a couple of weeks work, at most. (I can't really afford to
do that work myself, at the moment.) It's just a matter of
translating a small subset of FTP operations into svn operations --
nothing more.

You'd get, as a free side effect, a (good) form of distributed
repositories, "for free". People could write pretty simple scripts
that convert on-demand between parts of the svn tree holding arch
global revisions and parts holding ordinary full source trees. I'd be
willing to say (for what little its worth) that that's a reasonable
1.0 target for both arch and svn.

I think the general idea of providing a workflow-oriented interface to
projects, plus the "instant" distribution features svn would get, are
likely to put a whole new light on client design -- and since that
could be tricky, postpone it till after 1.0. (And advertise the 1.0s
accordingly.)

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 14 08:16:43 2002

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.