Darcs is a version control system. Like Arch or Monotone it is a distributed version control system, much unlike Subversion or CVS which are centralized. Darcs is also more simple to use and is certainly very robust. And as we'll discover when learn how to start using Darcs within our organizations, it provides us with protection from data loss.
First things first -- get a project going:
$> mkdir my_project $> echo "My first darcs project" >> my_project/some_file
Then to create a darcs repository all we have to do is type the following:
$> cd test/ $> darcs init
We now have a repository. You'll notice a new directory in test/ called "_darcs". As you may have guessed (and is common to most version control systems), this is where Darcs will keep all of its files.
However, our repository is still technically empty so we need to add files:
$> darcs add -r * $> darcs record -am "Initial import."
If successful, Darcs will tell us that it has finished recording our "patch." In Darcs, even though we call it a version control system it doesn't technically record changes as versions. Instead, it uses what it calls "patches," which are for all intensive purposes just that -- a collection of diff-like files that are manage by Darcs and systematically applied against a "pristine" copy of the source.
Don't worry if this all sounds like gibberish now, it will make sense in a bit hopefully. For now lets look at our changelog:
$> darcs changes
Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.
Notice it gives you nice GNU-style changelogs? You can also export CVS-style unified diff patches if you want. Darcs is really friendly that way.
You can share your Darcs repository in many ways. Either by sym-linking it into an apache path, via SSH, or through the filesystem. The easiest is simply via Apache.
To check out a fresh copy of a Darcs repository try this:
$> darcs get http://www.somesite.com/repos/my_project Copying patch 47 of 47... done! Applying patches to the "working" directory... ...................................................... Finished getting.
Now we have a complete copy of the remote repository. Technically we can think of this copy as our own private branch. We can work offline making changes and creating patches and submit them later when we get back online. Darcs is smart enough to merge all your changes in. Someone else can even move a file that you are working on into a different location within the project tree and Darcs will still know where to apply the patch. The only time it will get confused is if you edited the exact same line as someone else.
This is because Darcs applies context to patch sets. It can trace the history of a file and its place in the working directory. Very handy.
So, let's see how to make and submit changes to the remote repository:
$> cd my_project $> echo "Adding new line to file" >> somefile $> darcs whatsnew --summary M ./somefile +1
The whatsnew command lets us see what changes we made since we checked out the source or pulled in some patches. Giving the "whatsnew" command without the summary option gives you a more verbose output in the Darcs diff format. Try it to see what it looks like (Darcs calls them 'hunks').
Now lets commit our changes and send them to the repository:
$> darcs record -am "Added critical new line' Finished recording patch "Added critical new line." $> darcs send -a Created patch to http://www.somesite.com/repos/my_project... Sending by email to someperson@somesite.com Successfully sent patch bundle to someperson@somesite.com
So... that's the basics. Let's just do a run-down of some of Darcs' key features:
In a more complicated setup, Darcs can work with gpg and procmail to maintain an authorized list of senders who can send patches via encrypted mail. This means I can cut out anonymous access and securely transfer my code across the net.
Darcs can even take it a step futher. If you have a unit test framework or coverage tests, it's possible to have Darcs run the tests against incoming authorized patches before applying them. Failed tests will send a notification back to the submitter and the patch will not be applied. Very handy!
Development with Darcs is organic. Developers are free to branch, patch, and fork to their hearts desires. They can work offline and away from the office network while still maintaining the productivity and mangeability that version control affords us. Your project will spawn copies all over the place and hopefully take on a life of its own... in a good way of course. No savage spaghetti monsters of doom here.
Business organizations however, typically want a centralized location to store their source-code -- their assets. It feeds their sense of ownership and control, giving them the false sense of security. It's on a close network with limited access and one person holds the key. Policy, policy, policy. It's a warm fuzzy blanket that gets warmer and softer the bigger the company gets (something to do with risk averseness... you know what they say about the bigger one is).
However, a central server is also a central point of failure. Not only do you have only one portal to access it and one person to report to in order to get the permissions you need; but it is also the beating heart of an organization. All it takes is one small heart attack and the whole operation shuts down. If your sysadmin is really unlucky, it could mean that all your hard work just got vaporised.
Darcs on the other hand is a distributed system. Each checked out copy is a repository in and of itself. Copies spawn more copies. And branches and forks. All in a big chaotic mish-mash. Nothing could be better for protecting your hard work. The more copies there are, the more resistant your organization will be to accidents, freaks of nature, or poorly manufactured hardware (or the occassional disgruntled employee).
How does one manage a project where development is not linear?
Kind of like how most open-source projects are run, a project may have a maintainer (usually an individual, sometimes a committee) and a vast group of sometimes random developers.
Sometimes though, hierarchy isn't important. Perhaps a submitter has an idea that will take the project in a new direction. Darcs lets developers to branch and fork a project freely and cherry-pick patches from eachother.
Perhaps management will need to change. Instead of a single project maintainer managing linear progress, a manager instead with keen insight into the project will have to keep track of all the branches and cherry pick the best versions that pop up.
Linear development wastes cycles. Even with traditional centralized systems. Working asynchronously is still a linear approach.
Managers delegate task and associate time to delivery. The plan buffers, assign to individuals, and plan to waste time. This is largely because that the time it takes to solve problems or implement solutions is sometimes not accurate enough. So they plan to take the punch in their strategy.
For developers this is a pain because either they solve their tasks quickly and need to find more work, or it takes longer than they expected and they start getting distracted by the managers calling them up.
There's a lot of missed opportunity during delegation as well. Sometimes we have a great idea to solve a problem, or could have a great solution to a problem, but since either we weren't delegated the task or the maintainer didn't follow our solution; the potential of our project has just suffered.
Sometimes our manager just doesn't understand what we're talking about.
Self organization can play a strong role to remove such points of failure. It may also mean happier developers more engaged in the problems they are good at solving. Because nobody can do everything -- so why not plan for that? If you have a team of multi-disciplanry developers; so much the better for your organization.
It's a really really flexible system. Seriously. Darcs can serve as simply your personal backup system or productivity tool on your local machine. It also has very sophisticated automation abilities.
Generally I recommend one of two methods of deploying darcs:
Create a directory for Apache. Something like "/var/www/repos" and give it a path in your Apache config.
Then any user that wants to create a new repository can symlink the project directory to the "/var/www/repos" directory. Make sure Apache is set up to follow symlinks.
Each project is forced to have a maintainer in this way. People who check out a copy will use "darcs send" to email their patches to the maintainer who will be responsible for accepting or denying the patches.
This process can be time-consuming for busy projects for the maintainer; but it does ensure a high level of quality. To speed things up, procmail could be used to automate the sorting of incoming patches. Or if the administrator is particularly clever, the fully automated gpg features could be included.
This is good for limited but trusted groups. Darcs can accept patches via SSH using an scp-like connection string.
Because each user will require a shell account on the server, you can effectively control permissions and access to repositories. The benefit though is that you can probably trust these users to know what they're doing and they can submit patches without waiting for approval.
It really isn't a secret... but I don't usually mention it as an official third option. This is mainly because it's a lot more open than most organizations would like; but it is also by far the most radically conducive to the developers and their ability to get things done --
Create a bare open repository that is web accessible. Use Apache auth modules if you need to make sure just people within your organization access it. However, by making it fully web accessible (restricted to your employees); you give your people the ability to be outside your network. And if they have a great idea, they just might.
It's all about being conducive to great ideas.