On Tuesday 18 December 2007 13:05, Otavio Salvador wrote: > > - All developers are forced to install new software and learn it (always > > a pain). > > Developers are used (or ought to) to learn new things since it's of > programming art. I guess learning wouldn't be a problem.
From a theoretical point of view, you're definitely right, but the reality looks reverse to me. For instance, look at the inability of developers to editors... Even if Emacs is far superior when writing GNU-style C code, vi users never try to learn how to use Emacs. When it comes to command-line utilities vs. graphical applications, the situation is even worse. In my experience, (unfortunately) developers are too lazy to change tools. They change, only when they are forced or excited for some (geeky) reason. This includes myself. > > - All local (pending) changes in working copies become very hard to merge > > (extremely painful). > > Just a "cvs diff > /tmp/foo ; cd ~/newrepo ; patch -p1 < /tmp/foo" > works for most of cases and then it's not a really big problem from my POV. It is a problem. It is catastrophic, especially when an original repository is down. BTW, I have 4 different working copies of GRUB locally. All of them have small, different changes not committed. Do you think I would be happy to deal with these changes with a "mostly-working" solution? If I don't see more benefit from migrating to another SCM, I really don't want. > > - It is hard to re-select yet another SCM later, because old software is > > usually better supported for migrations, i.e. it's not cheap to migrate > > back and forth (very painful). > > I guess nobody wants to come back to CVS after getting out from it. You need it, if a new SCM does not have a converter directly. > Agree on that. However since git does offer a CVS server this can be > reduced a lot allowing you and anyother that don't want to move to it > to stay using CVS for hacking. This is nice. > > Ok, now about the git. As Tomáš pointed out, the lack of portability is > > regression from CVS. If you think, for example, grub4dos is important, > > why can you choose git? > > Agree on that too. > > It's not that bad[1] and users can use git with cygwin or via > git-cvspserver. > > 1. http://git.or.cz/gitwiki/WindowsInstall I can't say if it is good or not, since I myself does not use Windows at all these days. I leave the evaluation to someone who uses Windows every day. > While I agree that it's not the best merging algorithm I also fail to > see why it could be a blocker. > > I've been using GIT for a while and I do not see conflicts very > ofthen. Linux kernel also does it and I don't see people complaining > about it. The problem is not conflicts but merging. Usually, people don't understand the importance, until they get weird merging results, and spend several days only to fix up wrong results. However, if you notice a merging problem, you are still lucky; in particular when you merge big changes, it is not easy to see how merging went well. Sometimes, having conflicts is much better, because you obtain a chance to see what your SCM thinks. When merging is done silently, and it is wrong, the effort on finding mistakes is tremendous. > Personally I don't like bazaar due performance problem. It's really > slow for big projects (it wouldn't be a big problem since GRUB is a > small one) and it changes its data format too ofthen. Hmm, I thought they have fixed the performance issues already? About the data format, I have no idea. jbailey, do you have any comment? ;) > > If I'd going to choose, I'd go to GIT or Mercurial. Mercurial is not bad, except for the 3-way merging. Okuji _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
