using bzr with many small Python modules, forgetful person, and version numbers

[Eric S. Johansson]

Jan Hudec wrote a very nice answer:
> On Sat, Dec 30, 2006 at 06:49:45PM -0500, Eric S. Johansson wrote:
>> short question: How can a forgetful person use bzr to track revisions of 
>> Python modules and simultaneously update the module version number 
>> automatically?  (i.e. setup(...,version="1.10",...)) in setup.py)
...
> 
> In bzr, there is only version for the whole tree. That is a feature.
> In fact even you want it, because if the modules are more than one file
> (as yours seem to be) you don't want to see change in one of them and
> not the related change in the other. 

true.  Looking over the current set of seven modules, all but one has 
two files, the code and set up.
> 
>> if the answer is move the modules and make it one module per 
>> repository/branch, how does one split up an existing repository.
> 
> Yes, it indeed is. Make a branch for each module and delete all but that
> module in that branch.

I think this is where I'm having a bit of difficulty.  Making a 
repository/branch for two files seems a bit silly.  Are there any 
advantages to a multi-branch repository.  I understand that any other 
route induces significant complications so I shall follow your 
recommendation and continue to be amused at issues of scale (both upward 
and downward).

>> Also a related question, how does one make multiple repositories 
>> available via the built-in server?
>>
>> Your guidance is most appreciated.
> 
> IIRC (but I never actually used it), the builtin server provides access
> to it's working directory *and below*. Therefore if you run it from a
> directory where the branches you want to serve are subdirectories, it
> should allow access to all of them. Ie. if you have a directory
> containing subdirs 'a' and 'b', which are branches, and run a 'bzr
> serve' there, you should be able to access them as 'bzr://host:port/a'
> and 'bzr://host:port/b' respectively.

okay, I will give that a try.  Originally I was hoping to use my 
standard Web server (Cherokee) but it seems to have problems with bzr

> You can also use the server through ssh (the bzr+ssh: protocol), which
> has the advantage that ssh provides authentication. There the server
> will be automatically run in the directory you want.

I was going to use the built-in server to provide anonymous access for 
branches.  The SSH route I was going to use for contributors I trust. 
This is a great place for virtual machines.  You put your repository on 
the virtual machine, provide direct SSH access, and if anyone decides to 
be an ass, you nuke the virtual machine (assuming you kept proper 
backups), and start over.  Failing that, you need some sort of no shell 
ssh access that can run bzr.

Thanks again for your response.  For what it's worth here's the modules 
I currently have extracted from other projects of mine.

cookie_authentication

implementation of the model from: "dos and don'ts of client 
authentication on the Web". http://cookies.lcs.mit.edu   cookie recipe 
from section 4.1

portalocker

very simpleminded file locker from active states Python cookbook.  What 
I really needed was a systemwide semaphore.  What I say.  I was in a hurry.

dbm_utils

a wrapper around Python DBM methods.  Very simpleminded, locks on write.

postfix_transport

read the postfix transport file and for a given e-mail address, return 
the destination host.

union_config

supplies union of a set of configuration files.

file_queue

persistent queue built on top of the file system.  entries have state 
and are retrieved by state and order.

multi_auth

authenticate via one of multiple means.  Currently supports IMAP, 
system, and built-in authentication sources.  there are probably better 
methods of doing this but it's evolved over the past four years and it's 
real simple to use.