From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1J4SeO-0001Gq-KO for mharc-grub-devel@gnu.org; Mon, 17 Dec 2007 21:57:44 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J4SeN-0001Fk-2X for grub-devel@gnu.org; Mon, 17 Dec 2007 21:57:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J4SeM-0001FD-F5 for grub-devel@gnu.org; Mon, 17 Dec 2007 21:57:42 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J4SeM-0001Ev-AA for grub-devel@gnu.org; Mon, 17 Dec 2007 21:57:42 -0500 Received: from ns39764.ovh.net ([91.121.25.85] helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J4SeM-0003Ry-3C for grub-devel@gnu.org; Mon, 17 Dec 2007 21:57:42 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 3F1A43EB23 for ; Tue, 18 Dec 2007 04:01:17 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Tue, 18 Dec 2007 03:57:37 +0100 User-Agent: KMail/1.9.4 References: <1196963148.15804.44.camel@dv> <47670FF4.9070701@casema.nl> <20071217202057.ygvk8pyyowsok04g@webmail.spamcop.net> In-Reply-To: <20071217202057.ygvk8pyyowsok04g@webmail.spamcop.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200712180357.38552.okuji@enbug.org> X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Switching to git? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 02:57:43 -0000 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= =20 experienced such migrations twice, and they were always a pain, something=20 that nobody wants to repeat. Some reasons: =2D The repository will be temporarily down (negligible in a long term). =2D All developers are forced to install new software and learn it (always = a=20 pain). =2D All local (pending) changes in working copies become very hard to merge= =20 (extremely painful). =2D It is hard to re-select yet another SCM later, because old software is= =20 usually better supported for migrations, i.e. it's not cheap to migrate bac= k=20 and forth (very painful). Since Robert was in a hurry so much, I had to stop it immediately with very= =20 terse words. I am sorry about that, but please do not make a haste. I have= =20 discussed (and objected to) possibilities to move to another SCM in the IRC= ,=20 the mailing list, etc., but it seems that people forget my words at every=20 time. It's sad to me, as I must repeat the same thing again and again. =46irst of all, this is not a hurry at all. CVS is far from nice, but it ha= s=20 worked well for GRUB for the past 10 years, and we haven't had any critical= =20 problem with it. This is because GRUB is a very simple project from the=20 viewpoint of source code management. You might be excited with technical innovations, but please don't forget th= at=20 it costs to change things. Note that I don't mean that we should't change,= =20 but that we must be a bit more conservative with regard to SCM. Since we ar= e=20 not developing SCM itself, we should consider carefully pros and cons, befo= re=20 making an action. Ok, now about the git. As Tom=C3=A1=C5=A1 pointed out, the lack of portabil= ity is=20 regression from CVS. If you think, for example, grub4dos is important, why= =20 can you choose git? Besides the portability, I don't like the merging algorithm. If my knowledg= e=20 is not completely outdated yet, git still uses 3-way merging, right? I don'= t=20 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. CVS's merging algorithm is also very simple and stupid, but it is not a big= =20 problem, because CVS is centralized. When getting distributed, things get f= ar=20 more complicated and critical, since there are so many corner cases where o= ne=20 cannot see in a centralized SCM. These are the requirements for a new SCM in the context of GRUB from my poi= nt=20 of view: =2D Free Software (definitely!) =2D Good merging algorithm (if distributed) =2D Good web interface (as good as viewvc) =2D Commit notification by email at the server side =2D Good portability (as good as CVS) =2D Ability to track changes efficiently, i.e. annotation (probably support= ed by=20 most SCMs) =2D Usable interface (not like arch) =2D Good user document (like svnbook) =2D No conflict in a (main) repository (not like monotone) Other features are not so important, since GRUB is small. Here are some examples: =2D Subversion (+ svk) is good enough, if we only sometimes want to work=20 offline. =2D Bazaar looks good, if we believe that their claim is all correct. Okuji