R – Migrating Clearcase to X

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)

As an administrator of ClearCase, I would rule out that tool unless you have a complex merge workflow.

The workflow you mention involves being able to branch, fix and then merge back easily, which should not be in favor of SVN.

The biggest trap when you are used to ClearCase (espacially non-UCM ClearCase) is the "composition" of a config spec.
If you choose a DVCS (Mercurial, Bazaar -- or Git since it works really well on Windows), you would not be able to get the same "inheritance effect" -- (when you are selecting different versions with different successive select rules --: as said in that answer:

In a purely central VCS, you can define your workspace (in ClearCase, your "view" either snapshot or dynamic) with whatever rules you want.
That would not be practical in a DVCS (as in "Distributed"): when you are making a branch with it, you need to do so with a starting point and a content clearly defined and easily replicated to other repositories.

If you are using ClearCase UCM, that means identifying coherent sets of files, which can only be achieved through - for instance - Git submodules.
The complexity is higher with those DVCS, since they do not record the dependencies between modules (or "set of files") the way ClearCase UCM does.

So, to recap:

• Ease of setup: all the mentioned DVCS are easy to setup. What must be taken into account is the administration in terms of user access.
• Setting up workflows: a DVCS supports any kind of workflow, even a centralized one, or a public-private one, or.... Regarding finding a bug, they all support some kind of bisect process.
• Generating metrics: if by that you mean "metrics about the code managed", they all support some complete log system able to display a lot of information about what has changed.
  But in term of "metrics about the tool" (speed of a process or space taken by data), the DVCS tools mentioned are considered much faster than SVN (see here as an example).
• Reasonable learning curve for developers used to ClearCase: the GUI can be a factor to alleviate the learning curve, but a DVCS is very different from ClearCase, as this "core concepts" answer illustrates.
• Windows development: they all work well on the Windows platform, with maybe a slight advantage (better integration) to Mercurial or Bazaar.
• Issue tracker integration (probably going to be Redmine, though it isn't set in stone): Redmine supports now most of them (and not just SVN as it did at the beginning)