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

[Jari Aalto]

John Arbash Meinel <john at arbash-meinel.com> writes:
>> The idea behind this is to separate publishable files from the
>> developers own files which still need to be versioned properly:
>> 
>>     $ bzr add file.c file.h Makefile                [1]
>>       ...
>> 
>>     $ bzr root=.bzr-dev add mychecker.sh scp.sh     [2]
>>       ...
>> 
>> When it comes time to publish, only the [1] is pushed to the server
>> and the developer continues to have [2] in his private space. Those
>> might be programs that help him in his work, but which are not
>> genrally useful to anyone else outside of his environment.
>
> This is an interesting concept, which has come up in the past. Basically
> you could look at this as an "overlay" of 2 branches into the same data.
> The previous use case was for versioning /etc. Where you want separate
> branches for some of the files, even though they live in the same location.

I actually have to do this quite a much, so this is real working
situation for several projects. The way I do it now is to overlay
different VCS to get same effect (bzr+svn mostly, also , bzr+hg would
work), but this is unoptimal situation and I'd like to use bzr alone.

> 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.

> Now, if the to-publish branch is always a subset of the development
> branch, you can actually set up bzr so that it does one-way merging
> quite intelligently with a subset of files present.
>
> Basically if you do:
>
> $ cd $project
> $ bzr branch dev release
> $ cd pub
> $ rm X Y Z  *.c *.h
> $ bzr rm X Y Z *.c *.h
> # In the future this is bzr rm --force to unversion and delete the
> actual files)
> $ bzr commit -m "Remove unwanted developer files in the pub version."
>
> At this point, when updates are made to the $dev branch, you can
> $ cd pub; bzr merge ../dev
>
> There will probably be a couple conflicts where files modified in the
> dev branch show up as deleted in the published branch. But they
> shouldn't be very hard to resolve. In my testing it versions a foo.OTHER
> file, and marks a conflict for 'foo'.
> This is not necessarily optimal, but you can do something like:
>
> $ for x in `find . -name *.OTHER`; do bzr rm $x; bzr resolve
> ${x%.OTHER}; rm $x; done
>
> 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.

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