8
Branching schemes are very inflexible and changing them breaks the ability to
9
use the repository since they are embedded in the generated revision ids. It
10
should be possible to get rid of branching schemes but there are a couple of
11
properties of it that should still be usable.
13
When searching for revision ids, we need to search a limited set of paths in
14
the repository for branch properties.
16
When importing a branch, we need to import the relevant tags so we need
17
to know where to find them.
19
In order to push right hand side history into Bazaar, it should be
20
possible to create new branches inside the repository automatically.
22
Since there may be more than one project in a repository and it can be
23
very inefficient to have to browse the full repository it will be useful
24
to be able to restrict the paths searched on a per-project basis.
28
It should be possible to specify the repository layout locally as the user
29
may only have read-only access to the repository. It should be possible to
30
set the layout globally as well, inside of the repository, so it is possible
31
to use the repository and just have it work.
33
If repository layout is known, one should be guess - similar to the way
34
that is currently being done for branching schemes.
38
In order to deal with this information, we need to keep a list of branches
41
Backwards compatibility
42
-----------------------
43
Branching schemes should be derivable from the repository layout.
47
A new class RepositoryLayout will be created that can manage a list of
48
branch paths, tags paths and locations to add new tags or branches.
added
removed
specs/layout.txt
