An intresting article on GIT's growth

[dannyt]

HI,

I was reading this article today about the growth of GIT and I found the figure below quite interesting, plus there were a few comparison comments that were informative.

but Eclipse's 2011 survey of 704 developers still has Subversion as the source code management system of choice, with 51.3 percent of respondents using it. CVS, also a centralized system, comes in second at 13.3 percent. Git follows with 12.8 percent, while Mercurial was used by 4.6 percent

It placed the user base of GIT as much greater than Mercurial and yet I have noticed in the LabVIEW world a general settling on Mercurial & SubVersion

cheers

Danny

[Tim_S]

HI,

I was reading this article today about the growth of GIT and I found the figure below quite interesting, plus there were a few comparison comments that were informative.

It placed the user base of GIT as much greater than Mercurial and yet I have noticed in the LabVIEW world a general settling on Mercurial & SubVersion

cheers

Danny

I'm not familiar with Mercurial or Git; we use SVN at work. One thing that flags my attention in the article is that it states that Mercurial does not handle large binaries well, which indicates to me that it could have issues with the size of some LabVIEW VIs. There is also some allusion to the SCC method being to copy all files to everyone's machine, which would be bad for us as our development laptops do not have huge hard drives (~75 GB).

Tim

[dannyt]

I'm not familiar with Mercurial or Git; we use SVN at work. One thing that flags my attention in the article is that it states that Mercurial does not handle large binaries well, which indicates to me that it could have issues with the size of some LabVIEW VIs. There is also some allusion to the SCC method being to copy all files to everyone's machine, which would be bad for us as our development laptops do not have huge hard drives (~75 GB).

Tim

Yes I noticed the comment about large binaries. I think it depends on the project size you are working on, small tool-set type projects it is not a problem, but large application maybe be a different matter

Danny

[asbo]

I've used both Git and SVN, though most of my experience is with SVN. I like the concept of DCVSes and that was the biggest draw for me to Git. I didn't use it for many binary files, but it worked great for loads of text-based code. On the other hand, I still don't know its terminology and often find myself thinking in terms of SVN jargon. With that in mind, I'm thrilled to see that SVN 1.8 will bring offline commits.

I see the power and flexibility of Git, especially in community-based projects, but I think for LabVIEW development in particular SVN 1.8 will be perfect because most of our workflow depends on the lock model, and with offline commits, I don't see much else that Git would bring to the table for binary-based development.

[Black Pearl]

Offline commits sounds interesting. The main troubles I had with SVN is to manage changes I coded at customers location. At least took me a frustrating half an hour or so.

Using mercurial (and above article statesit is pretty similar to git) did resolve these issues in an elegant way. It proved to be robust enough to accept copy&paste behaviour instead of the correct push&pull way to sync between the hard disc of the dev PC and the USB Flash drive.

Having to deal with possible IT infrastructure changes, I'm glad to rely on a tool that will be able to adapt to those changes very quickly. I'm unsure if SVN will be able to catch fully up yet with the robustness I found in mercurial.

Concerning binaries, the members of my team doing electronics use mercurial as well. And I think they were transfering their schematics and layouts via USB from one member to the other as hg repositories, as available manpower and project timeline did require.

One thing we do is to reflect the modules in the system and not the complete system (doesn't really make sense to store electronics design and software/code in the same location/container), and keep those small enough to be managed by one person and passed along quickly. Second we have a very fast and direct communication inside the team, so we actually very much fullfil the requirement of 'collaboration' imposed by DSCVs.

It's pretty much an evolutionary process you can have in R&D teams, but might be problematic if you need to manage production throughput or document formally (documentation is always worth the effort, even in case of failure) to fullfil regulated industry standards or the like.

Felix