Technical Explanation for lack of version control?

epmenard · Post by **epmenard** » Mon Jan 10, 2011 8:55 am

We all know that version control is possible only by exporting jobs beforehand and that Ascential and now IBM have been struggling for years to get a decent version control framework. Can anyone explain what are the technical reasons to explain such difficulties with the integration of a version control tool?

eostic · Post by **eostic** » Mon Jan 10, 2011 12:38 pm

Hard to say....but looking at the 8.5 solution, one concern may have been the desire not to get boxed in. The 8.5 solution uses Information Manager, which is Eclipse based, and takes advantage of source code tooling that "supports the Eclipse Team" standard.... ...but there are many reasons why capabilities are developed (or not) for any and all software products.

Ernie

ray.wurlod · Post by **ray.wurlod** » Mon Jan 10, 2011 3:21 pm

The main reason is that DataStage does not use source code for everything.

That immediately rules out source code control systems.

The Version Control product that lived through versions 6 and 7 did a reasonable job of version control, but lacked component-wise check-out and check-in capability. While that could have been done, "they" opted for the approach we now see in version 8.5, in which IS "packages" can be checked in/out using ISM, as Ernie mentioned.

epmenard · Post by **epmenard** » Tue Jan 11, 2011 1:36 pm

Thank you for your answers. But can we dig deeper? Why can't a regular source version application lock a component or file?

I assume the reason is the architecture behind it. Each individual job is not stored in a unique file? Are all jobs meshed within a single container and once compiled, become unmanageable?

ray.wurlod · Post by **ray.wurlod** » Tue Jan 11, 2011 3:07 pm

Each individual job IS stored in an individual table. Indeed, several tables. But these are not files, and not source code - the design time or run time objects are what are stored. Therefore, until a version control system that can deal with these objects can be invented, there won't be one. (Of course, one was invented, it was called Version Control for DataStage and shipped with the Ascential-branded versions but IBM, in their infinite wisdom, chose not to run with it.)

kduke · Post by **kduke** » Wed Jan 12, 2011 2:01 pm

The old version control lacked diff. The new releases of DataStage can now diff but lack the old version control. You can always export a job as XML or DSX and check in and out of your favorite version control but that is a little ugly. Most of us have solutions that we are happy with so I do not see it as an issue. The new diff is awesome, so thanks IBM. I prefer it to a good version control.

epmenard · Post by **epmenard** » Wed Jan 12, 2011 2:33 pm

kduke wrote:The old version control lacked diff. The new releases of DataStage can now diff but lack the old version control. You can always export a job as XML or DSX and check in and out of your favorite version control but that is a little ugly. Most of us have solutions that we are happy with so I do not see it as an issue. The new diff is awesome, so thanks IBM. I prefer it to a good version control.

but you need 8.5...the rest of us still suffer in silence.

Thank you everyone for your participation.

cppwiz · Post by **cppwiz** » Wed Jan 12, 2011 4:19 pm

epmenard wrote: but you need 8.5...the rest of us still suffer in silence.

I would argue that DS 8.5 does not have version control, but merely "documentation control". There is no enforced check-out/check-in source locking mechanism. After the source is checked-out to a developer, someone else can still open the source directly in DS Designer and make whatever changes they want.

This violates the very definition of version control. Thus, DS 8.5 is merely documentation control to document the changes assuming/trusting that no one else modified the source while it was checked-out.

ray.wurlod · Post by **ray.wurlod** » Wed Jan 12, 2011 4:33 pm

For a extra few bucks you can buy a baseball bat that you can use to enforce best practice.

epmenard · Post by **epmenard** » Thu Jan 13, 2011 8:44 am

ray.wurlod wrote:For a extra few bucks you can buy a baseball bat that you can use to enforce best practice.

Ah yes the 'American Way' of doing things. I didn't know you played baseball down under. I Like it! Although us Canadians usually prefer pacific resolutions.

Well...I tried your solution this morning...now I'm on my way to jail...

ray.wurlod · Post by **ray.wurlod** » Thu Jan 13, 2011 2:05 pm

Better than that, our delightful weather permits two seasons per year. I'm currently playing my 104th season. Started in 1958.

cdp · Post by **cdp** » Thu Jan 13, 2011 4:33 pm

Why would you play baseball when you have cricket?

IBM Analytics Champion 2009 - 2020 · Post by **asorrell** » Thu Jan 13, 2011 4:49 pm

Hmm - looks like a serious thread derailment has occured!

Please start a new thread detailing your issues with American Baseball. As with all new topics please include specific details including (but not limited to):
- Earned Run Rule
- Designated Hitter
- Strike-box variances between conferences