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

[John Arbash Meinel]

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

Jari Aalto wrote:
...

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


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.

IIRC, it was brought up on both the git and bzr mailing lists
simultaneously. And I'm pretty sure the end result was that it just
added confusion, rather than helpfulness. For '/etc', at least, it was
felt that keeping real separate branches, and then just symlinking the
files into there was a better solution.

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.

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.

Another possibility would be to have export filters. So when you do "bzr
export --filter=public.filter /path/to/public" then it could create a
directory with only specific files. 'bzr export' doesn't generate a
target branch, though. (And I kind of like the idea of even the
published tree being a bzr branch, since it makes it easier to know
exactly what version is being published)

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

iD8DBQFF9YMHJdeBCYSNAAMRAreVAKDIi4CygYu6wwNvyez+PixX12SxLACgnChg
7oy5FTWeLwyxRTtNbDvIryo=
=4mbb
-----END PGP SIGNATURE-----