After seeing atheorist's recent post on Fossil I started taking a serious look at revision control systems again.

I've been using CVS to manage the source files for my papers and share them with my colleagues but am a little dissatisfied with it. In narrowing down my ideas for what I'd like in a revision control system, I came up with the following wishlist. What I haven't figured out is whether anything out there matches my wishes...

Essential features:

- Ability to share the same repository with users on multiple computers, and control the set of users who can access the repository. My CVS setup has been to do access control via Unix user login and file access permissions, and to do remote access via ssh; this works ok, but not great, because I don't have control over which users may log in to my department's Unix machines -- it means that many people who shouldn't have access do, and some people who should have access don't. I'd prefer a setup where I have full control over the user list and where repository access doesn't convey any other kind of privilege. Fossil does ok with this one.

- Ability to set up a web server providing free public access to files via a browser. I want to share e.g. the version history of my PADS Python library, and I don't want to have to create user logins for everyone who might want to see it. Fossil does this very easily, with its own standalone server that I can run on my own machines, without my having to run something big and unwieldy like Apache myself or figure out what hoops I need to jump through to get my department's support staff to authorize a CGI script.

- Ability to handle multiple subprojects within a single repository, to allow users to check out only those subprojects they're interested in, and to provide access control on a per-subproject basis. I want to be able to work on grant proposals or as-yet-unsubmitted papers privately with my collaborators, without sharing them with the public until I'm ready to do so. And I don't want to have to set up and keep track of hundreds of servers and hundreds of different repositories for each of my different papers and software projects. As far as I can see, Fossil fails miserably here. CVS does ok, in that one can at least use Unix file permissions separately on each file and folder in the repository.

- Ability to handle files of many types (text and binary) automatically. CVS is not so great here: one has to explicitly declare whether a file is text or binary, as it can't figure that out automatically, and failing to make this declaration is one of my most frequent errors in using CVS.

- Ability to run under OS X.

- No major security holes in any of the system's internet server software.

Desirable features:

- Ability for anonymous users to make distributed copies of the publically-viewable portions of the repository (that is, to get a copy of the version history and not just of the latest version of the files).

- Low communication bandwidth for checkins.

- Checkins via http or https. Sometimes my travels have taken me to places where these are the only protocols available from the local service provider. A system that didn't involve sending passwords in cleartext over http would be a plus.

- Ability for the same file to appear in multiple places in the hierarchy (e.g. via Unix-style links) in such a way that edits to one copy of the file automatically change the other copies. It might be good enough to be able to handle Unix-style symlinks, and have one master copy of the file that is linked to from several other places in the hierarchy.

- Ability to run under Solaris and Windows, and handle the varying line-ending conventions of Unix vs Windows.

- Integrated trouble ticket and wiki system (as provided e.g. by Fossil).

- Ability to import history from CVS archives

- Graphical display of timelines and version history

- RSS feed of recent changes

- Easy setup

None: SVN
2008-08-26T11:35:17Z
I suggest SVN, which is much easier and more powerful compared to CVS, as well as more plugins and graphical clients.
11011110: Re: SVN
2008-08-26T15:29:52Z
Everything I've read about svn indicates that it's an improvement over cvs. What I'm less sure about for that one is whether it's different enough to make switching worthwhile. For the style of use I've been putting it to, cvs isn't actually especially difficult to use, it's just lacking a certain level of control (particularly access control).
None: Re: SVN
2008-08-26T17:37:27Z
I'd have to agree with the first commenter. I've found to SVN to be much less of a pain than CVS or SCCS(yuck!). If you know cvs, though, the differences is usability will probably mean less to you. I've also used git and have mixed feelings about it. Git is more about running multiple decentralized repositories that you can merge together in a powerful and flexible way. Despite the fact that it is a Torvalds project, I'm still surprised how similar it is to Linux in the mid-90s. It is very powerful, and smart design decisions were made at every turn, yet it is terribly documented, and practically hostile to non-experts. Like UNIX/Linux, too, once you learn it, you can scoff at those poor neophytes using those lesser alternatives. ;-) J/K Actually, I wouldn't recommend git for anything except a project with many developers and limited central management.
chouyu_31: Re: SVN
2008-08-27T03:53:51Z
I would also throw my hat in for SVN. One of the methods that have been used for svn and user access control is the use of public/private key pairs to determine a local userid, and subsequently who has access via ssh. Toss in trac, and you can at least get read access to your repository. It may be worth adding a mechanism to upload patches (if it's not already available), which then get applied as the user who is logged into trac.
ext_83835: What about distributed VCS, for example Git?
2008-08-26T18:42:13Z
[repository:/Papers/vunfold]
anonymous = r