Comment 5 for bug 631611

Maybe I can add a usage case to help you judge what is appropriate behaviour.

There seems to be an implicit assumption amongst bzr develpers that a development environment and a target production environment are the same thing. e.g. usernames, packages, paths etc. are common.

In our case they aren't.

We mainly write perl code, with a fair bit of MySQL, java, javascript etc. thrown in.

All of these language are portable and can run on either Linux or Windows or MAC OS X whatever.

BZR is an ideal choice for us (thanks) because
1) it is cross platform
2) it allows local repositories to support a truly distributed development
3) it is very efficient
4) it allows extensive branch and merge for maintaining multiple customer specific versions of code
5) it allows secure transports into customer environments.

5) is becoming pretty important for us: we actually don't just use bzr for code development, but also for code distribution and installation.

That isn't unique by any means. Bugzilla do pretty much the same now.

It makes software version upgrades a snap. You just do a bzr update to get the latest perl code on the target machine from the central repository, and then run a local (perl) installer script to update local DB tables etc. as appropriate: no more tarballs or installers or package managers. You could even consider using a crontab to automate this sort of upgrade, or trigger it via a cgi script if you're brave enough.

So that assumption about dev and production being even vaguely similar is quite dangerous for us. The target customer environment generally isn't much under our control, so there could be all sorts of openssh implementations installed on the target production machine (either used for other purposes, or as a hosted webserver.) The usernames are almost always completely different too. And the way of setting up the SSH transport to the central repository is invariably different (sometimes direct SSH, sometimes via a putty plink tunnel, sometimes via http, sometimes via a proxy server etc. etc.)

That's our motivation for having a "stand-alone" bzr installer. We'd like to be able to set up the bzr transport connection to our central repository separately from other code packages that may do other things in the produciton environment (like synch databases or data files to other customer machines in the production environment using e.g. cygwin /rsynch).