Re: [AD] CVS access to Allegro

[George Foot <george.foot@xxxxxxxxxx>]

On Sun, Apr 09, 2000 at 11:29:19PM +0200, Stepan Roh wrote:
> The most common is to have a maintainer for each consistent part of the
> library.

I don't know whether that's effective here though... the whole
idea is that it's all independent of who's around to do the
updating.

> I suggest to have a web-based patch tracker system. I saw one on Freeciv,
> it's called Jitterbug, but they use it very inconsistently so some patches
> are there and some are not :-( Just have a system where there will be the
> list of patches with status indicator (Incoming, Refused, In progress,
> Applied) along with a maintainer name (except for Incoming which was just
> sent). Maintainers can easily change status of patches (access should be
> authorized with password of course) via browser.

That's a possibility.  Another is to use CVS's facilities for
marking who is working on files in the repository -- you can
effectively lock files against updates by other people, while
you do your updating.  I have no experience of this, but the
documentation (on my copy at least) describes it.  This is in
the info documentation:

    info cvs multiple watches

In this system, files checked out are created read-only, and
rather than using `chmod' to allow modifications, you issue a
`cvs edit' command on that file.  This changes the permissions,
and notes in the repository that you are editing the file.
Before doing this, you can run `cvs editors' on the file, to get
a list of anyone else who is already editing it.

The parent node of that page gives a footnote to the `-l' admin
option, which can be used in conjunction with a Perl script to
force file locking, so that only one user is able to edit a file
at a time.  This is stronger, because it enforces this; the
watch/edit system only lets you register who is working on
something already.

This isn't perfect, because it's possible that there are several
patches to apply to one file -- you couldn't know which patch an
editor of that file is applying.  But if we were to stick to not
editing files that are already being edited, and posting to the
conductors list just before commiting, it's very unlikely that
any patches would be applied twice, and we could see which
patches were already applied.

George

-- 
Random project update:
19/03/2000: Libnet 0.10.6 uploaded -- bugfixes and new features, of course!
        http://www.canvaslink.com/libnet/  (try changes-0.10.6.txt)