openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] Source Control


From: Ger Hobbelt
Subject: Re: [Openexr-devel] Source Control
Date: Fri, 20 May 2011 10:34:34 +0200

Also before you go and pick something, have a very good look at github (github.com): for me it's a major reason to stick with git.
Why?
Because there they offer some very useful graphs, which I use regularly and nobody else offers their equivalent. For example, pick a few projects on there and look at their 'network' graph: you click on a node in the graph and you get the visual diff from /any/ commit, including those who cloned your work. In my case, who's cloned off a few others, it's as useful, as anybody around can 'track' _visually_ who's done what over the past X days/weeks/months and decide whether I'll go and merge their work with mine.

google-code+Hg doesn't offer that sort of thing, at least not the graphic equivalent, and since I'm a rather 'graphic' person, github is it for me.

The other reason for git is the excellent merge ability: I have a few projects (not on github) where we have dual (or more :-( ) branches which need attention at the same time; git is the first which cut my 'merge costs' down to less than a quarter compared to our svn / cvs days, by having a better merge algorithm. (Scenario where multiple branches (git / hg would call them 'clones') see low development speed of their own, but which need to be in sync with everybody else ASAP for other changes in the same source files; before I had the 'joy' of having to go in and do a manual/visual diff/merge sort of code review of the whole thing when we're doing the 'sync' operation in there. Git cuts down the number of spots I have to check tremendously as it has given us zero errors in the automatic merge bit; anything git can't handle is clearly marked in the intermediate output. In my case it means a 4 hour merge/sync work where I need to stay sharp to not let anything wrong pass, is now cut down to a job of 30 minutes to 1 hour, without negative effect on the post-merge/sync test cost/time (just saying this because sloppy work would be caught in the post testing phase but taking them longer as any screwup needs to be fixed after all).

So git for github graphics and git merge ability. If you take out those two elements, it's a 50/50 between git and hg.  Just you stay away from svn (that one has been as 'useful' as cvs to us and in reality only added to the old mess. ye gods. :-( )

Examples to look at to see git/github in action:

- mootools-core (yeah, _javascript_, not C, but doesn't matter. Picked this one because I know it and know the network graph is complex enough to showcase several types of behaviour at the same time, particularly cloning and merging and a relatively large set of individuals working on a rather well known project of comparable scale as OpenEXR)
https://github.com/mootools/mootools-core/network
Just look at the pretty pictures. ;-)

- mongoose clone off google code: see the network graph at
https://github.com/GerHobbelt/mongoose/network 
It's just small stuff (mongoose isn't that big to start with ;-) ) but here I went and did a quick migration of googlecode+hg to git+github, just so I'd be able to see the various clones as a clickable graph in github fashion and track the ones that turn out to be truely interesting - if you want to know what all the clones have been doing when their description 'sounds interesting', you don't want to wade through googlecode.
May sound odd, but writing a few lines of shell script to do this was way faster than extracting the same info from googlecode itself. The graphs also keep 'working' when it's late at night and you're digging through stuff to find something or when you want to decide whom to check out in detail tomorrow.

(And on wading through stuff: 'git bisect' has saved my bacon at a few hot moments! binary search through your revision graph to find the commit where something went belly-up for the first time! Not something you do on day #1, but when the time comes and you need to dig out the point of failure, a serious time saver.)

My 2 cents.



--
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   address@hidden
mobile: +31-6-11 120 978
--------------------------------------------------


reply via email to

[Prev in Thread] Current Thread [Next in Thread]