Version Control

This topic has come up before. We rely on the standard Cloverleaf revisions directory, which is very low tech and pretty easy to circumvent. But it is there out of the box. Some people use svn and cvs and other tools.

https://usspvlclovertch2.infor.com/viewtopic.php?t=2729

https://usspvlclovertch2.infor.com/viewtopic.php?t=5787

https://usspvlclovertch2.infor.com/viewtopic.php?t=6729

Well the NetConfig can have the order of some of the keyed lists changed even though the values are the same as a result of just saving the NetConfig from the IDE (at least that used to happen).

So that might indicate changes that really did not occur for some of the generic tools.

Here is another thread.

https://usspvlclovertch2.infor.com/viewtopic.php?t=5913

We store NetConfig files in CVS with the site appended

eg

NetConfig_top_prod_rp

NetConfig_top_prod_fh

The problem is that everyone want source control as long as it is the source control we want.  😀   So the idea is to allow you to pick your own.

Git is really gaining popularity and there is a free version.  This is the same source control used by the keepers of SQLite and many others.

Take a look:  http://git-scm.com/

Greetings,

We are planning to migrate from 5.8.7.0 (AIX 6.1 TL 9) to 6.0.2 (preferably 6.1 if it becomes available soon) and understand that there are migration tools (the BOX function) that includes some sort of version management.

At least for migration of changes.

Has anyone seriously evaluated the BOX function?  checked into the versioning aspect of the BOX tools?

Thanks.

Bob,

We are on 6.0.0 and I am sure BOX has been updated after 6.0.0.

However I think these are still issues (and I am not sure how they might be solved):

Imbedded Tcl calls (lets say procA calls proc2) procA will be in the BOX, proc2 will not. I understand there is now a facility for you to manually include invoked procs (like proc2 in the above example) but that is not quite as automated and does require some manual intervention.

As I understand it that also applies to Xlates which invoke procs rather than in-line Tcl (we reference procs rather than in-line Tcl a lot). So for us that is a real potential issue.

Likewise I believe for Tables referenced from inside Tcl via hcitbllookup.

I suspect the same might be true for formats referenced (via GRM for example) inside Tcl.

As I said I don’t know how some of the above would be programmatically discoverable via BOX so they may be issues for some time.

Having said the above this should be tempered with the knowledge we are not on the most current release and have not exercised BOX a lot.

Bob,

We are on 6.0.0 and I am sure BOX has been updated after 6.0.0.

However I think these are still issues (and I am not sure how they might be solved):

Imbedded Tcl calls (lets say procA calls proc2) procA will be in the BOX, proc2 will not. I understand there is now a facility for you to manually include invoked procs (like proc2 in the above example) but that is not quite as automated and does require some manual intervention.

As I understand it that also applies to Xlates which invoke procs rather than in-line Tcl (we reference procs rather than in-line Tcl a lot). So for us that is a real potential issue.

Likewise I believe for Tables referenced from inside Tcl via hcitbllookup.

I suspect the same might be true for formats referenced (via GRM for example) inside Tcl.

As I said I don’t know how some of the above would be programmatically discoverable via BOX so they may be issues for some time.

Having said the above this should be tempered with the knowledge we are not on the most current release and have not exercised BOX a lot.