[Openroad-users] OpenROAD and versioning

54 views
Skip to first unread message

Frédéric Barbier

unread,
May 23, 2006, 4:12:04 AM5/23/06
to Openroad-Users@Peerlessit. Com

Hi,

 

We’d like to introduce a versioning and bug tracking system for all our development: Java, .Net and OpenROAD.

We were thinking to use Subversion. Java and .Net will not be an issue, but...

Does anyone have experience integrating OpenROAD with f.i. Subversion?

I know that source code is stored in a system table, but maybe there is a way...

 

Thanks for any feedback on this!

Frédéric Barbier

AP&P, Belgium

 

 

 

gareth.2...@bt.com

unread,
May 23, 2006, 9:16:38 AM5/23/06
to openroa...@peerlessit.com
Here's a link to the documentation:
ftp://ftp.ingres.com/pub/ingres/docs/

You'll need to contact CA to get OpenROAD. I'm not sure if a SDK is still available. No technical prerequisite for learning Ord, it's an OO based 4GL language. If you have VB skills it shouldn't that hard to convert. SQL knowledge is useful and I'm sure someone else will be along to fill in more info.


Cheers,
Gareth Edwards

BT Global Services
tel: +44 (0)131 345 4671
email: gareth.2...@bt.com

-----Original Message-----
From: openroad-us...@peerlessit.com [mailto:openroad-us...@peerlessit.com] On Behalf Of Sanjay S Patil1
Sent: Tuesday, May 23, 2006 11:16 AM
To: OpenROAD Users
Cc: openroa...@peerlessit.com; openroad-us...@peerlessit.com
Subject: Re: AW: [Openroad-users] OpenROAD and versioning

Hi ,
I am new to OpenRoad. I don't know anything on OpenRoad. Can you please send some Docs & Setup so that I can install it on my system & start learning OpenRoad.
Can you Please Guide me? What is the Prerequisite for learning OpenRoad?

Best Regards,
Sanjay Patil



<M.Schlienger@bjo
ernsen.de>
Sent by: To
openroad-users-bo <openroa...@peerlessit.com>
unces@peerlessit. cc
com
Subject
AW: [Openroad-users] OpenROAD and
05/23/2006 02:17 versioning
PM


Please respond to
OpenROAD Users
<openroad-users@p
eerlessit.com>


Salut Frédéric,

With OpenROAD development, the source code repository is actually the database where the OpenROAD development tables lie. Since you want to use an external code repository, you have to handle the OpenROAD development database as a temporary development platform: each time an update is performed, you need to replace the artifact in the database. You need to import and export the sources from the OpenROAD repository as you update and checkout from/into the subversion repository. There are tools out there for importing and exporting OpenROAD applications and components. You have the choice to handle the source code artifacts in two ways:
- either importing/exporting the whole OpenROAD applications (outofthebox command line utility: w4gldev backupapp in/out ...)
- or importing/exporting each OpenROAD application component, you basically have a folder per application with its list of components (the ORBatchUtilities from Christian Delaunay allow to import/export sole
components)

The problem with importing/exporting the application components is that you get lost of the dependencies amongst the applications. This information is only kept in the export-file when exported as whole application. If you have a strong committer activity among numerous developers, it might be better to use components, you would else get lots of conflicts using application artifacts.

Depending on the granularity you choose (component/application), you'll have a different set of tools and a different repository interaction workflow.

Hope this let you start in the right direction.

Mit freundlichen Grüßen,

Björnsen Beratende Ingenieure GmbH,
i. A.

Marc Schlienger.

_________________________________________

Björnsen Beratende Ingenieure GmbH
Maria Trost 3,
D-56070 Koblenz
Tel.: +49 (0)261/8851-145 (Durchwahl) -0 (Zentrale)
Fax.: +49 (0)261/805725

mailto:m.schl...@bjoernsen.de
Besuchen Sie unsere Homepage: http://www.bjoernsen.de

Die Björnsen Beratende Ingenieure GmbH macht Sie darauf aufmerksam, dass diese E-Mail und etwaig beigefügte Dateien nur der Vorabinformation dienen und keine rechtswirksamen Willenserklärungen oder Beratungsleistungen darstellen. Es können daher in keinem Fall Haftungsansprüche hierauf begründet werden. Alle rechtswirksamen Äußerungen (Verträge, Gutachten, Stellungnahmen, Berechnungen, Vermerke etc.) erhalten Sie von uns wie gewohnt und nach Qualitätskontrolle in schriftlicher Form und ggf. auf separatem Datenträger.

