[news.eclipse.technology.epf] EPF and Subversion/Subclipse

[scottrish@xxxxxxxxx (Scott)]

While Subversion is not an officially 'blessed' version control system 
according to the document 'Using Eclipse Process Framework Composer with a 
Version Control System' it is the one that we use so I thought some folks 
may find my experiences with it useful.

We're using Subclipse 1.1.8 on EPF 1.0.1. I don't have any experience with 
Subversive. Subclipse can be installed via the following update site: 
http://subclipse.tigris.org/update_1.2.x

We quickly realised that we needed to avoid merge conflicts so we now 
require that all files are locked before edits are made and we set a 
property on all files that forces the lock to be acquired prior to any 
edits. We also have a hook script that checks for the property on 
pre-commit (see below for instructions on how to configure this) to ensure 
that new files are created correctly. Subclipse handles the lock 
acquisition on our behalf whenever we start some operation that requires 
write access to one or more files that are not yet locked. For each file 
being modified Subclipse will pop up a 'Get Lock' dialog where you can 
optionally add a comment. It does quite often attempt to acquire multiple 
locks on the same file. The subsequent attempts fail with an error in the 
console but they can be safely ignored, so it's a relatively minor 
nuisance only. The worst I?ve ever encountered was a sequence of about 20 
lock dialogs, after a process move operation as I recall, that had me 
thinking I was stuck in a loop but it eventually completed successfully. I 
think with an enhancement to the hook script we could probably resolve 
this.

For the most part, during authoring I don't need to use the Navigator view 
where all the Subclipse commands are available via a context menu. I do 
find myself using TortoiseSVN to perform most adds and commits. No 
particular reason for that, I guess that's how I started and I've just 
continued that way. However, Subclipse works just fine. The only 
deficiency that I've noticed is that unlike TortoiseSVN it doesn't 
recursively search for files that have not yet been added to the 
repository so I would need to know the files to add. It does recursively 
search for modified files so I can simply right-click at the top-level of 
the work area to commit all changes if I so choose. As I said, I tend to 
jump to TortoiseSVN for those operations. If I could get EPF working well 
on my Mac then I'd be perfectly comfortable using Subclipse for all SVN 
operations.

I?ve found that in general naming/moving elements works seamlessly. 
Subclipse seems to do all the right things. Certainly I can continue to 
see the complete file history after it has been renamed so while the log 
indicates that remove and add operations were performed, in actual fact 
the SVN logs maintains the history across file renaming operations.
The only identifiable problem is if I attempt two operations that affect 
the filename without a commit in between. The first will succeed and the 
add/delete combo will be pending but not yet committed in Subclipse. The 
second rename succeeds in EPF (plugin.xmi is updated) but as the newly 
named and unlocked file is not yet in SVN when Subclipse attempts to get 
the lock on it, the second rename fails. This is likely as a consequence 
of a deficiency in the pre-commit hook script that we added rather than a 
deficiency of EPF/Subclipse but I haven?t yet fully investigated this 
issue.
On occasion I will get an error dialog stating that the underlying file is 
read-only rather than getting the lock dialog. The solution has always 
been to refresh the project from the Navigator view and then to try again. 
I don?t know why EPF/Subclipse gets out of synch with the filesystem but a 
refresh always resolves the problem.

One enhancement that could be made that would facilitate multiple authors 
within a plugin would be if EPF automatically created the file for the 
method element rather than deferring file creation until content is added. 
This would reduce the likelihood of conflicts over plugin.xmi and ease 
concurrent authoring sessions.

Hope this is of help/interest to some folks.

Scott.


Instructions on how to force locks to be acquired prior to edits:
On Windows the config file can be found at C:\Documents and 
Settings\<username>\Application Data\Subversion\config

Add the following properties:
[miscellany]
### Automatic properties are defined in the section 'auto-props'.
enable-auto-props = yes

### Section for configuring automatic properties.
[auto-props]
* = svn:needs-lock=yes