Revision control

Hi,

Would there be support for moving to a different revision control mechanism?
Anything is far better than cvs, especially if it's distributed. I saw
there was some talk of this a while ago but nothing happened. We've
got lots of good options to pick from that we know will scale well.


Andrei

Wed, May 28, 2008 at 10:34:41PM +0200, Arne Babenhauserheide wrote:
I like the idea.

It would lower the barrier to begin coding on the hurd (I think), and it would
be a good opportunity to clean up the cvs chaos a bit (so newcomers don't get
completely lost in the different repositories).

Also it has the advantage to remove the central point of failure, which feels
very Hurd-like to me: Everyone has a full copy of the repository, and only
the reference repository is under central control.

Well, CVS is certainly doomed, but I don't think the above two points
are strong arguments. Probably gnumach-1-branch should be moved back to
HEAD, yes, but otherwise, the CVS looks pretty decent to me (note that
glibc still manages to use CVS, which is a far bigger project commit and
code-wise).

Also, a central repo is not much of a SPF, if Savannah goes down with
all its backups, we got bigger problems than worrying about the Hurd I
guess.


Michael

Hi,

Wed, May 28, 2008 at 10:34:41PM +0200, Arne Babenhauserheide wrote:

and the wiki already uses git anyway (even though I prefer Mercurial
myself, since it feels more natural to me and doesn't have to be
cleaned up regularly

Well, I can't comment on the "natural" part, as I don't know Mercurial.
But as for the "regular" cleanup, that is actually one of the really
really brilliant things about git -- this alone IMH would be reason
enough to prefer git over anything else

It just makes so much more sense to let the user decide when it's time
to optimze: It means avoiding a lot of complexity, as well as
compromises to robustness (which are smaller in Mercurial than some
other systems, but yet present), while at the same time offering by far
the most efficient repositories in terms of performance and disk usage.
(If you care to do the GC once in a while.)

- and it works in my Hurd installation :) ).

You have a point here :-)

-antrik-

Hi,

Fri, May 30, 2008 at 10:44:08AM +0200, Arne Babenhauserheide wrote:

Due to the optimizations / repacking, git repositories after gc can be
smaller than mercurial ones (especially for binary data it seems to me
from my own tests), but optimizing takes time (and I'm bound to forget
it all the time :) ).

Eh? If you notice things getting too slow, and/or taking up too much
disk space, this should prompt you that it's time for GC

And if you do not notice, there is no need.

It's not like you need to GC every other day. Unless the repository is
very active, you can probably go without for months

-antrik-

Hi,

Thu, May 29, 2008 at 05:40:29PM -0400, Andrei Barbu wrote:

There's also the fact that moving to something like git is easy []
Since it's a rather simple change, aside from the fact that people
would have to learn a new set of commands, which is a few minutes of
work, []

Unfortunately, that's not quite true

Sure, you can learn the most important git commands in a couple of
minutes. But that will result in a lot of frustration (I have seen it
happen to some Xorg developers): Most cvs commands don't map to git 1:1.
To understand what the git commands do, and how to use them properly,
you really need to take the trouble to learn the basic concepts of git.
Luckily, it's only a few simple principles; but still, using git
properly without at least a few hours of learnig is unrealistic.

Nevertheless, it's definitely worth it :-)

-antrik-

Hi,

Sun, Jun 01, 2008 at 11:24:16PM +0200, Arne Babenhauserheide wrote:

[] but I'd prefer to see the Hurd development more accessible, and
even though there are many good candidates, Mercurial is best suited
for that, at least in my opinion.

How accessible it is, depends first and foremost on what most people
know. That probably leaves Mercurial and git as the only serious
contenders

Among those two, git is the one I know myself. My decision for learning
git rather than Mercurial was influenced mostly by Xorg's (or in fact
Keith Packard's) decision, but also other things like the fact that
Savannah offers git hosting but no Mercurial hosting.

I actually started learning git, I quickly became convinced that I
made the right choice. The thing I really like about git is that, unlike
almost all other software available today, it really follows the UNIX
philosophy, both in concept and in implementation.

git, like UNIX, is based on a couple of very simple yet powerful ideas,
and a set of basic tools doing the work. top of that, you get a set
of high-level scripts to easily perform all typical operations; but the
internals are not hidden behind a limiting interface -- once you
understand how things work, you can use the low-level tools to do about
anything you can imagine.

Not knowing Mercurial, I can't really judge. But I have a very hard time
believing that any other system comes even *close* to the power and
flexibility of git git is not a shiny toy with idiot-proof UI; it's a
powerful tool for serious users.

-antrik-

Hi,

Sun, Jun 08, 2008 at 01:18:25AM +0200, Arne Babenhauserheide wrote:

[] and because of some glitches like having to garbage collect
regularly instead of having a lean implementation in the first place.

Again, this is not a glitch, but a conscious decision -- and a brilliant
one at that IMH I mentioned only some of the many advantages of this
approach.

Would you use a file system you have to repack regularly? Just think
about what would happen, if we build a server on top of git, which
used it as filesystem backend. With Mercurial as backend it would just
work.

A revision control system is not a file system though. And running a
filesystem on it is not exactly the common use case Certainly not
what we want to do with the Hurd repository.

This was one of the things which helped to convince me, that Mercurial
is the right choice for me:

"""Unlike many revision control systems, the concepts upon which
Mercurial is built are simple enough that it???s easy to understand
how the software really works. Knowing this certainly isn???t
necessary, but I find it useful to have a ???mental model??? of
what???s going on.

This understanding gives me confidence that Mercurial has been
carefully designed to be both safe and efficient. And just as
importantly, if it???s easy for me to retain a good idea of what the
software is doing when I perform a revision control task, I???m less
likely to be surprised by its behaviour.

In this chapter, we???ll initially cover the core concepts behind
Mercurial???s design, then continue to discuss some of the interesting
details of its implementation."""

It's funny that you quote this passage: It fully supports my argument
that you need to understand the fundamentals -- much better than I could
ever argue it myself :-)

I wonder whether you were aware, while quoting it, how perfectly it fits
git

And you can easily access all the core functionality of Mercurial
using either the default Python shell (just do "from mercurial import
<module>", or advanced shells like ipython (which I very much
appreciate).

Except if I don't know Python

And that is only one of the many many reasons why libraries are usually
inferior to the traditional UNIX approach of reusing code by invoking
other processes.

But that's a totally different discussion Though it gets us back to
my original point about following UNIX philosophy.

-antrik-

Hi,

Tue, Jun 17, 2008 at 07:47:04PM +0200, Michael Banck wrote:

The point is: The Hurd doesn't need a powerful source control tool, it
just needs something which is much better than CVS and usable by all
possible contributors.

the Hurd has reached 1/100 of the RCS traffic of Linux, a switch
to a powerful tool might be feasable.

That's like saying that it's only useful to run GNU/Linux on very large
servers, because others don't need the power

There is probably a difference between a project with a single
contributor, and a project with more than one. But otherwise, the size
or activity of a project has very little influence on what kind of
things the developers need or want to do regarding version control.

-antrik-