A minimalist different flavor aproach

Please read my previous entry Going a little bit deeper before reading this one

I've considered the "Team-of-one" entry on Accurev's blog and I haven't liked a couple of points. These points are more related to Accurev itself than to the "Team-of-one" model:

1. 1. I do not like much using the trick of the Change Palette for promoting over a Snapshot. If I cannot promote into a Snapshot but I need to promote over it, then I can say that the considered Snapshot is not placed correctly on the chart.
   The chart has a logic and the change palette breaks that logic... IMHO the Change Palette would be to Accurev what the GOTO was to BASIC...
2. 2. There are 3 kinds of locks and all of them are represented just with the same icon... I think every stream has to represent "graphically" how it behaves considering Promotion & Inheritance... just a glance should tell us everything about the stream chart flow..

Taking into account the above points here is what I consider a slightly different approach.


The pictured development process is as follows (annotated as steps 1-12 on the pic)

1. 1. After installing Accurev we create our first Depot [Root] and our first Workspace [Workspace]. the Workspace is used to "develop" project XXX keeping the private versioning on it. This case only considers one programmer but it could be easily extended to a multi-developer environment adding more workspaces owned by the different developers.
   
2. 2. When we consider our development mature enough for "testing" we create [XXX_n_Test] where the testing takes place.
3. 3. Some times when coding for version N, code ideas for a future version N+1 come up, instead of writing them on a file or peace of paper we include them in our Accurev development process model. [XXX_n+1_Test]
4. 4. [XXX_n+1_Test] does not allow Inheritance avoiding conflicts with version N. Promotion is required when the code from version N+1 has to be integrated to the main line of development. This promotion will involve a Merge where just the specific version N+1 code will get to the main line.
   
5. 5. The root stream [Root] is the cornerstone where every project development process chart begins. It does not allow promotion from downstream. Different project (YYY, WWW etc) charts begin from [Root] and co-exists with project XXX chart.
   
6. 6. When version N tests are finished the project files have to be promoted to [Main XXX]
7. 7. When version 1.00 is ready to be built we create [XXX_1.X_Mant] where the "Maintenance" of versions 1.X is going to be done.
   This stream does not allow inheritance from upstream. As this stream do allow promotion from downstream the services of the old snapshot used on the "Team of one Pattern" (4), the associated downstream maintenance stream (5), and the services of the Change Palette will not be necessary anymore.
   Creating a snapshot [XXX_1.0] and moving the [Workspace] behind it we will be able to build the project XXX v1.0
   
8. 8. Locating the workspace behind [XXX_1.X_Mant] we are able to perform the v 1.X maintenance and to naturally propagate those changes upstreams.
   
9. 9. The XXX project continues advancing using the main line [Main XXX]--[XXX_n_Test]--[Workspace], when XXX v2.0 is ready we repeat the process creating [XXX_2.X_Mant]
10. 10. It shows the snapshot for version 1.2 [XXX_1.2]
11. 11. It shows the snapshot for version 2.0 [XXX_2.0]
12. 12. The XXX project continues moving forward repeating the same pattern and the [Workspace] is now ready to build the project XXX v3.0 for delivery.

The solution to both of my concerns implies the change of the stream icons and the implementation of a new type of stream (the one circled in red and blue on the diagram). I'd like to get some feedback on this just to see if these mods are considered necessary for other Acurrev users and also to check for the onset of any unconsidered negative side-effect on this model.