>--- Forwarded mail from [EMAIL PROTECTED] >[ On Saturday, February 26, 2000 at 13:18:45 (-0800), Paul Sander wrote: ] >> Subject: Re: removing the need for "cvs add file" to contact the server.... >> >> One of the requirements of this architecture is to share header files >> across multiple projects. (Such a project would also contain libraries >> that are shared among applications, which I've pruned for simplicity.) >To say it bluntly: That's a really really really stupid way of doing things. >Please use the build system or some other external SCM system to share >stuff, not CVS modules directly like that! >I.e. keep separate release management for your headers (and associated >libraries, if there are any) and install them on build systems so they >can be shared by other modules. I wrote this about 12 years ago: "My tool of choice for software reuse used to be the editor, until I inherited 70,000 lines of code from someone who felt the same way. Now my tool of choice for software reuse is the linker." So with regard to using libraries and other inter-project reference mechanisms to implement software reuse, I agree with Greg. However, such an argument does not reduce the validity of the claim that the modules database can be and is indeed used in the way I describe. >Yes, it might require more effort and thought to do things this way but >this additional work is necessary for good software hygiene. It also >makes much more sense in an object-oriented sense, and even if you're >not directly using OO programming techniques it'll still afford you some >of the benefits. >If you can't manage this level of internal release management then I >would strongly suggest just keeping separate copies of the shared code >in each module that uses it and learn to do maintenance across the >common files in the old fashioned way -- i.e. remember to apply each >change to each file separately. If you think this is too much work then >you're obviously ready to do as I say and do separate release management >of the shared modules. Nope, absolutely not. Shops that use the modules database in the way I have described have at least acknowledged that software reuse is a good thing because it is cheaper to maintain the code that way. That is a big step in the right direction. So while reusing source code is definitely not an optimal solution, it is much much better than not reusing the code at all as Greg recommends. Another area where this type of reuse is useful is when building third- party sources in which there is an overlap in the sources. Many good examples of this are available from the Gnu Project: They ship everything they need to compile in a single distribution. And yet things like the getline routine are replicated across a great many projects, and the source code repository gets cluttered with dozens of copies. It is useful to have the option of condensing this stuff down and tracking (for free, via the modules database) which projects require a rebuild when a library is updated. >Sharing code by using CVS to "link" it into separate modules only works >in the very most simple of scenarios. Paul's example shows pretty >clearly how it can get way out of hand in very short order, and that's >without even considering some of the deeper software development issues >(not to mention CVS issues like branching!). Yes, it can get out of hand, but it also allows great flexibility in managing the users' workspaces. One example I published here a couple of months ago allowed users to check out specific subsystems of a larger project and build them in their test environments, while composing them all into a gigantic nightly build. That mechanism increased the users' productivity greatly by requiring them to check out and build only the stuff they really needed, and it had the side-effect of minimizing their disk space requirements. >CVS is not a full blown configuration management system, nor should it be! >--- End of forwarded message from [EMAIL PROTECTED]
