David Jeske writes:

Agreed on both counts! Having a handy & up-to-date graphical depiction of the system-wide branch tree. However the fact that it is the depot's "directory" tree might actually be a help here (to a certain extent). I think there are some tools that will visually depict a directory tree for you, so that could help you here. Problem is you need to be able to tell it along each path, when the "components" in the path stop corresponding to version branches and start corresponding system directory structure.

But I think having the system element namespace/hierarchy be subordinate to the version branching namespace/hierarchy is one of the few things I don't care for in P4's inter-file branching model. I like that the branching topology is uniform for all elements, but I wish could view the directory-path and the branch-path independent from one another.

ClearCase lets these vary independently, but the version tree structure may be non-uniform between elements. If you want to make it uniform, you can, but it requires some extra effort and a few simple conventions. As for getting a visual tree, you can do that for individual element in ClearCase, but not the project as a whole. If you follow the aforementioned "conventions" you can go to the work of maintaining an extra file whose version tree matches that of the project, and then view the system/project-wide version tree that way. If P4 had a vtree-viewer, it would be system wide, and a much more powerful view (IMHO of course).

I realize that making the branch-hierarchy orthogonal from the directory-hierarchy adds some more implementation problems into the mix. Part of the elegance of P4s IFB implementation is that by mapping them both to directory-structure space and making one subordinate to the other, these problems seem to magically go away. But it also constrains you with this significant subordinate dependency of one upon the other that I'd rather not have. I'd be willing to go to the trouble of having a client-spec that could map files and/or directories and/or directory trees of the depot to specific branches.

Versioning the view-specs (or least the ability to do so) is also a good idea, and is something a lot of ClearCase users keep asking for from Rational. Some of them fake it by using something separate (like RCS or SCCS) to version control it in a separate space, while others simply go to the trouble of remembering to copy it into a versioned file in the depot that is checked in/out like everything else. They make a "view" directory, or a "view" depot (or both) for this purpose. Its not perfect, but its a start.

Cheers!

--- Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/ "And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng