4 messages in com.perforce.perforce-userDepot directory layout (main, release...| From | Sent On | Attachments |
|---|---|---|
| Rick...@vsl.com | 01 Jul 1999 23:24 | |
| Step...@vance.com | 03 Jul 1999 14:55 | |
| Rick...@vsl.com | 03 Jul 1999 15:45 | |
| Step...@vance.com | 04 Jul 1999 12:52 |
| Subject: | Depot directory layout (main, releases, dev branches) |
|---|---|
| From: | Step...@vance.com (Step...@vance.com) |
| Date: | 07/03/1999 02:55:54 PM |
| List: | com.perforce.perforce-user |
Rick Macdonald wrote:
We're just ramping up with Perforce. I'm wondering what's a reasonable convention for laying out the directory structure of the depot.
Say we have multiple software products, some absolutely separate but others share libraries, header files, etc.
Is this layout below reasonable? The "sage" system is shown expanded for the mainline, release branches and development branches. The "tango" and other systems aren't detailed, but would be similar.
The examples that I find in the Perforce manuals and examples are "flatter". For example, //dev/sage would be the mainline and //dev/rel_42 would be release #42. I'm wondering why not use a "deeper" directory structure?
//dev/tango - the "tango" system //dev/sage - the "sage" system //dev/sage/src - the sage mainline //dev/sage/src/act - the sage act package ... - there are 120+ sage packages //dev/sage/src/zon - the sage zon package //dev/sage/rel - release branches //dev/sage/rel/rel_42 //dev/sage/rel/rel_42/act - 120+ packages //dev/sage/rel/rel_42.1 - bugfix branch from rel_42 //dev/sage/dev - development branches //dev/sage/dev/erniep - a bunch of Ernie's branches under here //dev/sage/dev/rickm - a bunch of RickM's branches under here //dev/sage/dev/horizon_project - Wayne's and Todd's horizon project
An alternative for bugfix branches:
//dev/sage/rel/rel_42/0 - initial release 42 (42.0) //dev/sage/rel/rel_42/0/act - 120+ packages //dev/sage/rel/rel_42/1 - 42.1 bugfix branch from rel_42/0
...RickM...
There's nothing wrong with a "deeper" directory structure, except that it often implies unnecessary complexity.
Here are a couple other issues to consider:
Your path name should also indicate a "main" or "trunk" branch. For example, you have //dev/sage/dev with some specific branches underneath it. Where is the mainline for development? You should have a //dev/sage/dev/main or something of the sort to hold your mainline. (I may not fully understand your structure. The relationships between the various branches and directory trees is not completely spelled out above.) Directory structures of equal depth will make branch and directory management easier in the long run.
You somehow need to reconcile the global namespace of branch names with the directory namespace. Branch names are shared across all projects, but directory names are scoped to their parent directory. If your branch spec name and your directory name have some correlation, as they probably should, you need to reconcile their scopes. This is a strong motivation for putting branch directories toward the top of the directory tree, as it pushes the branch directory naming as close to the global scope of branch spec naming as possible. However, if you push it to high you lose the multiple project segregation you wish to achieve. These are the two competing tensions in deciding the level at which you want to branch in the directory structure.
I hope this helps somewhat.
--- ======================================================================= Stephen Vance | mailto:steve at vance.com | http://www.vance.com =======================================================================
A computer programmer is a machine for turning coffee into programs. --- Paraphrase of the late mathematician Paul Erdo"s