Feature Request: Track changes

[nigel]

In my lab we often write in a small workgroup. People rewrite a paragraph or edit a paragraph and pass it on. With Mellel we are all manually marking our changes with colors. I would like to see a track changes feature that would compare to documents and highlight the changes.

Other groups must write in this fashion as well. I think that it could be quite useful.

Thanks,
Nigel

[nvalvo]

I wonder (I haven't tried) how Mellel's XML file type would respond to use with a versioning system like Subversion or CVS.

Because that could be really great.

Edit: I just posted the following in the Undo buffer thread, because I think the two features should be envisioned together.

I would call it "File History," however. I am imagining the interface for it now. It would look like the bibliography pallette, except with two panes. One would be a listview of edits, scrollable. When each was selected, it would display the edit, and optionally, the name of the user had made it and the time it was made, color-coded with green for insertions, and red for deletions. Buttons (with key shortcuts) would allow navigation, approval and reinstatement of changes.

Another thought:

Would it be possible to have an additional XML file in the filetype package that would contain the (probably ballooning-ly large) file-change history? This way, the main XML file in the package would still reflect the current state of the file for the purposes of XSLT transformations.

[Stephen Still]

I wonder (I haven't tried) how Mellel's XML file type would respond to use with a versioning system like Subversion or CVS.

Should work just fine. Subversion can even do binary diffs.

I seriously doubt Mellel would be able to make much use of subversion for track changes though. For starters, svn isn't granular enough - it will only tell you if a line has changed, not what on the line. Given that most of a Mellel XML file is one line, that's a bit of a problem.

Having an additional file for change refs could work. One might envision a new element with a ref to a chunk of deleted text, e.g.

<deleted-text ref="GUID"/>

or

<changed-text oldtextref="GUID">New text goes here</changed-text>

It could get messy fast, however. I think it would be easier just to have two new elements, deleted and inserted:

Code: Select all

<p>
     <c>
           This text hasn't changed or been deleted.
           <deleted time="timeref">This used to be text</deleted>
           <inserted time="timeref" user="person">And this is now</inserted>
           This text hasn't changed or been deleted.
     </c>
</p>

I'm happy to leave this call up to the Redlers. I strongly suspect they know best how they want to work this into the file format.

[cyberbryce]

I seriously doubt Mellel would be able to make much use of subversion for track changes though. For starters, svn isn't granular enough - it will only tell you if a line has changed, not what on the line. Given that most of a Mellel XML file is one line, that's a bit of a problem.

In doing my own versioning with SVN, I have scripts insert line feeds into various types of XML files.

So, for the moment, as versioning is not supported by Mellel files internally, line feeds between tags could in principle be added to Mellel files, prior to commiting changes. Would this foul them up? If not, then this shouldn't be too much of a complication to add to a versioning script.

I'll have to try adding support for Mellel files to my system, at some point when there is time...

--Bryce

[Stephen Still]

So, for the moment, as versioning is not supported by Mellel files internally, line feeds between tags could in principle be added to Mellel files, prior to commiting changes. Would this foul them up? If not, then this shouldn't be too much of a complication to add to a versioning script.

I use W3C tidy (in TextMate, but it ships with OS X as a command line utility) to pretty-print Mellel XML files before analysing them - that may be a more robust option than a custom-rolled one.

The problem will still be that an entire character run i.e. up to an entire paragraph will be within the one element, and therefore one line. That's not very granular, or at least not nearly so much so as the change-tracking you get from competitors.

If you're feeling inspired, you could do a diff to get the elements which have changed, and then do further (custom) analysis to work out exactly what changed. Obviously that requires a certain amount of effort.

Don't get me wrong, I love svn. I just think that a usable change-tracking system requires document level support.

[nvalvo]

That was fascinating, guys.

I had, just like everyone else, only used subversion on web projects, etc. and not as a versioned backup repository for mellel docs. I always imagined the amount of granularity was customizable; it is interesting that it is not.

If we could get a versioning feature in Mellel, it would be amazing. If it were cross-compatible with Word, then I would no longer need a copy of Word on my machine!</pipedream>

[aechallu]

Thanks Stephen for the illuminating posts.

Know I wonder... if Mellel added a <CR> after each ". " (period-space) and kept the xml file "tidy," would SVN be able to be as granular as to the sentence level? I know that SVN and track changes is different, but I would be very happy with just having plain versioning instead of whole track change functionality. Even if it is granular at the paragraph level I would consider it a progress.