Re: thoughts on self-hosting SVN

On Mon, May 14, 2001 at 10:36:45AM +0200, Daniel Stenberg wrote:
>...
> a) reduce the amount of troubles for newcomers that have CVS clients
> installed locally and want to get the SVN source. Otherwise, they'll have
> to fetch a tarball/binary first, only to install a SVN client and then get
> the source to re-install the client (and possibly the server).

"users" can get tarballs. "developers" can follow your plan: grab a tarball,
build it, use it.

IMO, we don't need a CVS repository for the masses.

If somebody where to contribute a .spec file, then we could even publish
source RPMs and a binary RPM to easy the bootstrap. And the .spec would be
nice moving forward...

> b) offer the reliability of CVS in case something in SVN would blow up

For this, I'm thinking that we can do something along the lines:

After each commit:
1) snapshot the repository
2) generate an XML diff
3) copy the previous revision snapshot, apply the diff to the repository,
   checkout a copy. check out a copy of the current snapshot. compare the
   two copies.
4) check out a copy of the previous snapshot. apply the diff. check out a
   copy of current. compare the copies.

This will let us rewind to any repository snapshot. With the XML patches, we
can move forward to "current".

Two problems with the above:

1) we miss a clean snapshot of one revieions because two commits were close
   together
   (I may have a way to solve this, based on the DB_RUN_RECOVERY stuff;
    basically, we block all writers while we do the snapshot)

2) a problem in the diff generation

However, (2) is solved with steps (3) and (4).

Copying snapshots could chew disk pretty quick. We could accept that, or we
could keep N week's worth of snapshots.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org