Revision control

chill

I'm looking to implement some sort of revision control at my company. I know some of you are doing this, and I'd like to know what you're using, how well it's working for you, etc. I'm looking at subversion and git, and know something of the pros and cons of these. Anybody using either one, or do you recommend something else? Why?

We typically have many small projects - probably a dozen or two going at any one time, plus hundreds or thousands archived. In many cases, we'll have an upgrade to a system that we did years ago. Personnel are three each senior and junior programmers, plus the occasional subcontractor.

Thanks!
.

catalino

I work at a large University managing around 100+ classrooms. I use Git for all of my repository needs. I put in a gitignore file to ignore .src, .tko, and .tkn files unless they're specifically for proprietary modules, but I try to avoid that as much as possible and just store plaintext. I host it on a private github repository for code sharing and collaboration. I inherited a large amount of codebase but am trying to slim it down into two or three generalized codebases in order to cut down on maintenance work, because right now it's a maintenance nightmare. Collaboration is great with Git because it allows each user to modify their own copies locally, and the extra features Github provides a team with pull requests, etc. is fantastic. I haven't found a good way of dealing with touchpanel files, if there was a way of serializing the touchpanel data into a text file that would be wonderful. Hit me up if you have any specific questions about workflows or how to get familiar with it.

chill

One of the things I like about svn is that it apparently has no problem with binary files, presumably including .tp4. And it seems that svn also does deltas for binary files, which is excellent.

On the other hand, our guys often don't have internet access in the field, so I like the 'local repo' that you get with git.
.

catalino

Git also has no problems with binary files and does differential commits, and just the workflow encourages more frequent commits. I often do several branch commits before i merge into the production branch. Branching and merging are really a feature and strength of Git. Since the axs files are just glorified text files anyway, browsing and commenting on Github really is what makes the whole system worthwhile when working on a team.

PhreaK

After running subversion for years we've finally made the switch to git. Lets just say I now puke rainbows.

Don't get me wrong, subversion is fantastic and a highly useful tool however, the centralized approach can be somewhat of a pain as soon as techs are without a persistent connection to the repository.

Where git really shines is when you have multiple programmers working on site. They may or may not have a network connection to the outside world but they can easily set up a connection with each other (or if they can't, do a bare clone to a thumb drive and throw it across the room to each other) then push, pull, fetch and merge at will. Even if there's only one guy working away he can continue to commit locally, retain a nice granular history then push this elsewhere when a connection is available.

Workflow wise we use this branching model and have a bare clone sitting on a network share that is considered the 'central' repo. Every device module and set of common libraries gets its own repository and is versioned using Semantic Versioning with each 'release' (aka merge into the master branch) tagged with an appropriate version. Every system / system type then gets its own repo to store system specific guff in and pulls in the required modules and libraries via git submodules that reference the release tag. This removes any duplication of common components, provides uncluttered and project specific logs and ensures changes to one module will never break a system that links to it.

ericmedley

Currently using SVN and am firing up Git. For what we do, Git seems to be a little better solution.

rfletcher

We currently use SVN. I've thought about switching to either Git or Mercurial, but with only two of us accessing the codebase at this point (me and our service tech) I can't decide if it's worth the effort. If I were starting from scratch I think I'd pick one of those two though.

-Ryan