Date: Mon, 9 Feb 2004 19:24:41 +0100 (CET) From: Michael Reifenberger <mike@Reifenberger.com> To: Craig Boston <craig@tobuj.gank.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Subversion/CVS experiment summary Message-ID: <20040209185105.O72949@fw.reifenberger.com> In-Reply-To: <200402091130.05656.craig@tobuj.gank.org> References: <200402091130.05656.craig@tobuj.gank.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
first, this seems to be a good analysis of SVN and a good
starting point for thinking about moving away from CVS.
On Mon, 9 Feb 2004, Craig Boston wrote:
...
> Comments on importing: It's SLOOOOOOOOOOW. It took 43.9 hours just for
> src/sys, and this is a relatively speedy system! It starts out at a pretty
> good pace, but the more commits it processes, the slower each one seems to
> take.
>
...
Since this should be a one-time action, time should be less of a
showstopper (as long its not endless :-)
...
> * "Requires" Apache for the network server. There is a simpler CVS-like
> network protocol, but it suffers from the same problems with access
> control and locking and the like that CVS does. In order to overcome
> those limitations, you pretty much have to use Apache/WebDAV. Some may
> argue that this isn't really a negative, but it certainly doesn't go with
> the K.I.S.S. philosophy.
...
Apache is not strictly required.
As far I've seen there is a "svnserve" server mode available.
...
> * No cvsup equivalent yet. You can fairly easily use WebDAV to pull a copy
> of the trunk or a particular branch, but it's not nearly as efficient as
> the rsync algorithm. There's also no way to use WebDAV to grab a certain
> date or revision like you can with cvsup -- you have to have the svn
> client installed. In order to be even a contender to replace CVS, it
> still needs a *FAST* and *SIMPLE* way to synchronize source with an
> arbitrary tag or revision.
...
For me this is the biggest showstopper for FreeBSD development.
But since the whole repository is versioned instead of individual files,
in an first step an CTM-equivalent should be easier
( posting something like `svnadmin dump --revision <old>:<new>` ...)
or are there any native db4-tools for replication available?)
Additionaly a bad point is:
* SVN hasn't that many (fully integrated) clients than CVS (eclipse, ...)
Many are coming/growing but its still not there.
...
> Good points:
> * Atomic commits across multiple files
* Versions belong to the whole repository. That means that in case of
changes you only need the revision number to know what changed in
the whole repository.
In the FreeBSD environment it's necessary to know the exact time
or the affected files (and their individual revision numbers)
* It's extremly well documented!
It comes with an whole book of documentation.
> -----------------------------------------------------------------------------
> Section the 4th - Conclusions
> -----------------------------------------------------------------------------
> Honestly, I don't think Subversion is quite ready yet. However, it is getting
> _very_ close to being a viable alternative to CVS, for the needs of the
> FreeBSD project as far as I know them. I'll definitely be trying it out for
> some of my local projects that are currently stored in CVS.
>
Maybe we could see SVN as an equivalent to p4.
Probably most of SVN current shortcomings are also true for
p4 (no cvsup for p4 available, only an p4p service
for some selected archs)
Because SVN tries to be an CVS successor I found its usage very intuitive
for an first-time-user like me.
Furthermore I personaly don't like closed-source tools for open-source
development (when alternatives are available) and would try to
avoid p4 if possible.
Bye/2
---
Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting
Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com
http://www.plaut.de | http://www.Reifenberger.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040209185105.O72949>