Technical Explanation for lack of version control?
Moderators: chulett, rschirm, roy
Technical Explanation for lack of version control?
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?
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
Ernie
Ernie Ostic
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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?
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?
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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.
Mamu Kim
but you need 8.5...the rest of us still suffer in silence.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.
Thank you everyone for your participation.
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.epmenard wrote: but you need 8.5...the rest of us still suffer in silence.
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.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.ray.wurlod wrote:For a extra few bucks you can buy a baseball bat that you can use to enforce best practice.
Well...I tried your solution this morning...now I'm on my way to jail...
![Cool 8)](./images/smilies/icon_cool.gif)
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: