"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > On Tuesday 18 December 2007 02:20, Pavel Roskin wrote: >> If there are any specific problems with git pertinent to GRUB or >> preferences of the GRUB developers, I'm ready to convey them to the >> git developers and take the blame (if any). >> >> We don't have to look for the best tool, just for the best tool for >> this particular project and those working on it. > > I bet that you under-estimate the pain of migrating to another SCM. I have > experienced such migrations twice, and they were always a pain, something > that nobody wants to repeat.
I experienced such migrations a lot of times and have moved projects from: - CVS -> SVN - SVN -> Bzr - SVN -> GIT - CVS -> Darcs And others too. > - 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. > - 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 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. > First of all, this is not a hurry at all. CVS is far from nice, but it has > worked well for GRUB for the past 10 years, and we haven't had any critical > problem with it. This is because GRUB is a very simple project from the > viewpoint of source code management. Sure it's. But all developers want to use more time working on code then dealing with the bad merging of CVS and dealing with cvsps to identify when something has been fixed and like. > You might be excited with technical innovations, but please don't forget that > it costs to change things. Note that I don't mean that we should't change, > but that we must be a bit more conservative with regard to SCM. Since we are > not developing SCM itself, we should consider carefully pros and cons, before > making an action. 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. > 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 > Besides the portability, I don't like the merging algorithm. If my knowledge > is not completely outdated yet, git still uses 3-way merging, right? I don't > describe the math here, as it is (a little) documented in the revctrl wiki: > > http://revctrl.org/CategoryMergeAlgorithm > > As long as git uses this naive algorithm, I am not willing to use it. 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. 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. If I'd going to choose, I'd go to GIT or Mercurial. -- O T A V I O S A L V A D O R --------------------------------------------- E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br --------------------------------------------- "Microsoft sells you Windows ... Linux gives you the whole house." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
