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

[Kevin Smith]

I'm still new to the whole idea of distributed revision control, so help 
me out here. I don't see anything in the darcs manual describing how a 
single developer would manage two "editions" of a single project, nor 
how a three developer shop might use darcs.

I describe three scenarios below, and in some cases try to propose some 
processes. Please fill in the blanks, correct any errors, and suggest 
other alternatives where appropriate.


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?


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.


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.

----

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.

Thanks,

Kevin