Add global option --root=dir to specify location of .bzr
John Arbash Meinel
john at arbash-meinel.com
Mon Mar 12 17:47:40 GMT 2007
-----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-----
More information about the bazaar
mailing list