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

Re: svn 1.0 in 2006 or now?

From: Tom Lord <lord_at_regexps.com>
Date: 2003-01-01 05:19:26 CET

       It's not because it's New Year's Eve [Happy New Year btw !]
       that people will be drunk enough to accept that suddenly ;)

I suppose you may be right that that was my highest hope. (And Happy
New Year (and cheers) to you et al. also.)

More seriously: I've 99.9% given up on convincing the core developers
to reconsider their design but the question and answer did (and does)
seem like a fairly unique opportunity to try to draw out some of the
implications of their decision for that .1% shot; a fairly vivid
abstraction->instance situation.

        But changing the whole subversion design (which you are
        trying to say implicitly, ain't you ? :) ) is just madness.

In my eyes, it would be honorable bravery and a superlatively good
engineering decision.

        Assuming it does require such drastic design changes, why not
        make it 2.0 and just have some scripts to transfer 1.0
        repositories to 2.0 format ?

Because for non-trivial deployment, you should consider the logical
structure of your repository an at _least_ a 10 year investment, and
probably a few multiples of that. Screwing around with it every few
years and propogating that screwing around through your development
and support process is kind of wacky. I think it's not too different
from library cataloging systems: you don't see too many major
overhauls to dewey or library of congress classifications every 2.5
years, for example (may be a U.S.-centric analogy - sorry).

     If it doesn't last forever, it doesn't mean it cannot be used
     before something better is done.

You have to look at the costs of deployment, not just the "small
matter of hacking". This is a damn conservative area and rightfully
so.

5...4...3...2...
-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 1 05:12:38 2003

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.