This is something that’s been lingering in the back of my head for the last year or so. I think I am missing something in the sequence of [Branch, Repository, WorkingTree]. Here are some of the reasons why I think this is the case:
- Tags should ideally be shared amongst a set of related branches. This has come up often during discussions about where tags belong.
- Management of sets of bzr branches is hard
- It seems to make sense for the configuration of several plugins to be
project-specific:
- bzr-pqm-submit’s pqm address
- bzr-email target address
- bzr-cia’s project setting
- …
- may be useful to override whoami
- having a way to group branches allows mass-pushes/pulls
- It seems to make sense for the configuration of several plugins to be
project-specific:
- I often find that the public_location I set is almost the same for related branches, with only the last part of the url differing and containing the branch nick
- It would be nice if “bzr register-branch” could automatically determine what product to register as
I’m not looking for repositories: - repositories can contain data from multiple totally unrelated branches. a tag “1.0” could conflict because there are multiple unrelated projects that have it. - repositories are a storage optimization and I like them that way
although other projects (mercurial, git) seem to be using repositories to allow talking about a group of related branches.
I’m not looking for “just” directories: - There’s no place in a directory to store settings or tags - Having a long list of settings in ~/bazaar/locations.conf doesn’t scale and the settings won’t be able to propagate
Having another semantic object (”Product”?) on which options/tags can be set would help. Perhaps based on the root id (where available) ?
Currently Playing: Symphony X - The Odyssey
Go Top