martin f krafft wrote: > also sprach Matthieu Moy <[EMAIL PROTECTED]> [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
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
