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.
Comment removed (Score:5, Insightful)
Re:CVS or Subversion (Score:5, Insightful)
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: (Score:2)
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.
Git manual (Score:2)
B*llshit.
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: http://git-man-page-generator.lokaltog.net/
Re: (Score:2)
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)
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)
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:CVS or Subversion (Score:5, Insightful)
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: (Score:2)
Re: (Score:3)
Branching works fine in SVN.
Re: (Score:2)
Re:CVS or Subversion (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Re:CVS or Subversion (Score:4, Informative)
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.
Re: (Score:2, Funny)
Jeez, you really drank the git Koolaid didn't ya?
Re: (Score:2)
Dude, wow. I've used both git and svn, and there's little wrong with svn. git is nicer for extremely distributed projects, yes, but 15 people is not extremely distributed. They'll probably have about 10 people working on the trunk and 1-5 people on experimental branches. That's not a situation that is going to require git's advanced branching/merging capabilities.
And in any case, get a grip. We're talking about version control systems, not insulting your personal honor.
Re: (Score:3)
Have you considered getting over yourself?
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
EasyMercurial (Score:4, Informative)
I'll second the recommendation of Mercurial. There's also EasyMercurial, a nice little dead-simple GUI front end that lets you do a handful of the most common things (checkpoints, history overview, version comparisons, reversions, branching and merges) without having to learn much about the details. Very nice for beginners to get their feet wet with version control systems, and if/when they need something more powerful they can always use the command-line tools directly, or migrate to a more feature-rich GUI. But honestly, for a bunch of people without prior experience even the heavily restricted feature set will be a huge step forward.
There's probably similar "beginner" GUIs available for most of the major VCSes, but EasyMercurial is the only one I can vouch for. I would also lean towards recommending a distributed VCS that offers easy branching and merging for a bunch of VCS beginners - they seem to offer far less conceptual/procedural overhead to the "lone wolf" work flow, and thus are more likely to actually get used effectively.
Re: (Score:2)
However, it is missing some things on your "Things that would be great" list, but not many. Not at all with some of t
Re: (Score:2)
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)
> 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: (Score:2)
Re: (Score:2)
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)
Re: (Score:2)
Re: (Score:2)
Serious question, as I'm not really a coder... what makes Git harder on newcomers than svn, cvs, and so on? I've touched git, hg, svn, and cvs, and of them, git/hg seem to be MUCH easier to work with than subversion or cvs (especially cvs - I hate more than is healthy).
From my layman experience I'd consider git and mercurial more or less equivalent. The only downside I could see is how clients effectively get the whole branch history locally, which can grow to be pretty large if people aren't disciplined a
Re: (Score:2)
Yeah, because the submitter who professes to have absolutely no idea what he's doing will surely do a much better job staying on top of security.
Re: (Score:3)
>
why would you ever use cvs or svn instead?
Lighter weight, more mature and stable codebase, and a smaller footprint on the clients? Just to name a few things... It is a fool who has only one tool in their toolbox.
Re: (Score:3)
You see, I'd say git is better for compliance... as a solo developer, I have used svn and git extensively, and there's basically no difference between them - EXCEPT - git works when the server is down, or you are mobile with no connection.
And if you happen to be working collaboratively, you are always branched, so you aren't really forced to merge something back to trunk or get all sorts of crap permissions worked out to continue to use version control - if the branch won't merge easily - F it, it's a branc
Git (Score:2)
Except
That's not really a function of version control
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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: https://github.com/OpenMW/open... [github.com]
Click on the green check marks or red 'X's. This is something github has integrated into their system, but th
Continuous integration (Score:2)
In fact, what you want is several different tools, at least a VCS and an integrated build:
https://en.wikipedia.org/wiki/... [wikipedia.org]
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
Re: (Score:2)
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.
Re: (Score:2)
git meets your needs (Score:2)
I think git [git-scm.com] 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 [git-scm.com].
- For inexperienced developers, there are tutorials like this one [github.io].
- Here's decent guide to getting password-less authentication via ssh working on Windows [beanstalkapp.com] to connect to a server running locally on a Windows box (as long as it's running OpenSSH, maybe via cygwin [cygwin.org]).
- You can use Git hooks [git-scm.com] to do notifications, run syntax checks, etc.
I like (Score:2)
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 (https://help.launchpad.net/CommercialHosting). 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)
Use Git (Score:2)
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 github.com 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: http://www.gitguys.com/topics/... [gitguys.com]
Re: (Score:2)
Re: (Score:2)
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
Run docker in a virtual machine (Score:2)
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: https://git-scm.com/download/g... [git-scm.com]
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: https://docs.docker.com/instal... [docker.com], which means you'll have access to tens of thousands docker containers for various purposes such as gitlab: https [github.com]
Git, obviously, but there's a way to make it easie (Score:3)
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.
Re: (Score:2)
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)
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 probably go with Subversion (Score:2)
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
Git (Score:2)
Git. The best. Whether your company has one employee, or hundreds of thousands.
Stay away from git for "inexperienced team" (Score:3, Informative)
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.
Re: (Score:2)
> For example, this weekend I'm fixing a mess where three different developers rebased and made every commit from the past two years appear as their own.
This is _precisely_ why projects need tags. git's history is more vulnerable to stupid changes than Subversion's.
> Then, a third developer got angry and did a force push to delete all of the files the other two changed.
And this is _precisely_ why github.com has a "do not allow forced pushes" option today. And again, it's why a project needs tags.
>
Re: (Score:2)
Force Push doesn't delete data from Git you realize. It's still there, the commits are still there, until you GC them out. Maybe - assuming they're not pointed to by anything. There are ways to do it, but this is not one and if your project is public in anyway then it's dangerous advice that this works.
Also ff someone force pushes to a git repo you rollback the reflog to before the push to get to a known good state. Which again: is why force push doesn't delete things.
Re: (Score:2)
A "force push" after a "git gc" is precisely the dangerous problem I've seen. The "git gc" is used to clean the local repository of dangerous commits with confidential information, or with bulky items that should never have entered the repository. The "force push" is then used to clear them from the central repository.
Keeping the data out and preventing accidental remerges from remote repositories can get awkward, it's true.
Re: (Score:2)
Experience is overrated. An inexperienced team of reasonably smart developers can learn and implement one of the simplest git workflows very quickly. I'd actually expect them to do that by themselves, without the need of babysitting.
From what you describe the problem is not the team being inexperienced, it's the team being dumb, indisciplined and unprofessional. With such a team I think the choice of VCS is the least of your problems and even plenty of "experience" won't help that much in the long run.
What will you ACTUALLY be doing? (Score:5, Insightful)
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: (Score:2)
All these weird requirements (reports, bug tracking integration, email notifications..) are
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
Re: What will you ACTUALLY be doing? (Score:2)
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.
TL;DR GitLab/Git (Score:2)
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)
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)
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.
git (Score:2)
They all suck (Score:2)
Re: (Score:2)
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?
Re: (Score:2)
About a year later I started at Blackberry, who were using Preforce. I updated development code into the main repo
Re: (Score:2)
Well that's your problem -- you should have been using Perforce.
Whatever you use (Score:2)
Ok, others seem to have missed this (Score:2, Informative)
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
SVN/Trac for a small team (Score:2)
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
Mercurial is a good starting place (Score:3)
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*
Who is the project lead? (Score:2)
"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
The goal is modern, supported, popular tools? (Score:2)
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
subversion (Score:2)
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
IPython Notebook (Score:2)
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.
http://ipython.org/notebook.html [ipython.org]
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
Re: (Score:3)
Re: (Score:2)
I'd agree. Git is very powerful, in the same way that a double-ended chainsaw is very powerful. You can cut a lot of wood but you can also get seriously hurt. The thing is, Git isn't something where you can just follow a few simple formulas and have it all work. You really have to understand what it's doing and what the underlying model is, and even for people who are experienced with version control, that's going to take some time. I used Subversion for a while and it may not be as powerful, but for a
Re:git (Score:4, Insightful)
I don't know that I share the same experience. There are plenty of UI tools [git-scm.com] 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: (Score:2)
I haven't used git for a while so I don't recall the details, but I was with a small team of very experienced developers, and even for us going to git had a bunch of surprises. For me it's not so much the UI tools, it's understanding what's going on, and why git does what it does.
That's what I mean when I say there's no simple formula of "do these 3 commands to do this, those 2 commands to do that". You have to understand WHY the commands are doing what they are doing.
I'm even farther away from SVN, but a
Re:git (Score:4, Insightful)
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:git (Score:5, Informative)
I was with a small team of very experienced developers, and even for us going to git had a bunch of surprises. For me it's not so much the UI tools, it's understanding what's going on, and why git does what it does.
That's what I mean when I say there's no simple formula of "do these 3 commands to do this, those 2 commands to do that". You have to understand WHY the commands are doing what they are doing.
That's certainly a common view of Git, but after using it for the last few years, I think that a lot of the problems that beginners have with it are happening because of this assumption. That is, when a developer asks how to merge their code into the shared Git repo for the first time, the wise old Git gurus point them at a site that explains how Git works at the molecular level, called The Git Book. This is almost never helpful, because your average Joe C. Programmer doesn't have time in his schedule to read an entire book, and even if he reads it over the weekend instead of, you know, having a life, he just ends up with his head full of crazy circles-and-arrows diagrams, which, divorced from any concrete, hands-on practice, only serves to confuse the issue more.
What the inexperienced Gitsperson actually needs at that point is a short and to-the-point workflow that he can use to get his goddamn code in the goddamn repo, like (commands for illustration purposes only, I use a Fischer Price GUI): "git clone MyRepo; git switch master; git pull; git branch MyFeature; git switch MyFeature; [implement the code changes]; git commit; git push; git switch master; git pull; git merge MyFeature; [fix conflicts, resolve, commit again if necessary]; git push". And for the love of God, Newbie, please don't try to use "rebase", you'll just cripple our entire product at 5:30 pm on a Friday.
There's documentation of that kind out there, admittedly, but it's really hard to find among all the indistinguishable-from-autogenerated-prank-nonsense man pages and fifteen-part seminars on how the version hashing algorithm works.
Re: (Score:2)
(commands for illustration purposes only, I use a Fischer Price GUI): "git clone MyRepo; git switch master ..."
$ git switch
git: 'switch' is not a git command. See 'git --help'.
I must say you're not painting a pretty picture.
Re: (Score:2)
Comment removed (Score:5, Informative)
Re: (Score:2)
Re:UH oh (Score:4, Insightful)
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: (Score:2)
The hardware company I work in has all the usual languages and tools available. It's up to the engineers to use the right tools for the job.
Re: (Score:2)
I'm so sorry.
Re: (Score:2)
Which summary did you read? The one I read said they're looking at switching to Python, away from LabVIEW. That's perfectly understandable. LabVIEW is completely proprietary, and on top of that, it's really hard to find someone to take the job. I had some company try to talk me into a LabVIEW job a while ago, even though I had precisely zero experience with it, and no interest. Just because I have a EE degree and a lot of background in software (mostly embedded programming), they figured they could con
Re: (Score:2)
I'm not familiar with LabView. I just saw C and Java being replaced by Python. Depending the situation, it might work. Or might not. If the summary said, "we're moving away from a proprietary environment," I wouldn't be complaining about summary.
Re: (Score:2)
The summaries on this site are always awful.
Re:UH oh (Score:4, Insightful)
Re: (Score:2)
Yep. Python uber alles. And you would think that if people have the chops to program in Java or C that they have a pretty good handle on versioning, too. So I think there is a problem with the way the original poster is thinking of the problem.
Re: (Score:2)
Yep.... Different programming languages have different merits. "Rewrite everything in X" or "use X for all new work" is a bad idea, unless all the things you are writing happen to be most suitable for X.
I can see switching from Java to Python, as they have a very similar use case. I think recoding C code into Python just to standardize on a language, would be insanely idiotic.
Choose the best language for each job.
If you have a choice: standardize on a few best of breed languages for all common jobs
Re:UH oh (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
Mercurial: I personally haven't seen any other VCS easier on windows
Subversion is easier. It does have less features, but from ease of use, that can be a good thing!