Change Management / Versions

WYSIWYG editors and information/projects with multiple text files (among others)

Due to "strange" and unexplained (at least for me) policies/changes  of this server, this page/site is out of date since Jun 2009. The new page/site with this content is

Change Control – Version Management System in some WYSIWYG editors


General Comments:

        (a) It seems that WYSIWYGs are, in fact, binary files for “general” change control systems (oriented to source code software projects), so in this case it is convenient to use the change control mechanisms included in  WYSIWYGs.

        (b) Comments related to 2000-2003 (1) are first and then, OpenOffice.Org 2.0 Writer (2).

        (c) Use: See - Header and footer in 2003, otherwise they will not be seen..

        (d) As it will be commented out, WYSIWYG editors do not handle versions directly, but on demand.


Use of what is available for change control - versions:

        (1) Tools - Change Control: a new bar associated to this task appears. In 2000, See - Tool Bar - Revision should be “activated”, and when you go to Tools - Change Control, other options appear, among them: “Control changes when modifying”. Well, once again you should say yes and choose the associated options.

        (2) Edit - Changes - Record.


How both (1) and (2) work?:

        (a) Draw a continuous line in the left margin, which encompasses the changed lines.

        (b) A comment can be associated to each change, in a “box” placed in the right margin.

                  (1) This box distorts the margin view because it makes it look bigger, but in fact it does not change it (though the editor is WYSIWYG).

        (c) The changed text appears in another color and underlined.

                  (1) The font’s color is changed when the user who makes the modifications to the text changes.

        (d) When something other than the text is changed, a box with a comment is placed in the right margin:

                  (1) Comments are also added when page format changes are made.

        (e) When the mouse is placed on something changed, it shows the date, hour and user who made the change.

        (f) No change is made effective unless it is explicitly accepted.

        (g) Changes are accepted one by one. Only accepted changes become text without underlining or any mark.

                  (1) The revision bar or the mouse right bottom can be used to see, accept or leave changes as they are, i.e. as changes not yet accepted.

        (h) It is common that in these editors, and in general, versions can always be stored. This would be as leaving a copy of the current state. The difference of making it “manually” with “save as” is that all is kept within the same file. In addition, each version can have its own comment of the version, beyond the comments particular to each of the content changes. Versions (and, in fact, all what is related to change control) still remain, as expected, in the file’s “save as”. In any of the cases, it seems necessary to limit the generation of versions so that the (only) file does not increase its size too much (even though it can also be expected that it manages “differences” or “incremental changes” for this).

                  (1) File - Versions: it shows all the versions that have been stored as such with their corresponding comments and options to open them, delete them, etc.



        If the usual task is editing without change control, and what is related to change control is incorporated, it is possible that a detail excess in the recorded changes may be evident. In fact, the “intermediate changes” to get to a given text are not important, and those intermediate changes may be confusing when they are reviewed by someone who has not direct contact with the user who made them. This may happen when having a draft text and starting to make control changes or when a user changes a text in two different places or machines, who are interpreted as different users (changes are shown in different colors and are “different changes”, i.e. to be accepted/rejected separately even though they are part of the same paragraph). All this is useful evidence to affirm that, in some time, it may be necessary to deactivate change control or directly accept changes without any review on the part of anyone else. 

This should go on... This should go on... This should go on... This should go on... This should go on...


Change Control – Version Management System in software projects (or .tex, isn’t it?)


Error Report /comments: ftinetti @ gmail . com (delete whitespaces), with subject "ctrlofchg"