What is lost using Subversion instead of Jazz SCM
3 answers
Hello kesterto,
Hi Anthony,
It is more inconvenient than our Jazz SCM integration - you have to type
the workitem ID manually. So you loose Start working, Stop Working.
SVN does not support a server side sandbox (Repository Workspace) so you
loose all that too. The build engine would require some manual work to access
the latest code in svn and I guess you would loose the convenient WorkItem
that went into the build too. SVN can not suspend work so you either have
to manage several workspaces or you have to commit work that does not compile
in order not to loose it. I think Jazz SCM ist is far better than SVN anyway
- again the Repository Workspaces.
Drop me an e-mail, I have some slides where I tried to sum up what I think
the differences are. Also, if you want to try it out, my demo toolkit has
a small SVN enabled demo setup that comes with preconfigured workspaces and
a svn database plus batches to install them. Drop me an e-mail and I can
share that. It works in the POT image updated to 1.0.1.
Ralph
Hi Anthony,
It is more inconvenient than our Jazz SCM integration - you have to type
the workitem ID manually. So you loose Start working, Stop Working.
SVN does not support a server side sandbox (Repository Workspace) so you
loose all that too. The build engine would require some manual work to access
the latest code in svn and I guess you would loose the convenient WorkItem
that went into the build too. SVN can not suspend work so you either have
to manage several workspaces or you have to commit work that does not compile
in order not to loose it. I think Jazz SCM ist is far better than SVN anyway
- again the Repository Workspaces.
Drop me an e-mail, I have some slides where I tried to sum up what I think
the differences are. Also, if you want to try it out, my demo toolkit has
a small SVN enabled demo setup that comes with preconfigured workspaces and
a svn database plus batches to install them. Drop me an e-mail and I can
share that. It works in the POT image updated to 1.0.1.
Ralph
Hi
I used the Help system to work out what you can do with Subversion
used in place of the normal Jazz SCM (link RTC work items to SVN), but
what do we lose using SVN?
thanks
anthony
Comments
You mentioned you have some slides comparing SVN vs RTC. We are preparing to roll our existing code into our new JAZZ Project but some developers want to continue using SVN instead of using the eclipse plugin that comes with RTC.
We are very concerned with tracebility back to the RTC eclipse baseline, work items, requirements, etc. We will have some developers at other sites using the eclipse plugin and checking in code to RTC as well as the possibility of this SVN base.
Do you have any current documentation about what we would be losing if we used the SVN bridge? The information on jazz.net is from 2008/2009 and we are using v4.0.1 of JAZZ.
As far as I can tell, there are no enhancements to the SVN bridge since then. So all above still applies. I would strongly suggest to use Jazz SCM.
With respect to some developers 'wanting to use SVN', well, sometimes you have to decide and overcome resistance to change. :-)
My project is in the process of moving from SVN to Jazz SCM. Most sentiment in the team is that Jazz SCM is much better than SVN. Apart from the items mentioned by Ralph, what you do get with SVN is the fact that people can check code into the repository without a work item (unless the RTC integration provides some locking of the SVN system). This is obviously not safe from an traceability perspective.
Kieron
Kieron
Apart from the items mentioned by Ralph, what you do get with SVN is the fact that people can check code into the repository without a work item (unless the RTC integration provides some locking of the SVN system). This is obviously not safe from an traceability perspective.
Delivering code without a work item is also possible in RTC. just clear all the pre-requisites in the deliver permission. This however makes it hard for me to deliver items to the integration stream (which has this requirement on top of other things) that I made sure nobody can deliver un-associated change sets to the development stream. Creating work items in RTC is a cheap operation anyway. :)
ciao!