What would be the Pros and Cons of using CA SCM in this way ?
Is there a better alternative that using CA SCM as a Definitive Software Library ?
Looking for guidance. All information would be appreciated on this topic.
Thanks.
Hi,
I was building SCM towards the goal of having a DSL... in the end came to the conclusion that the software *could* be used to provide a load module DSL for midrange.. but that I would have to build everything else.
So, in the end, gave up on using Harvest to build a DSL with.
If COTS software does not provide 80% of the functionality you are looking for..
Cheers
G
Most version control tools can be used as a library for your baselined releases. I am more used to calling this a definitive media library (DML) - which is the terminology in ITIL. (Please clarify where DSL is from.)
We used to called our DML a release vob in ClearCase. The key is to NOT put the binary releases in the same repository where your developers are checking in their code (for performance reasons). But many people do include the source just for reference in the DML and I would view that as being a best practice.
Bob Aiello
Bob,
In ITIL v2 it was called the DSL. They updated it to the DML in v3.
So, your point is that you don't put the binaries in the same repository as where the developers are checking their code in. That being the case, where would you then store said binaries?
Regards,
Tim
Apologies Bob, I was using the ITIL V2 reference (thanks betzltr).
I agree with your synopsis: Source should be controlled separately to the storage and maintenance of load objects. The developers then have access to checkout/in the the source, and after build (hopefully with some automation - build management) the resulting objects are stored in a central location for release to specific target environments.
The main issue I had with Harvest is that since we are not using it for source control, and we could not use it for change management / release management, requiring users to interface with yet another product was getting to be unwieldy. In the end, an end-to-end solution was needed and it would have required a significant investment.. more than what was allocated for the project.
For a basic DSL, Harvest will do the job. It allows for checking in and checking out of load objects and can deliver the load objects to a target location. It does not have release management or automation functions. It has basic administration functions. You can define approver groups and implement an approval system (although, this may require database access).
One of the issues I was facing was on how to get the load modules into Harvest.. something I never adequately resolved..
It really does come down to 'what are your requirements'.
Tim - you would use the same technology but have separate instances. So if you were using ClearCase, you would have a separate Vob for the DSL. If you put the binaries in with the source then you will usually end up with a very big repository that has performance issues (bad idea).
I don't know the internals for Harvest, but presumably you can have different repositories are physically separate. This is a good example of why many people favor version control tools that are supported by robust back-end databases (e.g. Oracle, DB2, SQL Server)
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.