| EPF and Subversion/Subclipse [message #573943] |
Fri, 08 December 2006 13:35 |
 Scott Dunn
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
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 Ive 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.
Ive 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 havent 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 dont 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
|
|
|
Powered by
FUDForum. Page generated in 0.03014 seconds
] 
Search
Help
Register
Login
Home
