Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EPF » EPF and Subversion/Subclipse
EPF and Subversion/Subclipse [message #25283] Fri, 08 December 2006 13:35 Go to next message
Scott Dunn is currently offline Scott DunnFriend
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 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
Re: EPF and Subversion/Subclipse [message #25326 is a reply to message #25283] Fri, 08 December 2006 14:59 Go to previous messageGo to next message
Scott Dunn is currently offline Scott DunnFriend
Messages: 10
Registered: July 2009
Junior Member
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.
Re: EPF and Subversion/Subclipse [message #25366 is a reply to message #25326] Fri, 08 December 2006 15:23 Go to previous messageGo to next message
Mark Phippard is currently offline Mark PhippardFriend
Messages: 129
Registered: July 2009
Senior Member
Scott 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.

Subclipse does not have a dependency on Mylar. A new optional feature
was added that a user of Mylar and Subclipse can install that brings
tight integration between those tools. But Subclipse itself has no
such dependency on Mylar.

Mark
Re: EPF and Subversion/Subclipse [message #25408 is a reply to message #25283] Fri, 08 December 2006 15:29 Go to previous messageGo to next message
Mark Phippard is currently offline Mark PhippardFriend
Messages: 129
Registered: July 2009
Senior Member
Scott wrote:

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

Obviously no one likes to get merge conflicts, but why is that such a
big deal? Are you dealing exclusively with unmergable binary files or
something? Requiring locks on all files is not a solution that anyone
that uses Subversion would recommend -- ever. Only exception being
binary files.

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

I have never heard of this happening. You are saying the lock dialog
is coming up 20 times for one file? Do you have a reproducible
scenario? If so report it to users@subclipse.tigris.org. In general,
it is Eclipse that calls the method that causes that dialog to come up.
I cannot imagine why it would happen so often though.

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

Commit will show unversioned files in the dialog and add them as part
of the commit.

> The only identifiable problem is if I attempt two
> operations that affect the filename without a commit in between.

This is a limitation that exists within Subversion itself. The
Subclipse team has actually fixed/enhanced this in Subversion and it
will be part of the 1.5 release (no date at the moment).

Mark
Re: EPF and Subversion/Subclipse [message #25444 is a reply to message #25408] Fri, 08 December 2006 16:10 Go to previous messageGo to next message
Scott Dunn is currently offline Scott DunnFriend
Messages: 10
Registered: July 2009
Junior Member
Mark Phippard wrote:

> Obviously no one likes to get merge conflicts, but why is that such a
> big deal? Are you dealing exclusively with unmergable binary files or
> something? Requiring locks on all files is not a solution that anyone
> that uses Subversion would recommend -- ever. Only exception being
> binary files.

In general I would agree, but have you looked at the XMI files that the
EPFC produces?
The EPFC developers also recommend avoiding merging. See following thread:
http://www.eclipse.org/newsportal/article.php?id=239&gro up=eclipse.technology.epf#239

We have geographically dispersed authors that need to work with the same
content, so preventing merge conflicts by using locks is far simpler than
resolving conflicts by merging XMI files.

> I have never heard of this happening. You are saying the lock dialog
> is coming up 20 times for one file? Do you have a reproducible
> scenario? If so report it to users@subclipse.tigris.org. In general,
> it is Eclipse that calls the method that causes that dialog to come up.
> I cannot imagine why it would happen so often though.

I haven't fully investigated this, but as I said, it could be a deficiency
in our hook script. If we can't resolve it in the hook script then I'll
post ther scenario to the Subclipse forum.

> Commit will show unversioned files in the dialog and add them as part
> of the commit.

Thanks. Didn't realise that.

Scott.
Re: EPF and Subversion/Subclipse [message #25484 is a reply to message #25366] Fri, 08 December 2006 16:12 Go to previous messageGo to next message
Scott Dunn is currently offline Scott DunnFriend
Messages: 10
Registered: July 2009
Junior Member
Mark Phippard wrote:

> Scott wrote:
> Subclipse does not have a dependency on Mylar. A new optional feature
> was added that a user of Mylar and Subclipse can install that brings
> tight integration between those tools. But Subclipse itself has no
> such dependency on Mylar.

My mistake, when I selected Subclipse in the update dialog I didn't
realise a new optional component had been added.

Scott.
Re: EPF and Subversion/Subclipse [message #25524 is a reply to message #25444] Fri, 08 December 2006 16:16 Go to previous messageGo to next message
Mark Phippard is currently offline Mark PhippardFriend
Messages: 129
Registered: July 2009
Senior Member
Scott Dunn wrote:

> Mark Phippard wrote:
>
> > Obviously no one likes to get merge conflicts, but why is that such
> > a big deal? Are you dealing exclusively with unmergable binary
> > files or something? Requiring locks on all files is not a solution
> > that anyone that uses Subversion would recommend -- ever. Only
> > exception being binary files.
>
> In general I would agree, but have you looked at the XMI files that
> the EPFC produces? The EPFC developers also recommend avoiding
> merging. See following thread:
> http://www.eclipse.org/newsportal/article.php?id=239&gro up=eclipse.tec
> hnology.epf#239

I do not really even understand what EPF is, so no. So essentially you
have XML files that do not merge very well. As long as you are
limiting the use of locks to the files that do not merge well, than
that is OK.

> > I have never heard of this happening. You are saying the lock
> > dialog is coming up 20 times for one file? Do you have a
> > reproducible scenario? If so report it to
> > users@subclipse.tigris.org. In general, it is Eclipse that calls
> > the method that causes that dialog to come up. I cannot imagine
> > why it would happen so often though.
>
> I haven't fully investigated this, but as I said, it could be a
> deficiency in our hook script. If we can't resolve it in the hook
> script then I'll post ther scenario to the Subclipse forum.

I do not think a hook could effect this. Unless it is a pre-lock hook
that is preventing the lock or something.

Mark
Re: EPF and Subversion/Subclipse [message #26859 is a reply to message #25326] Thu, 18 January 2007 13:32 Go to previous messageGo to next message
jan masaryk is currently offline jan masarykFriend
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 #573978 is a reply to message #25283] Fri, 08 December 2006 14:59 Go to previous messageGo to next message
Scott Dunn is currently offline Scott DunnFriend
Messages: 10
Registered: July 2009
Junior Member
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.
Re: EPF and Subversion/Subclipse [message #574008 is a reply to message #25326] Fri, 08 December 2006 15:23 Go to previous messageGo to next message
Mark Phippard is currently offline Mark PhippardFriend
Messages: 129
Registered: July 2009
Senior Member
Scott 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.

Subclipse does not have a dependency on Mylar. A new optional feature
was added that a user of Mylar and Subclipse can install that brings
tight integration between those tools. But Subclipse itself has no
such dependency on Mylar.

Mark
Re: EPF and Subversion/Subclipse [message #574032 is a reply to message #25283] Fri, 08 December 2006 15:29 Go to previous messageGo to next message
Mark Phippard is currently offline Mark PhippardFriend
Messages: 129
Registered: July 2009
Senior Member
Scott wrote:

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

Obviously no one likes to get merge conflicts, but why is that such a
big deal? Are you dealing exclusively with unmergable binary files or
something? Requiring locks on all files is not a solution that anyone
that uses Subversion would recommend -- ever. Only exception being
binary files.

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

I have never heard of this happening. You are saying the lock dialog
is coming up 20 times for one file? Do you have a reproducible
scenario? If so report it to users@subclipse.tigris.org. In general,
it is Eclipse that calls the method that causes that dialog to come up.
I cannot imagine why it would happen so often though.

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

Commit will show unversioned files in the dialog and add them as part
of the commit.

> The only identifiable problem is if I attempt two
> operations that affect the filename without a commit in between.

This is a limitation that exists within Subversion itself. The
Subclipse team has actually fixed/enhanced this in Subversion and it
will be part of the 1.5 release (no date at the moment).

Mark
Re: EPF and Subversion/Subclipse [message #574052 is a reply to message #25408] Fri, 08 December 2006 16:10 Go to previous messageGo to next message
Scott Dunn is currently offline Scott DunnFriend
Messages: 10
Registered: July 2009
Junior Member
Mark Phippard wrote:

> Obviously no one likes to get merge conflicts, but why is that such a
> big deal? Are you dealing exclusively with unmergable binary files or
> something? Requiring locks on all files is not a solution that anyone
> that uses Subversion would recommend -- ever. Only exception being
> binary files.

In general I would agree, but have you looked at the XMI files that the
EPFC produces?
The EPFC developers also recommend avoiding merging. See following thread:
http://www.eclipse.org/newsportal/article.php?id=239&gro up=eclipse.technology.epf#239

We have geographically dispersed authors that need to work with the same
content, so preventing merge conflicts by using locks is far simpler than
resolving conflicts by merging XMI files.

> I have never heard of this happening. You are saying the lock dialog
> is coming up 20 times for one file? Do you have a reproducible
> scenario? If so report it to users@subclipse.tigris.org. In general,
> it is Eclipse that calls the method that causes that dialog to come up.
> I cannot imagine why it would happen so often though.

I haven't fully investigated this, but as I said, it could be a deficiency
in our hook script. If we can't resolve it in the hook script then I'll
post ther scenario to the Subclipse forum.

> Commit will show unversioned files in the dialog and add them as part
> of the commit.

Thanks. Didn't realise that.

Scott.
Re: EPF and Subversion/Subclipse [message #574080 is a reply to message #25366] Fri, 08 December 2006 16:12 Go to previous messageGo to next message
Scott Dunn is currently offline Scott DunnFriend
Messages: 10
Registered: July 2009
Junior Member
Mark Phippard wrote:

> Scott wrote:
> Subclipse does not have a dependency on Mylar. A new optional feature
> was added that a user of Mylar and Subclipse can install that brings
> tight integration between those tools. But Subclipse itself has no
> such dependency on Mylar.

My mistake, when I selected Subclipse in the update dialog I didn't
realise a new optional component had been added.

Scott.
Re: EPF and Subversion/Subclipse [message #574095 is a reply to message #25444] Fri, 08 December 2006 16:16 Go to previous messageGo to next message
Mark Phippard is currently offline Mark PhippardFriend
Messages: 129
Registered: July 2009
Senior Member
Scott Dunn wrote:

> Mark Phippard wrote:
>
> > Obviously no one likes to get merge conflicts, but why is that such
> > a big deal? Are you dealing exclusively with unmergable binary
> > files or something? Requiring locks on all files is not a solution
> > that anyone that uses Subversion would recommend -- ever. Only
> > exception being binary files.
>
> In general I would agree, but have you looked at the XMI files that
> the EPFC produces? The EPFC developers also recommend avoiding
> merging. See following thread:
> http://www.eclipse.org/newsportal/article.php?id=239&gro up=eclipse.tec
> hnology.epf#239

I do not really even understand what EPF is, so no. So essentially you
have XML files that do not merge very well. As long as you are
limiting the use of locks to the files that do not merge well, than
that is OK.

> > I have never heard of this happening. You are saying the lock
> > dialog is coming up 20 times for one file? Do you have a
> > reproducible scenario? If so report it to
> > users@subclipse.tigris.org. In general, it is Eclipse that calls
> > the method that causes that dialog to come up. I cannot imagine
> > why it would happen so often though.
>
> I haven't fully investigated this, but as I said, it could be a
> deficiency in our hook script. If we can't resolve it in the hook
> script then I'll post ther scenario to the Subclipse forum.

I do not think a hook could effect this. Unless it is a pre-lock hook
that is preventing the lock or something.

Mark
Re: EPF and Subversion/Subclipse [message #574986 is a reply to message #25326] Thu, 18 January 2007 13:32 Go to previous messageGo to next message
jan masaryk is currently offline jan masarykFriend
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 #799921 is a reply to message #574986] Thu, 16 February 2012 13:20 Go to previous message
Tarcisio Pereira is currently offline Tarcisio PereiraFriend
Messages: 10
Registered: April 2011
Location: Brazil
Junior Member
Hi, Scott and Jen.

I'm using EPF with Subclipse and I have some doubts, mainly when I have to checkout more than one project or solve conflicts in plugin.xmi

Can you help me?

Thanks!
Previous Topic:EPF with Subversive
Next Topic:Activity Diagram problems
Goto Forum:
  


Current Time: Tue Dec 23 03:17:01 GMT 2014

Powered by FUDForum. Page generated in 0.03302 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software