Yes. There should be a clear text copy in ./src/inc. So, you should:
SCCS Ver aa.bb.cc.dd | | | |-> Sequence, maintained by SCCS | | |----> Branch, code as 1 = std. code, 2 = custom, 3-8 = site[1-5] | |-------> Level, maintained by SCCS |----------> Release, incremented as necessary
Am I asking too much? This doesn't seem too outrageous! I have been looking though the printed SMGR materials and the SCO Manuals trying to come up with a solution. I can force new branches, but I am having no luck specifying the branch number. I also believe that if I do this in a script I will have to create stsrev.d records that I will have to import into the database to keep it current. Is this a reasonable thing to do. Some of us would prefer to work in vi and use Unix scripts than to work inside the 'robust' Progress editor.
Regarding SCCS branch revision numbering, I don't expect you to have much luck. If you checkout 1.3, and it is the end of the chain, you will end up with 1.4. If it is not, you will end up with 1.3.1.1. If you then check that out, you will end up with 1.3.1.2. Seems logical to me.
Now looking at what you are trying to do with the branch code, I should mention that the stsrev record contains the "revision status" field, which is totally user definable and modifiable within the user interface. Our intent is to allow you to mark certain revisions as "experimental", "tested" etc. You could later use it for FOR EACH selections and/or reporting. I think it would serve your purposes.
Regarding making changes to SCCS master files outside of SMGR, there is a program called "resetrev.p" which is not on the menu. It reloads SMGR data for a single program and is intended for a catastrophy where in the two are out of sync.
Regarding working in VI, yup, we do that too. We just keep another window running for SMGR.
Regarding custom code versions, SMGR has bunches of code in the appcomp.p compiler which understand that a single file name can existing in a base category AND one or more CUSTOM categories. It also knows how to recompile multiple incantations of .p files if they use include files which have custom versions using multiple PROPATHS and storing results in multiple .r code directories. We take the strategy that once you split off custom changes it will continue to diverge and you might as well handle it as a different file.
No, we really hadn't had much call for an "rm -r *" for SMGR.
However, you could do something like this:
for each stsadm:
for each stsrev of stsadm:
delete stsrev.
end.
unix silent value("rm $SMGRHOME/data/" + stsadm.cat + "/s." + stsadm.file).
delete stsadm.
end.
Well, I suppose. You realize that it searches anywhere in the name, description or category?
I am unclear on what you mean. The inuse display lets you tag checked out sources and issues and do a mass checkin. You can change the trigger procedure on the checkin to automatically submit changes to the Production manager.
Uhhhh, we don't. Just let Sccs/SMGR do it. If you checkout 1.9, the new source is 1.10. Checkout an old rev like 1.7, you will create 1.7.1.1.
Now, you can check out the end revision and FORCE (or bump) the revision up to the next whole number, eg 2.01.
Our experience has been that using SMGR comes pretty easy. Thus far no installation has needed training.
Setting up the Production Manager, if you choose to do that, does involve making some policy decisions, and usually requires some discussions which we are happy to help with.
Uhhh, works ok on our demo system, so I must assume it is a fluke, uhh, sunspots, and will have to think about why that might be happen.
There is a chunk of code in the trigger procedure trafchki.i which you can uncomment to do this exact thing.
Perhaps there is some confusion there. If you are saying you checked a file out and listed an issue number on the checkout dialog, be aware that that issue field is a non-required info only field, which serves only to alert someone as to WHY you checked something out. The only way Fixed By records are created are:
The full system has source code for all the reports. Most of the things people want to modify are in the trigger procedures. Obviously, we vastly prefer to either:
I suppose that it might be possible to bludgeon us into providing source if the above options don't meet your needs.
Ah, you mean like "let's submit all the files which address this issue, which is hundreds of programs".
Here is a sample program which submits all files in SMGR:
/* Suball.p - submits all SMGR files to project */
{smgrglob.i} {strevvar.i}
def var shell-cmd as char format "x(50)".
def var sub-reply as char init "y" no-undo.
for each stsproj no-lock: display stsproj with 6 down. end.
update sdestination. hide all.
pause 0 before-hide.
for each stscat no-lock with 10 down frame boink:
for each stsadm of stscat no-lock with frame boink:
scat = stsadm.cat.
sfile = stsadm.file.
find last stsrev where stsrev.cat = stsadm.cat
and stsrev.file = sfile no-lock.
srev = stsrev.rev.
if type <> "INCLUDE" then next.
display scat sfile srev.
{stsubex.i}
down.
end.
end.
You could readily adapt that scheme to submit all programs, or all include files, or all programs which have a fixed-by record for issue XXX, or whatever you might like. This example is going to dig up the last revision for each. There is also a version status field, which is totally user modifiable. You could use that to pick a version to submit.
There is no function in SMGR to submit all files to a category. What I supplied you was some sample code which invokes SMGR modules to accomplish that.
It probably means that until you invoke the SMGR menu program those variables have not yet been created. Once you invoke it during a progress session those variables are GLOBAL SHARED and should stick around for the session.
See my previous email, and fax on this. Yes, the default string is in $SMGRHOME/adm/srchdr. You can change it. Yes bull03 shows how to modify all your sources. NO, we don't think it is a good idea to make the revision string a comment; you lose ability to track revisions in .r code. We have used the form statement in all our Progress include files with no problems.
However, some software has a few teeny tiny include files which aren't even a complete Progress statement. One client had this as an include file: "XXXXXXXX"
Needless to say, no revision string which include Progress keywords will work here. Only a comment will suffice.
I have seen a few include files so small that not even a comment could be added to them. Of course, they aren't worth tracking changes to either. SCCS will not manage a file it can't put a revision string in.
I suggest that you just deal with the teeny files like dl-acct.i by checking them out, modifying the revision string, and checking them in.
I am unclear on what you mean. The inuse display lets you tag checked out sources and issues and do a mass checkin. You can change the trigger procedure on the checkin to automatically submit changes to the Production manager.
Uhhhh, we don't. Just let Sccs/SMGR do it. If you checkout 1.9, the new source is 1.10. Checkout an old rev like 1.7, you will create 1.7.1.1.
Now, you can check out the end revision and FORCE (or bump) the revision up to the next whole number, eg 2.01.
Do you mean as in the case of browsing issue 102, which (sadly, to my great regret) has bogus demo information regarding files, which do not, in fact exist on the demo database? Try looking at Issue 2001 instead.
The only other place I remember where you can submit is from the Versions window, which only shows existing versions.
Perhaps there is some confusion there. If you are saying you checked a file out and listed an issue number on the checkout dialog, be aware that that issue field is a non-required info only field, which serves only to alert someone as to WHY you checked something out. The only way Fixed By records are created are:
If you don't tag an issue, it doesn't get modified. If you don't tag a checked out source, it doesn't get checked in.
The sequence of events is:
All SMGR files have a file type:
Type Actions ------ ------- SOURCE: Compile it. INCLUDE: Look at the Xref to see where used, and compile them. SCRIPT: Do a chmod to Make it executable. TEXT: Just put the dang file where it belongs. SCHEMA: Similar to text; during checkin, it will dump for you. DB CONTENTS: Similar to text; during checkin, it will dump for you.
This indicates that the checkin code did not see the result it was expecting from either SCCS or RCS. Possible causes:
type delta It should come back with something like: delta is /usr/bin/delta
$SMGRHOME/data/fum/p.foo.p
If not, then the file really isn't checked out. Run resetrevs.p on that file to clear this condition and get make SMGR reload version data from the SCCS file.
In order to investigate this, you can try this procedure:
This should show the exact SCCS command being issued, and its output. In the case of any doubt, you can cut this command out and paste/retype it on the command line yourself, to see what SCCS is returning.
If all this fails to shed any light, then we will see how to get a look at your installation to troubleshoot farther.