Hi.
> 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.
Take a look at the subversion manual for this one. It gives clear examples
of how you should/could structure your repository.
But basically:
<repospath> / projectA / trunk
/ source
/ documents
/ resources
/ ...
/ branches
/ tags
/ projectB / trunk
...
is one option.
> 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?
Basically anything that is generated does NOT go in the repository.
Sources do, resources do (sound files etc).
You can always organising the repository in such a way that if multiple
projects are sharing sound files etc. have them in a shared folder
somewhere.
Binaries do not. Generated docs do not. Generated anything does not.
It might SEEM easier to store these generated things in there, but it's
generally not done and I highly recommend it. Size of the repository is one
prime reason, and speed of database recovery/restore is another reason.
External jars are often included in the repository particularly in the
instance you state of not having access to the sources.
> Another concern I have is how often I should be committing to the
> Subversion repository.
Agile processes suggest commit, commit, commit. If you're writing developer
tests (code unit tests using the likes of JUnit, CPPUnit, NUnit, etc.) then
so long as the test results are green, then commit away.
> 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?
Still commit, commit, commit. If you wish to tag a release a Release 2 then
just create a tag (svn copy) which effectively gives a name to a specific
revision in the repository.
> 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?
Why would you want to have checked out code that you're not working on?
Eclipse clearly works faster with less projects. You could always just
close inactive projects but I generally only check out what I'm working
with.
You might have inter-project dependencies and in this case one option is to
check out all the required projects as well as the one you're working on.
Another option is to have a release area with pre-compiled copies of the
projects and you can reference that area in your projects' CLASSPATH.
> 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.
Again I'd say refer to the Subversion manual. This all depends on if you're
using svnserve, apache or ?? for your repository access.
Greg.
Received on Thu Jan 6 12:48:16 2005