RFC: default to creating a repository directory during branch/init.

Eduardo O. Padoan eduardo.padoan at gmail.com
Wed Apr 8 13:36:58 BST 2009


On Wed, Apr 8, 2009 at 8:29 AM, Robert Collins
<robert.collins at canonical.com> wrote:
> Currently, one of the major usability problems we have is that it is
> hard to setup an efficient work area for large C style programs - that
> is one where you switch between branches rather than just making a new
> branch on disk.
>
> We explicitly create branches for:
>  - init
>  - branch
>
> and implicitly for:
>  - push
>  - export-loom
>
> If we changed 'bzr init foo' to create a shared repository automatically
> when one isn't present - like so:
> $ls
>
> $ bzr init foo
> $ ls -a foo
> .
> ..
> .bzr
> trunk/
>
> And similarly for branch
> $ bzr branch http://bazaar-vcs.org/bzr/bzr.dev
> $ ls
> bzr
> $ ls -a bzr
> .
> ..
> .bzr
> bzr.dev
>
> push should do the same thing.
>
> When branches are being made stacked, it shouldn't make a shared
> repository to meet the current constraints and logic on reusing shared
> repositories.
>
> Possible caveats:
> 'version /etc' and other use cases require initing a branch on an
> existing directory. I propose to meet this by saying that when init
> finds an existing directory, it create it inline like it does today.
>
> This approach changes the UI for init/branch/push. But it also fixes
> some bugs: people wanting a shared repo don't know what format to
> create, creating a repo is non-trivial.

My 2¢: Why not make this behavior explicit, adding a
--create-shared-repo option to this commands?
I don't think that everyone would want their ~/Development directory
to become a shared repository, and those who want could add this as
default with aliases.


> There are other approaches we could take, such as colocated branches. I
> see this as a reasonable thing to do that does not preclude such steps
> being taken later.

Colocated branches also make some workspace setup simpler, by hiding
all branches that aren't your focus at the moment, and would make some
hg/git fans a bit more happy. This may be a better solution, IMHO, but
it don't need to exclude the feature you suggested here, that could be
better for people like me that is more used to the bzr-style of
one-directory-per-branch.


> -Rob
>



-- 
    Eduardo de Oliveira Padoan
http://importskynet.blogspot.com
http://djangopeople.net/edcrypt/

"Distrust those in whom the desire to punish is strong."
   -- Goethe, Nietzsche, Dostoevsky



More information about the bazaar mailing list