It's all about the answers!

Ask a question

Ability to link a work item to an SVN branch


Dan Rivett (1211115) | asked Mar 19 '09, 9:20 a.m.
We're using Subversion and some of our work items are large enough to merrit taking a branch to implement the work item, whilst others we work off trunk. I know svn revisions can be linked to the work item, but there doesn't seem to be a way of linking a work item to an svn branch to track it. Is this possible?

I don't believe it is, and it probably would be useful to the wider svn-rtc community so perhaps I should raise an enhancement if it isn't possible.

In the meantime I wanted to see if I could implement it myself so had a play around but to be honest it got a bit stuck.

This is what I tried:

I first created a plug-in which implemented the com.ibm.team.repository.common.linkTypes extension point in order to be able to link a work item to an svn branch. I expected it to appear as an option under the 'Add' drop down box in the links presentation type, but it didn't. But I believe I must have done something wrong as I thought I only needed to extend that extension point as below and add that to the client and it would be found. I also added it to the server but that didn't help. I've included the xml at the bottom in case I have done something wrong.

After implementing that extension point I wanted to then look at how to make it so that when you double click the linked svn branch name in the links presentation it opens up the branch in the subversive (or subclipse) "SVN Repositories" view.

I was going to look at the current implementation for linking an svn revision to a work item, as when you double click on a revision link it opens up that revision in the History view. However after downloading the source (at both 1.0.1.1 and 2.0M2D1) I couldn't find the source for the subversive and subclipse plug-ins. Any chance that the source zip could be updated to include that source?

I believe the source code I needed was in those there because after digging around it seemed I need to implement HyperLinkHandler or something to handle the URI associated with the link and open the appropriate "SVN Repositories" view. I found that com.ibm.team.scm.svn.esubversive.ui and com.ibm.team.scm.svn.psubversive.ui plug-ins implemented the com.ibm.team.foundation.rcp.core.hyperlinkHandler extension point. I assume I only need to look at one - probably the esubversive one - as I'm guessing 'p' is used for the older version (polarion) and 'e' for the newer incubated eclipse version.

I wasn't sure how URI is created for my new link type, I hadn't got that far.

I feel I have dug as far as I can without taking days looking at it, and without RTC's source code for the subversive integration I wasn't getting very far.

Any ideas about how to implement this would be really appreciated.
Thanks,
Dan

My implementation of the com.ibm.team.repository.common.linkTypes extension-point:

   <extension

point="com.ibm.team.repository.common.linkTypes">
<linkType
id="com.ibm.cics.service.jazz.svn.common.linktype.relatedbranch">
<target>
<endpoint
displayName="SVN Branch"
icon="icons/branch.gif"
id="svn_branch"
multiplicity="0..1">
</endpoint>
</target>
<source>
<endpoint
displayName="Owning Work Item"
icon="icons/wi_general.gif"
id="svn_branch_owner"
multiplicity="0..1">
<itemReferenceType
itemTypeName="WorkItem"
packageURI="com.ibm.team.workitem">
</itemReferenceType>
</endpoint>
</source>
</linkType>
</extension>

4 answers



permanent link
Dan Rivett (1211115) | answered Mar 24 '09, 11:33 a.m.
Thanks Michael, I'll have a look at the source and see if I can get something to work with 1.0.1.1 and the latest 2.0 beta, hopefully any differences won't break me.

The reason why we're using SVN is that the Development team decided on SVN a few years ago when RTC was not around (or certainly not a GA product) and so in Service we want to remain on the same code repository system as Development.

There are plans to investigate moving Development (and Service) from SVN to SCM in the next 12 months - when product schedules allow, but until then we need to try and integrate SVN to RTC as best we can to make sure the user experience isn't too disjoint. (It makes it more interesting that the Service team are new to SVN as well as RTC so any UI simplifications we can provide will help).

I'll have a go at getting it working, and I post later with any updates.

Thanks again,
Dan

permanent link
Michael Valenta (3.7k3) | answered Mar 24 '09, 10:36 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Dan,

I implemented the SVN/RTC work item bridge. I'm not sure why the source
code is not included in the source drop. I can send you the source code
if you like but the problem is that the code makes use of SCM internals
tat are subject to change (i.e. for link management) so anything you
build on top of it could be broken by future changes in SCM.

I am curious to know something. Why did you decide to use RTC work items
but not SCM? Is there something that ties you to SVN? I ask because
managing and merging between streams in Jazz SCM is easier than it is in
SVN (IMHO).

Michael

dansoton wrote:
Hi Michael,

Thanks for your response. I've raised
defect
75533 to track the missing source code.

Regarding the reasons for linking a branch to a work item, the main
reason is that I work in a Service team we need to isolate code
changes for each APAR (bug fix) so that we can concurrently deliver
fixes to customers without pulling in other half-finished code fixes.
Because of this it is useful to record the branch that was created to
put the code change in, before it's merged into our service stream.

I could create a custom attribute for our work item, but I believe
that the linking architecture has been created to allow work items to
be linked to other artifacts, and so thought I would continue down the
same lines as what RTC development have implemented for linking work
items to SVN revisions.

By using a link it means we can have better UI integration, so that by
double clicking on the link it can take the user directly to the
branch in the "SVN Repositories" view. Then if the user
wants to look at the code they can look at the history of that
branch, or they can check out the code at that release or browse it
on the server directly.

If a custom attribute was used instead, the user could manually look
up the branch for sure, but the UI integration wouldn't be very good.
We're hoping to extend the existing UI integration for linking work
items to revisions to also linking work items to a branch.

This should hopefully further enhance the integration between RTC and
SVN.

