| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1133.1 | CMS merge outpute | FAILTE::LAAHS | An accumulation of Celts | Tue Jul 28 1992 11:23 | 17 |
| Trevor,
Looking at OA$BUILD:CM.A1$MSG it would appear that the symbol should
be _MER_ and NOT _MERGE_ OR _MRG_. Looks like a bugette.
As to the actual contents of the element when it has a merge conflict.
The contents are the direct output of the CMS MERGE operation so it
must be putting in the reverse video stuff. I *assume* you are trying
to merge a form? If so, it is the FLG that is actually merged. Can you
confirm that it is an FLG you end up with?
You should have a file in the development area
OA$SITE_DEV_<area>:<name>.FLG_MERGE which
contains the merged conflict. If you edit it directly does it still
have the reverse video etc?
Kevin
|
| 1133.2 | It's a bug | MAULS::REDMOND | Thoughts of an Idle Mind | Tue Jul 28 1992 11:24 | 9 |
| Yes, it looks like a bug. CM$_E_MRG_CON seems to be the correct symbol to
use. Easy to fix - insert the symbol into the SITE$CM literal symbol file and
away you go. Make sure that this bug is reported though, just to get it onto
the bug list.
What editor are you using when attempting to resolve merge conflicts? Where
are the elements to be merged coming from?
Tony
|
| 1133.3 | | COMICS::TALBOT | Trevor Talbot | Tue Jul 28 1992 17:10 | 20 |
| Thanks for the quick responses,
Re: .1
Kevin,
Yes, you assumed correctly the elements being merged are
type of FRM. Yes again, there was an output file breakdown.flg_merged
created in the oa$site_dev_area directory. No, if edited directly using
the EDT editor, no reverse video guff but still lots of unwanted chars.
Re: .2
Tony,
Initialy WPS-PLUS was my default editor, hence the reverse
stuff etc, I switched to EDT and the same results as if edited
directly. The elements are coming from some application areas that I
set up for testing, the elements are both .FRM, both named the same the
only diffs are some screen text added to force a conflict and again
some named data designed also to conflict.
|
| 1133.4 | Here's the breakdown.flg_merge file | COMICS::TALBOT | Trevor Talbot | Tue Jul 28 1992 17:15 | 1 |
|
|
| 1133.5 | 2nd try at getting file in!! | COMICS::TALBOT | Trevor Talbot | Tue Jul 28 1992 17:19 | 91 |
| Here is the file:
**************** Conflict 1 ************************************************
! FMS Form Description Application Aid
! Version V2.4
FORM NAME='BREAKDOWN'
AREA_TO_CLEAR=1:23
WIDTH=80
BACKGROUND=CURRENT
;
TEXT (1,1) 'breakdown'
;
TEXT (2,1) 'Created in ALL-IN-1 V3.0'
;
TEXT (3,1) 'TEST2'
;
TEXT (5,17) 'Invoice_no:'
;
TEXT (7,17) 'other:'
;
ATTRIBUTE_DEFAULTS FIELD
CLEAR_CHARACTER=' '
NOAUTOTAB BLANK_FILL NOBLINKING NOBOLD NOREVERSE
NOUNDERLINE NODISPLAY_ONLY ECHO NOFIXED_DECIMAL
LEFT_JUSTIFIED NOSUPERVISOR_ONLY NOSUPPRESS NOUPPERCASE
;
FIELD NAME='INVOICE_NO' (5,28)
PICTURE=6'X'
;
FIELD NAME='OTHER' (7,23)
PICTURE=30'X'
;
ORDER BEGIN_WITH = 1
NAME='INVOICE_NO'
NAME='OTHER'
;
NAMED_DATA INDEX=1 NAME='.TYPE'
DATA='ENTRY /MODE=update/HARD=''GGGG''' ;
NAMED_DATA INDEX=2 NAME='.FILE'
DATA='breakdown,TEST2.FDL' ;
NAMED_DATA INDEX=3 NAME='INVOICE_NO'
DATA='/rse_valid = inv_ent.invoice_no with .cost_code = "YYYYYY"' ;
NAMED_DATA INDEX=4 NAME='.COMMENT'
DATA='This was added to show up some diffs between CMS copy and CM copy.' ;
END_OF_FORM NAME='BREAKDOWN' ;
********************************************************************************
6
FMSFRMFED20028-JUL-1992 09:47:0328-JUL-1992 09:47:03�
6 6 �
&
20$ P4 BREAKDOWN
INVOICE_NO
OTHER
*
,
.TYPE ENTRY /MODE=update/HARD='GGGG'
"
.FILEbreakdown,TEST2.FDL
N
INVOICE_NO:/rse_valid = inv_ent.invoice_no with .cost_code = "YYYYYY"
T
.COMMENTBThis was added to show up some diffs between CMS copy and CM copy.
breakdown
Created in ALL-IN-1 V3.0
TEST2
Invoice_no:
other:
************** End of Conflict 1 *******************************************
|
| 1133.6 | DIfference between .FRMs included in .FLG | 47215::EIJS | All in 1 Piece | Wed Jul 29 1992 12:29 | 37 |
|
Hi Trevor,
The result you see it the merge of 2 FRMs into the FLG. Let me explain.
The original file is the .FLG. You then select the 2 elements of which you
want the differences included into your .FLG. The difference should run on the
2 .FLGs. However (yes, you found another one), when CM gets copies of the 2
elements, instead of obtaining the .FLGs, it obtains the .FRMs. Differences
are run between the 2 FRMs (which might be different), but obviously the result
is always different from the contents of the .FLG. So the result is one big
conflict, and the funny characters are binary (FRM) characters.
Fix:
CM_PRE_MERGE_FRM.SCP
.
.LABEL NOT_SDC
.
GET #CM_GET_KEY = #CM_SEL_KEY\-
GET #CM_SRC_LOC = "DEV"\-
--> GET #CM_FORM_TYPE = "FLG"\-
GET OA$FUNCTION = CM$ETYPES:NUMBER.GET_SOURCE[CM$SITELOG.NUMBER[#CM_SEL_KEY]]
.
GET #CM_GET_KEY = #CM_SEL_KEY\-
GET #CM_SRC_LOC = "DEV"\-
--> GET #CM_FORM_TYPE = "FLG"\-
GET OA$FUNCTION =CM$ETYPES:NUMBER.GET_SOURCE[CM$SITELOG.NUMBER[#CM_SEL_KEY]]
The lines starting with '-->' are missing. (CM_GET_FRM.SCP actually nullifies
the symbol after procssing).
Sorry,
Simon
|
| 1133.7 | | PAULUS::BAUER | Richard - ISE L10N Center Frankfurt | Wed Jul 29 1992 12:33 | 35 |
| Hi Trevor !
Merging an FRM will not give satisfactory results. This has primarily to do
with the structure of the FLG file.
It is more appropriate to handle forms as screen and named data seperately.
I'm convinced that handling the screen part manually will be quicker in 99% of
the cases. Hence, displaying the old form, editing the new form and applying
the changes.
However, the named data could be merged automaticaly. But again the FLG format
isn't suitable. It list each line of named data with an INDEX number. Any
additional line causes that the following lines can't be matched (and therefore
can't be merged) by CMS because the INDE number is incremented.
There is a solution to it. Using the FDNDEDT1.EXE and FDNDEDT2.EXE one would be
able to get the named data in the style GOLD N shows it (there are propably
other ways in V3 too). Now this file can be merged with good results !!!!
In order to implement it the following script need to be modified
OA$LIB:CM_MERGE_CMS_FRM.SCP
- splitting the form into screen and named data part
- calling the FMS editor for the screen part only
- calling CMS with the named data portion only
- resolving conflicts
- combining the result again with the associated screen part
This is how we handle forms during the translation effort.
hope this helps
Richard
|