Differences from CVS
This page will describe various differences between CVS and darcs.
Contents
CVS keywords
CVS keywords are single line informational strings that can optionally be added to files to managed by CVS. They look like this:
$Id: File2.java,v 1.3 2004/06/02 17:30:42 JHunter Exp $
darcs intentionally doesn't support this concept. These keywords modify the source files directly, whereas the versioning system should leave the source untouched. Also, it becomes much more complicated to compute diffs, to apply patchsets in different orders and so on. Which date should appear? The date you applied the patches, the date of the latest applied patch or the date of the latest patch applied?
However, darcs provides a similar and more useful feature-- it can easily give you a summary of the last change, including a human-readable description of what it was. Try this:
darcs changes --last=1 --summary file.txt
It produces friendly output like this:
Mon Oct 25 07:01:55 EST 2004 Mark Stosberg <mark@summersault.com>
* typo fix: scopre -> scope
M ./Changes.lhs -1 +1
If this does not satisfy you, try fleshing your thoughts on CVSKeywords.
Merge conflicts
How CVS handles them
You try to commit and get a message that there are conflicts, and the commit fails. You run update, which causes the conflicts to be marked in your working directory. You review and resolve the conflicts, and try to commit again, hoping another conflict hasn't developed.
How darcs handles them
darcs is similiar in that it will notice conflicts, name the conflicted files, and possibly mark them for you. It will not mark conflicts for some cases if you are using version 1.0.0rc3 or earlier. It will also not mark conflicts if --no-resolve-conflicts is set in the target repository.
If you pull in changes, the conflicts are marked in your local repo. If push changes, they may be marked in the remote repo. The case for pushing is explained more in the offical docs for push.
To avoid causing conflicts in remote repos, you may want to pull from those repos before you push to them.
Tags
In CVS, tags are per file. There is no easy way to get a list of all the tags that apply to the whole tree. In darcs, tags apply to the whole tree.
In CVS, tags are forced to be unique. In darcs, they are not, but you can restrict a query about a tag to also be restricted to a date range.
TODO: reformat this as table for better readibility. --MarkStosberg
Benefits for non-committers
A non-committer is a person who doesn't have write access to the master repository of a project he's contributing to.
CVS is a centralised version control system. To a non-committer, CVS degenerates to being little more than a tool to get the latest sources. Darcs, on the other hand, is a decentralised system, and gives the full benefits of version control to everyone, even non-committers.
Submitting patches to the project
By definition, non-committers can't push or commit their contributions directly back to the project. E-mailing a patch is the usual alternative. With darcs, this process is fully automated: just use
$ darcs send
and you will be interactively prompted for which patches to send. If the remote repository is properly set up, figuring out which e-mail to use and actually mailing the message happen automatically.
With CVS, you need to manually create a patch, and then send it as an attachment... once you figure out the right address to use.
With CVS you also have to make sure you are creating a 'diff' against a version that will apply cleanly and contains the data that you want to send. For example, you may have other changes in your local tree that you don't want to submit (yet).
Automatic patch attribution
In CVS, when a committer receives a patch from a non-committer, they apply it under their own name. They may mention the author in the commit message, but then they might not. Giving credit to non-comitters requires extra work in CVS.
With darcs, the original author's name is preserved by design when it is committed in a remote repository. Giving credit is built into the system, it's not giving credit that requires extra work.
Conflict Reduction
Sometimes committers need to modify the patches they receive.
In CVS, this will cause conflicts for the non-committing contributor who pulls a later version with the integrated change.
In darcs, the standard workflow avoids this issue. The easiest thing for the recipient to do in darcs is to apply the complete received patch to their personal repo, and then make any refinements as a separate patch. Also, should the committer reject the patch, she has two options:
use unpull after reviewing it to forget the patch ever existed
use rollback after reviewing it to reverse the patch if the issue handled in the patch has been fixed another way. In this case, the patch submitter will properly be able to pull both the right fix and the reversal of her useless patch.
Now when the contributor pulls the fully-integrated changes, darcs will do the right thing, and there will be no conflict.