--On Saturday, January 12, 2002 22:47 +0000 Do...@ao... wrote:
> OK, I'll be a good straight man. What do you want me to do with this
> transparency patch. (Phrase your answer as something anatomically
> possible for an intellectually challenged physicist)
>
> Wayne Keen
The short answer is, "You don't have to do anything!" Here's the long
answer:
What dman was doing was proposing new C++ code for the Visual module.
Here's a very brief sketch of the way open-source development works, using
Visual as an example.
SourceForge (sf.net) is a repository for open-source development projects,
one of which is VPython. You can see this by going to sf.net and typing
"vpython" into the search box. Housed there is a "CVS" repository
("Concurrent Versions System") which holds not only the most recent version
of each and every C++ file in the Visual project, but all previous versions
as well. There exist (freeware) CVS programs for checking out any or all
files from the CVS repository. Having checked them out (which does not lock
out anyone else from checking them out), you make changes in one or more
files, recompile Visual (the files include project compilation files for
Microsoft Visual Studio and makefiles for Linux), and test your changes.
When you're satisfied, you run a "diff" program whose input is a current
CVS file and your changed version, and whose output is a "patch" file of
the kind that dman posted, listing all of the differences between the two
files in a standardized form.
Next a "gatekeeper" (one of the small number of people responsible for
maintaining the integrity of the project) can use a "patch manager" program
to apply the patch file to the current CVS version to produce a new version
of the file. There may be other patches to the file, from other people.
With all patches applied, the gatekeeper tests the changes. If the
gatekeeper agrees that the new version should become part of the project,
the new version is checked into the CVS repository, using a CVS program
that leaves the previous version in place. With all previous versions kept
in CVS, it is possible to backtrack when something goes awry, retreating to
a point when some feature worked. (Actually, I believe the multiple
versions are themselves stored as something like incremental patch files
based on previous versions, and these patch files take up little space.)
As you can see, these mechanisms make it possible for many people to work
together. However, there does need to be good communication among
contributors to avoid duplication and collisions of certain kinds. CVS
doesn't automatically resolve conflicts involving overlapping patches; that
has to be done by a knowledgeable human.
One other mechanism provided by CVS is a "branch", where someone starts a
major project that will take a long time and doesn't want to interfere with
ongoing work. When the branched version is ready, that person has the
responsibility to merge the side branch into the main branch.
Python itself is a big open source development project that works in this
way. However, it is so big that it has fairly elaborate additional
mechanisms for planning, documenting changes, etc.
Bruce
|