If you have any more information on how I could achieve this, or a
contact in the RTC development team who implemented the SVN
Subversive/Subclipse integration I would find it very useful. If I
had the source for the SVN plug-ins I could probably work out how to
implement it based on the existing integration with the SVN History
view, but without it I need to get some pointers from someone who has
already done something very similar.

Many thanks in advance,
Dan

permanent link
Dan Rivett (1211115) | answered Mar 24 '09, 6:42 a.m.
Hi Michael,

Thanks for your response. I've raised defect 75533 to track the missing source code.

Regarding the reasons for linking a branch to a work item, the main reason is that I work in a Service team we need to isolate code changes for each APAR (bug fix) so that we can concurrently deliver fixes to customers without pulling in other half-finished code fixes. Because of this it is useful to record the branch that was created to put the code change in, before it's merged into our service stream.

I could create a custom attribute for our work item, but I believe that the linking architecture has been created to allow work items to be linked to other artifacts, and so thought I would continue down the same lines as what RTC development have implemented for linking work items to SVN revisions.

By using a link it means we can have better UI integration, so that by double clicking on the link it can take the user directly to the branch in the "SVN Repositories" view. Then if the user wants to look at the code they can look at the history of that branch, or they can check out the code at that release or browse it on the server directly.

If a custom attribute was used instead, the user could manually look up the branch for sure, but the UI integration wouldn't be very good. We're hoping to extend the existing UI integration for linking work items to revisions to also linking work items to a branch.

This should hopefully further enhance the integration between RTC and SVN.

If you have any more information on how I could achieve this, or a contact in the RTC development team who implemented the SVN Subversive/Subclipse integration I would find it very useful. If I had the source for the SVN plug-ins I could probably work out how to implement it based on the existing integration with the SVN History view, but without it I need to get some pointers from someone who has already done something very similar.

Many thanks in advance,
Dan

permanent link
Michael Valenta (3.7k3) | answered Mar 23 '09, 10:13 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
What are you hoping to accomplish by "linking" a work item to a branch
to "track" it. Are you just hoping to link a work item to a particular
folder path in SVN (since, in SVN, a branch is really just a folder) or
are you hoping to get more out of it?

In regards to the missing "Add", you need to make your linkType
uncontrained. For example:

<linkType>

In regards to the missing source, your best course of action would be to
log a work item against Source Control requesting the source be added.
You are right that the com.ibm.team.scm.svn.esubversive.ui handles the
linking for Subversive but I believe the linking behavior is abstracted
out into a more general plug-in that is used by both Eclipse SVN
clients. In the end, I'm not sure how much the existing code would help
since it links to the history view, not the Repositories view.

Michael

dansoton wrote:
We're using Subversion and some of our work items are large enough to
merrit taking a branch to implement the work item, whilst others we
work off trunk. I know svn
revisions can be linked to the work item, but there doesn't seem to
be a way of linking a work item to an svn branch to track it. Is this
possible?

I don't believe it is, and it probably would be useful to the wider
svn-rtc community so perhaps I should raise an enhancement if it
isn't possible.

In the meantime I wanted to see if I could implement it myself so had
a play around but to be honest it got a bit stuck.

This is what I tried:


I first created a plug-in which implemented the
com.ibm.team.repository.common.linkTypes
extension point in order to be able to link a work item to an svn
branch. I expected it to appear as an option under the 'Add' drop
down box in the links presentation type, but it didn't. But I believe
I must have done something wrong as I thought I only needed to extend
that extension point as below and add that to the client and it would
be found. I also added it to the server but that didn't help. I've
included the xml at the bottom in case I have done something wrong.

After implementing that extension point I wanted to then look at how
to make it so that when you double click the linked svn branch name
in the links presentation it opens up the branch in the subversive
(or subclipse) "SVN Repositories" view.

I was going to look at the current implementation for linking an svn
revision to a work item, as when you double click on a revision link
it opens up that revision in the History view. However after
downloading the source (at both 1.0.1.1 and 2.0M2D1) I couldn't find
the source for the subversive and subclipse plug-ins. Any chance that
the source zip could be updated to include that source?

I believe the source code I needed was in those there because after
digging around it seemed I need to implement
HyperLinkHandler or something to handle
the URI associated with the link and open the appropriate "SVN
Repositories" view. I found that
com.ibm.team.scm.svn.esubversive.ui and
com.ibm.team.scm.svn.psubversive.ui
plug-ins implemented the
com.ibm.team.foundation.rcp.core.hyperlinkHandler
extension point. I assume I only need to look at one - probably the
esubversive one - as I'm guessing 'p' is used for the older version
(polarion) and 'e' for the newer incubated eclipse version.

I wasn't sure how URI is created for my new link type, I hadn't got
that far.

I feel I have dug as far as I can without taking days looking at it,
and without RTC's source code for the subversive integration I wasn't
getting very far.

Any ideas about how to implement this would be really appreciated.
Thanks,
Dan

My implementation of the
com.ibm.team.repository.common.linkTypes
extension-point:

extension

point="com.ibm.team.repository.common.linkTypes"
linkType

id="com.ibm.cics.service.jazz.svn.common.linktype.relatedbranch"
target
endpoint
displayName="SVN Branch"
icon="icons/branch.gif"
id="svn_branch"
multiplicity="0..1"
/endpoint
/target
source
endpoint
displayName="Owning Work Item"
icon="icons/wi_general.gif"
id="svn_branch_owner"
multiplicity="0..1"
itemReferenceType
itemTypeName="WorkItem"
packageURI="com.ibm.team.workitem"
/itemReferenceType
/endpoint
/source
/linkType
/extension

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.