Hi again Andre, I wondered if you could put a note reminding people that they might want to consider how the diff of two related versions might look in source form and in any picture.
It would be good if the parsers were written so that removal of some logical entity of the diagram is mirrored as some removal of a textual block of source code that shows up well in a diff.
If you try and put binary pictures in a revision control system then although successive versions of the picture may show clear visual changes (an apple is placed on a chair for example), there is no easy way to list the difference within the revision control system except by adding a comment.
If you are creating pictures from a textual description and only storing the textual description, then the text could be formatted in such a way so that a textual diff (with context), of the sources would give enough information for you to ideally visualize the what the difference in the generated pictures would be
So in some turtle-like graphic the example of the apple might show the following diff results between two versions:
moveto(chair.coords); draw_apple()
It is always going to depend on how the source is written, but I hope you get the general idea.
Paddy, I understand what you mean. I strongly suspect that it would be always clear from the context what changed from one version to the next in a diff. Just like there's no need to tell people to format their (Python) code in a certain way so as to be able to easily grasp what changed when viewing a diff, I don't believe there is a need here either. The intention is that the docpicture "code" will be simple, easily understood, so that changes would also be easily understood from diffs.
4 comments:
Hi again Andre,
I wondered if you could put a note reminding people that they might want to consider how the diff of two related versions might look in source form and in any picture.
It would be good if the parsers were written so that removal of some logical entity of the diagram is mirrored as some removal of a textual block of source code that shows up well in a diff.
- Paddy.
@paddy: I'm sorry, I don't understand what you mean by your comment.
If you try and put binary pictures in a revision control system then although successive versions of the picture may show clear visual changes (an apple is placed on a chair for example), there is no easy way to list the difference within the revision control system except by adding a comment.
If you are creating pictures from a textual description and only storing the textual description, then the text could be formatted in such a way so that a textual diff (with context), of the sources would give enough information for you to ideally visualize the what the difference in the generated pictures would be
So in some turtle-like graphic the example of the apple might show the following diff results between two versions:
moveto(chair.coords); draw_apple()
It is always going to depend on how the source is written, but I hope you get the general idea.
Paddy, I understand what you mean. I strongly suspect that it would be always clear from the context what changed from one version to the next in a diff. Just like there's no need to tell people to format their (Python) code in a certain way so as to be able to easily grasp what changed when viewing a diff, I don't believe there is a need here either. The intention is that the docpicture "code" will be simple, easily understood, so that changes would also be easily understood from diffs.
Post a Comment