Source Control Management
Features to check
- Reliability of file depot: Prefer RCS format over binary proprietary
- ATOMIC operations
- Good performance over WAN links
- Fast diff viewer
- Server/client over TCP/IP or repository available through SMB/CIFS?
- On which OS does it run?
- Access control (let such and such user only access such and such part
of the repository)
- Client must integrate into development IDE
- Supports one-click patching of code branches
- Supports deleting of files in one branch with no effect on other branches
- Can set a revision and/or label to a set of commits
- Keeps track of directory/file renaming and deleting
(from Slashdot) Version control system minimum requirements by Anonymous
IMHO, these are the bare minumum requirements:
- atomic commits - your change happens only if all the files can be processed.
This prevents a corrupted workspace when CVS processes half your files
in a commit and then exits on an error throwing the other half of your files
on the floor.
- change list management - all commits have a unique reference number.
CVS process files by directory instead of by workspace, so it is impossible
to tell which files are associated with a commit.
- access control by workspace or workspace directory - the ability to
give certain users or groups access to certain workspaces or directories.
Ideally, access control can be by done by bug id.
- graphical resolve of conflicts - a graphical three-way diff is the only
way to resolve complex conflicts
- The ability to move files and directories and maintain file history
and label integrity from the client. CVS requires the whole workspace
to be locked so that moves can be performed on the server side and
does not maintain label integrity.
- web viewer and graphical difference viewer - the ability to browse via
the web change set lists to see what files changed and what the actual differences
- the ability to integrate workspaces across projects - the ability to
arbitrarily merge/integrate any source code from any project to any other
- powerful labeling features (parallel development and prior version support).
- rollback or undo multiple changes - this is great way to recover from
a developer commit disaster.
- multi platform support - must run on all platforms.
- command line and graphical interface. Command line for scripts
and graphical interface for those who can't work without it.
- push and pull notifications - built in support for e-mail and news group
notification of changes in the workspace.
(from Slashdot) 10 problems with CVS by j1mmy (email@example.com)
- Documentation is piss-poor. There's an easy solution to that one, but
nobody likes writing documentation.
- Updates don't always work as expected. They won't grab new directories
and a few other quirky things.
- Empty directories should be pruned by default in a checkout or update.
- I'm tired of seeing a CVS directory everywhere I look. How about .CVS
- Access control is poorly handled. It's good that you can map virtual
user names, but it would also be useful to control access by groups.
- Local CVS tree file ownership is by user, not the CVS owner. This opens
up all manner of problems for users with a local CVS repository. Repository
data should be in a non-user account, checkout should force authentication,
and the server should handle who has access to what. This would not be tremendously
hard to manage, since in the general case a user has access to a project
or not. Fine-grained access control of the repository isn't a common necessity.
- Plays badly with (most) IDEs. When I want to work on a project in an
IDE, it floods my checked out directories with all manner of crap I don't
want in the repository. You can set up refuse files to clean these out,
but it might break your IDE project. This is more a fault of IDEs than CVS,
- Needs smarter add functionality. I don't like writing stuff like 'find
./src/ -name "*.java" | xargs -n 100 | cvs add' just to hunt bring
in my new source code.
- CVS is a boring acronym.
- I can't think of a tenth thing.
(from Joel on Software) CVS vs Perforce vs ? by Rajesh Jayaraman - Friday,
September 27, 2002
I have personally used both CVS and Perforce extensively. And when I moved
from CVS to Perforce, it definitely was an "upgrade". A few of the
really good reasons why the 750 bucks is worth it
a. A commit is a transaction - How many times have you started a long checkin
on CVS, and the network or something goes down, and you have code breaking.
In P4, an entire commit(submit) is an atomic operation. This is a real blessing,
because you can be sure that a checkin will never break the code (Provided you
have verified it doesn't before checking in!!!)
b. P4 is not as chatty as CVS - P4 maintains state on the server, which means
you do not have those dirty /CVS directories in your code. What CVS does in
order to do an update is, it communicates to the server(repository), which version
of the file it has. Then the server figures which file version to give it. And
this is done for each directory in turn! The volume of communication is very
large between the client and server.
c. P4 maintians labels as references to the file versions instead of placing
a marker on the physical file itself.
d. P4 maintains differenct branches as distinct files - Unlike CVS where
all branches of a file are marked on the same repository file
The above two combined, give you a much superior performance when it comes
to labelling and branching. I have persoanlly faced situations where we have
had to maintain a large number of branches, and releases on each of these branches.
CVS locks each file it's trying to label, and if you are labelling the whole
source tree, every developer's work is pretty much frozen. In P4 labelling a
whole source tree (of about 5000 files) takes 2 minutes flat.
Apart from this, pretty much everything that CVS provides is provided by
P4, including watching, auditing etc.
The bottom line is this: If you are working on a really large project, with
a lot of source branches go for P4. If you are working on a WAN (as we are)
go for P4. If you run a single or dual branch software shop, with everyone sitting
in the same place, go for the free alternative. You won't notice the difference.
(From JOS) Robert Tuesday, October 07, 2003
"what are issues with CVS that would drive people to choose another
SCM, either open-source or commercial? "
Where to begin?
- branches are expensive, fragile, and semantically braindead.
- you can't rename a file without losing its history or fiddling with
the repository itself, which will likely cause gremlins later on.
- operations are file-centric, rather than tree-centric. It is fragile,
error-prone, and generally a waste of time to attempt to mark "logical
changesets" to a tree, using some kludge like CVS tags, or heuristics
on check-in logs and times.
- since commits are not atomic per tree, it is nearly impossible to revert
a "change" as a unitary operation if it crosscuts more than one
- it is not possible to follow development on a branch, versioning your
own changes, without write access to that repository.
- You can't rename a directory without losing ALL of the history of all
of the directories and files underneath it. Or, you can hack the repository,
which also has its cons, usually in the form of gremlins later on.
- You can't version symlinks.
The list goes on. This is really the kind of thing that you never really
realize how truly awful it is until you've had the opportunity to use something
- As of August 2002, this open-source SCM called subversion is still alpha,
and is only available as source code, so Windows users have to get a C compiler.
A wxWindows-based cross-platform GUI client (rapidsvn) is available for different
- Subversion can run either as an Apache module (communication with clients
over WebDAV), or a stand-alone server (in clear-text with no authentication,
or through a SSH tunnel.)
- Single-User Subversion
- Multiuser Subversion
Due to differences in security mechanisms, not available for NT.
- Apparently also available on NT, but primarily a Unix tool
Team Coherence Version Manager
- Commercial, but cheap, TCP/IP-based client-server setup. Primarily Windows,
but a Linux version is available for the server part.
Big, difficult to configure, expensive.
MS Visual SourceSafe
Unstable, slow on WAN links (add-on available to increase performance), server
not available on Unix systems.
"SourceSafe was created by One Tree software. Microsoft orginally had
their own version control system, called Delta, but it was yanked from the shelves
shortly after it was released. (If anyone knows the story behind this, I'd love
to hear it). Microsoft quicky bought One Tree, re-packaged the existing versions,
and then sold off the non-windows versions. Metrowerks picked up the Mac version,
but they've dis-continued it."
- www.regexps.com . Not available for
- "I'm also broke. 2002 revenues for regexps.com have totalled just
about exactly $10,000, which isn't enough to keep these projects alive for much
longer (we're talking about days of life left, here). So, today (21-Jul-2002)
I'm announcing a fund raiser, and if it works out well enough, I'll make it
a permanent part of how regexps.com operates." http://www.regexps.com/arch.html
- "Code Co-op is a peer-to-peer version control system which uses
email to synchronize project files between remote locations and uses LAN
- Commercial, but very low price
- Only available for Windows
- Uses network drives to share data among different developers -> SMB
access required if sharing over the Net...
- Formerly known as FreeVCS; JediVCS started recently (june 2003)
- Data in DBMS
- News server
- Now open-source
- To set up the server part on a Windows host:
- unzip dbiarch.zip
- copy servercrypt.dll in folder
- copy fvcsappserver.exe in folder
- start server
- To set up the client part on a host:
- start freevcs.exe
"The CS-RCS/CS-CVS product
family is today the most powerful, yet easy to use, version control system for
Windows. The CS-CVS solution consists of two products:
- CS-RCS Pro provides extended version control and configuration management
solution for software development projects
- CS-CVS provides additional support for networked projects stored on
CVS servers. This product is automatically installed by CS-RCS Pro the first
time this type of access is required.