Re: CVS for Cfengine (Was: Re: Bugzille for cfengine)

[Sven Mueller]

address@hidden wrote on 15/12/2004 15:35:
> I am strongly considering extending the Oslo website to incorporate 
> a subversion service, instead of sourceforge. This is partly because
> I am a control freak and like to know what is going on. But it is also
> because I think the project belongs here in Oslo and there are at least
> as many potential developers here as in the US.
>
> I would like a couple of questions answered before diving headlong into it:
>
> i) could one have a private master repository on host A and a mirror
> for public access on host B (provided all commits are done on A).
> I am worried about the security of subversion.

This is possible with svk (an SVN addon). However, for all I can say, 
Subversion is pretty secure, more secure than CVS IMHO. Also the 
subversion developers react quite fast when (possible) security issues 
are found.

> ii) is there an easy web interface for developers that does not require
> significant web-programming to access. 

Yes, several. If you make the SVN repository available by HTTP/WebDAV, 
HEAD revision (and any tags and branches available in that revision) can 
be browsed directly through HTTP. It is also (quite easily) possible to 
make HTTP access read-only for everyone and require svn-protocol or 
svn-protocol over SSH to do commits.

> iii) Will the system be intuitive for CVS users?

mostly, yes. The main differences a developer has to know are that SVN 
has no locks and that one should use "svn mv A B" to rename a file from 
A to B and "svn cp A B" to copy it (copy includes revision history) and 
"svn rm A" to delete a file from the repository (actually only from 
future revisions of it). Anything else is _very_ similar, just replace 
"cvs" with "svn" and you are ready to go. Obviously, without further 
learning (just a little), you don't use all the features SVN provides.

The SVN manual (actually an online copy of the SVN book) contains a 
chapter just for CVS users that migrate. It's easy to read, easy to get 
used to SVN and the manual is (IMHO) a lot better than any non-print CVS 
book/manual I have seen.

> iv) there have been several SVN security patches recently. What
> do I need to be concerned about?

Most of them have been of theoretical problems which would occure only 
on very limited occasions. We deploy SVN quite fully, but still those 
patches wouldn't have fixed any real issue for us. The most important 
fix was a while back when a user could surpass read restrictions on a 
sub-path (TRUNK/A/B/C not being readable for him) by creating a copy of 
it's parent in a part that is readable for him - like copying TRUNK/A/B 
to BRANCHES/X/B and reading BRANCHES/X/B/C afterwards.

Any other security fix in the past 6 month has been of the kind "this 
might lead to a buffer overflow which might lead to DoS/code execution" 
with both "might"s being very unlikely.

cu,
sven