Home » Archived » EPF » Integration with ClearCase
| Integration with ClearCase [message #43926] |
Fri, 12 October 2007 23:53  |
Eclipse User |
|
|
|
Originally posted by: Sevon.Vanbebber.baesystems.com
I just was set up with ClearCase and I am using a dynamic view. Should I
be using snapshot views? How do I check out a file from within EPFC with a
dynamic view? With a snapshot view (if dynamic is not applicable).
Are there any other suggestions that you have for converting my current
library into ClearCase?
Thank you,
Sevon
|
|
| | |
| Re: Integration with ClearCase [message #44043 is a reply to message #43986] |
Sat, 13 October 2007 22:00  |
| Eclipse User |
|
|
|
Originally posted by: Sevon.Vanbebber.baesystems.com
Peter,
I've created my ClearCase View and opened it in the composer. I can open
the files (through the VOB) now in the EPFC, but I cannot edit them (which
I believe means I cannot check them out). When I try to write something I
get these 2 error messages:
Read-only File Encountered
File 'XXXX' is read-only. Do you wish to make it writeable?
Then I click Yes
Edit Element
IUPA0015E: Cannot edit element
Reason:
File 'XXXX' is read-only
Any Advise? All of the information in the Help file I believe is the same
as was located in the paper whose link I attached in the previous post. It
is useful, except that I do not know how to switch to the "ClearCase
Perspective", which I think is why I can't edit the file. Is it the same
as the CVS Perspective? or did I do something wrong?
Thanks, and happy Saturday :)
Sevon
|
|
| | |
| Re: Integration with ClearCase [message #44306 is a reply to message #44139] |
Wed, 17 October 2007 18:09 |
| Eclipse User |
|
|
|
Originally posted by: Sevon.Vanbebber.baesystems.com
I still have a couple questions about using ClearCase.
Because all of the content items in the folder are referenced in
pligin.xmi, or library.xmi, ClearCase Checks out those items, along with
every other items attached to it. This is not useful because then it keeps
others from being able to check out anything in the plug-in, which defeats
the purpose of even having Config Control.
So we worked around this by deleting library.xmi and plugin.xmi from the
VOB and added it to each of the Views. Now, when you edit, no one else's
library.xmi or plugin.xmi gets updated, which created a new set of
problems because library&plugin.xmi cannot find newly created content or
content with changed names.
So now, we have everyone working out of the same view, which is
essentially the same as having no CM systems at all, but with all the
extra CM hassle, which is still not what we want, but at least we are up
and running again for teh short term.
Checking out everything "unreserved" and putting library.xmi and
plugin.xmi back into the VOB under CM is our only remaining option. So my
question is how well does that work? Are there any potential complications
associated with using the unreserved funtionality? Can you set up CC so
that it always check them out unreserved to save clicking 3 extra times
every time you check out something?
Thanks,
Sevon
|
|
|
| Re: Integration with ClearCase [message #44429 is a reply to message #44306] |
Wed, 17 October 2007 22:24 |
 Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello Sevon.
What you are trying to do would be comparable with two developers editing
the same source code file at the same time. To be able to do that you need
a compare-and-merge editor that would show you all conflicts the two people
created and let's you choose how to resolve this. Unfortunately, we do have
an editor like that (but hope that someone would be interested in developing
and contributing such an editor to the project).
However, you can create multiple plugins that are used by different content
authors. For example, I know of many users that create a plugin per
discipline plus a common base plugin in which they introduce 'stubs' for
shared elements; for example work products that are used and produced in
more than one discipline. Such a work product would be defined as an empty
element in the base and then Contribution variability would be used by the
disciplines to fill the work product with content from the discipline plugin
that would own it. Other discipline plugins can then reference the base
work product (e.g. tasks as inputs). When you publish the base and its
contribution will be published as one element because of the variability
relationship.
This approach for a content architecture also provides an inherent
governance for your method authoring team as it assigns clear
responsibilities for who can change which element instead of having everyone
change everything all at the same time creating content that is
inconsistently structured, for which conflicts need to be resolved, and
which requires constant refactoring.
Check-out the online help for a description of all files that get checked
out. The plugin.xmi file is basically storing the whole 'model' for the
plugin, i.e. the name and ids for all elements, packages, categories created
plus all their relationships. The idea is that there is a method designer
role owning this file which makes all modeling decisions on a coherent set
of tightly coupled/dependent method elements; which is what we call a method
plugin. The other .xmi files are content and process files which can be
checked-out by other content authoring users who do not model, but write the
rich text content. You see the implied usage and governance model for EPFC
is that there is a (or a small numbers) of designers/architects who performs
the modeling part and a larger number of content authors who document the
method elements by filling in and writing the rich text.
The library.xmi file is your central plugin registry that stores ids and
references for all your plugins. This file is indeed a bottleneck file for
parallel development as everyone who wants to add a new plugin or
configuration needs to check this file out. IBM Rational Method Composer
does not require this file as it has been designed as an extension to EPF
Composer to address such enterprise and larger team development needs.
Hope this helps,
Peter.
"Sevon Vanbebber" <Sevon.Vanbebber@baesystems.com> wrote in message
news:c296825cad32dcbb6ac4d1811e4ad4d5$1@www.eclipse.org...
>I still have a couple questions about using ClearCase.
> Because all of the content items in the folder are referenced in
> pligin.xmi, or library.xmi, ClearCase Checks out those items, along with
> every other items attached to it. This is not useful because then it keeps
> others from being able to check out anything in the plug-in, which defeats
> the purpose of even having Config Control.
>
> So we worked around this by deleting library.xmi and plugin.xmi from the
> VOB and added it to each of the Views. Now, when you edit, no one else's
> library.xmi or plugin.xmi gets updated, which created a new set of
> problems because library&plugin.xmi cannot find newly created content or
> content with changed names.
>
> So now, we have everyone working out of the same view, which is
> essentially the same as having no CM systems at all, but with all the
> extra CM hassle, which is still not what we want, but at least we are up
> and running again for teh short term.
> Checking out everything "unreserved" and putting library.xmi and
> plugin.xmi back into the VOB under CM is our only remaining option. So my
> question is how well does that work? Are there any potential complications
> associated with using the unreserved funtionality? Can you set up CC so
> that it always check them out unreserved to save clicking 3 extra times
> every time you check out something?
>
> Thanks,
> Sevon
>
|
|
| | |
| Re: Integration with ClearCase [message #584894 is a reply to message #43986] |
Sat, 13 October 2007 22:00 |
| Eclipse User |
|
|
|
Originally posted by: Sevon.Vanbebber.baesystems.com
Peter,
I've created my ClearCase View and opened it in the composer. I can open
the files (through the VOB) now in the EPFC, but I cannot edit them (which
I believe means I cannot check them out). When I try to write something I
get these 2 error messages:
Read-only File Encountered
File 'XXXX' is read-only. Do you wish to make it writeable?
Then I click Yes
Edit Element
IUPA0015E: Cannot edit element
Reason:
File 'XXXX' is read-only
Any Advise? All of the information in the Help file I believe is the same
as was located in the paper whose link I attached in the previous post. It
is useful, except that I do not know how to switch to the "ClearCase
Perspective", which I think is why I can't edit the file. Is it the same
as the CVS Perspective? or did I do something wrong?
Thanks, and happy Saturday :)
Sevon
|
|
| | |
| Re: Integration with ClearCase [message #585018 is a reply to message #44139] |
Wed, 17 October 2007 18:09 |
| Eclipse User |
|
|
|
Originally posted by: Sevon.Vanbebber.baesystems.com
I still have a couple questions about using ClearCase.
Because all of the content items in the folder are referenced in
pligin.xmi, or library.xmi, ClearCase Checks out those items, along with
every other items attached to it. This is not useful because then it keeps
others from being able to check out anything in the plug-in, which defeats
the purpose of even having Config Control.
So we worked around this by deleting library.xmi and plugin.xmi from the
VOB and added it to each of the Views. Now, when you edit, no one else's
library.xmi or plugin.xmi gets updated, which created a new set of
problems because library&plugin.xmi cannot find newly created content or
content with changed names.
So now, we have everyone working out of the same view, which is
essentially the same as having no CM systems at all, but with all the
extra CM hassle, which is still not what we want, but at least we are up
and running again for teh short term.
Checking out everything "unreserved" and putting library.xmi and
plugin.xmi back into the VOB under CM is our only remaining option. So my
question is how well does that work? Are there any potential complications
associated with using the unreserved funtionality? Can you set up CC so
that it always check them out unreserved to save clicking 3 extra times
every time you check out something?
Thanks,
Sevon
|
|
|
| Re: Integration with ClearCase [message #585068 is a reply to message #44306] |
Wed, 17 October 2007 22:24 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello Sevon.
What you are trying to do would be comparable with two developers editing
the same source code file at the same time. To be able to do that you need
a compare-and-merge editor that would show you all conflicts the two people
created and let's you choose how to resolve this. Unfortunately, we do have
an editor like that (but hope that someone would be interested in developing
and contributing such an editor to the project).
However, you can create multiple plugins that are used by different content
authors. For example, I know of many users that create a plugin per
discipline plus a common base plugin in which they introduce 'stubs' for
shared elements; for example work products that are used and produced in
more than one discipline. Such a work product would be defined as an empty
element in the base and then Contribution variability would be used by the
disciplines to fill the work product with content from the discipline plugin
that would own it. Other discipline plugins can then reference the base
work product (e.g. tasks as inputs). When you publish the base and its
contribution will be published as one element because of the variability
relationship.
This approach for a content architecture also provides an inherent
governance for your method authoring team as it assigns clear
responsibilities for who can change which element instead of having everyone
change everything all at the same time creating content that is
inconsistently structured, for which conflicts need to be resolved, and
which requires constant refactoring.
Check-out the online help for a description of all files that get checked
out. The plugin.xmi file is basically storing the whole 'model' for the
plugin, i.e. the name and ids for all elements, packages, categories created
plus all their relationships. The idea is that there is a method designer
role owning this file which makes all modeling decisions on a coherent set
of tightly coupled/dependent method elements; which is what we call a method
plugin. The other .xmi files are content and process files which can be
checked-out by other content authoring users who do not model, but write the
rich text content. You see the implied usage and governance model for EPFC
is that there is a (or a small numbers) of designers/architects who performs
the modeling part and a larger number of content authors who document the
method elements by filling in and writing the rich text.
The library.xmi file is your central plugin registry that stores ids and
references for all your plugins. This file is indeed a bottleneck file for
parallel development as everyone who wants to add a new plugin or
configuration needs to check this file out. IBM Rational Method Composer
does not require this file as it has been designed as an extension to EPF
Composer to address such enterprise and larger team development needs.
Hope this helps,
Peter.
"Sevon Vanbebber" <Sevon.Vanbebber@baesystems.com> wrote in message
news:c296825cad32dcbb6ac4d1811e4ad4d5$1@www.eclipse.org...
>I still have a couple questions about using ClearCase.
> Because all of the content items in the folder are referenced in
> pligin.xmi, or library.xmi, ClearCase Checks out those items, along with
> every other items attached to it. This is not useful because then it keeps
> others from being able to check out anything in the plug-in, which defeats
> the purpose of even having Config Control.
>
> So we worked around this by deleting library.xmi and plugin.xmi from the
> VOB and added it to each of the Views. Now, when you edit, no one else's
> library.xmi or plugin.xmi gets updated, which created a new set of
> problems because library&plugin.xmi cannot find newly created content or
> content with changed names.
>
> So now, we have everyone working out of the same view, which is
> essentially the same as having no CM systems at all, but with all the
> extra CM hassle, which is still not what we want, but at least we are up
> and running again for teh short term.
> Checking out everything "unreserved" and putting library.xmi and
> plugin.xmi back into the VOB under CM is our only remaining option. So my
> question is how well does that work? Are there any potential complications
> associated with using the unreserved funtionality? Can you set up CC so
> that it always check them out unreserved to save clicking 3 extra times
> every time you check out something?
>
> Thanks,
> Sevon
>
|
|
| | |
Goto Forum:
Current Time: Thu Dec 26 10:37:55 GMT 2024
Powered by FUDForum. Page generated in 0.04140 seconds |
] 
Search
Help
Register
Login
Home
