The Devil's Advocate's Versioning Quandary

[cruxdestruct]

@richardgrant

• Finally, on a strictly practical level, it presents a real-world problem: whenever you export text from one app to another, you create two separate documents. They may (assuming the export/import process works perfectly, which is not always the case) be separate-but-equal for a couple of minutes, or a few hours, or however long this happy state lasts. But sooner or later, any real writer looking at any real piece of writing is going to start tweaking things – a word here, a comma there – and now you’ve got two separate and unequal documents: one in the “production” app that is actually being used to put the document in final form, and another in the “playing with text” app that was used, up to a certain point, in the writing process. Do I need to list reasons this is not a good thing? And there’s no easy fix for it. There’s no non-laborious way to pluck a revised document out of, say, Nisus Writer Express, split it back into the separate pieces it comprised in Scrivener, and re-import them. Naturally you can re-import the whole document, but what’s the point? It’s in NWE now, which is a smart app capable of printing and saving in a variety of formats – you might as well just leave it there and keep things simple.

It’s worth noting, in this context, that the writing process is seldom finished when the document reaches the stage of being ready to format and send out. Most often, you need to go back to work on it, either at the direction of an editor, or because you’ve had new ideas yourself, or you need to cut X words, or whatever. So here we are facing the two-app problem again. Are we going to bounce back and forth? If we’re just going to stay in the “production” app right through the later, tougher editorial stages of the process, then this rather relegates Scrivener to the “not ready for prime time” category, to my way of thinking.

@cruxdestruct

Well, the guy had a small idea what he was talking about. I think the whole publish-then-edit problem IS real. It’s not in the slightest confined to Scrivener, though, nor is it really Scrivener’s responsibility to fix it; but the notion does resonate with me: You write a document, then export it, or print it, or publish it—then you make a change in some later iteration of the document and need to go back and synchronise the change in whatever you were working on.

Honestly, this can take the form of writing in scrivener, then making an edit in the published RTF just as easily as it can take the form of writing in word, then printing, then crossing out a word or inserting a sentence. It seems to me that they’re the same problem, and it seems to me that in both instances the only way to responsibly avoid descent into version hell is to go back to the original working doc (scrivener or word, respectively), make the change THERE, then re-export.

Still, it’s something I find interesting, and I’d be interested to hear your fellows’ thoughts.

@janra

I can’t say I’ve ever had this problem, actually - but then I’ve always done my editing in exactly the print/scribble method you describe, so I’m quite accustomed to have a source document that must get the changes, and which generates the subsequent versions.

It wasn’t much of a reach for me to have a source electronic version and a differently-formatted display electronic version, and once I started using LaTeX some time ago, this behaviour was reinforced. Regenerating the html/pdf/print/whatever versions from a single source that gets all the actual changes is natural to me now

Topic split, at Keith’s request. What thoughts have you?

[Dunx]

There’s a similar problem in software development.

One of the most powerful ways of understanding a complex system during the early stages of development is to draw diagrams to describe it. They make it easier to comprehend a system in its entirety. These diagrams are useful at other stages too, like testing.

There are a number of techniques that take diagrams and generate code. The problem is the same now as it was fifteen years ago when I first encountered these techniques: the diagrams get out of sync with the code that’s generated, which makes them less valuable for understanding the system because they are wrong.

The problem has not been definitively solved. I’ve worked on a few products over the years that have tried to address the whole business of keeping diagrams up to date with the code, and updating the code to match the changes made to the diagram, and there are always corner cases where something will break - usually disastrously.

At least in writing the best solution is at least practical: use the technique which janra describes of always making changes in the source document and regenerating the result when needed.

… but there are always changes which need to be made in the result. If there are a lot of them and they need to be done manually, then that is going to cause problems. Chapter numbers are my bete noir, and I need to look at MMD more closely for exactly that reason.

[Rayz]

If Keith finds a bug in Scrivener. Let’s assume it’s nothing serious; he’s spelt ‘NO’ incorrectly on the feature request dialog box for example. Now he has two choices in how he goes about fixing it.

1/. He can take the tedious option of finding the error in his source code, fixing it then recompiling it into a binary file.

2/. He can open the binary up in a hex editor, search for the offending spelling mistake and and then change it. No need to recompile.

Now which is the better option? Here’s a hint; I’ve seen programmers fired for going with the number 2 approach.

The Scrivener project is the ‘source code’ for the book; which it uses to generate the output. Dunno about anyone else, but I wouldn’t have the finished book and the Scrivener project fall out of step, for much the same reason that I don’t hack binary files to fix software bugs.

That’s the geeky perspective anyway.

[werebear]

That can, Jekyll & Hyde-like, be either a Typesetting Machine (this is how I think of Word) or a Writing Machine (which is Scrivener.)

Is there a way Word files, with page breaks (the easiest and most likely way to break sections) can strip out all formatting… except that?

Not likely.