"Plain text" vs. "Oberon DoCument" for sources

[ReneK]

I think that we face an ackward decision here. Text only as a source code format would be extremely awkward and a step backwards, yet for comparison of changes, color is clearly not a good idea. I think that all uploads to the repository need to go through a beautifier step first, so that only BB center standard format is used. Is there a versioning and comparison tool that handles rtf and where we could add preupload and predownload steps, like conversion to and from rtf and beautifier? I think this would solve all issues.

Gesendet von meinem LIFETAB_E7316 mit Tapatalk

[ReneK]

Probably a new converter in BBF would do the trick.

We should discern between changes in source code and changes in documentation files. Let's talk about source code first.

When converting to "sourceversioning", the program source code would be converted to text, while pictures hyperlinks would be converted to StdEncoded text stretches. Then, the output could be uploaded to a text only versioning tool. This way, pure changes in format would not be seen as changes in source code.

After downloading such a module, the de-converions would not only convert to odc and decode the pictures and hyperlinks, but also apply the CPCBeautifier.

This way, we would have the benfits of source code version comparison, add a unified look and feel to all BBF center modules, while still retaining the ability for users to either use beautify (in any way they like) or adding their own formatting ideas in their own subsystems. The "price" would be, IMHO, to write a few lines of simple code and to integrate CPCBeautifier as part of the initial framework.

For an initial upload or download,we would also need a bulk concert/deconvert.

When talking about documentation files and help files, we also want versioning and comparison, I guess, but in that case, we do need the text formatting as part of the versions. Thus, our repository needs to be able to do rtf or html. The conversion/deconversion in that case would be to rtf/html, and that's already supported in BBF.

Of course, this does not address the question of using non-BBF text-only sources in Compile lists. I think it would be quite easy to do a command that checks, if the file has a .txt ending, in which case it would automatically open it with the txt-Converter before executing the compiler.

[Ivan Denisov]

http://community.blackboxframework.org/ ... ?f=30&t=63

[Josef Templ]

We should not forget that the issue of binary versus ascii files also
appears with documentation files and form resources.
Converting the modules to ascii does not solve all problems.
Leave it as it is and use an appropriate diff viewer for a local git repository copy
or use the tuned redmine synchronized with a git repository to look at differences
on an ascii projection of text files.

I use the first approach (local repository with BB as a diff viewer)
for many years for subversion and it works the same way for git.
This is not an issue.

- Josef

[Ivan Denisov]

We should not forget that the issue of binary versus ascii files also
appears with documentation files and form resources.
Converting the modules to ascii does not solve all problems.
Leave it as it is and use an appropriate diff viewer for a local git repository copy
or use the tuned redmine synchronized with a git repository to look at differences
on an ascii projection of text files.

I use the first approach (local repository with BB as a diff viewer)
for many years for subversion and it works the same way for git.
This is not an issue.

Josef, I have the same point of view. However that is good, that such highlighting tool exists now, because developers will have a choice. It will be great if the the Center produce some common and well discussed opinion about plain text for sources (not forms and documentation). We can fix this opinion with a vote.