> I think it's becoming hard to maintain a source code if anybody
> (except gerald and the original author of a particular file)
> can check in files in the CVS tree (for instance most of the
> fddi patches was already done by me, but now I can't anymore
> merge easily my other changes ... :-) or maybe should I lock
> files ?
That's one of the problems with multi-developer projects - you run the
risk of having to merge two developer's changes to the same file (and
given the amount of stuff I want from a network sniffing program, and
stuff I have lying around in another such program on which I'd been
working, there's probably a significant risk there...).
Using CVS and the merging done by "cvs update" is one way of dealing
with the problem; it's *largely* worked here at NetApp (and the similar
Perforce features, Perforce being what we're using now, largely work as
well), but, every so often, you end up with a merge "train wreck", and
somebody has to do a fair bit of merge work by hand.
Another approach is to have changes by people other than the "owner" of
a module be submitted as patches for somebody to merge; that leaves that
somebody, whether it be the owner or, perhaps, Gerald, to do the
merging (and, on some occasions, cleaning up the result).
I wouldn't be bothered by either policy, but choosing a policy might be
a good idea.
> Another point :
> Many #define or structure definitions have nothing to do in
> packet.h but should be declared in a packet-xxx.h file or
> directly in the .c.
Absolutely.
