question about bzr model of shared repository

[John Arbash Meinel]

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

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,
not terrible).

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:

  repo/
    dev/
      0.7-foobar

But locally I use:

  $working/
    dev-0.7-foobar

Because I want the full name to be included in the branch nick when I
commit.



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

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

John
=:->

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

iD8DBQFGO2nYJdeBCYSNAAMRAiFTAJ9PAL2FbukZAbLjqCPC2WvOjWQEEwCdE0nj
KfGHct+xJMy1vl/QSPSXvyM=
=I5lD
-----END PGP SIGNATURE-----