bzr revno always an integer, redux and new workflow questions

[Chris Hecker]

This is basically a thread-necro of this:
https://lists.ubuntu.com/archives/bazaar/2011q2/072795.html

Okay, so I finally screwed up my monotonic revno on the main feature 
branch in a way that mattered (meaning put it far enough behind an 
existing released revno that I had to check in 6 empty commits to fix 
it) due to a merge-then-push on another branch.

I'm using the local revno as part of a version number on an executable, 
which is probably not great, but it's what's happening and has some 
benefits that I'd like to keep.

So, assuming I don't want this to happen again, can somebody walk me 
through the correct workflow?

Here's my current workflow:

- there's a server repository with append_revisions_only=False

- there are two separate working branches on two different machines that 
I push and pull to the server with, or merge when things have diverged

Obviously, what happened was I did a bunch of work on my main 
developement machine, the revno was up past 2319, and then I pushed it 
to the server, and then I had some work in the other branch, and merged 
to it, then pushed, and it knocked the revno back to 2306 or something. 
  I'd already released a 2319 build, so now I needed to do a bunch of 
empty commits to get the local revno over 2319.

I shouldn't be doing it this way, I know, but I don't have a build 
server right now, and it's very convenient to have the version number 
contain the actual local revno, or at least it was when it did.

So, I think I want to turn on append_revisions_only=True on the server. 
  I'm just a bit confused about my workflow then.

I have to have a clean branch on each of the machines I merge into then, 
before pushing to the server, right?  So, I have:

- server repo, append_revisions_only=True

- client a - feature and trunk branches
- client b - feature and trunk branches

I do a feature on client a, checking in a bunch.  On a's trunk branch, I 
pull from the server repo, and then merge the feature to it.  Then I can 
push to the server repo, right, because it's a pure superset?  And pull 
to the feature branch to update it.  Same on client b.

Should I use colo to do each client?  Is it working well enough?  What's 
the workflow then?  It sucks to have to have two branches per client, 
but I guess that's the price I have to pay?

Will this keep a's feature branch with a monotonic revno?  That's what I 
need.

Thanks,
Chris