Hello, Andrew!

>  I am interested in the fact you are using subversion with BlackBox.
>  I have a large long running project with BlackBox called OpenBUGS. I
>  think it is time to start using some sort of version control.

  Since I got myself familar with Subversion, I use it for all my new
  projects. And also for most old ones which I still maintain. This is
  really great. It gives you much more precise control over what's
  going on in your code. (And I'm saying that being a solo programmer,
  not member of a team. For any team developement this is truly a
  "must-have" kind of tool.)
  
>  The project is an open source version of the WinBUGS software for
>  statistical modeling. The project is large in the number of modules
>  (~200) and number of users of WinBUGS (~20000) so there is a lot to
>  keep track of.

  : ) I can't even imagine your possible headaches.

>  When I read the documentation for subversion the examples seem to be
>  in C. How do things work for CP where you have interface definition
>  files? I would like to hear your tips for using subversion

  Did you read the book on SVN? There is a link to it somewhere on
  their site. The book is very good.

  Don't mind the examples. Subversion has no prejudice about the files
  you will keep under version control, because it performs binary
  diff, not textual diff. You may have your MP3 music collection under
  version control if you want to. 

  Now, the tips.
  1. Don't use command line interface unless you are a complete geek
  and have everything automated with Perl scripts. Install the GUI
  client (for Windows - TortoiseSVN). It has 95% of functionality
  under your fingertips. And it integrates directly into the Explorer
  shell context menu for files and directories. If you don't like to
  use Explorer (I use Total Commander), you will most probably see the
  same menu in your other shell program. 

  2. Since BlackBox's .odc files are not ordinary text files, you will
  not be able to see the differences between revisions (or between the
  last committed and current working copy versions) of a file content
  in the standard program TortoiseMerge: it will say that binary files
  are not supported. The problem here is not with SVN, but with
  TortoiseMerge. To see differences in the text you need a program
  that would ignore the binary prefix and suffix and would compare
  only the textual content. And there is such a program, and it is
  called BlackBox. What you really need is configure TortoiseSVN to
  handle *.odc files with an external diff viewer:
    Settings -> External Programs -> Diff Viewer -> Advanced -> Add...
      extension: .odc
      external program:
wscript.exe "<Path_To_TortoiseSVN>\Diff-Scripts\diff-odc.js" %base %mine //E:javascript

  And an external merge tool:
    Settings -> External Programs -> Merge Tool -> Advanced -> Add...
      extension: .odc
      external program:
wscript.exe "<Path_To_TortoiseSVN>\Diff-Scripts\merge-odc.js" %merged %theirs %mine %base //E:javascript

  The "wscript.exe" is a standard windows script engine.
  The scripts "diff-odc.js" and "merge-odc.js" are attached to this
  message.

  Preconditions for these scripts:
  - *.odc files are associated with BlackBox application;
  - BlackBox has the title "BlackBox";
  - F9 is the hotkey for "Info - Compare Texts";
  - one second is enough time to start BlackBox with a document.
  All of these are true by default (the last may depend on the
  system).

  One thing to note here is that the default "Compare Texts" command
  ignores changes in text formatting (i.e. coloring, font and size
  changes, etc), embedded views and whitespace (i.e. changing number
  of consequent tabs or changing tabs to spaces). But if you want to
  compare a program code, you will be satisfied with the results.

  3. Another thing I'd like to discuss is whether to keep code files
  (*.ocf) and interface definitions (*.osf) under version control. My
  answer is this. If you need the ability to revert changes to a code
  file, keep it under version control. But if you may click a
  commander and quickly recreate all your binaries, you will only
  waste space keeping them in your database.
  For example, I sometimes modify BlackBox's core files. If I break
  something, I may not be able to start BlackBox again to recompile
  files into previous state. That's why I have BlackBox under version
  control with all binaries.
  On the other hand, in each of my other projects I have a commander
  that would quickly recompile the entire subsystem, therefore I only
  need the sources under version control. (Also, Rsrc and Docu.)
  Another reason for NOT keeping binaries under Subversion is that
  code files get modified after every compilation (probably they
  contain some soft of a time stamp in them), so you will most of the
  time see these files highlighted with red overlay icon even if you
  changed nothing since your last commit. And this red sign will also
  mark your entire subsystem's directory as "modified", so it will
  mislead or distract you or force you to less compile and more
  revert. 

  4. Use trunk/tags/branches directory structure in repository. It
  helps. (See SVN book.) If you want several projects in one database,
  use separate root directories "ProjectName", with
  trunk/tags/branches inside each of them. Prefer creating different
  databases for independent projects. Smaller bases are easier to
  move or backup and will have smaller revision numbers.

  5. Use Native database format, not Berkeley DB. Unless you are
  forced to stick with Berkeley.

  6. Write meaningful log messages describing every commit. Verify
  that the files to be committed contain only the described changes.
  If this is not true, make two commits with appropriate descriptions.
  Commit one logical step of developement at a time. Commits must not
  have side-effects. Ideally, every revision of your "trunk" directory
  should be compilable and work as stable as you can manage. If you
  need to perform a series of changes between which you will not have
  a working product, make it a branch. Why? Think what will happen if
  you get interrupted in the middle of the brach and later will forget
  what you were doing. At least the trunk will be stable.
  Review changes to every file before committing. This helps me to get
  rid of forgotten temporary and debug code.

  7. To edit a log message after it is committed, place attached
  "pre-revprop-change.exe" into "hooks" subdirectory of the
  repository. This file was created with BlackBox and it does NOTHING.
  It was just a single module with no code in it, and it is the
  smallest EXE file I could create (I also tried Delphi). Actually,
  the file could be any executable. If it returns zero, the new log
  message will be accepted. You could also just create an empty .bat
  file with the same name, but you would see a flash of console window
  when it is executed.

---=====---
 AlexaoUSV4WoB