From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Switching to git?
Date: Tue, 18 Dec 2007 03:57:37 +0100 [thread overview]
Message-ID: <200712180357.38552.okuji@enbug.org> (raw)
In-Reply-To: <20071217202057.ygvk8pyyowsok04g@webmail.spamcop.net>
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.
Some reasons:
- The repository will be temporarily down (negligible in a long term).
- All developers are forced to install new software and learn it (always a
pain).
- All local (pending) changes in working copies become very hard to merge
(extremely painful).
- 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).
Since Robert was in a hurry so much, I had to stop it immediately with very
terse words. I am sorry about that, but please do not make a haste. I have
discussed (and objected to) possibilities to move to another SCM in the IRC,
the mailing list, etc., but it seems that people forget my words at every
time. It's sad to me, as I must repeat the same thing again and again.
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.
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.
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?
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.
CVS's merging algorithm is also very simple and stupid, but it is not a big
problem, because CVS is centralized. When getting distributed, things get far
more complicated and critical, since there are so many corner cases where one
cannot see in a centralized SCM.
These are the requirements for a new SCM in the context of GRUB from my point
of view:
- Free Software (definitely!)
- Good merging algorithm (if distributed)
- Good web interface (as good as viewvc)
- Commit notification by email at the server side
- Good portability (as good as CVS)
- Ability to track changes efficiently, i.e. annotation (probably supported by
most SCMs)
- Usable interface (not like arch)
- Good user document (like svnbook)
- No conflict in a (main) repository (not like monotone)
Other features are not so important, since GRUB is small.
Here are some examples:
- Subversion (+ svk) is good enough, if we only sometimes want to work
offline.
- Bazaar looks good, if we believe that their claim is all correct.
Okuji
next prev parent reply other threads:[~2007-12-18 2:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-06 17:45 Switching to git? Pavel Roskin
2007-12-06 18:04 ` Otavio Salvador
2007-12-07 1:42 ` willem
2007-12-07 11:43 ` Otavio Salvador
2007-12-08 5:39 ` willem
2007-12-08 0:06 ` Vesa Jääskeläinen
2007-12-08 1:16 ` Otavio Salvador
2007-12-08 2:54 ` Pavel Roskin
2007-12-12 14:30 ` Robert Millan
2007-12-12 15:03 ` Otavio Salvador
2007-12-12 16:21 ` Amin Azez
2007-12-12 15:36 ` Pavel Roskin
2007-12-12 16:01 ` Robert Millan
2007-12-15 10:54 ` Robert Millan
2007-12-16 4:32 ` Otavio Salvador
2007-12-16 11:03 ` Robert Millan
2007-12-16 17:21 ` Pavel Roskin
2007-12-17 7:02 ` Yoshinori K. Okuji
2007-12-17 11:11 ` Markus Elfring
2007-12-17 23:53 ` willem
2007-12-17 11:40 ` Tomáš Ebenlendr
2007-12-17 12:20 ` Markus Elfring
2007-12-17 11:58 ` Otavio Salvador
2007-12-18 0:10 ` willem
2007-12-18 1:20 ` Pavel Roskin
2007-12-18 2:04 ` Otavio Salvador
2007-12-18 2:57 ` Yoshinori K. Okuji [this message]
2007-12-18 12:05 ` Otavio Salvador
2007-12-18 18:30 ` Vesa Jääskeläinen
2007-12-18 21:32 ` Pavel Roskin
2007-12-21 17:54 ` Vesa Jääskeläinen
2007-12-19 0:11 ` Gregg C Levine
2007-12-22 8:28 ` Yoshinori K. Okuji
2007-12-22 11:16 ` Robert Millan
2007-12-23 4:58 ` Pavel Roskin
2008-01-04 17:06 ` Jeroen Dekkers
2008-01-04 17:39 ` Otavio Salvador
2007-12-18 16:29 ` Pavel Roskin
2007-12-22 8:50 ` Yoshinori K. Okuji
2007-12-22 11:20 ` Robert Millan
2007-12-22 12:28 ` Yoshinori K. Okuji
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200712180357.38552.okuji@enbug.org \
--to=okuji@enbug.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.