[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Switching to git?

From: Pavel Roskin
Subject: Re: Switching to git?
Date: Tue, 18 Dec 2007 11:29:52 -0500
User-agent: Internet Messaging Program (IMP) H3 (4.1.4)


Quoting "Yoshinori K. Okuji" <address@hidden>:

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 went through some migrations (CVS to Subversion and CVS to git), and it's not a trivial task, but it's not a big deal for other developers who are not doing the migration.

Some reasons:

- The repository will be temporarily down (negligible in a long term).

Yes, negligible.

- All developers are forced to install new software and learn it (always a

We can alleviate it by switching to software that is already widely used, so that the time invested into learning can be used on other projects. Mercusial and git are good examples, as they are used in many other projects. Monotone and darcs are not so popular; learning them would give less benefits.

- All local (pending) changes in working copies become very hard to merge
(extremely painful).

Actually, the great thing about git (especially when used with StGIT) is that the changes can sit in the local tree without any problem. CVS, on the other hand, doesn't allow any organization of the local changes. They can be exported to a diff file and applied to the new repository, perhaps as more than one patch.

- 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).

That's true, but only to a degree. Any serious contender would have to support migration from git. Mercurial had it from the first months if not days of development.

I don't see why we would need to migrate from git. It's good for Linux, which is a much bigger project. It's under development, which mean that it will improve.

Speaking of CVS, since it doesn't record the changesets, migrating from it to anything will require some guesswork.

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.

I didn't know that.

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.

The problem is, some patches need to be split into series. For example, one patch prepares ground, the other makes the radical switch, the third carries on some simplifications that become possible.

People who learned working with patch series are annoyed by a version control system that doesn't provide facilities for that.

Another problem is bisecting bugs. git makes is possible in a simple, effective and formal way, so that I don't have to look at the dates in the changelog and guess where the next test point should be. I'm not aware of any other version control system providing that feature. The bisecting facility is important to assure code quality.

Finally, things like grub4dos should not be forks, they should be branches. This would give then a better exposure. CVS branch support is pathetic, and the same applies to Subversion, although for different reasons.

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.

I see serious advantages when it comes to attracting developers, fixing existing bugs and improving future changes.

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?

I understand you are concerned about for Windows portability, not about DOS.

git works with Cygwin, and it's not an unrealistic requirement. Looking at the amount of recent changes in git for things like newline conversion, I'm sure that they come from the developers actually working on Windows. An active development community assures code quality and minimal bit rot.

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:

As long as git uses this naive algorithm, I am not willing to use it.

No, git uses recursive merge by default.  But I don't see why it's important.

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.

I'm afraid I don't understand this argument. Linux trees are merged all the time, and nothing particularly bad happens. GRUB should heve less corener cases, not more.

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)

All this is present in git.

- Ability to track changes efficiently, i.e. annotation (probably supported by
most SCMs)

I don't know what it means.

- Usable interface (not like arch)
- Good user document (like svnbook)

git is very close, although the work is underway

- No conflict in a (main) repository (not like monotone)

I think it's a policy issue. In any case, I don't see it as a problem with git.

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

- Bazaar looks good, if we believe that their claim is all correct.

I agree, but in both cases developers will have to learn something they won't be using elsewhere, unlike git.

Last time I tries svk, it was adding some useless (for other developers) annotations to the commit messages, so I thought it would be impolite to others to commit directly from svk to the main repository. StGIT keeps all marks to itself.

Pavel Roskin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]