question about bzr model of shared repository
John Arbash Meinel
john at arbash-meinel.com
Fri May 4 18:14:00 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Aaron Bentley wrote:
> Alexander Belchenko wrote:
>>> I wonder why in case of shared repository branches always
>>> should be created inside the shared repository?
> Because we want to be able to find all the branches that refer to the
> data in the shared repository.
> We want to be able to do garbage collection. We can't do that unless we
> know which revisions are in use. We don't know that unless we know what
> all the branches are that refer to the repository.
>>> What I missing here? Probably it's better (to me) to read about
>>> main assumptions and limitations of bzr model, does such document exists?
>>> 'cbranch' command looks too complex for me.
> Perhaps you should just make your home directory a shared repository.
> That's what everyone else seems to do, rather than trying to make
> treeless repos work smoothly. Not that I'm bitter or anything.
Well, I don't make my Home dir, but I do have one for all my
project-level directories. (dev/bzr, dev/project1, etc).
I also use a treeless remote repository on my server. I can't say for
sure how Robert and Martin work, but I don't think they use checkouts as
much as I do. (I use heavy checkouts, you use lightweight ones). I
believe David Allouche also works in a similar fashion to you.
I do use cbranch a lot. Everytime I create a new bugfix branch. It
doesn't fit my use case 100%, though, because I create branches in
subdirectories, so whenever I create a new working subdir, I have to
edit ~/.bazaar/locations.conf to let cbranch know where to put things.
Since my subdirs are based on bzr releases, that means I do it about
1/month. Which is reasonable enough that I don't worry about it. (It
means I have to do it on the 4 different machines I work on, but still,
The primary alternative (to me) instead of cbranch would be to have
shortcut location aliases (bzr branch %repo/branch1 %repo/branch2).
However, my workflow is also a little bit weird, in that my 'bzr.dev'
branch is in a different repository from all of my personal branches.
(It is in my mirrors/ repository which is automatically updated 2x per day).
I suppose if we had really useful within-one-repo commands, I would
switch and move my bzr.dev mirror into that repository.
For some projects, I also have difficulties with cbranch, because my
working layout is different than the repository layout.
Specifically, on the repository we have:
But locally I use:
Because I want the full name to be included in the branch nick when I
I also think that having a local shared repository with working trees
"just works", rather than dealing with a tree-less local repository, and
then lightweight checkouts, and then another remote treeless repository.
I believe you (Aaron) use rsync to move your local repo to the public
location. But I've been feeling "rsync doesn't touch my bzr branches"
for a while now, since it doesn't copy knits in a safe manner. (^C can
break referential integrity).
>>> I'm still don't understand policies, and in most cases
>>> I think I don't need them. Moreover, when I move repo/branch
>>> over filesystem I need to modify configuration file accordingly,
> Not if you use policies.
I do find policies useful. It works really well for my "bzr-email"
settings, so that everything in ~/dev/bzr sends an email to commits, but
things in ~/dev/home or ~/dev/personal do not.
Alexander- if you find them confusing, perhaps we just need to work on
documenting them to make them more obvious (we almost definitely need to
do that anyway).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar