understanding shared repo and push

[Gavin Carr]

Hi Jake,

On Tue, Aug 01, 2006 at 01:30:48PM -0400, Davis, Jacob wrote:
> The method you describe is what I am used to with CVS/SVN, or any other VCS,
> when (in typical fashion) it is used by several users to make changes to a
> single set of files. 
>
> The way I'd like to use BZR is the other way around. I want a single user to
> make changes to many different sets of files on remote machines. Ideally I
> could do this without having to log into each machine individually to execute
> commands. I might accomplish this by various other means but it seems like BZR
> has some unique features that could make it useful for what I want. It would
> give me a sort of centralized approach to system configuration change
> management without having to figure out http://www.cfengine.org/ . And since
> BZR supports Windows it is (hopefully) also cross-platform.

I've been doing something similar to this with tla/bazaar for a while now, 
pushing via rsync. One variation I use is that I have a top-level all--etc
tree and then have separate host--etc branches off of that, so I can make
common changes at the top and have them inherited to individual hosts.

The main reason I aren't using bzr for this yet is permissions tracking, since
bzr only captures the execute bit at the moment, I believe, where tla/bazaar 
record all permissions and group ownership, I think. Are there any plans to 
broaden the metadata support in bzr? I realise it's not particularly
important for the development use case, but for configuration management it
can be quite important.

> I think I am mostly there. I init a repository on each client and add all the 
> files to it that I want to track.
>
> Then I check out each of the client repositories into my central shared 
> repository.
>
> I can then make all changes to the client files form the central repository
> and commit them, which will update the client repositories. I still need to
> execute "bzr update" on the clients for the working directory to update, which
> is not ideal, but I do have centralized tracking of changes and if the central
> server is ever unreachable I can still commit changes on the clients to their
> local repository and update the central server later.

You should also be aware that pull vs. push is a nice religious debate in the
configuration management community. Push is easier and more direct for small
setups, but pull seems to scale better and have better handling of transient 
errors (e.g. what happens if you push to all your machines and 2 of them are
offline?)

Cheers,
Gavin