* Offline mode. Darcs is distributed. This means your own working directory is a repository in its own right. * Local preparation. Darcs enables you to modify patches before sending them to a remote repository, or even to throw them away completely and start over. * Easy branching and merging. Every repository is a branch. There is no branch administration except pushing and pulling between repositories. * Easy collaboration by e-mail. If you want to add a feature or bugfix to some project, you can make a local clone, apply your changes, then send the patches by email (darcs send). * Parallel development. Let’s say you follow the development of an open-source project, and you have some controversial patches that aren’t accepted by the official maintainers. No problem – make your changes and publish your own repository. It’s a fork, of sorts, but it’s still connected to the mainline. * Cherry-picking. If you’ve ever worked on a team, you will know that somebody often has a change you want, with Darcs you can grab just the one change by pulling it into your repository. * Interactivity. Darcs enables you to be precise and say “yes” or “no” to every change that you can include in your patch. Thus you can really create minimal patches, or separate your work in several patches, each one doing a consistent change. Other commands, like darcs pull and darcs push, behave the same. * Hosting. You can host your repositories with hub.darcs.net or darcsweb and share them to the world!

* Subversion versions directories as first-class objects, just like files. * Copying and deleting are versioned operations. Renaming is also a versioned operation, albeit with some quirks. * Subversion allows arbitrary metadata ("properties") to be attached to any file or directory. These properties are key/value pairs, and are versioned just like the objects they are attached to. Subversion also provides a way to attach arbitrary key/value properties to a revision (that is, to a committed changeset). These properties are not versioned, since they attach metadata to the version-space itself, but they can be changed at any time. * No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file, and commit's log message is attached to its revision, not stored redundantly in all the files affected by that commit. * Branching and tagging are cheap (constant time) operations. * Merge tracking, File locking, symbolic links can be versioned. * Executable flag is preserved. * …and a lot more!