Scenario for evaluating source/version control tools

We're currently researching different source control tools, and want to test each one with some light-weight but meaningful scenario to get a feel for the capabilities of each one.

Terminology and internal logic varying wildly between some tools, it would be nice to have the scenario expressed in terms of use cases ("We have to correct a 开发者_运维问答bug on Release 1.3"), rather than in potentially tool-specific terms ("Create a branch named Release 1.3").

It's true that different things are important for different teams, but it would be interesting to have some kind of canonical test case from which different scenarios could be picked. Or am I being too optimistic?

Is anyone aware of something like this? Have you used a similar approach when investigating source control tools?

These are the requirements that Mozilla had when they set out evaluate version control systems for internal use in 2006. You might find a similar approach useful.

If you find scenarios that are specific to your company, perhaps you can translate them to requirements like the ones above.

You have some general criteria with Google DVCS analysis which can give some ideas.

But you need first to see if you want to evaluate:

• CVCS (Central Version Control): update-merge-commit
• DVCS (Distributed Version Control): commit-rebase/merge

For more on the different scenario to test (one answer for CVCS, one for DVCS), see the SO question:

" Describe your workflow of using version control (VCS or DVCS) "

You have to question things like: Do you have only a single line of Release/Development or do we create multiple releases in parallel? No only the mentioned scenario is needed you need to think about upon that one like merging back the changes into dev line or multiple other lines as well. This can influence the approach. The approach you selected sounds very good cause you try to understand the process and not using tool terms. I've done that for multiple times for customers of mine. In different teams/companies different things are handled different. So the problem is to figure out what the process of yours is (sometime people are not aware of this).