Re: [Gnu-arch-users] Re: Future of GNU Arch, bazaar and bazaar-ng ... ?

[John A Meinel]

martin f krafft wrote:
> also sprach Matthieu Moy <address@hidden> [2005.08.23.1133 +0200]:
>
>>>You have half of a point. As neither of the arch frontends supports
>>>automated consistency checks, you can't ensure that any commit was
>>>tested beforehand.
>>
>>That's trivial to do with a precommit hook.
>
>
> How do I ensure that all developers run this hook?
>

Method 1: Set up a pqm, which is configured to pull patches and make
sure the appropriate tests are run before committing to mainline. This
denies users direct access to the repository, so you are sure that all
commits are properly done.

Method 2: Same thing, only a human does the work of pulling things into
the mainline. They can automate their own tree (put something in
~/.arch-params/hook) to make sure the right thing is done.

Method 3: Go to *everyone's* personal working directory, and make sure
that they have ~/.arch-params/hook setup correctly before allowing them
to commit to the main repository. Have them vow not to mess anything up,
on pain of being denied commit access.

The issue here is that you have a dumb filesystem, you don't have a
server process running that can enforce anything. So you can use a pqm
to setup a server process that does the enforcing.

Alternatively, it looks like bzr will get a SmartServer at some time in
the future. For some of us (myself), I'm very happy having a dumb
filesystem to push things to, it's simpler to setup, and I don't need
the overhead of a service. All the details haven't been fleshed out (do
you ssh in, and spawn a process, or does it just wait on a port, etc).

But I have little doubt that it could support plugins and hooks on the
server side. So you can have a single process that writes to the archive
again, and it can be the point of serialization, and making sure nobody
does bad things to your archive.

Just remember, that while you probably want your mainline to always be
consistent, it is very useful to be able to commit a broken tree (like
because you are falling asleep/going home/going to work), even if only
in a local tree. (Though going to work might require pushing those
changes somewhere else).

One of the issues I have with Aegis is that it requires all changes to
pass the test suite (and expects you to add a new test for any new
changes). I think this is a great thing when you have a stable codebase,
but to me it hurts incrementally changing and fixing things up. But that
is also what branches are for.

John
=:->

signature.asc
Description: OpenPGP digital signature