Newbie Questions

I'm a newbie to Subversion/Subclipse. I'm also new to using version control
software, aside from having used Panvalet in MVS almost 20 years ago! Please
bear with me as I get oriented....

I've installed the latest version of Subversion and Subclipse. If I am
understanding the documents correctly, Subversion is the server and
Subclipse is the Eclipse client that talks to the Subversion server. I have
put a small Eclipse project into Subversion via Subclipse by putting it
under version control. As far as I can tell, things are working correctly. I
plan to do a bit more playing with this small project to make sure I
understand how to do the major activities, like checkout, commit, diff, etc.
While I work away at that, I'd like to look ahead a bit and ask about
organizing my repository.

I have quite a number of projects in Eclipse, some of which are active and
some of which have fallen by the wayside, at least temporarily. I'd like to
work out the best way to handle both active and inactive projects. At the
moment, I am the only developer using this copy of Subversion; that could
conceivably change but isn't likely to in the near future.

I'm curious to know what parts of each Eclipse project veteran Subversion
users are storing in the repository. Obviously, source code should be stored
in Subversion and binaries should not. I'm inclined to store resources, like
images or sound files, that my project uses too; even if they don't change
very often (or maybe ever), I suppose I might want to revert back to older
versions of those files in some circumstances. What are veteran users doing
about things like jars, such as those used by particular servlets or
external jars needed to enable compiles to work, javadocs, and war files?

Javadocs and war files are generated from sources so they should be easily
reproducible with only the sources so I'm inclined to think that they
shouldn't be put into Subversion. But maybe it's just more convenient to
store them in Subversion anyway, rather than having to regenerate them?

I'm especially concerned about the external jars that support compiles or
that enable a given servlet to do its thing, such as
commons-fileupload-1.0.jar. These jars don't get updated by their vendors
very frequently but the sources aren't within my control and many projects
may potentially use them. It seems foolish to store umpteen copies of
commons-fileupload-1.0.jar under these circumstances. However, it may well
be more convenient to do so, even if there is going to be some redundant
storage. I'd appreciate your guidance on this issue.

Another concern I have is how often I should be committing to the Subversion
repository. On one hand, I could conceivably commit every time I do a save
of a given version of a source file. On the other hand, I could conceivably
commit only when there's been a major change in the source, such as starting
"Version 2" of the program, and not bother to commit lesser changes, since
Eclipse keeps local history of changes for me. What are veteran
Subversion/Subclipse users doing in this regard?

My final concern for the moment is whether I should have all of my projects
in Eclipse at any given time, even ones that are inactive? Or should I put
all of my projects in Subversion and only check them out when I'm actively
working on them - and commit them when I'm putting them away for a while. It
would reduce the size of my Eclipse workspace if I kept only active projects
in Eclipse, although it might take some time for me to get into the habit of
putting things away when I'm not using them (just like in real life ;-).

Oh, one other thing. I gather that I am supposed to stop the server before I
do a backup of the repository. Even if I am the only user of Subversion and
it resides on the same machine as Eclipse, that makes sense to me. How do I
stop the server? I haven't seen a command yet that will do that.

Rhino

---
rhino1 AT sympatico DOT ca
"There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies." - C.A.R.
Hoare