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.
--
Sincerely,
Stephen R. van den Berg.
"People who think they know everything are annoying to those of us who do."
