[jsword-devel] SVN and refactoring

[DM Smith]

Stephen Denne wrote:
> 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.
>   
Interesting. I am using it as it comes "out of the box". Which is that 
it uses JavaHL. I use SVN at work and always via the command line or 
Tortoise SVN (the source is SQL) and I never have the problem when 
working from the command line. But then again, I check out trunk in that 
case.

Anyway, I thank you for your thoughts and I will be doing some 
experiments. (Keep lurking and jump in too.) I'll post if I find out 
anything noteworthy.
>   
>> 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.
>   
I find it useful for pretty much the same reasons. We have not done this refactoring earlier in CVS because it would have lot history. It was much quicker within Eclipse than it would have been using TortoiseSVN.

I think as I play with it I may get use to it. But, I just don't like it when it tries to do more that what the command line does, without asking or presenting me with options.) Basically, my first impression is that it is too tightly integrated. For example in TortoiseSVN, I can either do an OS delete or an SVN delete. But with Subclipse, a delete within Eclipse is always an SVN delete. Sometimes, I just want to pitch what I did and start over. Same with copy. So, to do those things, I have to resort to going outside of Eclipse.

What I am not sure of is how Subclipse works for someone with anonymous, read-only access to the repository. It appears that Subclipse assumes that the user is a committer.