views:

57

answers:

3

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?

A: 

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).

khmarbaise
The thing is, it is very chicken-and-egg. Our current process is both determined and limited by our current tool, which is something I'd like to change...
Benjol
Ah...so the most important is to answer the questions in which ways does the current tool limit you? And which tool supports that what you like to do?
khmarbaise
+1  A: 

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.

bitc
Excellent link, thank you!
Benjol
+1  A: 

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) "

VonC
Excellent links, thank you! As you may have noticed, I've been playing with git for a while now, but I'm not sure I'll manage to get that flying here. Even if we do opt for a DVCS, we'll be using it in CVCS mode, I think.
Benjol
@Benjol: It is possible to use Git in a CVCS manner, provided you take advantage of the publication process (http://stackoverflow.com/questions/2563836/sell-me-distributed-revision-control/2563917#2563917) and you encapsulate your "central" repo with a repo access manager like, for instance, gitolite (http://github.com/sitaramc/gitolite)
VonC