> >more mature in what sense? if everyone uses git on the client side then > >the maturity of svn on the server does not muy anything because you > >still have to deal with git. it only adds hassle which wouldn't exist > >otherwise. > > 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.
We're clearly getting into a hand-waving area here. I don't have any solid evidence where either git or svn might cause integration problems or breakage. I'd have to implement pelix-NG with both tools to provide that. 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. 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. Anyway, arguments like that are a bit FUDish. To get to an earthlier level it's probably required to look in more detail how the server setup would be in either case, which tools around the repo would be used, how much work there is to fix it, and how willing people are to do that. Personally I don't have much to contribute to that debate. > 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. > 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. (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.) 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. > 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. 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. Btw, git-svn choked on the pike svn repo. I let it run through the night and it had only gotten to 0.7 by the morning, and each imported commit and tagging was becoming slower and slower. Something there isn't scaling properly. Haven't dug into it very much, though.
