Should we split git projects across multiple repositories?

Dickon Reed wrote “Recommendations Keep your project source code in a single repository for simplicity as long as you reasonably can while keeping your developers working efficiently. Invest in your build to keep your median automated build and test time as fast as possible – 15 minutes is good, 1 minute is better. Keep large binaries out and…”

Clincher: checking your signed git commits

Tom Parker-Shemilt wrote “Recently for a project with tight regulatory requirements we decided that git signing throughout the project was a good idea. There’s a debate about it’s level of effectiveness, given that all it tells you is that a particular commit was made from a particular developers machine, and if they’re not careful, they can end up…”

Scrutiny: Github permissions audit and backup tool

Tom Parker-Shemilt wrote “These days we’ve all got an awful lot of our code in Github, and so we really need both a backup (so we can cope with them having a catastrophic failure) and a permissions auditing mechanism (so we know who’s getting access). For the latter, some of you may be saying “just use the audit…”

Raspberry Chef

Tom Parker-Shemilt wrote “Last month I wrote about temperature monitoring, and how I ended up using Raspberry Pi’s. I’m still fiddling around with their configuration, and I ran into a few problems. For starters, if I brought them home, they knew how to talk to the work WiFi, but not my home system, and vice versa (although this is…”

By Prashant Shrestha from Kathmandu, Nepal (branches Uploaded by russavia) [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons

Everything you ever wanted to know about git submodules and more

Ashley Hewson wrote “I regularly hear complaints that git submodules are difficult to work with. If you search for ‘git submodules’, then (depending on your filter bubble) you’ll probably get several blog articles warning you not to use them. I agree that the UI is not at all intuitive,1 but like most things in git, submodules are quite…”

Enhancing peer review through GitHub

Frank Shearar wrote “You love GitHub. Of course you do. You love peer review. You especially love sending a pull request back asking for nits to be picked. So when your submitter claims to have addressed your concerns, how do you check? You could walk the commits. You could diff the entire pull request against master. If only…”

Continuous Integration for Github Pull Requests with Teamcity

Ceri Storey wrote “Most developers with an interest in open source software these days have seen the Github interface for handling pull requests, and relatedly, Travis CI’s support for pull requests. And so we thought it’d be useful to have something similar for our internal CI system.”

mercurial-server 0.8 released

Paul Crowley wrote “mercurial-server home page mercurial-server gives your developers remote read/write access to centralized Mercurial repositories using SSH public key authentication; it provides convenient and fine-grained key management and access control.”

Mix and match version control

David Ireland wrote “LShift’s standard version control platform these days is Mercurial, but just before we adopted it, I started a project using Trac and Subversion, mostly because that’s what Trac does out of the box. Later, we branched the project to add a large new project, and during that branch we converted from using ant to Maven…”

Smalltalk vs. Javascript; Diff and Diff3 for Squeak Smalltalk

Tony Garnock-Jones wrote “Many of my recent posts here have discussed the diff and diff3 code I wrote in Javascript. A couple of weekends ago I sat down and translated the code into Squeak Smalltalk. The experience of writing the “same code” for the two different environments let me compare them fairly directly. To sum up, Smalltalk was…”

Adding distributed version control to TiddlyWiki

Tony Garnock-Jones wrote “After my talk on Javascript DVCS at the Osmosoft Open Source Show’n’tell, I went to visit Osmosoft, the developers of TiddlyWiki, to talk about giving TiddlyWiki some DVCS-like abilities. Martin Budden and I sat down and built a couple of prototypes: one where each tiddler is versioned every time it is edited, and one where…”

Mercurial merge technique

Tony Garnock-Jones wrote “We’re using Mercurial here at LShift for much of our development work, now, and we’re finding it a great tool. We make heavy use of branches (“branch per bug”) for many projects, and this is also a pretty smooth experience. One issue that has come up is policy regarding merging the trunk (“default”) into any…”

diff3, merging, and distributed version control

Tony Garnock-Jones wrote “Yesterday I presented my work on Javascript diff, diff3, merging and version control at the Osmosoft Open Source Show ‘n Tell. (Previous posts about this stuff: here and here.) The slides for the talk are here. They’re a work-in-progress – as I think of things, I’ll continue to update them. To summarise: I’ve used the…”

Diff for Javascript, revisited

Tony Garnock-Jones wrote “Last weekend I finally revisited the diff-in-javascript code I'd written a couple of years back, adding (very simple) patch-like and diff3-like functionality. On the way, not only did I discover Khanna, Kunal and Pierce's excellent paper "A Formal Investigation of Diff3", but I found revctrl.org, the revision-control wiki, which I'm just starting to get my teeth into. I'm looking forward to learning more about merge algorithms. The code I wrote last weekend is available: just download diff.js. The tools included: * [cci no_cc="true"]Diff.diff_comm[/cci] - works like a simple Unix comm(1) * [cci no_cc="true"]Diff.diff_patch[/cci] - works like a simple Unix diff(1) * [cci no_cc="true"]Diff.patch[/cci] - works like a (very) simple Unix patch(1) (it's not a patch on Wall's patch) * [cci no_cc="true"]Diff.diff3_merge[/cci] - works like a couple of the variations on GNU's diff3(1) Read on for some examples showing the library in action.”

Choosing a new version control system

Paul Crowley wrote “(Continued from Moving away from CVS) The wealth of options for a replacement for CVS presents us with a problem. We can't choose a version control system by comparing feature lists: what seems perverse when presented in the manual may become natural in real use (which is the reaction many have to CVS's "merge-don't-lock" way of working at first), and contrarily what seems attractive on paper may prove problematic in real use (the system may claim sophisticated merging, but will it actually do what you want given your version history?). Equally, however, trying to use every system in anger would impose a very serious cost: unless we write the infrastructure for every system we test, some live project will have to do without it while they try out the shiny new system, and for every system someone will have to undergo the considerable expense of really learning how to use it and make it behave well. So we have to find ways to at least thin the candidate list. ”

Moving away from CVS

Paul Crowley wrote “When LShift first started off in 2000, the only real option for mature, open source version control was CVS. We've used CVS for most of our projects since then, and gone on to develop a strong infrastructure for managing CVS-backed projects, including a web interface for viewing versions, a web-based searchable database for related CVS commits ("CVSzilla") which infers transactions from multiple simultaneous commits, and integration with the Bugzilla bug tracker. Today, there are many other options, and I'll discuss six major alternatives here: Subversion, Monotone, darcs, Git, Bazaar, and Mercurial. ”