[darcs-users] Using darcs in the real world (branching, multiple developers...)

[David Roundy]

On Mon, Nov 17, 2003 at 08:12:22AM -0800, Kevin Smith wrote:
> SINGLE DEVELOPER, MULTIPLE EDITIONS
> 
> I am working on a project, with the repository on my local machine, 
> mirrored out to some public http site for people to pull from. Suddenly 
> I need to roll back to a specific tagged version, make some changes, and 
> re-release. For the next couple weeks, I want to be able to bounce back 
> and forth between that legacy version and my latest version.
> 
> How might I do that?

A single user using multiple versions is actually quite natural with darcs.
The key is that every working copy is a full repository (although with the
get --partial and checkpointing options I'm working on this will be less
true), so having two versions of the repo is very natural.

I'd use a "darcs get" to get the tagged version:

darcs get -t "OLDVERSION" ./therepo

This won't waste much disk space, since the patches will be hard linked.
The new copy of the repo will probably be something like ./therepo_0.
There's a --repo-name option to specify it, but I always just rename it
afterwards.

So now you have two versions.  You can pull between them, if you want to
move changes between them, so you could just develop on them separately.

> MULTIPLE DEVELOPERS (TRUSTED PEERS)
> 
> Three of us are working in the same company, on the same project. We 
> want to stay in sync with everyone's code on a frequent basis (multiple 
> times each day). With CVS, we perform 'cvs update' very often, like 
> maybe every half hour, to be sure we are up-to-date. We commit whenever 
> we are at a stopping point with good code that passes the tests.
> 
> I think we would want to use a 'star' model, where there would be a 
> 'master' repository somewhere on our LAN. We would probably push our 
> changes to it whenever we were at a stopping point.
> 
> Mechanically, I suppose we would use push --and-apply to move our patch 
> into the master repository. Or we could push our patch-bundle to a file 
> in a particular directory, where a daemon would notice it and apply it 
> to the master repository. There are alternatives, of course.
> 
> Then, we would frequently 'pull' from the master repository. It sounds 
> like our method of working wouldn't have to change much.

Yes, this method would work.  You could use any one of a number of
mechanisms for doing the push.  Your method of working wouldn't be forced
to change very much, but you'd gain some benefit over CVS even in this
situation.  You would be able to record changes as they are made, and then
push when it is stable.  This can make a big difference if someone is
working on a large change, since it allows them to have the benefits of
version control while working on the large change.  You could do this in
CVS by creating a branch, but in darcs you already have the branch.

Also, if you have a major change that you aren't sure if you trust, you
could ask another developer to pull or get from your repo to try it out.
That is to say, you aren't restricted to a star topology.  Any user can
pull from any other user, provided either their repo directories are on a
shared disk (e.g. nfs) or are exported via http, or the users have accounts
on one another machines and can use ssh.  Letting other people try your
changes (especially if they're risky) can be very handy.

> MULTIPLE DEVELOPERS (LEAD/CONTRIBUTORS)
> 
> Three of us are working on the same free software project, from 
> different continents. One of us is the lead, who decides which patches 
> get into the master repository. The other two contributors want to stay 
> up to date with the master, and generally not with each other, although 
> occasionally they will want to directly exchange a patch or two.
> 
> Because the lead is also a developer, she still wants a separate master 
> repository aside from his personal workspace.
> 
> So when the lead completes a task, she would push --and-apply to the 
> master repository. The contributors would frequently pull from the 
> master, but would push their changes (via email) to the lead. The lead 
> would evaluate each patch to decide whether or not to accept it.
> 
> The lead would need to use a 'staging' repository to evaluate the 
> patches. That might be the master repository if the public version is 
> merely a copy. Or, if the public version is symlinked, the lead would 
> need a third repository on her machine. One for personal development, 
> one for staging, and one as the public master.
> 
> Probably the lead would pull from the master into her working 
> repository, and would push from the working repository to the staging 
> repository (just like everyone else). Then she would push from staging 
> to master.

This scenario is actually pretty close to how darcs is developed (except
that I'm a he, not a she :), so I'll describe how I do things.  Your idea
is pretty much sound.  In my case, I have two computers at home on which I
run darcs, and the abridgegame.org server, which also runs darcs, so I need
to have copies of the repo on the various computers.  Most of the work is
done on my laptop, which has three repositories, because it is running
debian with sid, woody and sarge chroots (so I can test and compile darcs
in a few environments).

Rather than push --and-apply, I actually use plain email push and run apply
--verify on the emails in my .forward on abridgegame.org by a special user
(which exists for the sole purpose of serving this repo).  This allows me
to run the test suite automatically and easily (without slowing down my
laptop), and get the results back via email.  This is especially useful, as
the server runs ghc5 while all my other computers run ghc6 of one variety
or another.  The pushable server actually isn't the "real" public server,
because when I first created it, I didn't trust it, and I haven't bothered
to change things since.  So once the test is done, I have to log in and
pull to the actualy primary darcs repository.

As far as receiving patches goes, often people send them via push, but it's
almost as common (see recent email by Peter Strand) for people to have an
http server and just make their repo available via pull.  This is nice for
the list, as it doesn't overload anyone's mailboxes, but the changes are
available to the interested before I get around to pulling them.

> That's my thinking so far. It's really hard to do these mind experiments 
> without having used darcs in a multi-user setting, nor (thankfully) 
> having struggled with CVS on a multi-person project.

Well, you seem to be doing all right...  :)
-- 
David Roundy
http://www.abridgegame.org