[jsword-devel] SVN and refactoring

[Stephen Denne]

Hi,

I'm not an active jsword developer, but have been on this list for an age.
I do use eclipse and SVN every day for java development of various projects, both at work, and personal projects, and thought I'd
comment on your observations.

> 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.

Is this also the case when using JavaSVN instead of JavaHL or SVN command line options? I read something today that I now can't find
about committing from multiple projects varying by SVN interface used, and that JavaSVN can be used to combine commits from multiple
projects as a single commit.

> 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.

I almost always do this, probably due to bugs and inflexibility in old versions of subclipse. I still use subclipse to decorate
views with changes, modification dates, etc.

The other key value of subclipse though, which you'll have used extensively, is for with refactorings that result in new or moved
files. I haven't done a lot of that recently, but when I do it, I always check what subclipse has decided to commit for each
refactoring, think about it for a bit, and if I agree with it I commit, otherwise I replay the refactoring using a combination of
TortoiseSVN and a text editor, checking the java result is the same but with the SVN modification history that I desire.

> So my suggestion is to save what you have, delete the projects and 
> start over again.
> 
> Hope this is good,
>    DM

I think it's good. Hope my comments are useful too.

Stephen Denne.