A few notes on the Subversion SVN for those that are not familiar with it.
One of the problems with collaboration (especially over the internet) is how do you manage contributions from multiple people? This becomes a real problem with code files where multiple functions reside, such as LISP files. This is where Subversion comes in to play: allowing users to make contributions in the same file without (necessarily) overwriting the work of others or locking others out for the sake of a minor change.
A central repository is created in a common location (in this case, here at theSwamp), with folders and files as required. Each user installs a Subversion client application (TortiseSVN is recommended) which manages the users connection to the repository. A local "working copy" folder is connected to the repository using the application, which will download/upload the selected files and folders. Now, for the cool part. When the files in the repository are changed the SVN client can be used to indicate *what* was changed from the users working copy, and those changes can be incorporated into the users working copy without disturbing any changes the user has made (provided it doesn't conflict with what the user changed). SVN also allows for multiple working "branches" to be developed independantly then merged back into a central "trunk" later on e.g. one branch for pure DXF/entmake, another for VLISP, and a third for ODCL. Finally, you can load the working files into AutoCAD right from the working directory - no temp copies required.
Sending changes back to the repository can be done in one of two ways. The simplest method is to perform a "commit", where the working copy overwrites the repository copy. This requires the user to take responsibility for updating their own working copy first, otherwise previous changes to the repository copy may be lost. This operation is usually reserved for admin-level users for this reason. The second method is to create a "diff patch". This creates a file with a set of instructions (called a "diff") that indicate the changes to be made to the repository file. This "diff" is then sent to an admin-level user who checks the contents for QA/QC and conflicts with other "diff" submissions. The "diffs" are then collectively applied to the repository copy (usually on a regular schedule) and users are alerted to update their working copies.
How does this apply to us? At the start, I forsee a lot of movement in the code: new functions, new global variables, changes to function names, and so on. Creating diff patches for each of these would be tiresome for the coders which is the reason I suggested isolating each function into its own LISP file. This will allow individual coders to perform their own "commits" to the repository with little fear of mucking something else up. If they are not comfortable with SVN access or don't want to install the SVN client then they can simply submit the file wholesale to a lieutenant to commit. Once the code base has stablised then we need to decide how to proceed. I would suggest we consolidate the functions into a handful of files and change to the diff-submission system, although we could continue with separate files and individual commit operations. We don't need to make the decision immediately - it can be put on hold for a while.
