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

CVS or Subversion

[benjfowler]

As far as I can tell, you're describing the classic CVS or Subversion small team setup. You can run a server on the network (via Apache, or via SSH), run ViewCVS, set up checkin hooks, and give your clients a nice client like TortoiseCVS/TortoiseSVN built into Windows Explorer.

If you want integration with bug tracking tools, then have a look at Bugzilla and Bonsai.

All your users need to know about, is check in, and checkout, so the cognitive overhead is low.

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

Re:CVS or Subversion

[rainmaestro]

Agreed. For small / inexperienced teams, we've always recommended VisualSVN. GUI to manage most of the project admin tasks, easy integration with AD for user/group auth, and a fairly simple workflow.

Git is has some really nice features, but I wouldn't push it onto a team with no VCS experience.

Re:CVS or Subversion

[gonz]

For a small-to-medium team that has easy access to a centralized server, choosing Subversion instead of Git could save you a TON of time. In my experience, Git has a constant overhead of messed up merges, "brown bag" discussions to educate new devs about various gotchas, and ongoing debates about the right usage strategy (merging versus rebasing, branch management, how to keep histories from growing too large, etc).

By contrast, I've also worked at several different companies that used Subversion, and basically you just show new devs how to sync and commit, and they figure out the rest themselves. The reason is that having a single always-up-to-date master is an order of magnitude simpler than Git's model of working-copy/branch/master on your local PC and then also branch/master on a remote PC and push/pull/fetch/merge between them.

With Subversion you still have to manage branches sometimes, but there is typically a maintainer person who handles that. Whereas the model of Git is that every dev is doing merge algebra from day 1.

Re:CVS or Subversion

[angel'o'sphere]

SVN might have drawbacks, one is its name. However this: SVN doesn't work. is simply wrong.

Linus had special requirements, hence he wrote git. If he claimed SVN does not work, he is not smart as he looks like.

That does not mean that SVN etc. does not work. CVS is another thing. Having non atomic commits (how retarded is that anyway????) is a huge problem.

Mercurial

[roman_mir]

Super easy to set up, take a day with your team to learn the main functionality and you are good to go.

As your team gets more experienced, you will be happy you made that choice.

What will you ACTUALLY be doing?

[GrantRobertson]

First we need to take a step back and figure out what you are actually doing. You have pulled up with a "software version control" bandwagon and everyone just jumped on without looking to see if it would take you where you wanted to go.

Are you wanting to keep track of the versions of your code or the reports generated by that code or the data that the code used to generate the reports? Each type of information is best suited for a different kind of versioning system. Are the reports generated only by the code or are they written by humans? Trying to use a code versioning system to keep track of modifications to reports or data is a loosing game. Don't make the mistake of thinking every problem is a nail just because you have a hammer.

Re:UH oh

[__aaclcg7560]

Or a hardware company being run by a marketing hack: "Python is new and popular! Let's get all our programmers and code base on Python yesterday!"

As the summary makes no justification for switching away from C and Java, I'm just assuming the worse possible reason for switching programming languages.

Re:OUCH!!!

[Njovich]

The one thing I agree with is that Git is the obvious choice as it is the current standard. For the rest I guess you are fairly inexperienced. If you really believe it's easier to shoot (or nuke) yourself with Python than with C you are extremely wrong. Obviously you can write bad code in any language, but Python is no worse than most others.

In a couple of hours most Git basics can be taught to any reasonable programmer. It can be worthwhile to make sure they set aside some time to read up on Git usage. Especially with a GUI it's not exactly rocket science (and any programmer worth their salt should have no problems with the CLI, some annoyances notwithstanding). Making your hiring decision for a Python programmer based on Git skill is a bit weird, as there are much more important factors to choose a programmer on. I have seen good and bad Git usage across all ages and skill levels, it mostly just depends on what exactly they worked on in recent years.

As far as massively changed programming paradigms, unless you just time traveled from the 70's, that's BS.

As for Scrum and Test Driven Development, you would need to know more about this project before you can make a decision like that. I don't see anything in this description that would give you enough information to advise on that.

Re:git

[ATMAvatar]

I don't know that I share the same experience. There are plenty of UI tools that help make git easier to work with, such that I wouldn't have much hesitation in making it the first VCS for a team.

I certainly don't expect them to be doing rebasing, bisecting, or force pushes anytime soon, nor would I suggest they start by setting each other as remotes to take advantage of the distributed aspect. However stage, commit, merge, pull, and push operations on a central origin are all pretty simple, and not much different than they would be doing with any other VCS.

Re:git

[Electricity Likes Me]

No you're not? With Git its not at all distributed unless you really really work at it. The simplest and most naive git model is "get latest head, edit, commit and push". This is what everyone is going to be doing with any other tool.

The difference is, when they get more advanced, you'll be in the good company of the *massive* git ecosystem and featureset which will make your life a lot easier. If you're dealing with people who don't know version control, then it doesn't matter what you pick - they are not going to understand it and you will be doing a lot of support.

Re:UH oh

[Megane]

LabView is not only proprietary, it's a visual programming language (connect a bunch of boxes with lines) that stores its stuff in binary blobs. So you can't do version control on it, or even diff it. If someone changes one of those little boxes in a big LabView project, you will likely never know who did it or when it happened, and good luck finding where it was changed. Or you might not even know that it happened at all, just things start acting screwy.