| Date: | 2009-11-26 |
|---|---|
| Version: | 0.5 (dev) |
| Implemented: | Partially |
UPDATE: Plain workspace choosen as default. Furthermore: support for boxed workspace will be removed at all. This is the final decision.
Project workspace is the area where component working trees are recreated to work on the whole project.
There is 2 main variants of managing components branches/trees in the workspace:
- plain environment (simple, should be default)
- boxed environment (recommended way for scmproj)
What:
- Every component branch is checked out directly in the project workspace
- Internal depot is not used at all
Why:
- In this environment the scmproj is only light helper that glues together several branches and allows the user to work on the set of branches at once
- This is most simple way to work with simple projects
Pros:
- Simple machinery, so people should easy grok the idea
- User can easily select the preferred workflow: standalone branches, bound branches (aka [fullweight] checkouts), stacked branches etc.
- Removing .scmproj control dir (by accident or by intent) does not break actual working branches, i.e. user won't lose his local commits
Cons:
- We can't support alts/subsets idiom in the plain environment without using colocated branches
What:
- All component branches (without trees) stored in the internal depot inside control dir.
- Working tree of each component is actually lightweight checkout of the corresponding branch in the depot.
Why:
We want to emulate multiple branches in one location idiom, i.e. git-style branches, so we can support multiple alts of the project and we can support local short-lived feature branches as well.
XXX: this emulation layer may become obsolete when colocated branches support will appear in bzrlib itself
Therefore we make the control project dir the "thing in itself": user can carry only .scmproj as complete "repo" of the project.
Pros:
- having local copy in the internal depot will allow us to implement switch between alts and subsets, and even custom subsets to provide very flexible reconfiguration of component on the fly.
Cons:
- some people don't like lightweight checkouts
- complex internal machinery
- we have to manage some sort of garbage collection for internal depot
- to make boxed workspace movable across filesystem we need to use relative paths in branch references. Unfortunately the bug #330086 completely prevents this. (https://bugs.launchpad.net/bzr/+bug/330086)
Choice of environment variant should be done at the project-get stage. User should specify his preferences, and in the future we support only selected way (internal actions will be adjusted to the selected environment when needed).
The selected variant will be saved in local config (see ScmProj/NewLocalCfg) as scmproj_workspace variable. Possible values: boxed, plain.
Because we're using user options to save this sort of info, it's possible to setup the default value for all (or some) projects by specifying scmproj_workspace option in the main bazaar.conf or locations.conf.
Reconfigure environment is possible in the case plain->boxed, but may become tricky in the reverse direction. Today this should not be the essential problem.
Additionally we can automatically select plain/boxed based on the content of project.cfg: if there is alts defined then we need boxed, otherwise we can stick with plain one. As I wrote above the transition plain->boxed is straightworward, so we user can "upgrade" project workspace when he will need the boxed features.
XXX: auto-configure seems very sensible option.
User should be able to work with boxed branches inside local depot, so we need to provide proper UI. Although our constructor pcmd can help here, but we think we need to provide special command ''project-manage (pmng)'' to update/pull/push/create/delete boxed branches in the depot.