Which workflow(s) do you use?

[Bill Barry]

Arne Babenhauserheide wrote:
> I want to write a page for mercurial-scm.org about workflows. Since I want the 
> page to contain real-life workflows, I'd like to ask: 
>
>
> 	Which workflow(s) do you use? 
>   
For work we mostly use a centralized style workflow. There is one big 
repository with 14 projects in it and we all can push to it. We tag 
releases for each product in this repo and use named branches for 
major/minor versions (ex: 1.0.0 is tagged on the default branch, 1.0.1 
is released off of a 1.0 branch with a base of the 1.0.0 tag whereas 1.1 
would come off of the default branch). Essentially, every machine only 
has one copy of this repository.

Additionaly, each developer has their .hg/attic folder wired up to a 
central attic repository, and we each have .hg/patches wired up to an 
individual mq repo on the central server.

We do have several rules:
1. The main repo must never have more than one head (across all 
branches). This head must be from our default branch (which happens to 
be named trunk due to the fact that I named it at revision 0; looking 
back it might not have been my greatest idea, but it really hasn't 
caused any problems other than minor confusion when reading docs and 
wondering what the 'default' branch is)
2. Developers are strongly encouraged to never have uncommitted work in 
their repositories when they are not at their machines working on 
something. All work should be committed/pushed to the main repo, or 
shelved/pushed in the attic or in the developer's central queue.
3. If somebody commits something that causes the main repo to start 
burning then that dev is expected to immediately fix it. We have 
CruiseControl.NET watching the repository which compiles/tests each 
commit and sends out an email when it finishes.
>
> Some important things about a workflow are
>
> * What is special about your workflow? 
>   
Nothing really... It is pretty easy to understand (feels quite similar 
to our svn usage before we switched, except we have the added benefits 
of mq and attic).
> * Do you use extensions for your workflow? 
>   (Are they essential, or do they just make it easier?)
>   
We heavily use Attic and the log viewer in tortoisehg (we all use 
windows; the rest of tortoise we don't really find useful though). I 
also have purge and rebase enabled, simply because I find them useful 
(none of the others use these, we don't particularly care about seeing a 
branchy log).
We all occasionally use MQ (much less now that I wrote Attic as we 
rarely built queues more than one patch deep).

In my attic, I also have boundmode enabled (another extension I wrote) 
because I tend to commit there a lot and it makes it pretty easy to not 
have to remember to commit and push every time (boundmode makes hg ci 
attempt hg ci then hg push). It is completely unnecessary, but saves me 
typing. I'd use it on my main repo, but I often will commit 3 or 4 times 
before I decide to push there (generally after I push I go and read my 
email and comment on some bugs in bugzilla).
> * How do you work locally? 
>   
Each developer has a single copy of the main repo. As a developer:
Generally at the start of the day you would run hg pull -u (I have a 
scheduled task that does this for me at 5am before I wake up).
Throughout the day you will commit and push (and merge/rebase where 
necessary).
Occasionally you might pull and update or shelve and unshelve (or 
qpush/qpop).
When committing, you should put a bug number into your commit message, 
the bugzilla hook will link to the changeset in the bug and ccnet will 
know what bug to link to with the build.
After committing you would pay attention to the CI email (generally 
comes in about 5 mins).
At the end of the day you would make either one last commit and wait for 
the CI email, or you would shelve your work and push to the attic repo 
(merging where necessary) or if you are working on something big you 
might push your queue.
> * How do you share changes? (between developers and for releases)
>   
Finished work (or other changes that can be made public in the main repo 
without causing a burning tree) generally goes directly in the main repo 
where anybody can pull it at any time (last I checked we were averaging 
something like 20 commits a day).
Unfinished work usually goes into the central attic; if I wanted to 
share something I would shelve a patch and commit/push the attic. My 
coworkers would pull the new changesets in the attic and can unshelve my 
patch.

> * How many people are in your team? 
>   
Right now we are down to 3 constant developers. There is one person 
working on skins who also commits (about twice a week or so) and two 
other developers who will occasionally commit (we have a second team who 
are working in a language called Powerbuilder against a Visual Source 
Safe repository...). There used to be 5 of us full time on these 14 
projects.
> * Why did you choose this workflow? 
>   
It works...
We didn't exactly choose this workflow. It sorta evolved out of our 
needs. We started with the idea that a centralized repository would be 
much like how we used subversion, just replacing svn ci with hg ci && hg 
push and svn up with hg pull && hg up. Already we had Subversion wired 
up to Bugzilla and using Mercurial the same way just seemed natural. 
Originally we worked just like we were with Subversion, always 
committing everything at the end of every day, no matter what (some 
hyper-intelligent person thought it would be a great idea to contracts 
with our clients that we would never leave unfinished work on our 
machines and that their code escrow service should always have all of 
our code, finished or not; using Subversion we had 3 choices: 1. breach 
contract by not committing at the end of the day, 2. let our main tree 
simply not be stable, or 3. deal with patches/user branches in svn; 
generally we went with option 2 and nobody was really happy because our 
releases suffered for it). We knew there had to be a better way, so we 
started using MQ (and almost immediately our releases and build server 
were much improved). Sometime around then, I joined this list and 
started looking around for a tool that better modeled the way we wanted 
to work (sharing queues kinda sucks when you only care about one patch 
in them at any time). After a while I realized that there really wasn't 
a tool that quite matched the way we wanted to work, so I wrote Attic.
>
> If you also have an idea for a nice name for your workflow(s), please post it!
>   
I would call this workflow Centralized. When it comes down to it, that 
is really all it is:

We have:
1. https://central-server.ourcompany.com/hg/Trunk
2. https://central-server.ourcompany.com/hg/Attic
3. https://central-server.ourcompany.com/hg/Trunk-mq-Bill
4. https://central-server.ourcompany.com/hg/Trunk-mq-Mike
5. https://central-server.ourcompany.com/hg/Trunk-mq-Andrew

each developer has:
c:\work\Trunk (with default path set to 1)
c:\work\Trunk\.hg\attic (default path set to 2)
c:\work\Trunk\.hg\patches (default path set to a local \work\mq repo; 
when looking at someone elses queue you delete this dir and pull another)
c:\work\Bill-mq (default path set to 3)
c:\work\Mike-mq (default path set to 4)
c:\work\Andrew-mq (default path set to 5)

> And if there's anything you'd like to add beside the questions, please do so! 
>   
Everybody who works here has had experience with Subversion; this 
workflow was really easy to get used to. For the small size of our team, 
I feel that this workflow is pretty good but it certainly wouldn't scale 
up. I doubt it would be useful for more than about 10-15 developers.
> A script which simulates your workflow(s) would be a nice bonus :-) 
> (but that's not necessary for a useful description)
>   
How about some instructions to set it up?

central server:
1. set up hgwebdir on a folder
2. in this folder you should create the following repositories: Trunk, 
Attic, and one MQ repo per developer

each developer machine:
0. install Mercurial and Attic globally
1. create a work folder
2. clone Trunk to work\Trunk
3. clone Attic to work\Trunk\.hg\attic
4. clone everybody's queues to work\name-mq
5. set up path aliases for everybody's queues locally and for push 
locations (saves typing later when you want to change queues; though 
most of the time queues will be unused because the attic is just so much 
better).