Since you employ the term Baseline, I will assume you are using UCM.
On a stream, you can not revert backward a baseline.
One possibility is to make a parallel stream, with the desired baseline as foundation: this is the quickest way.
After changes on this new stream, you can make a new rebase to change the foundation baseline, but only if that new rebase is using a more recent baseline from the parent stream (not an older baseline)
For your specific need, I would recommand a non-UCM snapshot view with a simple rule
element * thePreviousBaseline
In order for the developer to have:
- his/her current UCM view for development (always set on the LATEST of a branch associated to a stream)
- a second snasphot view set to whatever baseline he/she needs.
That second snapshot view is completely not-related to the UCM project and takes advantage of the "full" nature of the baseline (do check that your baseline has been put as "full", not "incremental". If it is "incremental", simply change its type and upgrade it to full)
So, beside your current snapshot UCM view, you can create anywhere you want a non-snasphot view:
cleartool mkview -snap -tag mylogin_myComponentname_csl_snap -vws myPathToViewStorage myPathToRootView
cd myPathToRootView
cleartool edcs
[add the selection rule: element * myOlderBaseline]
[add the load rule at the end: 'load /myVob_Including_MyComponent]
[save, type 'yes']
That is fine for consultation/execution, but if you need to patch (that i is to write, check out and in some files), then I would recommend one UCM stream per baseline to be patched.
That way, the stream clearly represents the patch effort for a given baseline. There should not be too many of them, unless you put into production a new version of your application every five minutes... which is not advisable ;)
So to summarize:
- the non-UCM snapshot view is unique and serve for a quick consultation/debug of one older baseline at a time.
- for patches (source modification), you create a parallel stream properly named, with the correct foundation baseline, and then a UCM view on it. You can not only debug but also fix some bugs in an activity, the deliver that activity to the main Int stream if that bug need to be retro-fitted on an higher stream.
(note: all bugs do not always need to be delivered: they can be obsolete when compared with the current state of the development)
B and C are based on different baselines of A. Is it ok to do merges between B and C in both directions from B to C and vice versa
What you are describing is called sideway merges and you can see (following the link) that they comes with a price: merges will likely be non-trivial at some point.
In your case, though, if B did not touch the files that were merged (with non-trivial resolution) from A to C, then merges from A to B should be trivial (simple copy of the version stored in A on top of the one in B)
By merging from V to B, you would include potential modifications from C which you would have to eliminate during that merge.
In a more general way, you can rebase/deliver in whatever order you want, but some workflow can be rigged to produced non-trivial merges if they follow a "sideway" pattern as the previous link illustrate.
Best Answer
Yes it would: it would be a sideway merge
You can see one side-effect in the question ClearCase wants to merge unchanged files after deliver to alternate target.
In your case though, the effect should be minimal:
Merging from B to A should not generate more conflicts than usual for modified files, except if those files (modified in B) are no longer present in A (because rmnamed in BL2):
then a manual merge of the parent directory of those files would be needed.