Add global option --root=dir to specify location of .bzr

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jari Aalto wrote:
...

>> For your use case, I can see one minor issue, which is that .bzrignore
>> isn't parameterized by the .bzr/ directory, so you would be using the
>> same ignore list for both the development tree and then publishable
>> tree. Which you probably don't want.
> 
> Bzr would need a command to alters the state. All file locations and
> names would not be hard coded in the programs. Instead it would be
> possible to assign new values:
> 
>         bzr config bzrignore ".bzrignore-dev"
>         bzr config user-conf "~/.bazaar-dev"
> 
> The idea would be that the location of files were kept in state files
> under ROOT with pairs:
> 
>      key = value
> 
> Or whatever is appropriate internal representation.

I really think you are starting to get into a troublesome state, where
everything is suddenly being double-handled. So if you are working with
hat "developer" all the commands do something different than when you
are working with hat "release manager".

...

>> I could see automating this with a plugin, or even a different merge
>> algorithm. (bzr merge --subset, or bzr merge --ignore-deletes).
>>
>> How close does this get to what you are looking for.
> 
> Yes that would work. It however requires to set up similar structure
> for every current an ongoing project and doing rm+merge command +
> conflict resolution.


Well, either way you have to set it up 2 times. Whether that is an 'rm +
merge' cycle, or setting up 2 different branches.

I think we could make the conflict resolution a bit easier for you.
Which may be sufficient.

Also, remember that if you have 2 branches that don't know about
eachother, you can't really 'bzr merge' between them. You basically have
2 unrelated branches that coexist in the same location. (Notice how you
are doing it with bzr+svn or bzr+hg.)

It seems a lot more reasonable to be able to say "this is release
version XXX, which has the development bugfixes YYY, and ZZZ". (Make the
branches related, rather than completely independent).


> 
> What do you think about generalizing the bzr enought to accomodate any
> ROOT and any user setting? Would there be many hardwired things in the
> bzr source code that would be major obstacles to reach towards that
> direction?
> 
> Jari

There are things that could be done. If I was going to recommend a path
for you, it would be to write a plugin that overrides the defaults for
all of those internal constants based on some configuration value. So
when the plugin is loaded, it changes the '.bzr' control directory to
being a '.bzr-dev' control directory. And it monkey patches
'WorkingTree.is_ignored' to read a different file, etc.

It would be a lot of hacking for what I consider a misfeature. But if
you are really set on doing it, I can give you some pointers.

I really think having a 'dev' branch versus a 'pub' branch is the way to go.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9ZI8JdeBCYSNAAMRAlg8AKCjZMzBeNEz49lajHbwYwbcWFu4GwCgyT8N
8CsuPUIwlLu8mswk9zph4fI=
=VKY4
-----END PGP SIGNATURE-----