Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days.
But it is as you say: It is maturing very fast, hence it's not mature yet. I found several new and semi-essential features just by moving from the latest Ubuntu package to the latest upstream release.
Please keep in mind that many, if not all, of those initially missing features are things which never existed before in any VCS. So it's not really fair to compare that to e.g. SVN where some of those features are simply not viable.
I think it's reasonable to say that a lot more is changing, and some of it at deeper levels, in git right now than in svn. That means both that there's still a need for such changes, and that the changes increase the risk for bugs.
In theory, you're right. In practice, however, I've seen corrupted SVN repositories more than once (myself and on the net at large), with both FSFS and BDB backends, simply spontaneously (because you killed an SVN update at an unfortunate time, or ran two updating commands simultaneously and the locking got mixed up); and also because I tried to fix history by editing the SVN-dump files, some changes in there are highly non-trivial and rather errorprone.
Contrary to that, the git core repository format layout hasn't changed since the start, is very simple and does not break even when updated concurrently (it was designed with robustness in mind). Even if it should break due to disk-sectors going south, most of the repository is still retrievable (there have been documented cases, the standard git tools usually recover it quite nicely). So the development in git concentrates mostly on the user-interface, *not* on the repository layout. I.e. the number of bugs you're going to be encountering have zero effect on your already committed history.
Even stronger: released git versions have (not to my knowlegde in the past year) never resulted in corrupted repositories (due to bugs). Development versions have in some cases resulted in corruption, however, that corruption was always in the repacking code, not in the base repository, and therefore were always 100% recoverable.
Indeed, for every CVS/SVN command, there is an equivalent git command. /.../
You can't honestly believe it's that simple. The commands are different, the output is different, many core concepts are different, there are subtle semantic differences in the kind of data you put into the commands and get back.
Git can be made to emulate SVN/CVS, the other way around is close to impossible. Let's just say that the amount of effort required to make git behave similar enough to CVS/SVN is not easily determined.
Which properties are you missing (git has properties, like file modes, BTW)?
The eol handling property is nice when the same file is edited from both unix and windows. Content type is also good to allow better diffing, annotation and merging.
"man gitattributes" addresses most of these issues.
(In svn it's currently only used to tell text and binary files apart, basically. But the possibility for more content-specific plugins exist. A fully structural diff/blame/merge for xml files would be quite neat, for instance.)
"man gitattributes" allows you to specify custom merge strategies for xml files, for example.
In-file expansion of $Id$ stuff can be controlled with them too. Which, btw, is something I haven't found in git. Putting the commit hash inside the file would invariably change it, so that's not possible. I guess the best one could do is to expand it with a timestamp and the closest tag, but even so it'd be a useful feature.
"man gitattributes" solves that too, ident attribute.
Git gives you tools to actually fix that with a small price to pay: anyone who already synced from that branch, will have to rebase, but other than that, there is no downtime, no complicated dump-editing; it's all less-filling and easy to use.
I wouldn't call that price small, though. It's good that the possibility exists, but it should be used only in extraordinary cases.
That price is small in comparison to the effort needed in SVN (editing and reimporting every time); in git you can fix immediately if the fix is in the vicinity of the tip of a branch; fixing things deeper down can be checked in immediately in git and be verified/accumulated as you go along, and then at an appropriate time the whole repository could be rebased (but the latter, I agree, should be rare if ever; in SVN though, it's not really workable).
Another detail in the comparison is that windows support for svn is infinitely better. Not that windows is a very important platform for us, but we are afterall attempting to change that a bit.
That statement would have been true december 2007. Windows support for got has come a long way since then. I'd say "infinitely better" is way too strong these days, but I admit that SVN still has a slight edge there; git is closing that gap faster than you'd think though.