How Do You Control Your Source Code?

[eluser]jedd[/eluser]
Hi Knitter. I'm a bit of a git advocate / apologist (take your pick) these days, so I'll bite.

I'd recommend you watch the google-tech-talk that Linus gave a year or two ago - it's pretty lengthy (about an hour) but pretty interesting. Available [url="http://www.youtube.com/watch?v=4XpnKHJAok8"]here, at youtube[/url]. It addresses some of the points (and misunderstandings) in your post.

Git has become very popular, maybe because of it's creator, I personally prefer Mercurial, as it was the first I used, in what decentralized systems is concerned.

There was a lot of 'interesting history' wrapped up in the development of git, to be sure, but even if it was written by someone(s) else, it would have been adopted by Linus, and in all likelihood be as popular as it is now.

There's an interesting thread, dating back a few years, [url="http://lkml.org/lkml/2005/4/25/267"]over on the lkml[/url] that involved Linus and Matt, relating to performance and design of Mercurial, and comparing both to git.

I think your point illustrates a common trend though - we tend to prefer that which we play with first.

... I find it's limitations, or design choices as you prefer, to be more annoying the those of SVN, not having a central location for my source ...

I think you might be missing the point of distributed SCM's - and the first link I posted covers this several times over - you can have a central location for your git project if you want to - that's a social or semantic or usage consideration only, rather than a technical limitation. Compare and contrast cvs/svn where you are constrained by that design flaw.

... something that controls the quality of the code, is just moving the responsibility from the machine to the user, and users make more mistakes and use more time than machines.

If you're seeking something to save yourself from yourself, then you might be in the wrong profession.

Seriously,
a) if the quality of your code is at risk because of your choice of SCM, then you have far bigger concerns,
b) I can't see how a distributed SCM could possibly affect the quality of your code.

Also it's performance issues, as noted by Linus, can be a downside if you, like me, need to do a lot of file control instead of "content" control.

I'd be curious what benchmarks you've generated that show svn or mercurial to out-perform git, especially on common functions. Not quite sure what you mean by file control / content control here, either.

But Git has it's strong points, like easy merging of branches, for example, or "content" control, but those are things small projects and teams, especially if branching is something not often made, don't use and end up being wasted. On a small team, using Git over SVN doesn't seem to me as an advantage.

I think if you view your software choices in terms of non-wasted features, you might be missing the point again.

I reckon on a small team - but this isn't based on first hand experience of working within one - git would become even more compelling. And to clarify - I think this, because of its distributed nature, and not because there'd be less features being wasted.

Since I use version control systems, I can count by finger of one hand the times I really needed to branch something that I then wanted to merge into trunk, branching, and tagging, have always been used as a way to mark versions and to allow for support to be maintained.

I reckon that if your history with SCM's is with software that makes branching and merging expensive, painful, arduous, etc - that you'll certainly get into the habit of not using branches and trying to limit your need to do merges. I don't think that it necessarily follows that if you didn't have that experience from using svn, that you'd still adopt the same usage habits with another SCM.

Oh, and possessive its has no apostrophe.