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

[Antique Geekmeister]

> classic CVS or Subversion small team setup

Yes, but I'd recommend _really strongly_ against either today. Both have considerable difficulty establishing disaster recovery or failover, and the tendency to set either of them up with the passwords stored locally in the user's home directory present profound security problems. And neither of them allow developers to make their own branches, and record their changes locally on their own systems, and submit them only when needed. The result can be a profound amount of clutter in the main repository, especially if anyone accidentally commits bulky binaries to a branch. CVS at least allows deletion of accidentally committed bulky objects: Subversion does not, not without extraordinary effort.

I'm afraid that building your own bug tracking systems from scratch, even with tools like Bugzilla or Bonsai or RT or any of the major toolkits, is a blackhole of support work. Git has proven _very_ good for developers, because it allows them to branch, and to merge, far more cleanly, with very good mechanisms to make a "pull request" and get code review, and much more reliable and verifiable GPG signed tags. For small private repositories, github.com has proven very robust and resilient, with very good tools for Wikis and bug reports and integration with build systems.

The only compelling reason I see to use Subversion today is the very, very good "TortoiseSVN" inteface for Windows users. "TortoiseGit" simply does not work well enough, and the X based GUI's aren't as good.

> It would take one engineer half a day to set all this stuff up on a spare machine, and you could try it out fairly quickly.

And it can take a full day every week to support just this one service, even in a small shop, with backup, high availability, bug fixes, security updates, end user support, and the hand management of user access and privilege management that is common to these small setups.

> And best of all, this setup is gratis as well as Free. This has worked really nicely for me in both an academic and a commercial environment.

I've unfortunately had to clean up from a number of "free as in beer" source control systems mismanaged over the long term.

Re:CVS or Subversion

[Maxmin]

The ONLY reason git gained popularity is Linus Torvalds. If an unknown engineer released a VCS with similarly confusing, incoherent command-line semantics? It would NEVER have taken off. git survived because Linus Torvalds. That's it.

But git is the lingua franca. It has a learning curve, but because of that there is a virtually unlimited selection of learning materials out there. There is NO EXCUSE for not having some expertise in git, as engineers. Why rebase? How to cherry-pick? Only stubborn engineers don't know these things, and it's odd because they're smart enough to grasp the concepts, do the katas and gain proficiency.

I work with a bunch of engineers that refuse to branch in git! They're terrified of it! Because, once they branched, worked out of that branch for three months, then had a disastrous merge to master (of course). So now master is the development branch! master is the release branch! THAT is terrifying. Although they do tag releases, but still.

Re:CVS or Subversion

[Anonymous Coward]

I am watching this talk and so far I have learnt (or perhaps reaffirmed) that Linus can display narcissistic and a control freak tendancies and has no trouble abusing people who disagree with him. If he wasn't so talented or hadn't hit upon Linux at the right time I would not be surprised if he was homeless instead, because no one would work with him.

To call any SCM broken because is in fact ugly and stupid. Note that I did Linus the courtesy of not calling him ugly and stupid as he called everyone he disagreed with ugly and stupid - I just called his statement ugly and stupid. People can and do work with centralized SCM ssytems every day and a lot of excellent systems have been written using them.

To call an SCM broken because it doesn't protect against disk or memory corruption is also unreasonable. You can offload those duties to the operating system and focus on designing a good system.

It is true that distributed source control requires a distributed system but for a lot of organizations having code in one central repository is actually seen as an advantage. I have more of an issue with the lack of fine grained security for individual projects, branches or commits. But it's nothing that can't be worked around.

The fact that Linus built git in such a fashion that when he'd finished after his 2 weeks it was unusable "by mere mortals" but he considered it finished speaks volumes.

This talk is proof again, as if it was needed, that one can be technically brilliant and socially inept.

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.

Re:UH oh

[__aaclcg7560]

I gave a trivial example where I wrote a Python that took 123 seconds to do one million dice rolls. I then use Cython to convert dice rolls into an C extension, which resulted in Python script that executed in two seconds. I didn't convert the entire Python script into an C extension. If the goal is to standardize the code base from C to Python, Cython can fix the performance issues.