Script for evaluating version / version control tools

Question

We are currently studying various source management tools and want to test each of them with an easy but meaningful scenario in order to understand the capabilities of each of them.

Terminology and internal logic wildly vary between some tools, it would be nice to have a script expressed in terms of use ("We must fix the bug in version 1.3"), and not under potentially specific conditions (Msgstr "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 selected. Or am I too optimistic?

Does anyone know about something like this? Do you use a similar approach when researching version control tools?

Answer 1

These are the requirements that Mozilla had when they installed the evaluation of version control systems for internal use in 2006. You may find a similar approach useful.

If you find scenarios specific to your company, perhaps you can translate them into requirements such as those listed above.

Answer 2

You have common criteria: Google DVCS analysis , which may give some ideas.

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

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

For more information on the various test scenarios (one answer for CVCS, one for DVCS), see the SO question:

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

Answer 3

You should ask questions such as: Do you have only one Release / Development line or are we creating several releases in parallel? Not only the mentioned script is required, you need to think about it, for example, merging changes in dev line or several other lines. This may affect the approach. The approach you choose sounds very good, because you are trying to understand the process, and not use the terms of the tool. I have done this several times for my clients. In different teams / companies, different things are handled differently. So the problem is figuring out what your process is (sometimes people don't know about it).