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

[Aaron Bentley]

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

Jari Aalto wrote:
> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
>> 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.

That is true, but you should understand that we want Bazaar to be a joy
to use.  Even if we addopted your suggestion exactly, I would not
consider that workflow to be joyful.  Perhaps you would remember which
files were versioned under which regime, but I doubt anyone else could
figure out how it worked.

If you have files intermixed that require differing versioning regimes,
it seems to me that your files are disorganized.  Organizing them into
directories will help anyone else who tries to understand your project,
including Bazaar.

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

Sure it did.  It meant that "repository" in Bazaar doesn't mean the same
thing as it does in Darcs, Mercurial, and other distributed systems.
That hurts comprehension.

In fact, you misused the term "repository" in your initial email:  "I'd
like to propose an option --root which would specify the location of the
root directry of the repository".  Since all the repository does is
store revisions, moving the location of the repository would not have
the effect you desire.  What you want to move is the location of the
(working tree) control directory.

Introducing a centralized model also introduced new commands that
sometimes confuse new users.

It also took time away from other features.

Features always have a cost.  An initial cost of development and an
ongoing cost to maintain.  In the case of lock-step development, I
pushed for the feature, and I'm pushing for nested-trees now.  But the
benefits of any potential feature must show that its benefits outweigh
its costs.

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

As Robert noted, there are other VCSes that do support this, notably
git.  Git is a very hackish system, so it does not surprise me that they
do this.  Bazaar does not want to emulate git's hackishness.

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

Working trees are mostly opened with WorkingTree.open_containing(path)
and WorkingTree.open(path).  What you are suggesting would require
changing every command.  This is because many commands operate on more
than one control directory at a time, but they should only apply your
- --root option to one of the control directories that they open.  Only
the command that invokes WorkingTree.open can know which directory that is.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+qd90F+nu1YWqI0RAs4xAJ9IxbsFOLxeFyTxC8JLLT2ahgij8wCfRw/S
TtHf3ZXZMpl3KwwSVlsXfHk=
=FOBI
-----END PGP SIGNATURE-----