[MERGE] bzr-dir phase 2

Erik Bågfors zindar at gmail.com
Mon Feb 13 00:11:07 GMT 2006


2006/2/13, Robert Collins <robertc at robertcollins.net>:
> On Sun, 2006-02-12 at 17:01 -0600, John A Meinel wrote:
> > Robert Collins wrote:
> > > On Sun, 2006-02-12 at 16:42 -0600, John Arbash Meinel wrote:
> > >>
> > >> Right, but the api shouldn't be that sprout() creates a standalone
> > >> should it? If format 4,5,6 all only support that, I'm okay with it.
> > >> But
> > >> we want an api that doesn't changed when we get repositories.
> > >
> > > bzrdir formats 5,6,7 all create standalone trees when you sprout. Format
> > > 4 is readonly these days.
> > >
> > > With repositories, the sprout routine will be modified to use a
> > > repository for storage if one exists. As for working tree initialisation
> > > at the same time, I think we can talk about it. This api will be in the
> > > same release as repositories - 0.8 - so I'm happy with it being fluid
> > > until then.
> >
> > So how do you sprout from a remote repository to either A) a local
> > standalone branch (I don't want to commit to your read-only repository),
> > or B) a local repository (so I can save space on my laptop).
>
> A) bzr branch REMOTEBRANCH LOCALBRANCH
> B) bzr branch REMOTEBRANCH LOCALBRANCHINSIDEYOURREPOSITORY

I love this!

> > > What I had envisioned is a keyword to sprout to force on or off the use
> > > of an existing repository, and likewise for the creation of a working
> > > tree. (It -has- to create a branch always.). On SFTP for instance it
> > > will quietly not create a working tree. And I'd like a repository flag
> > > to control default creation of working trees - I can see having a
> > > repository at ~/source/baz for all my bzr work and I will want working
> > > trees much of the time. I'd also like a command to nuke a working tree
> > > but leave the branch intact. But thats separate.
> > >
> > > Rob
> > >
> >
> > We definitely need to figure out the ui for these sorts of things. And I
> > think that will help us understand what the api needs to be.
>
> Sure.
>
> What I am proposing is a policy knob inside the repository called
> 'default-no-workingtree' or some such.
>
> samples:
> bzr repository --create REPO
> cd REPO
> bzr branch REMOTE brancha
>
> This will consult the repo (at '.' in this case) and create brancha with
> a working tree. This is the default behaviour and thus consistent with
> the behaviour when using standalone branches : you get a working tree.
>
>
> bzr repository --create REPO --no-working-trees
> cd REPO
> bzr branch REMOTE brancha
>
> This will consult the repository and see that the policy knob is set,
> and will now create just brancha/.bzr/branch/*
>
>
> bzr repository --create REPO --no-working-trees
> cd REPO
> bzr branch --with-working-tree REMOTE brancha
>
> Will force the tree on
>
>
> bzr repository --create REPO
> cd REPO
> bzr branch --no-working-tree REMOTE brancha
>
> Will force the tree off.


I'm confused, do we really want a working tree within a repository??

For me a repository is a magic box where I put all my branches, to
access any data in it, I need to checkout.

Until this message I had never thought of the idea to have working
trees inside repositories, but maybe I see the point now.

Does this mean that I could go to my ~/src directory, create a repo
there (bzr repository --create ~/src ?) and then whenever I run bzr
init or bzr branch inside it, it goes into the repository?

Then I'm starting to see the point of it :)

Regards,
Erik - full os stupid questions




More information about the bazaar mailing list