Follow Slashdot stories on Twitter


Forgot your password?
Programming Python

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

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • CVS or Subversion (Score:5, Insightful)

    by benjfowler ( 239527 ) on Sunday October 11, 2015 @12:43PM (#50704219)

    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.

    • by rainmaestro ( 996549 ) on Sunday October 11, 2015 @01:02PM (#50704351)

      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.

      • If the team has no experience at all it does not matter what their first VCS is!!!!!

        Especially if they have to consider to switch to git later.

        Git is only difficult to grasp if your mind is polluted by CVS/SVN.

        • by Anonymous Coward


          Git is difficult to grasp because
          * it makes simple things complicated
          * you need to read an entire book before using it
          * and its manual reads like this:

          • git pull [URL]
            [do stuff]
            git add [modified files/dirs] (might not be necessary, probably mixing up git and hg)
            git commit -m "message"
            git push

            WOW, That was so incredibly complicated! Seriously, I'm not seeing a difference (to the user) for basic use between svn and git. I'm speaking from the perspective of a user who has a few local repos for random things he's created.

      • Re:CVS or Subversion (Score:4, Interesting)

        by Maxmin ( 921568 ) on Sunday October 11, 2015 @06:18PM (#50705777)

        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 (Score:5, Interesting)

          by swillden ( 191260 ) <> on Sunday October 11, 2015 @09:44PM (#50706399) Homepage Journal

          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.

    • by gonz ( 13914 ) on Sunday October 11, 2015 @01:02PM (#50704357)

      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.

      • by bre_dnd ( 686663 )
        SVN works well with a single up to date master, but that model eventually breaks if you want to have experimental features. At some point that will become a need -- trying something outside the main branch that is actively being deployed. Git is a bit of a pain at first but you simply can't do the things git does in svn.
        • Branching works fine in SVN.

          • SVN doesn't work. If you think it does, it because you have never used a real VCS. Linus explained this quite way back in 2007. That was 8 years ago. There is no excuse for using a tool that literally can't do proper version control, when there has been a kickass tool available for free for close to a decade.
            • by angel'o'sphere ( 80593 ) on Sunday October 11, 2015 @04:47PM (#50705417) Journal

              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.

            • SVN works just fine for tons of projects, developers and companies. It would probably not work great for a project such as the Linux kernel but top poster does not seam to have that requirement.
            • If you think SVN doesn't work, you don't know what you're talking about - and you never used the systems that came earlier. Linus is a bright guy, but he did not invent software development, and his "not-invented-here" complex is sometimes counterproductive.
        • Re:CVS or Subversion (Score:4, Informative)

          by sugar and acid ( 88555 ) on Sunday October 11, 2015 @01:49PM (#50704553)

          It is perfectly possible to branch in SVN and manage it. Git is better for branching and developing in complex and large team environments. But this is not the case here. They probably have max 3 guys maintaining and max 3 guys on a development branch. SVN is more than capable of handling that.

      • I'll say this about your post of misinformation. No. Just NO [].
      • I agree with the Subversion recommendation. I've been forced into using git because its the next "great" thing in source control. Subversion met all our needs and worked well without much fuss. git is a pain to use, with cryptic commands and plenty of ways to screw yourself.

      • Except that the author of the story does not need merges.

        They only want to have a version history on automatic generated reports ... reading sometimes helps.

        If your team messes up merges with git, they will mess it up in any other VCS anyway.

        A merge is a merge, there is no difference what tool you use for it.

        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 a

    • by bre_dnd ( 686663 )
      I use SVN at work and for a small number of developers it works decently well. SVN is quick to set up and to learn -- it somehow feels easy. I agree with the TortoiseSVN as a client -- all of that works quite well. However. Doing merges in SVN is an absolute nightmare. The "cherry picking" model of implementing features and merging them back in, one by one, as code gets ripe is painful in SVN. There is a learning curve for git, but not much more so that for SVN, and the habit of using a feature branch and
      • Merge early and often. In a 5-person group new to using ANY kind of VCS (plus me with experience), we had one user insisting that merging was impossible; when it turned out that his code base had not been updated for 3 months, while everyone else's gap was a week or less, other newbies were more annoyed than I was, because the absence of the stuff he had been working on had been slowing everyone down for weeks, and his insistence that it was now ready turned out to be totally wrong because it was connected
    • by Z00L00K ( 682162 )

      I'd pick Subversion or Git.

      Mercurial isn't something that I have had any good experiences from. Seems to require quite some learning threshold.

      Of course - the merging of branches - that's a source for curses in many version control systems since it's hard to make smart stuff around merges.

    • Another vote for SVN (Subversion) here. You can spin up an SVN server on Ubuntu in about 30 minutes. Then add the web front end in another 10. A WEALTH of clients in both GUI and non-GUI for all platforms. And it is lightweight on the client side. (Only has a single version locally) The code is very mature, and you do not have to worry about patches often, and it is just easy to use.

      However, it is missing some things on your "Things that would be great" list, but not many. Not at all with some of t
      • Another vote for SVN (Subversion) here. You can spin up an SVN server on Ubuntu in about 30 minutes. Then add the web front end in another 10. A WEALTH of clients in both GUI and non-GUI for all platforms. And it is lightweight on the client side. (Only has a single version locally) The code is very mature, and you do not have to worry about patches often, and it is just easy to use.

        However, it is missing some things on your "Things that would be great" list, but not many. Not at all with some of the larg ammount of tools and addons built for SVN.

        If it doesn't REALLY need to be on a Linux system, you can get Apache+SVN up and running in about a minute with VisualSVN Server. Domain integration, GUI for fine grained access controls, and it's all brain-dead simple and free.

        CollabNet seems to have something similar called Subversion Edge for multiple platforms, but I haven't used it and they were late to the game.

        I wouldn't recommend anyone roll their own svn+apache system. It's not worth even ten minutes of your time when those tested, out-of-os-dist

    • Re:CVS or Subversion (Score:4, Interesting)

      by Antique Geekmeister ( 740220 ) on Sunday October 11, 2015 @02:09PM (#50704657)

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

    • Subversion is very easy to teach to beginners. I got a bunch of hardware people to join me in using it by starting with a very simple shared-file system just for myself and one other person, and over a year or so even the nay-sayers saw that it was trivial to use - and so used it.
    • I'd recommend away from CVS, and even Subversion - to git.

      I lived in svn long enough to regret it, git is billed as "scary and hard to learn" but it's gotten past that stage, and the price of not using a distributed version control system is just too damn high.

    • Re:CVS or Subversion (Score:4, Informative)

      by jrumney ( 197329 ) on Sunday October 11, 2015 @09:07PM (#50706259)
      I never thought I would see a recommendation for CVS in 2015. The OP is on the right track looking at git and mercurial to start with. The only probem with his requirements are the Windows server. Maybe a virtual machine running on the Windows server would be acceptable to IT? While it is possible to run a git or mercurial server on Windows, there are a lot of good tools that would give the "things that would be great" that are not supported on Windows []. On the client side, TortoiseGit and TortoiseHg are available, giving the same Explorer integration as TortoiseSVN/TortoiseCVS.
  • by beck24 ( 1772278 )
    Seems to be the defacto standard almost everything these days. It's got everything you mentioned.


    Do basic test on the code (Syntax errors, pytest/nose/or alike with coverage (of tests), check coding style)

    That's not really a function of version control

    • Actually you can do that with git.
      Just set the right pre commit, or pre upload hooks and it'll do it all.

      One project I contribute to on github preforms automatic coverity and travis-ci builds/tests every time someone asks to merge their code to the master branch.

      Easy way to see if the thing even builds, without the maintainers having to do a thing.

      • Is that git, or build scripts on the git repository? Which could also be build scripts on a subversion repository.
        • Git has what are known as hooks. Things that are run whenever you do something, like committing a file or trying to push to somewhere. It's how you get E-Mail notifications. These aren't anything new, so I think subversion offers something similar. The large difference is in what these let the maintainer do when it comes to integration.

          Take a look at this page: []
          Click on the green check marks or red 'X's. This is something github has integrated into their system, but th

  • In fact, what you want is several different tools, at least a VCS and an integrated build: []

    At my company, we are using CruiseControl.NET, which is free and open-source, but seems discontinued.
    It's sufficient for our needs.
    We use a SVN server to make our commits (with TortoiseSvn on the clients), it's dead simple to install and use.
    Configuring CruiseControl is more tedious, but you'll get automated builds, along with code coverage and unit tests.

    A better tool may exist, but we

    • You could try out Jenkins [] (a fork of Hudson) which is under active development and integrates fairly well with some of the other project management tools (e.g. Jira, Trac, etc.) people tend to use for bug tracking. Its also FOSS and under active development.

      It's got a fair bit of community support in terms of plugins, so even if you're doing something a little bit niche, there's a reasonable chance that someone else might have built a plugin to solve those needs.
  • I think git [] can meet all of your needs, and personally I love it.
    - It's a free, well-established, and well-documented open source project.
    - There are plenty of GUIs [].
    - For inexperienced developers, there are tutorials like this one [].
    - Here's decent guide to getting password-less authentication via ssh working on Windows [] to connect to a server running locally on a Windows box (as long as it's running OpenSSH, maybe via cygwin []).
    - You can use Git hooks [] to do notifications, run syntax checks, etc.

  • git
    gerrit (especially how implented via LibreOffice/Openstack)

    Launchpad (what Ubuntu uses) also just added git support, and it's $250 flat a year for a proprietary project. This would not be hosted locally though ( I wouldn't recommend starting a new project with Bazaar today.. but if this was 5+ years ago it might be perfect for your use case.. (great Windows client)

  • I'm always going to recommend git as the version control system of choice. It scales well, and you can learn how it works without mucking with servers to start. Plus has some good tutorials, and there are several web interfaces available. If you could convince your IT department to let you use a cloud based system, github would actually be perfect. Also, the speed. Don't underestimate how important that is.

    Here's a list of reasons to use it instead of SVN or CVS: []

    • A lot of the things they see as benefits, can also be drawbacks. Having the entire repository and all it's history can be quite large on older (or frequently moving) projects. Making local branches, and just lots of branches in general, easy can result is some serious code sprawl as well. And SVN project can often allow for tighter management.
      • In some ways yes, in some ways no. Large history can be an issue, but to get to that point you pretty much need to be doing something pretty special for a fortune 500 company. The entirety of the Linux Kernel clocks in at under 2GiB, the only company I've ever heard make the claim that this is an issue was Facebook, who went with Mercurial instead.

        The trick with branches is that each represents a different feature or bug fix. So long as they don't touch the same bits of code, git makes merging them painl

  • I recommend git. It's fast, it's easy, it's decentralized so code cowboy can't burn your project. And there are gui's for it for windows as well: []

    Since IT has set the policy to a Windows operating system only server, you've had your hands tied as to what technology you can use. Fortunately for you, you can run Docker on Windows: [], which means you'll have access to tens of thousands docker containers for various purposes such as gitlab: https []

  • by Tumbleweed ( 3706 ) on Sunday October 11, 2015 @01:08PM (#50704383)

    Use a GUI like Atlassian's "SourceTree". It's what we use at work, and it works pretty well. You'll still want at least one Git expert on the team for when someone does something stupid, but you'll need that for whatever platform you choose.

    • Use a GUI like Atlassian's "SourceTree". It's what we use at work, and it works pretty well. You'll still want at least one Git expert on the team for when someone does something stupid, but you'll need that for whatever platform you choose.

      With an inexperienced team you'd probably be better off with SVN. It's easier for complete noobs to understand and a bunch of noobs is not likely to need the extra features you get with Git. By the time they have gotten comfortable with SVN and you feel that your team is ready for more complex work you can always upgrade to Git.

  • Mercurial (Score:2, Insightful)

    by roman_mir ( 125474 )

    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.

  • I'd go with Subversion. It's older and has a centralized repository rather than Git's distributed-repositories approach, but that won't be a problem for your team since they aren't spread out across multiple locations. It's got better support for running on Windows (CollabNet sells a supported commercial Windows-based server plus the whole TeamForge line), has Windows clients (both integrated into Explorer and stand-alone) and has supported integration with Visual Studio. Older means that almost every devel

  • by X10 ( 186866 )

    Git. The best. Whether your company has one employee, or hundreds of thousands.

  • by iamacat ( 583406 ) on Sunday October 11, 2015 @01:18PM (#50704429)

    Source control with git is like using (char *) &myStruct in C. Very flexible, but impossible to explain to someone who wants to do simple tasks, and most commands result in corrupting your work. Including correct commands accidentally used twice. Worked with it for two years, still regularly find things that baffle me.

    Better to start with a comprehensible tool like svn and a good IDE with a source control plugin such as IntelliJ. You might migrate several years down the road, but by that time either team will become experienced enough to use git, or hopefully something better comes along.

  • by GrantRobertson ( 973370 ) on Sunday October 11, 2015 @01:21PM (#50704447) Homepage Journal

    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.

    • by hsa ( 598343 )
      I have been developing software professionally for over 10 years now.

      All these weird requirements (reports, bug tracking integration, email notifications..) are .. weird. Sounds like a manager is trying to use version control system for parts of his job. Or you are talking about continuous integration, and should look elsewhere, like CruiseControl.

      Nevertheless, I will never ever again do a multiperson project without a version control system. Seriously, I even use version control on my personal projects. Ve
      • But what kind of "projects" do YOU work on? Is it just code (or code-ish things like XML), or do you mean documentation, or databases, or graphics files? Each different thing works best with a different form of "version control."

        I once tried to hack together a way to use Git to track updates to my FrameMaker files. It "worked" but was a nightmare to use and took up just as much disk space as simply keeping every version of the file and assigning different filenames.

  • As far as your basic requirements are concerned, pretty much any major (git, svn, mercurial) open source version control system will cater for them, with some third party (mostly) free tools. Local server, well established, open source, email notification via hooks, extensive (if not easy to read) documentation ... all of these would be covered by the VCS itself. Single sign on integration with Active Directory (AD) can probably be set up using an LDAP extension. Many windows clients exist, most catering to

  • OUCH!!! (Score:4, Informative)

    by LostMyBeaver ( 1226054 ) on Sunday October 11, 2015 @01:57PM (#50704585)
    I'll start by answering your question. Use GIT. It's the most widely supported system at this time and it works really well.

    Next let me be a typical slashdot asshole that makes abrasive comments that may be well intended by will come off as being a dick. I'll explain that I already see endless problems coming from this.

    If you're working with a team of 10-15 developers who all lack experience with version control, you have a major problem with out-of-date programmers and you're throwing them into a hell called Python. If you generally accomplish projects using C and LabView, the developers you have more than likely lack a modern development skill set and coding in a language like Python will produce some of the worst code ever written. If C is like shooting yourself in the leg and C++ is like blowing the whole damned leg off, Python is like dropping a nuke. You will have an endless supply of options for writing terribly bad code in the worst ways possible. The only redeeming feature will be it will have nice uniform spacing.

    I would highly recommend doing what always works best which is to hire a Python developer with good GIT skills that can lay the majority of the foundation of the project and create a uniform set of standards of coding for the project and then bring the other developers on 3 at a time and perform constant code review. Focus heavily on test driven development and use a system like SCRUM for lifecycle management. If you want to teach old dogs new tricks, don't just throw them in the fire and tell them to figure it out. The programming paradigms are so drastically different between your old method and new that without some sort of leader with experience, it will turn out to be a disaster and jungle of crap code. I personal avoid Python projects not because the language is bad, but instead because they tend to be like this.

    You should of course know by now that if you are traditionally a LabView shop, you're going to sacrifice a massive number of really important features to save a buck. Python has great support too multi-threading but it's not an awesome environment for event driven programming like LabView is. You of course can accomplish all the same things, but even with the thousands of toolkits/libraries out there, you'll have to write the entire underlying architecture yourselves and you'll lose almost all visualization you've come to depend on.
    • Re:OUCH!!! (Score:4, Insightful)

      by Njovich ( 553857 ) on Sunday October 11, 2015 @02:31PM (#50704785)

      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.

  • by Greyfox ( 87712 )
    Git, with jenkins integration and sensible branching policy. When jenkins sees a commit to the current development branch, or nightly, it can kick off your testing for you and tell you if anyone broke the build. Have a development branch where most churn takes place, an integration branch that you can release the development branch to when you're gearing up for a release and the features go to integration testing and a current release branch that's updated with the integration-tested code and released. Once
  • Just go with GIT. The trust is no version control or SCM software is very good, they all suck in a lot of ways and have very limited strengths. One to totally stay from is Preforce, it's unstable, unsafe and you run a serious chance of loosing your code into a corrupted mess of memory errors.
    • I've worked on game projects over the last fifteen years which used Perforce for millions of files and terabytes of data, and to my knowledge we never once had anything get corrupted.

      Can you describe some of the times your stuff got broken by Perforce?

      • In one company we had Preforce storing about 20 TB's of information. In a course of three months we had about 100 MB of that data get corrupted to the point the entire repo locked up. We then tried to delete the data but thanks to the corruption, which was caused by Preforce, we couldn't. We ended up on a call with Preforce and it took them weeks to figure out how to solve this problem.

        About a year later I started at Blackberry, who were using Preforce. I updated development code into the main repo
  • Be precise and thorough about your check-in process. Each developer's modifications should pass tests under varying sets of real world inputs. I develop Python code for our observatories using ASCOM [] hardware simulators for the DAQ process. Convenient, but not the same as the real thing.
  • by Anonymous Coward

    Knowing what industry you're working in helps to understand what you're trying to do and what you actually need. Others have seemingly missed this, but you did mention FDA compliance at the end of your extended list of requirements. So, I'm guessing you're a life sciences, pharma or drug discovery company working with microarrays and other data acquisition hardware where the data WAS passed to LabView and then processed there or in one of the Java, C, or other apps you mentioned that were developed in-house

  • Either SVN/Trac for a small team and a moderate size code base.
    SVN and Trac for bug handling works really well and Subversion is pretty easy to pickup if you don't already have any version control experience.

    Otherwise go with Git/GitLab if your people prefer it. I find working with git to be more arcane but then I kind grew up on CVS/SVN.
    If you like the distributed model but have issues with Git then Mercurial is you best next option.

    I would strongly advise against:
    Perforce, ClearCase, Team Foundati

  • by Xtifr ( 1323 ) on Sunday October 11, 2015 @04:16PM (#50705277) Homepage

    Hear me out. I know git is more popular—I prefer it myself—but mercurial has a much simpler conceptual model, is easier to learn, and offers nearly all of the benefits of git.

    With git you really need to learn about the difference between "add" and "commit" and how the staging area works. That's a very useful feature, but it also complicates the teaching, and for basic day-to-day stuff, doesn't offer huge benefits. And git just has _so_ many commands. They're powerful, but intimidating to a newbie.

    Mercurial, on the other hand, has most of the power of git, but it's a lot more straightforward for the most part. The lack of a fast-forward capability means you end up with a lot more merge commits in your history, but that's not a huge deal. At least not at first. And its fairly easy to migrate from mercurial to git later, once your team is more comfortable with the way the system works. So it's not like you're making a lifetime commitment.

    Mercurial is less powerful than git overall, but it's a great introduction to the whole model of DVCS. And for day-to-day stuff, mercurial is definitely more than adequate.

    Both git and mercurial are vastly superior to svn, especially for performance. Having to make network round trips for all but the most basic examinations of history is a serious disadvantage of svn. If you're just testing a script, for example, a bibisect can be many orders of magnitude faster with git or mercurial. And you can do it even if you're sitting in a hotel room and don't want to pay the outrageous wifi fees. You don't need a network at all. Using SVN in this day and age is simply inexcusable. There are absolutely no benefits—only disadvantages.

    If you just want to get up and running with a vcs that will offer great benefits with minimal floundering while people learn the ins and outs of the system, mercurial is a pretty darn good place to start. If you have a little more time to spare getting everyone up to speed, though, it might be just as well to leap straight to git. *shrug*

  • "I have been programming in Python for quite a while, but so far I have not used a version control system."

    Don't mean to be a pain but if you have no experience with versioning, not sure why you seem to be the one making critical choices (like dictating the language the team uses or what version control makes sense...)

    Short answer is just use git. Its dominate. Its got some weird alien brains but there's going to be plenty of help and good examples. I find smart people manage and also its sufficiently we

  • If you're switching from LabView to Python because it's an open, popular, well-supported language that's easy to find experienced programmers for, I can't recommend learning anything other than git for version control. SVN works, yes, and lots of people have previous experience with it, yes, but git is ubiquitous and there are lots of excellent tutorials that should have your team up and running on it in less than an hour. My biggest difficulty in moving from SVN to git was not git, but rather un-learning

  • For my personal use i am a fan of git, but if you have a team with the possibility for a constant server, and all team members have a decent network connection to it (and that is a big if), go for subversion server and buy supported client tools for the applications where tortoiseSVN does not seem fit.

    My reasoning (favoring subversion over git is as follows):
    * in a beginner team, the reduced choices and the standard layout of a project in subversion are an advantage
    * Migrating to git can happen at any time

  • I don't have a clear picture of what your organization will be doing, but your comment about "managing that data (=measurements + reports)" made me wonder if you will want to use the IPython notebook. []

    When people work to analyze measurements (make plots, etc. and make decisions) and then write new code, if they do so step by step in an IPython Notebook, and then other scientists can peer-review the notebooks, this might be even more useful to you than version control. It woul

"Now this is a totally brain damaged algorithm. Gag me with a smurfette." -- P. Buhr, Computer Science 354