Hi, On Thu, Jun 19, 2008 at 03:11:02PM +0200, Arne Babenhauserheide wrote: > Am Donnerstag 19 Juni 2008 00:46:55 schrieb [EMAIL PROTECTED]:
> > > Once the Hurd has reached 1/100 of the RCS traffic of Linux, a > > > switch to a powerful tool might be feasable. > > > > That's like saying that it's only useful to run GNU/Linux on very > > large servers, because others don't need the power... > > No. > > It's like deciding to go on a trip through the country together and > saying: "We don't need racing cars which run only on a small subset of > the roads and have fancy controls most of us have to learn from > scratch. We want to drive together to a place we don't necessarily > know already." [...] > The difference you name would in my opinion be better described by > saying, we only need OpenBSD on the most critical servers, because for > the others, its gain in security isn't worth the effort to set it up > correctly and the time to learn its quirks. Would you use OpenBSD in a > university as shared working server for people? Both your examples miss the point: These are not suitable for everyday usage, because they are extremely specialised. Git is not. On the contrary, git is extremely generic -- which is precisely what I like about it :-) > One reason for wanting to be able to drive many different roads: The > informatics professor from whom I learned about the Hurd uses Windows > on his presentation machine (on which he also works quite often), and > he wouldn't be able to use Git efficiently in that environment. "Frankly, my dear, I don't give a damn" ;-) It's nice to hear that there are computer science professors talking about the Hurd; but I don't buy the argument that being able to easily access the repository from Windows matters for Hurd development in any way. > > There is probably a difference between a project with a single > > contributor, and a project with more than one. But otherwise, the > > size or activity of a project has very little influence on what kind > > of things the developers need or want to do regarding version > > control. > > Just look at the workflows in Linux and in other projects. As far as I > know, there is a huge difference. Every project has a different workflow -- both small and large. Git is nice because it serves *all* kinds of workflows; it is extremely flexible in this way. Again, that's what I like about it... > But the Hurd isn't in the position to force devs to learn new ways to > contribute (not that I like forcing people to do something they don't > need). It needs developers to be able to jump in easily, and every > programmer lost on that way due to an infight with Git would hurt > quite much. Sorry, I just fail to believe that any serious contributor will be detained by "infight with Git". > And Xen, xine, SymPy, OpenSolaris, OpenJDK, NetBeans and many others > aren't really one-dev projects, so they should be enough hard proof, > that Mercurial works well for bigger projects. And many equally large projects still use CVS, or SVN. So what exactly does that prove?... > But in the end, much about the current distributed version control > systems depends on gut feeling, personal preferences and the needs of > the specific project, since they are quite similar, and there is one > big shiny light at the end of the decision tunnel: > > Whatever we choose, the technical side of switching the files and all > history from one to another is very easy, since there are simple > automated tools for the task (Git to Mercurial as well as Mercurial to > Git). Indeed :-) -antrik-