Re: Thoughts on revision control systems

Georg Seidel wrote:
> Here is a link to an article that compares some revision control systems:
> http://seppuku.editthispage.com/2003/07/30
> 
> The article is not very detailed but it's a good starting point.
> I didn't know some of the mentioned tools before (darcs for example, 
> which sounds really interesting ["based ... on operators of the Quantum 
> Mechanics", "written in Haskell", "token patches"]).
> 
> One thing I do not understand is what the author means with the "CVS 
> interop" of arch - probably it's possible to convert CVS repositories to 
> arch archives?

There are two way of interop between cvs and arch:

1. The old cvs repository is converted once to an initial arch 
repository. It is very difficult to extract good changesets from the cvs 
history, but there are some scripts around that try to do the job.

2. Regular updated between an arch and a cvs repository. For convenience 
of non arch users there is sometimes the need to commit all the changes 
to the arch repository also to a cvs repository. This is like the linux 
bitkeeper repository gateways to cvs and subversion.

If think both aren't that important for us. The new GePhex will be a 
rewrite in major parts so we don't have much historic knowledge to 
preserve. If the new revision control system is superior there is no big 
  need to maintain a legacy gateway. Providing daily snapshots on the 
webserver and sending autogenerated diffs of all commited changesets to 
a mailinglists should be enough.

> I suggest that we have a look at some of the more interesting 
> alternatives (darcs, aegis and arch of course) before we decide which 
> tool to use.
> 
> So far, I think arch is quite good, I even managed to display the diffs 
> between to old revisions (or rather patch levels in arch terminology) by 
> now ;).
> The main features that seem to beat CVS and Subversion are, in my 
> opinion, the possibility to work on an offline repository (with history 
> sensitive merging later on) and the so called "cherrypicking" of 
> patches, that is the possibility to decide which patches go into one 
> specific distribution of the software. (I didn't try that stuff yet).

This seems to me like a great feature.

> I would like to propose some important features that can be used to help 
> with the decision for the right tool (provided it supports all the basic 
> features that CVS has):
> 
>   - offline work possible

Subversions(+-) offline facilities are good for shortterm offline work. 
But for developers with non commit status this isn't a solution.

In my opinion archs(+) possibilitiy that every developer can setup an 
own repository and the development steps can at some point be replayed 
to the main repository is quite powerful. But i don't know whether this 
is really important for us.

>   - anonymous access easy to set up and use

The cvs(-) anonymous pserver, rsh or ssh way is crap from the 
administrators view. I think it is no option to add new users or new 
open services just to allow read only access to the repository. The Http 
is a quite good protocol for theses things. For arch(+) we just need a 
plain http server and for subversion(+-) there is also need for the 
webdav module of apache 2.

>   - commit access easy to set up and use

Cvs(+) and subversion(+-) uses a ssh connection and some binary tools on 
the repository server. Arch just needs a sftp connection.(+)

>   - client available for unix and windows

cvs(+) yes , subversion(+- in cygwin)

with arch and cygwin there are some problems:
http://mail.gnu.org/archive/html/gnu-arch-users/2003-09/msg01107.html
We have to check the cygwin port first.

Martin