[jsword-devel] SVN and refactoring

[DM Smith]

Hi,
   One of the advantages of SVN is that it manages versions for each 
directory and file, not just the content of a file. What this means is 
that we can re-arrange the source without losing revision history.
   Since we have released and since we are now in SVN, I thought I would 
take some time to re-arrange our repository a bit. The changes were 
first to make each product orthogonal and then to follow the suggested 
structure for Maven.

Here is a summary of what I did:
Each subdirectory of trunk is an Eclipse product. This is the same as it 
was before.
Each product has a src directory where it stores all source. Previously, 
it was not in any particular directory, but java was under a java 
directory.
Within the src directory is main, test, limbo, historical, web, ... for 
each major grouping of source.
Under each of these directories is a java directory, if there is java 
code; resources if there are resources and so forth.
We used to let Eclipse build to target/classes and ant builds were to 
target/ant/classes. These have been changed to bin (Eclipse's default) 
and target/classes (the default for Maven).

I also split common into common and common-swing. And I consolidated out 
code into src/main/java and the tar code into src/tar/java.

I have the build working, but I am making some improvements to it. No 
longer do we need to have a resources directory with a dummy file when 
we have no resources otherwise. Same with 3rd party jars.

I have changed the name of the zips and tar.gz files to also include the 
current version and the day's date as jsword-1.0-20060127-src.tar.gz. 
And with in the file all the code is in a directory by the same 
"release" name. This is something that RPM build expects.

Some observations about Subclipse, an Eclipse plugin for SVN:
1) It's not quite there yet. Checkins are by project, not by repository. 
So what should be an atomic checkin, is not. It is a set of atomic 
checkins. Atomic checkins are core feature of SVN.
2) The plugin assumes that every operation that you do is something you 
want to do in SVN. A common scenario where I did not want it to. I have 
a similar file in two directories and I want to start with a copy of the 
contents of the other. I wanted to slap a new copy on top of the old, 
but I could not, it assumed I was branching from the other. I wasn't.
3) It is a bit buggy. It would sometimes get so confused, I had to drop 
the connection to SVN, delete the project and start all over again. This 
almost always was during a directory renaming.

Fortunately, TortoiseSVN works like a champ and does things as I want. 
So does the command line. So several times I resorted to working outside 
of Eclipse and then doing a refresh inside.

So my suggestion is to save what you have, delete the projects and start 
over again.

Hope this is good,
   DM