> -----Ursprüngliche Nachricht-----
> Von: openroad-us...@peerlessit.com
> [mailto:openroad-us...@peerlessit.com] Im Auftrag von Frédéric
> Barbier
> Gesendet: Dienstag, 23. Mai 2006 10:12
> An: Openroad-Users@Peerlessit. Com
> Betreff: [Openroad-users] OpenROAD and versioning

_______________________________________________
Openroad-users mailing list
Openroa...@peerlessit.com
http://www.peerlessit.com/mailman/listinfo/openroad-users

_______________________________________________
Openroad-users mailing list
Openroa...@peerlessit.com
http://www.peerlessit.com/mailman/listinfo/openroad-users

_______________________________________________
Openroad-users mailing list
Openroa...@peerlessit.com
http://www.peerlessit.com/mailman/listinfo/openroad-users

Sanjay S Patil1

unread,
May 23, 2006, 6:16:15 AM5/23/06
to OpenROAD Users, openroad-us...@peerlessit.com, openroa...@peerlessit.com

Sanjay S Patil1

unread,
May 24, 2006, 12:01:53 AM5/24/06
to OpenROAD Users
Hi Gareth,
Many thanks for your kind cooperation.
I have tried the ftp you mentioned but I don't have permissions. I am
not getting the docs.


Regards,
Sanjay



<gareth.2.edwards
@bt.com>

Sent by: To
openroad-users-bo <openroa...@peerlessit.com>
unces@peerlessit. cc
com
Subject

RE: AW: [Openroad-users] OpenROAD
05/23/2006 06:46 and versioning

Neil Warnock

unread,
May 23, 2006, 9:43:40 AM5/23/06
to OpenROAD Users
Hi Frédéric, All,
 
Marc Schlienger covers the main issues in his follow up email. It is spot on.
 
Many have glued OpenROAD into code versioning systems in the past,
with varying degrees of success. I remember Kim Ginnerup demonstrated a great
solution at CAWorld some years ago, involving DBEvents on the system catalogs (!) to
track changes. And I think he offered the source code - sorry if I've got this wrong, Kim...
I know people like Paul White, Pete Rabjohns etc have also got this taped, as have others
(including Ingres Corp); but approaches, and I've seen a few, vary from 'trust-to-luck' through
'discipline & manual spreadsheets' to Megasystem3000 !
 
Luminary has the same issue and it's getting worse: the volume of .NET and Java stuff being integrated
with OpenROAD is on the increase, so after years of jogging along with sticking plaster and string, we bit
the bullet and built something a bit more mainstream that works with CVS or SubVersion.
It's not perfect, it's not complete (it's an internal grad/bench project that will eventually be an IUA case study!)
but it's well designed from the ground up rather than a hacked 'that'll do for now' approach.
 
I'll send anyone the external design proposal which includes block architecture
diagram and screen shots. Feel free to nick ideas from it - it's not rocket science but there are some
good bits in it - and if anyone wants to fund us to 'productise' it that'd be fine!  It's a 1Mb word doc so I
won't broadcast it (don't want more trouble from that Paul White bloke ;) )
 
Here's the  intro FYI
 

1     Introduction

Software Configuration Management (SCM) is a term that encompasses a breadth of activities employed throughout the typical software development lifecycle. An established SCM approach offers numerous benefits to customer and developer alike and reinforces process and quality of deliverable. There is no formal list of processes or tasks that constitute SCM but widely accepted elements include the following:

·         Version Control

It is usual for software applications to evolve through several versions during their lifetime. In turn, each version can be made up of interim releases e.g. software patches or service packs. An effective procedure to manage and deploy these versions is an important part of any business SCM;

·         Source Control

Typical software development consists of a number of developers working on a number of project components such as documentation, resource and source code files. This is open to abuse and mismanagement unless rigorous but easy to follow source control practices are put in place;

·         Release Management

The deliverable and frequency of release varies significantly from application to application. Some products may require an update every year whereas some may be subject to nightly builds. A proper methodology should be established to allow the smooth running of application build and deployment;

·         Change Management

It is impractical to produce software that is completely free from errors; in addition the required functionality will usually evolve over time. To manage this, the software development process should have change management mechanisms in place to handle issue tracking and customer change requests.

A number of solutions exist to address many of the issues raised by SCM requirements. Luminary undertook an investigation into these options out of a need for improvement to the configuration and management of its many concurrent software development projects. In particular, the focus was on managing developments which incorporate OpenROAD because:

·         This platform is used in the majority of Luminary’s current developments;

·         SCM functionality within the OpenROAD Workbench Integrated Development Environment (IDE) is severely lacking.

