[Haskell-cafe] darcs upgrade HOWTO (was: poll: how can we help you contribute to darcs?)

[zooko]

On Aug 5, 2008, at 0:26 AM, Ketil Malde wrote:

> The consequences of moving to the darcs-2 format are a bit unclear to
> me. For instance, I'd like to keep my main (export) repo in darcs-1
> format, in order to make it as accessible as possible (Ubuntu still
> ships with darcs-1.0.9, and that's a fairly cutting edge
> distribution.)  Can I convert my working repos to darcs-2?  Should I?
> How about darcs-hashed?  In short, I'd like to see examples of
> recommended migration strategies, and associated benefits.

Here's what I recommend, and what I've been doing for months, both  
with the large Tahoe code base -- http://allmydata.org/trac/tahoe and  
with numerous smaller codebases -- http://allmydata.org/trac .

1.  Upgrade any executables you have to the latest stable version of  
darcs immediately.  The new executables are fully backwards  
compatible -- you will not have any compatibility problems as a  
result of upgrading.  They are also much less buggy and faster than  
older darcs executables.

(There are at least two known issues with the darcs-2.0.2 executable  
which cause performance problems -- one is a issue with ghc v6.8.2  
and the other is an issue with the latest version of libcurl --  
v7.18.2.  Hopefully the darcs core team will release darcs-2.0.3 soon  
to fix these two issues, but even if darcs-2.0.2 is still the current  
version, I recommend it over any previous version.)

If your use of darcs is currently satisfying (fast enough, no bugs  
getting in your way), then stop at this step.  You are now using the  
latest stable darcs executable while using old-fashioned darcs-v1  
repositories.  Other people who are using older versions of darcs can  
continue to share patches with your repositories just like always.


2.  If there are problems with this situation of using darcs-2  
executables and darcs-1-format repositories, then report it to the  
darcs-users mailing list, and then make a new hashed-format  
repository in parallel with your existing darcs-1-format repository,  
like this:

darcs get --hashed ${repo} ${repo}-hashedformat

Now people who have new darcs-v2 can push and pull to the - 
hashedformat repository and people who have darcs-v1 can continue to  
push and pull to the original repository.  You can transfer patches  
between those repositories with normal darcs push and pull.  For  
those projects of mine which have a high rate of patches I have gone  
ahead and added post-apply hooks to automatically do a "push --all"  
to the other one, like this:

echo "apply posthook darcs push --all --repodir=/home/source/darcs/ 
tahoe/${repo}-hashedformat /home/source/darcs/tahoe/${repo}" >> $ 
{repo}-hashedformat/_darcs/prefs/defaults
echo "apply run-posthook" >> ${repo}-hashedformat/_darcs/prefs/defaults

echo "apply posthook darcs push --all --repodir=/home/source/darcs/ 
tahoe/${repo} /home/source/darcs/tahoe/${repo}-hashedformat" >> $ 
{repo}/_darcs/prefs/defaults
echo "apply run-posthook" >> ${repo}/_darcs/prefs/defaults

(Note that this is mutually recursive, but it terminates because the  
post-apply hook doesn't trigger in the case that zero patches were  
pushed.)


If your use of darcs is currently satisfying then stop at this step.   
You are now using the latest stable darcs executable, and maintaining  
two darcs repositories -- an old-fashioned darcs-1-format repository  
for your darcs-1-executable-using friends and a hashed-format  
repository for your darcs-2-executable using friends.  Your post- 
apply hooks cause these two repositories to get automatically synced  
with each other.


3.  If there are problems with this situation of using darcs-2  
executables and a pair of repos -- one of which is darcs-1-format  
repo for the use of darcs-1-executable-using users and the other of  
which is a hashed-format repo for the use of darcs-2-executable-using  
users -- then report it to the darcs-users mailing list and await  
further instructions.


Note that these instructions do not involve any use of darcs-2-format  
repositories.  Those are only for projects which (a) have no darcs-1- 
executable-using users, and (b) have no extant branches stored in  
darcs-1-format or hashed-format repositories.  Personally step 2 has  
satisfied all my needs so I use the step 2 strategy for all my  
publicly shared repositories, although I do tend to create new  
private repositories with darcs-2-format.


If someone wants to adapt this message to the darcs wiki I would be  
grateful.

Regards,

Zooko

http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month