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.
---=====---
Alexander
Received on Fri Jan 19 2007 - 21:11:30 UTC