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

Re: thoughts on self-hosting SVN

From: Daniel Stenberg <daniel_at_haxx.se>
Date: 2001-05-14 16:29:49 CEST

On 14 May 2001 cmpilato@collab.net wrote:

> > Have anyone put any thoughts on doing some kind of duplicate storage in
> > both CVS and SVN
> The short answer is yes, I have put some (tiny, insignificant) amount of
> thought into this. I don't really have cycles to spare thinking about
> it, so it would be wonderful if you would carry your ideas a few steps
> further and begin to spec out such a system.

Fair enough. I'll jot down some notes and post a suggestion.

> I'm not sure what I personally think about making such a "kit" part of
> our 1.0 distribution, though.

That wasn't what I had in mind either. I was thinking of a system that
provides a "safety net" while we're smoothing out the initial glitches and
experience the initial repository crashes. It would be a tool that makes us
less vulnerable to bugs in SVN while still being able to use SVN for version

When the time comes for 1.0 to be released, we will have a stable enough
system that won't need this kind of hack.

> Also, SVN is adding some new features unsupported by CVS (such as
> directory removal, copies/moves, etc.). These scripts for dual storage
> would of course have to run at the feature-support level that's common to
> both CVS and SVN, which means our new clients will be missing out on some
> the biggest reasons why SVN is the friggin' whip (and CVS is, well, just
> whipped).

Yeah, but the idea would only be to keep a fair "backup" repository in CVS.
It can't be an exact clone (obviously).

      Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:30 2006

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.