To follow up my previous post on svn/git : Linus has posted a pretty thorough explanation on why he thinks that decentralized SCMs work better than centralized ones. Contrary to his talk at google, this post actually convinced me of his point. Even though it doesn’t apply to all projects (not Rosegarden, for instance, since there aren’t enough developpers to justify this), I now understand what benefits a decentralized system brings in terms of flexibility, with almost no drawbacks indeed.
It really boils down to this : creating a branch and merging it anywhere (i.e. not just to the trunk) should be a trivial operation. Once you have this, branches become a much more useful and versatile tool, and you can start thinking your development from a different perspective.
Well, after months of wait and speculation, Canon finally announced the 40D. Specs look good, though I wish they’d look into a HDR sensor like the Fuji S5 Pro has. I don’t care about the full frame, my walk-around lens is the 17-55 f2.8 IS, for which there’s no equivalent in the EF line (not with IS). And given that Canon seems pretty committed to the EF-S lens line, it’s a safe bet the x0D line won’t be full frame anytime soon.
Aside of that, the real attractive feature is the WiFi grip. Along with the obvious file-transfer features, it also has gps connectivity and enables wireless shooting through http. Now that is geek-appealing :-).
Anyway, bottom line is, for me the upgrade is tempting, but not compelling. We’ll see.
I’m actually typing this while waiting for svn to merge a branch back to the trunk of rosegarden source tree…
Anyway, a while ago, I watched this talk by Linus at Google about his own Version Control System, git. I’ll skip the comments about his attitude and mention a few points I felt like commenting about.
- When Linus says that KDE should have split its repository into multiple ones, I don’t see how that would make things any easier for devs. KDE has a base dependency, namely the KDE libs. How would you split KDE’s code into several repository while avoiding the problem of keeping them in sync ? Doesn’t that break the whole idea of a version control system ? “Hey, I need to backtrack kmail’s code to a week ago to check for a regression, now what version of kdelibs do I need to get it to compile, mhhh, let’s see…”. Yeah, that’s bright.
- I wish Linus would show a basic workflow of how git works
- And to the point of this post : Linus really does have a point when he says that a version control system really must make merging an easy operation. Yeah, even if branching is cheap (and remembering having to lock a cvs repository for hours just to make a tag or a branch, I can appreciate how important that is), if merging is a headache, it does defeat the whole purpose of it. That is, branches will still be seen as something you use only when you really have no other choice. And merging in svn really is a headache, simply having to find the version number of the branch’s origin is dull enough, but merge tracking is way too error-prone. Fortunately it should be part of the next version of svn, but I’m not sure leaving it out was the right decision. Then again they had to cut the feature list somewhere…