out of the DARC(nes)S
If we want darcs, we need to consider some issues and make sure everyone is happy to make some changes in the way they work on Epigram.
Firstly, why is it a good idea, without getting into CVS bashing?
- It’s Haskell — thats good politically (we like functional programs), and, maybe even, practically (if it don’t work fix it!).
- The theory of patches is an good idea. It gives us more control over different versions/experiments/dead ends. Say I had a copy of the main development trunk, but also an experimental version of my own devising, if Conor writes a bug fix on the main version I can (if appropriate) apply that patch to both my versions. If I do some work on a file that breaks the main trunk I need only send a patch to Conor who can propogate the changes through the rest of the system before we make both patches publicly available. I can think of many more such situations. Perhaps you can too.
- OK I promised no CVS bashing but… wouldn’t it be nice to move files/folders and keep their history (there, I said it).
There is no halfway house here though, we can’t piggy back CVS on DARCS or vice versa… We either twist and get everyone up to speed on the new practices asap or we stick save the wandering around in the dark for a bit but, in my opinion, lose out in the long run.
So what about the practicalities, well anyone with darcs will be able to pull down a copy from the website, from then on we make these changes:
cvs commit
becomes
darcs record
(locally) or
darcs push
globally
cvs update
becomes
darcs pull
Theres a big list of cvs -> darcs translations here. The rest of that page is a good introduction to why DARCS is different, it’s worth a read.
So what about it?