Home » Archived » EPF » EPF and Subversion/Subclipse
EPF and Subversion/Subclipse [message #25283] |
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
|
|
| | | | | | |
Re: EPF and Subversion/Subclipse [message #26859 is a reply to message #25326] |
Thu, 18 January 2007 13:32 |
jan masaryk Messages: 50 Registered: July 2009 |
Member |
|
|
we using EPFC with subversion as well, therefore I would share some notes
....
Why we use svn (subversion)? CVS is too old-fashion with many problems and
ClearCase is too much
'heavyweight' for us. From all alternatives looked svn as a good choice
because SVN:
- commits are atomic
- support for rename/move
- branching and tagging are relatively cheap
- network protocol uses bandwidth efficiently
- access rights (path/access based)
- easy administration
- available plugins for eclipse-based IDE (EPFC is eclipse-based)
As a next I tested eclipse-based subversion clients.
Subversive is very fine, but I was not successful with installation.
Subclipse has two main versions: 1.1.x and 1.0.x, however version 1.1.9
has some problems
with locking files (when I try open/edit some files I have to lock it).
Version 1.1.8 has been fine.
Because of that problems I choose version 1.0.4. No problem with
installation,
it's runnign quite well and we don't recognised any serious problems until
now (around 6weeks using).
Concerning way how to work with EPFC and SVN ...
We do not lock file during editing, we are modeling with some preventive
methodical
rules/principles in mind and trying solve conflicts when they appear.
Most conflicts come in plugin.xmi (of cource they appear often because it's
a reference file). However it's not so big deal resolve this conflict,
see svn book for help (part resolving conflict).
I should say that I don't see many difference in 'Version Control System
background'
between common development project and modeling project in EPFC except
these reference
files (plugin.xmi and library.xmi). Both have to manage 'text' file and
their dependencies.
Therefore I try solve problems as in common development project ... maybe
I'm wrong.
If so, please warn me ....
Yes, maybe this style of work is runnign only because we are really small
team (around 5-8 people) ...
Our configuration is: win32, epfc 1.0.1.2, subclipse 1.0.4, subversion
(svn-win32-1.4.2).
In subversion repository we have open only one 'branch' for actual
delivery and
of course exust 'trunk' as valid model.
take care,
jan
ps for EPFC team: element definition of plugin.xmi would be VERY VERY
helpful. :-)
ps2: yes, TortoiseSVN can help is some case.
On Fri, 08 Dec 2006 15:59:23 +0100, Scott <scottrish@gmail.com> wrote:
> No sooner do I post this than Subclipse is updated to 1.1.9 and
> introduces a dependency that can't be easily resolved within EPFC!
>
> It seems like 1.1.9 now has a dependency on Mylar which in turn has a
> dependency on 'org.eclipse.ui.browser' that is not in EPFC and itself
> has additional dependencies that are also not in EPFC.
>
> Feature request - in hindsight I realize that the EPFC being an RCP app
> I probably shouldn't have expected to have been able to install any
> arbitrary plugin. However, if the EPFC could be made available as a
> plugin, or incorporated additional core Eclipse elements then users
> could incorporate additional capabilities such as Subclipse. For
> example, I've also been wanting to incorporate task/issue tracking and
> I'd actually been looking at Mylar. I realize this is probably frowned
> upon and at some point I'll try and do the right thing and build and
> deploy the EPFC as a plugin from source, however, for expediency I just
> naively copied over, from Eclipse (using the same base version I
> believe), all the missing features/plugins and now have a working EPFC
> using Subclipse 1.1.9 and Mylar (bonus!). Required plugins/features
> follow:
>
> plugins/
> org.eclipse.ui.browser
> org.eclipse.pde.*
> org.eclipse.jdt.*
>
> features/
> org.eclipse.jdt.source_3.2.0
> org.eclipse.jdt_3.2.0
> org.eclipse.pde_3.2.0
> org.eclipse.platform_3.2.0
>
> After copying these over I was able to use the update sites for
> Subclipse and Mylar.
>
> Scott.
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| | | | | | |
Re: EPF and Subversion/Subclipse [message #574986 is a reply to message #25326] |
Thu, 18 January 2007 13:32 |
jan masaryk Messages: 50 Registered: July 2009 |
Member |
|
|
we using EPFC with subversion as well, therefore I would share some notes
....
Why we use svn (subversion)? CVS is too old-fashion with many problems and
ClearCase is too much
'heavyweight' for us. From all alternatives looked svn as a good choice
because SVN:
- commits are atomic
- support for rename/move
- branching and tagging are relatively cheap
- network protocol uses bandwidth efficiently
- access rights (path/access based)
- easy administration
- available plugins for eclipse-based IDE (EPFC is eclipse-based)
As a next I tested eclipse-based subversion clients.
Subversive is very fine, but I was not successful with installation.
Subclipse has two main versions: 1.1.x and 1.0.x, however version 1.1.9
has some problems
with locking files (when I try open/edit some files I have to lock it).
Version 1.1.8 has been fine.
Because of that problems I choose version 1.0.4. No problem with
installation,
it's runnign quite well and we don't recognised any serious problems until
now (around 6weeks using).
Concerning way how to work with EPFC and SVN ...
We do not lock file during editing, we are modeling with some preventive
methodical
rules/principles in mind and trying solve conflicts when they appear.
Most conflicts come in plugin.xmi (of cource they appear often because it's
a reference file). However it's not so big deal resolve this conflict,
see svn book for help (part resolving conflict).
I should say that I don't see many difference in 'Version Control System
background'
between common development project and modeling project in EPFC except
these reference
files (plugin.xmi and library.xmi). Both have to manage 'text' file and
their dependencies.
Therefore I try solve problems as in common development project ... maybe
I'm wrong.
If so, please warn me ....
Yes, maybe this style of work is runnign only because we are really small
team (around 5-8 people) ...
Our configuration is: win32, epfc 1.0.1.2, subclipse 1.0.4, subversion
(svn-win32-1.4.2).
In subversion repository we have open only one 'branch' for actual
delivery and
of course exust 'trunk' as valid model.
take care,
jan
ps for EPFC team: element definition of plugin.xmi would be VERY VERY
helpful. :-)
ps2: yes, TortoiseSVN can help is some case.
On Fri, 08 Dec 2006 15:59:23 +0100, Scott <scottrish@gmail.com> wrote:
> No sooner do I post this than Subclipse is updated to 1.1.9 and
> introduces a dependency that can't be easily resolved within EPFC!
>
> It seems like 1.1.9 now has a dependency on Mylar which in turn has a
> dependency on 'org.eclipse.ui.browser' that is not in EPFC and itself
> has additional dependencies that are also not in EPFC.
>
> Feature request - in hindsight I realize that the EPFC being an RCP app
> I probably shouldn't have expected to have been able to install any
> arbitrary plugin. However, if the EPFC could be made available as a
> plugin, or incorporated additional core Eclipse elements then users
> could incorporate additional capabilities such as Subclipse. For
> example, I've also been wanting to incorporate task/issue tracking and
> I'd actually been looking at Mylar. I realize this is probably frowned
> upon and at some point I'll try and do the right thing and build and
> deploy the EPFC as a plugin from source, however, for expediency I just
> naively copied over, from Eclipse (using the same base version I
> believe), all the missing features/plugins and now have a working EPFC
> using Subclipse 1.1.9 and Mylar (bonus!). Required plugins/features
> follow:
>
> plugins/
> org.eclipse.ui.browser
> org.eclipse.pde.*
> org.eclipse.jdt.*
>
> features/
> org.eclipse.jdt.source_3.2.0
> org.eclipse.jdt_3.2.0
> org.eclipse.pde_3.2.0
> org.eclipse.platform_3.2.0
>
> After copying these over I was able to use the update sites for
> Subclipse and Mylar.
>
> Scott.
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| |
Goto Forum:
Current Time: Thu Dec 12 05:58:04 GMT 2024
Powered by FUDForum. Page generated in 0.05482 seconds
|