From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2007-01-11 21:20:00
On Thu, Jan 11, 2007 at 06:23:51PM +0100, Spiro Trikaliotis wrote:
> CVS can operate on a local filesystem, too. ;) The http server is
> "problematic", but IIRC, this is possible, too.
Actually, the Subversion over HTTP or HTTPS can be hard to set up, since
it requires a special Apache module that implements part of the WebDAV
protocol. On the other hand, this can be worth the trouble if you are
working in a place that blocks ssh access to the outside. HTTP and
HTTPS are usually allowed, at least through a proxy.
> Anyway, I would never use it this way. ssh is the only remote access I
> trust.
Right, I wouldn't ever trust an unencrypted protocol (such as CVS pserver)
for non-anonymous access either. If I had to use CVS, I'd pipe it over ssh.
Also Subversion and rsync can be piped over ssh.
> > If you choose FSFS, it's very nice for doing incremental backups
> > (e.g., with rsync <http://rsync.samba.org/> to another hard disk or
> > over the network), because commits never modify existing files (unlike
> > earlier revision control systems, such as RCS and CVS).
>
> rsync does a very good job sync'ing CVS repositories, too.
But if the transfer is aborted for some reason, you will end up having
the remote copy in a severely inconsistent state. In Subversion fsfs,
commit writes two new files (properties and tree diffs) and edits one
file (the one that points to the most recent revision).
Also, in case the file system containing your master repository becomes
corrupted for whatever reason, if you do "rsync -n" first to see what
needs to be copied, with Subversion fsfs you'll get alerted if you see
any changes to old files. With CVS, changes to old files are normal,
and you would be less likely to notice this. So, you will have to
preserve old backed-up versions of the CVS repository to be sure that
nothing is corrupted.
> Personally, I do not like binary formats (as SVN uses it) very much, not
> to speak about databases. ;) If something goes wrong (mostly user
> error), if it is really needed, I can edit the CVS repository by hand -
> I have done this more than once, especially when I started using CVS.
Me too. With Subversion fsfs, you can just delete the two new files per
revision and tweak the third file (it's plain text).
> CVS repository is nothing more than some RCS files in directories, and
> the RCS file format is very good documented. With SVN, this is not
> possible.
Right, you cannot edit Subversion repositories on the file level like
the ,v files of RCS and CVS, but you can edit them on the tree revision
level. There even exists a command for editing tree properties (such as
svn:log, the change notes of a revision). But for editing the diffs,
you are pretty much limited to deleting the most recent revision(s) and
recommitting the changes. Not something that you'd do in a multi-user
environment. But then again, editing a RCS or CVS repository by hand
is not usually a good idea either.
I find it great that Subversion commits are truly atomic. Also, you can
rename and remove files and directories without having "Attic" directories
appear all over the repository.
> I have seen some SVN repository bailout, where everything was lost
> (only the backup helped). This was with some 1.0.x version.
> Additionally, you might want to read the ChangeLogs for SVN - they are
> very interesting. :)
I switched from CVS (after almost 10 years of using it) to Subversion in
late 2005, so I didn't have to deal with the potential horrors of the
original BDB-backed Subversion. I know of one company that has all its
documents and source code in a single Subversion fsfs repository, tens
if not hundreds of thousands of revisions. And surprisingly, it works
for them.
Of course, no system is perfect. To get back on topic, I wonder what
system Commodore used for managing source code. Perhaps just the
version-numbered files of VMS? (I presume they used VAX/VMS at least
for some pre-Amiga development. I remember seeing cbmvax.commodore.com
on the Usenet.)
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.