Connecting CVS to RTC
Perhaps I just don't understand RTC, Jazz and it's relation to source control. Let me ask generally...
I've installed RTC. I have a CVS repository containing a web app written in PHP. I would ilke to connect this CVS area into RTC. How do I do that?
Is it such that I "import" a CVS project into a Jazz repository and thereafter forget about my CVS repository? IOW can I open a PHP file in RTC, edit it, debug it, and check it in and see the change in my CVS repository?
I'm confused.
I've installed RTC. I have a CVS repository containing a web app written in PHP. I would ilke to connect this CVS area into RTC. How do I do that?
Is it such that I "import" a CVS project into a Jazz repository and thereafter forget about my CVS repository? IOW can I open a PHP file in RTC, edit it, debug it, and check it in and see the change in my CVS repository?
I'm confused.
12 answers
I assure you - I am not resisting change merely because change is painful. Indeed, if there were much to be gained then I would be changing. However if there is not that much to be gained then IMHO there's not much reason to change.
Look around, I'm posting other articles and asking other questions about things that IMHO will make me more productive. They are oriented toward the "How do I use this environment to get my portion of the job (coding, debugging, etc.) done" and they are not oriented towards the "How can I create more views/ways/reports about what I'm doing and what I'm planning to do". There are some parts that I am interested in and other parts that I just am not interested in because it's just not how I roll as they say.
I really don't care how well RTC is oriented to managing projects - my true interests will always reside in the coding side over the planning side. That's why I'm not in management and have never really had an interest in being in management. To me, coding is much more interesting than managing.
Look around, I'm posting other articles and asking other questions about things that IMHO will make me more productive. They are oriented toward the "How do I use this environment to get my portion of the job (coding, debugging, etc.) done" and they are not oriented towards the "How can I create more views/ways/reports about what I'm doing and what I'm planning to do". There are some parts that I am interested in and other parts that I just am not interested in because it's just not how I roll as they say.
I really don't care how well RTC is oriented to managing projects - my true interests will always reside in the coding side over the planning side. That's why I'm not in management and have never really had an interest in being in management. To me, coding is much more interesting than managing.
Hey Andrew,
As someone who has to manage software projects, I end up using the
planning aspects of RTC a lot. Having the things you don't like to do
be made simpler and easier can sometimes be the most important :-).
But when I do get to put on my coder hat, the parts of RTC that are the
most valuable are the ability to easily suspend and resume change-sets,
and if I'm working with my buddies, easily grab their change sets (even
before they are ready to deliver them) and take a look at them in my
workspace (dropping them when I'm done looking at them, with everything
returned back to the state it was in before I accepted them).
It's equally easy to back change sets out of the team stream (i.e.
*after* they've been delivered, either my own or someone elses), and
easy to see what changes my other team mates have delivered (either at
the change set level, or at the file level, my choice).
Cheers,
Geoff
defaria wrote:
As someone who has to manage software projects, I end up using the
planning aspects of RTC a lot. Having the things you don't like to do
be made simpler and easier can sometimes be the most important :-).
But when I do get to put on my coder hat, the parts of RTC that are the
most valuable are the ability to easily suspend and resume change-sets,
and if I'm working with my buddies, easily grab their change sets (even
before they are ready to deliver them) and take a look at them in my
workspace (dropping them when I'm done looking at them, with everything
returned back to the state it was in before I accepted them).
It's equally easy to back change sets out of the team stream (i.e.
*after* they've been delivered, either my own or someone elses), and
easy to see what changes my other team mates have delivered (either at
the change set level, or at the file level, my choice).
Cheers,
Geoff
defaria wrote:
I assure you - I am not resisting change
merely because change is painful. Indeed, if there were much to be
gained then I would be changing. However if there is not that much to
be gained then IMHO there's not much reason to change.
Look around, I'm posting other articles and asking other questions
about things that IMHO will make me more productive. They are
oriented toward the "How do I use this environment to get my
portion of the job (coding, debugging, etc.) done" and they are
not oriented towards the "How can I create more
views/ways/reports about what I'm doing and what I'm planning to
do". There are some parts that I am interested in and other
parts that I just am not interested in because it's just not how I
roll as they say.
I really don't care how well RTC is oriented to managing projects - my
true interests will always reside in the coding side over the planning
side. That's why I'm not in management and have never really had an
interest in being in management. To me, coding is much more
interesting than managing.
page 2of 1 pagesof 2 pages