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.

Going a little bit deeper

After founding the "Team of one" post I've started moving forward faster...
At the same time I began to consider the differences among the several types of streams and its uses.... There is no a guide saying, OK this is the best way of using the different types of streams for building your chart... It's like when building a house, we know that bricks are for walls, roof tiles are for the roof etc... even when you are free to use bricks on the roof nobody does that....

Trying to understand the different type of streams I've noticed they are basically differentiated upon Promotion & Inheritance handling. Every stream can:

• a) Allow promotion from downstream
• b) Deny promotion from downstream
• c) Allow promotion to upstream
• d) Deny promotion to upstream
• e) Allow inheritance from upstream
• f) Deny inheritance from upstream
• g) Allow inheritance to downstream
• h) Deny inheritance to downstream

Mathematically there are 2^4=16 different possible types of streams even when not all of them are used/implemented by Accurev today.

i.e.
A Dynamic Stream would be a Stream that verifies a & c & e & g
A Snapshot would be a Stream that verifies b & d & f & g
A Workspace would be a Stream that verifies b & c & e & h
etc

A problem I've saw using the Stream Browser was that the different streams do not graphically display on the chart how they behave considering Promotion and Inheritance. Then I've started wondering if probably a stream shouldn't look closer to something like this...

The last stream on the pic is not currently implemented in Accurev but I consider it would be useful as we'll see on the next entry...

From walls to a little house...

Ok, in the previous entry (Stream flow) we saw a very interesting set of rules among blocks or Streams, Workspaces, connection among them etc etc etc.... so... what can we do with all of this??

The best answer I've got to this question is this minimalist example. The best and only complete simple example, don't look anywhere else...
Team of One Pattern
It deserves to be red many times until it's fully understood.

Stream flow

In order to work with streams there's a handy GUI tool called Stream Browser which, at the moment of writing this, has not an user manual but it's well worthy the effort of learning it just reading its help. Personally I consider this tool the soul of Accurev.

When I first started with the tool I was trying desperately to understand if the X and Y axises of the chart where the streams are located and connected to each other, had some meaning... probably time or some other magnitude. I couldn't find a written answer to this.
I finally came to understand that within the stream chart the Y axis helps to:
1-Differentiate among several projects
2-Differentiate equivalent areas within a project with different versioning status.
In the other hand the X axis talks about the Upstream if we move to the left and the Downstream if we move to the right. Those movements involve two new Accurev key concepts. Promotion and Inheritance.

I'd like to mention a couple of sources for understanding Stream Flow
Stream-Based Architecture of SCM
Understanding-accurev-stream-inheritance-the-short-version
Even when it takes some time getting the idea behind streams it is well worthy the effort...

At this point I can mention some key point that helped me to get the picture so far...

1. After installing Accurev we create a Depot and the first Workspace; the Depot is represented for a "root stream"on the left of the chart and right to its right we found the connected Workspace Stream; just 2 blocks connected by a segment.
2. Workspaces are the only streams that have the ability to interact with the real directory where the Project files we want to put under versioning control reside. Workspaces are the gateways between the Accurev versioning control world and the Project real files.
3. Our work in a project is performed over the project source files, we tell to the OS to "save" those files when we consider we've got something that deserves to be kept... in a similar way we tell to the related Accurev Workspace to perform a "keep" command to keep under the Workspace control the new set of modified files.... The OS save command "overwrites" the previous version, the Workspace keep command "adds" a new version keeping the former one.
4. Workspaces have an owner; a programmer. Many programmers can be assigned to work on the same project set of files, but every workspace keeps every programmer's work "private" as long as this work resides on the Workspace.
5. When programmer's work reach a certain maturity point can be "promoted" to a higher hierarchy stream (upstream) using the "promote" command. After doing this the programmers work becomes public to the programmers community following the rules of promotion & inheritance.

The basics rules of Stream flow.
Promotion casts the programmer work upstream while Inheritance bring it back downstream.
A stream con only have one stream upstream but many ones downstream.
A Root stream cannot have any upstream stream.
A Workspace cannot have any downstream stream.

From bricks to walls...

After dealing with the stream concept a lot of doubts immediately showed up...

1. How real files in my computer become elements of a stream?
   Here Accurev created the concept of Workspace that is really a special stream that has an association with a folder where the files we want to put under versioning control reside.
2. That means I have to put all my files on the same directory for versioning control?
   No no, we can create many Workspaces, let say a Workspace per project in every member's team PC.
   
3. Where are the elements really stored?
   The Depot. The Depot is an Accurev proprietary database where all the files and its different versions plus the versioning control meta data are kept. When we install Accurev we define a physical location for this database.
4. Well, then the streams do not keep the files on them?
   Not really, streams are not file directories. They are just an element of a map that represent our software development process...
5. How can I build that map with streams?
   Big question, at this point I've got stucked with Accurev documentation...
   The thing is to represent with streams the flow of our software development process... let say for Project X we might have an Integration stream where several programmers are putting together a first version. When the project is ready for testing we might want to do this in a Testing stream. After testing we release using a different stream, and finally we maintain in a maintenance stream... Yes I know, it sounds so simple but...
6. Probably is time to know how the flow among those streams is...
   It comes next entry.
   

Streams... Streams... Streams...

Kind of a myth; they are famous for being not so easy to understand but it wasn't my hardest issue with Accurev...
The Accurev Concepts Manual defines a stream as "a configuration of the depot that changes over time" well it didn't really say much to me when I first red it

Now I like to think of streams as "hierarchical blocks for holding elements (files) subject to versioning control" depicting a bit the thing

1. Blocks: We label them, We define the criteria for the equivalent class to which the Block's elements belong.
   
2. Hierarchical: There are factors that define a hierarchy among those blocks, there are predecessors and successors.
3. Elements: the blocks hold "elements" (actually references to them)
4. Subject to versioning control: the elements of a particular block evolve with time, the information of that evolution is kept always available within the block.