This document summarises the findings of the investigation and all of the follow up activities performed. The intended audience for this document is OpenROAD technology shops who may be experiencing similar difficulties in SCM including source code lineage and release management.

The remainder of this document is comprised of the following sections:

·         Management Summary

A brief summary of the principal findings of this document;

·         SCM Alternatives

A critique of each of the SCM solutions investigated by Luminary and a recommendation of the approach decided upon;

·         High Level Architecture

A description of the architecture employed in the proposed Luminary SCM solution and its key benefits;

·         SCM Product Description

A detailed description of the functionality so far implemented in the prototype Luminary SCM solution. Example screenshots are included to illustrate the key features discussed;

·         SCM Application Roadmap

Suggested future enhancements to the Luminary SCM.

At the end of the document a reference section highlights some of the items discussed with any URLs that provide further reading.


2     Management Summary

Luminary is a software development company with many concurrent software developments active at any one time. These use various technology platforms including Ingres, OpenROAD, .NET and Java. Procedures and standards are in place to ensure the correct management of these developments and their deliverables. These vary depending on the technology concerned, for example Microsoft’s Visual Source Safe (VSS) is incorporated into all .NET development source control whereas the open source product Subversion is used for Java development.

A significant amount of software development at Luminary involves the Ingres relational database and OpenROAD 4GL programming language. Whilst the OpenROAD language provides a comprehensive IDE via Workbench it leaves a lot to be desired in provision of SCM functionality. Source control is difficult as there is no reliable mechanism within the product. Code is repository based, living in an Ingres database, which presents immediate problems compared to file based languages like Java. Versioning of OpenROAD components is possible but this is prone to error, buggy and is not commonly used. Build and deployment relies heavily on the Workbench and requires a considerable amount of human interaction to control.  Excel spreadsheets are often used to track component versions and releases, which is acceptable for short ‘build and deliver’ projects, but unwieldy for projects where multiple concurrent versions are required; for example when ‘test’, ‘live’, and ‘development’ versions of the same software exists.

OpenROAD is not the only development environment to suffer from a lack of SCM support and this is why the market for this kind of product is thriving. There are numerous vendor products available, both commercial and open source, that provide some level of SCM for developers and customer. Luminary has evaluated a number of these products, with particular regard to addressing issues with concurrent development of OpenROAD applications. From these alternatives an approach was chosen that offered the ‘best fit’ in terms of balancing flexibility with future development and addressing immediate issues that Luminary has with SCM.

This document discusses the solutions evaluated and describes in some detail the approach chosen with justification of decisions made. It is intended to provide an impartial view of the steps Luminary recommends in addressing problems in the area of SCM. It is hoped that this information will be useful to other software developers, not just in Ingres and OpenROAD, but with a similar technology portfolio as that used at Luminary. 

Even though the discussion attempts to provide a solution that is generic enough for any technology, the intended audience of this document is those who are familiar with the OpenROAD development environment.

<snip>

 Rgds,

Neil Warnock
Luminary Solutions
Tel: +44 (0)870 757 40 90 
Mob: +44 (0)771 265 0291 
Email: Neil.W...@luminary.co.uk

For more information on Luminary go to http://www.luminary.co.uk
 

M.Schl...@bjoernsen.de

unread,
May 23, 2006, 4:47:01 AM5/23/06
to openroa...@peerlessit.com
Salut Frédéric,

Mit freundlichen Grüßen,

Marc Schlienger.

_________________________________________

> Betreff: [Openroad-users] OpenROAD and versioning


>
> Hi,
>
>
>
> We'd like to introduce a versioning and bug tracking system
> for all our development: Java, .Net and OpenROAD.
>
> We were thinking to use Subversion. Java and .Net will not be
> an issue, but...
>
> Does anyone have experience integrating OpenROAD with f.i. Subversion?
>
> I know that source code is stored in a system table, but
> maybe there is a way...
>
>
>
> Thanks for any feedback on this!
>
> Frédéric Barbier
>
> AP&P, Belgium
>
>
>
>
>
>
>
>

_______________________________________________

Paul Andrews

unread,
May 23, 2006, 9:32:32 AM5/23/06
to OpenROAD Users
Err.. OpenROAD is shown as a product from ingres corp..
http://www.ingres.com/products/Prod_OpenROAD.html

Paul

Lovell, Simon

unread,
May 23, 2006, 7:08:02 PM5/23/06
to OpenROAD Users

Hi,

I may soon be interested in Kim’s solution here – you’ve certainly got my attention.  Does anyone (like Kim) have more information?

 

 

Simon Lovell
Analyst/Programmer
CA Technical Services
07 3367 7116


Reply all
Reply to author
Forward
0 new messages