Ask Slashdot: Selecting a Version Control System For an Inexperienced Team

An anonymous reader writes: I have been programming in Python for quite a while, but so far I have not used a version control system. For a new project, a lot more people (10-15) are expected to contribute to the code base, many of them have never written a single line of Python but C, LabVIEW or Java instead. This is a company decision that can be seen as a Python vs. LabVIEW comparison — if successful the company is willing to migrate all code to Python. The code will be mostly geared towards data acquisition and data analysis leading to reports. At the moment I have the feeling, that managing that data (=measurements + reports) might be done within the version control system since this would generate an audit trail on the fly. So far I have been trying to select a version control system, based on google I guess it should be git or mercurial. I get the feeling, that they are quite similar for basic things. I expect, that the differences will show up when more sophisticated topics/problems are addressed — so to pick one I would have to learn both — what are your suggestions? Read below for more specifics. These are the requirements I can see so far:
- __Server_running_locally__ (as opposed to in the cloud) on windows (IT departments choice, non-negotiable)
- Good/easy to use Windows clients (IT departments choice / company policy, again non-negotiable)
- Use windows credentials (maybe, single sign on)
- Open source server/client (personal preference)
- Well established Project that will not disappear/ get unmaintained within a foreseeable future
- Do basic test on the code (Syntax errors, pytest/nose/or alike with coverage (of tests), check coding style)
- email notifications
- good documentation
- reasonable price for 5 — 10 users : free — 500€

Things that would be great ...
- web interface (like github) would be nice
- integration of bug tracking / bug reports
- possibility to do and print out a code review
- some kind of jupyter / ipython integration

Things I am not sure I will need but seem to be a good idea at the time of writing...
- Include other files/ file types for measurement data, documentation and user manuals (docx, xml, xlsx, gz, ...)
- When thinking about measurement data /reports it would be great to have digital signatures (--> FDA compliant). I know this is extremely hard, if this exists I would love it, if not I am fine. Somehow this feels like mixed document/version control, but I would love to have data + code + text = report at the same place to easily find implications of a bug — which data has to be re-evaluated and so on.

Comments

Re:CVS or Subversion

[swillden]

So now master is the development branch! master is the release branch! THAT is terrifying. Although they do tag releases, but still.

Developing on and releasing from master has its risks, but given appropriate QA, including code reviews, extensive automated unit, functional and integration tests, and extensive release tests, it can work very well. That's what Google does. 25,000 engineers, one source repository, 45,000 commits per day, developing on and releasing from HEAD.

Well, almost. Developers create local branches for their work and don't commit into master until code review is complete -- including of automated tests. The actual commit into master doesn't go in unless the commit and everything else that could possibly depend on it builds and passes all of the tests (the build/test/submit cycle is automated; engineers kick it off and then get informed of the results). Releases are branched off to freeze them while release testing is done, and sometimes a few commits are cherry-picked into a release to fix issues, but mostly the release either passes the tests and goes out, or fails the tests and is abandoned. Most projects operate on a weekly release cycle, so the impact of abandoning a release is small. As long as it doesn't happen too often.

Note that I'm speaking of the web properties; search, Gmail, etc. Obviously other groups have different approaches. For example, I currently work on Android, which has a roughly annual release cycle. That drives a very different strategy. One with lots of branching, actually.

Also note that I'm not claiming that this is a good strategy for every team or company. I'm just pointing out that it can work, if you manage it well. Of course, the same is true of virtually every development process, though different processes are better suited to different contexts.