Daniel Stenberg <daniel@haxx.se> writes:
> Have anyone put any thoughts on doing some kind of duplicate storage in both
> CVS and SVN (like a script that takes the comments and commits in both
> systems)?
>
> It would:
>
> 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).
>
> b) offer the reliability of CVS in case something in SVN would blow up
>
> Possibly, (a) can be substituted by automaticly generated tarballs or
> something.
For (a), we wouldn't want automatically generated tarballs. We'd want
stable, named source snapshots that are known to successfully check
out the latest Subversion source tree, which you can then use to build
any version you want. :-)
However:
IMHO, once we're self-hosting, I don't think we should continue to
support real CVS access. If someone wants to play around with
Subversion, they can always grab a tarball. But if someone wants to
hack on it, they should use it. That's the whole point of M3. :-)
Continuing to provide real-time CVS access will just be encouraging
developers to not switch, as well as be a resource drain on whoever
has to maintain the parallel repository system.
For (b), our answer is to get thorough backup coverage during the time
when we're still not completely trusting Subversion. That might mean
tarballing after every commit for a while, or tarballing every N
commits with diffs in the meantime, or whatever. Let's cross that
bridge when we come to it.
-K
---------------------------------------------------------------------
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