first impression of RTC
Now that I've got a feel for the tool, I'm pretty impressed, despite some quibbles. It's pretty neat the way the changes flow between workspaces, the way they are displayed and handled, the way you can back out of accepted changes and get them back later, the way diffs are shown, the way conflicts are resolved, etc.
The history looks pretty odd to someone used to the ClearCase version tree, but maybe this is a better way. I particularly applaud the RTC approach to branches. The CC approach, though it initially seems right, turns out to be clearly wrong, as the silly idea of trivial merges shows. This idea is not just silly, it kills the performance of deliver and rebase (RTC accept), since instead of some simple bookkeeping involving the change sets, new versions are created with all the overhead of checkout and a resultant blowup of metadata. Then you are presented with an incredible version tree, which takes minutes to render, only to find that there wasn't one significant merge in the entire history of a file! This means the things you want to be fast so you can get on with the real work are constantly in your face in CC. These are early days in my evaluation, but RTC looks like a big improvement over UCM! |
9 answers
Thanks for the feedback David.
I've got an article underway with a detailed tour of how the history view works and why, that should help map the concepts from the CC version graph. In summary, we really wanted history to be fast, and allow progressive discovery of other states. What we do want to add in 3.0 is the ability to see in which streams change sets have flowed, which currently is only available when you run "locate change set". This will help answer the question, what other streams will I need to flow this change set to fix this problem? Other than that, we really think that we have the other use cases covered and match the CC version tree, but with a bit snappier responses to the most common scenarios. Cheers, Jean-Michel |
|
I thought I would share a small benchmark comparing RTC and ClearCase performance.
I imported a slug of files (~450 files; ~40 MB zipped; mostly binary), into RTC and CC (clearfsimport) in similar environments (my pretty good notebook, local servers, clients, storage, etc.). RTC slurped down the lot in ~2 minutes. (It was so fast I didn't note the time exactly; could have been more like 1 1/2 minute.) CC labored along like a an old freight train for 14 minutes to do the same. Of course, this isn't a realistic setup, but I'm hoping the discrepency will be even greater when I get a real evaluation environment. -David |
|
My second impression of RTC isn't quite as rosy as the first.
I tried out adding a large binary file (5 GB). In my local notebook setup this took 80 minutes. (Sorry I can't compare this to ClearCase, because I can't get the file into the vob at all in this setup: cleartool: Error: INTERNAL ERROR detected. Typical CC misery...) Can someone comment if the time is probably due to the Derby database? Can I expect better with Oracle? |
My second impression of RTC isn't quite as rosy as the first. Hi David I expect you should see somewhat better performance on an enterprise-level DB and RTC - esp if the database is not on the same machine and you have a good network connection. However 5 Gb is a pretty big file - so it will take a while to add to source control. How long does a directory-to-directory copy of that file take? Have you discovered the Metronome tool inside the RTC Eclipse client yet? This is in the Windows->Preferences->Team->Jazz Source Control. Turn it on and you can do some network tests, as well as analyse where the time is spent on any of the operations. regards anthony |
|
Derby if definitely for playing around. We don't recommend for anything
real and not for large files. For real performance testing and testing large files I'd use DB2 or Oracle. Cheers, Jean-Michel On 8/14/2009 7:08 AM, David.Sedlock.infineon.com wrote: My second impression of RTC isn't quite as rosy as the first. |
Derby if definitely for playing around. We don't recommend for anything David, as an outsider, I can second that statement. When we first started piloting RTC, we used Derby, but ran into much the same thing with the large files (although not nearly 5 GB!) We installed DB2, which doesn't take long at all (the directions are easy to follow), and have had much better success/performance in our pilot. Good luck, Mike |
|
I figured Derby was the culprit - thanks for the confimation. So I will drop this topic until I have a real installation to test.
anthony said "I expect you should see somewhat better performance on an enterprise-level DB and RTC - esp if the database is not on the same machine" Is it really recommended to run the RTC server and Oracle on different hosts? Has this been definitively shown through benchmarks? My experience has all too often been that ideas that look nice architecturally often run foul of even slight amounts of latency... |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 17 '09, 8:22 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I believe by "not on the same machine", Anthony was referring to not
having the RTC server on the same machine as the RTC eclipse client. Cheers, Geoff David.Sedlock.infineon.com wrote: I figured Derby was the culprit - thanks for the confimation. So I |
Is there a work item for this feature (ideally planned for the next release :)? Thanks.
What we do want to add in 3.0 is the ability to see in which streams change sets have flowed, which currently is only available when you run "locate change set". This will help answer the question, what other streams will I need to flow this change set to fix this problem? |
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.