Re: [Openexr-devel] Source Control

[Ger Hobbelt]

On Fri, May 20, 2011 at 4:01 PM, Bob Friesenhahn <address@hidden> wrote:

While I have not used the feature yet, I am told that Hg Queues offers fantastic import/merge capability as well.  Here are some pages which describe this feature:

http://mercurial.selenic.com/wiki/MqExtension
http://mercurial.selenic.com/wiki/MqTutorial

I assume it'd be good, because Hg and git are in some pretty stiff competition, so Hg's got to have a good import/merge ability or they wouldn't have survived upto today.

The only thing I can say is this: I've tested the git merge and hg abilities about a year ago, based on the advice on the net and in a couple of books about these systems and for the projects where I had the toughest time to make sure any merge/sync op would not produce a plethora of regression issues and other crap in the next test round, git came out on top. I seem to recall it was by a nose-width, but I was looking for a system that was smart enough to stop being 'smart' when it couldn't handle a three-way merge. Git then (and now) meshes very nicely with my original visual diff workflow -- which I use to resolve to the markers == unresolved chunks spit out by git. Since it was an often recurring job (and a nauseating one), I have figures for this bugger: 4 hours per merge/sync on cvs (and svn), <= 1 hour for the same on git. Those are numbers gathered from about a year using each, that's why I don't have Hg numbers; it quickly dropped from our tests as we got something (git) which did the job and no surprises.

 

>https://github.com/mootools/mootools-core/network
 >Just look at the pretty pictures. ;-)

This looks pretty neat.  I assume that it works if all cloned repositories are hosted by github so activity can be tracked.

Yep, of course.

Since OpenEXR is OSS, you can host it there for free; if you want to do your own flavor off it (a clone / branch), you can do so at ease. 

Their ticketing system was crap a year ago, but that's improved enormously and integrated well with features such a commenting on the visual diffs (click on node in network graph or go to commit URL straight away: click on line number to add comment which is transmitted to submitter of commit; from there you can discuss. Commits can be linked up to tickets in the commit comments, tickets and docs can link to commits, so you can create arbitrary ticket/commit/comment/doc graphs. (graphs, not graphics ;-) )

 

> For example, features would be lost if a clone was hosted at SourceForge or on a private machine internal to ILM?  Since OpenEXR is still primarily developed at ILM, I assume that they will maintain their own internal private repository and then push their changes to the public repository once they have been blessed via some internal procedure. This model seems like a major advantage for Hg/Git vs CVS/SVN.

To give an example of that, and, yeah, you don't get a pretty picture of stuff you don't have available for them to munch on. I have here a few commercial projects which aren't going to end up on github, ever. So I'm 'stuck' with what everybody else's got when they use git or Hg re tooling; I have a couple of scripts for some projects and a 'manual action' on others when I want to move code from the commercial branch to the OSS git repo; I have a local copy of the github repo (with git you always make local copies anyway and do 'git push/pull/remote update', so nothing special there; the commercial (local) repo is located on another share and linked to the OSS one through 'git remote add <name> <path>'; any 'git remote update' in the OSS one syncs with the commercial one without github seeing anything.

Only when I perform a 'git merge' into the master (or other) branch or when I've done a 'cherrypick' is the code/content pulled in the OSS local and the next 'git push --all' will pump that data to github to become visible for everyone.

If you feel unsafe doing it like that, you can always place a 'security check' repo in between (we call it a 'redaction repo', in-house terminology); one project of mine has that: the OSS code (in this case it's a C API for a stock market tool) knows a local remote which is just there so we can doublecheck nothing undesirable is going 'out'. Stuff that's for public consumption is merged from the local 'real live' development repo to that intermediate 'redaction'; it is checked at some point and when that repo produces only the intended stuff is it signed off for merging into the public OSS repo which is linked with the github 'remote'. (If there's 'too much' in there we can simple git checkout HEAD^^^whatever; git reset --hard and for total paranoia there's a 'git gc'; we've checked and git checkout + reset --hard to rewind the repo is good enough to nuke anything that's not meant to be in there.)

Two stages before stuff goes out may sound 'odd' but it's financial stuff and then the extra 'redaction' stage is desired; moving the stuff from the intermediate repo ('redaction') to the local clone / github is a few command lines; not worth scripting; I do that by hand.

 

> The pretty network graph depends on the user's browser supporting the Adobe FLASH plugin.

Yup.

But when you're developing on a box that's only got, say, Konqueror, installed, then you still got all the other access at github; you only 'loose' the pretty picture of that network graph. It's a thing that's 'bloody handy handy to have around' for certain task, but look at gitorious (another git hub): they don't have a graph like that and they're doing fine. Similar to googlecode. So that's your 'downgrade path', in a sense. :-)

When you're behind strict corporate firewalls which prohibit Flash you're without the network graph (have seen that with banking, but with ILM, which is a graphics-intensive company itself, I'd be at least a bit surprised when development wouldn't have access to Flash)

> "fringe" operating systems

can thus use git / github just like everybody else. If you want graphs on 'fringe', I guess you'll have to port gitk or tool something if you want those graphs. Again, you're not /forced/ to use them. I'm using them a lot because I find it easier to hover over the nodes in there to see what's going on, then pull a 'git log' or view the commit log / change / diff pages at github.

So no worries, mate.

I run commercial stuff and share bits and pieces of that on github; never been bitten and took some sanity measures to make sure I don't get bitten. And since I test and sometimes develop on Linux server boxes (no gui whatsoever; having lynx is luxury) I still use the full power of git on those boxes as well as on the main dev stations (Windows).

-- 
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
--------------------------------------------------