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

[Jari Aalto]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:
>> Jari Aalto wrote:
> If you can set up your directories so that each owner controls a
> different subdirectory, then you can use nested-by-reference trees for
> this, e.g.
>
> /project/ <- containing tree
> /project/developer <- subtree
> /project/publish <- subtree
>
> With this set-up, commits in /project will also affect /project/publish
> and /project/developer, but you can "publish" /project/publish separately.

That's a good setup, but approaches the "problem" from project
management point of view. It means restructuring the workflow to
accomodate the bzr's.

>> What do you think about generalizing the bzr enought to accomodate any
>> ROOT and any user setting?
>
> I'm not in favour of it.

I'm asking to consider the direction bzr is moving. At this point of
development -- although bzr has got very good set of features -- the
cost of change will double as the code base and features increaser.


DIRRENT "VIEWS" TO THE PROJECT (or "overlays")
----------------------------------------------

Think it form this perspective. The bzr quickly added CVS/SVN style
central-cehkout support, because that was the typical workflow of
group projects, where code needed to be at authoprative place. This did
not hinder the use of the initial distributed model at all.

In here, I'm temptated to see that bzr has niche to conquer are that
no other VCS system has not foreseen:

* several "views" to project.

With th view here, I'm referring to SQL language "CREATE VIEW", which
-- using the underlying tables -- contructs new presentatyion of the
data that is transparent to the user.

  Perron A / has role A

       * Sees data from model X

  Person B / has also role A

       * Want's to see model X

 Person C / has role A and B
       
       * Manages both X and Y models

INTERCHANGEABLE VIEW (selecting the effective ~/.bzr etc.)
----------------------------------------------------------

Since bzr hands the underlying security model to the operating systm
(file permissions), it would be possible to restrict access to the
separate parts of the project through the models.

And with the model implementation I refer to the concept, where the
repository (is that the correct term?) is user defineable:

    --root=.bzr

The metadata associated with the repository is stores in there and not
hard coded into places. Like, that there is central ~/.bazaar. Instead:

     bzr config user-init ~/.bazaar

Would sore this metadata information under (fictional file):

      ~/.bzr/admin/user-init

This in effect would allow making all places configurable and thus
enabling rolocation of the ROOT of repository (~/.bzr)

TECHNICAL CHALLENGES?
---------------------

I can't know if this is even possible, but I hope to live to trust
that the bzr code has designed very well, so that any hard coded
locations would be easily tracked down and converted into using some
"class" that provided the metadata locations after it wa initialized
from "--root" (if supplied; defaults to ~/.bzr)

Jari