Differences from CVS ==================== This page will describe various differences between CVS and darcs. [[`TableOfContents `_([2])]] 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 * 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. Related Pages ------------- - `Real World Benefits of Switching from CVS to darcs `_