Making .scriv bundles more friendly for SVN/CVS

Hello

although there is an option for enabling SVN/CVS-compatible saving the bundle still is not really handy for using SVN/CVS. My personal Issue is the pattern of names for text inside a Scrivener project. At the moment there is a number pattern, e.g. 42.rtf .

I know, the numbers come in handy for project handling. But, is there a possibility for creating a pattern which is more human readable and related to its actual content? It could help to keep track using a SVN/CVS-tool.

Thank you very much
JamesWalter

P.S.: what does the SVN/CVS-compatible saving option actually do?

All the SVN/CVS-compatible saving does is make it so that the binder.scrivproj file gets saved as a plain text property list instead of a binary file.

I’m afraid that there is no way to change things so that the internal files have human-readable names, no. They are really only intended for internal use by the app - the use of Subversion/CVS isn’t fully supported; the modifications that are there are just very basic at the behest of a couple of users. The numbering system tallies with an internal ID system which allows the program to have different files with the same file name and to keep track of documents much more efficiently than relying on file names, so it’s unlikely to change, I’m afraid.

All the best,
Keith

The two main reasons for using internal serialised document names is A) duplication and B) file-system compatibility. Consider the following Binder example from someone using the number generator to create chapter titles:

Part <$R> Chapter <$n> Chapter <$n> Chapter <$n> Part <$R> Chapter <$n> Chapter <$n> ...

You get the idea, and any sort of “human readable” version of that is just going to run right back into serialisation work-arounds. The other issue is file-system compatibility. Currently you can dump a hundred words into the title field with a variety of punctuation and Unicode characters. Sure, there is truncation and punctuation cleaning to HFS+ spec, but a lot of people store their projects on a variety mediums. Imagine the mess that would be created when someone puts a project file onto their FAT-16 formatted USB thumb drive. Programs that use human-readable data storage methods often resort to forcing the user to comply with limitations within the software itself. Nothing is more frustrating to me when I cannot use something like the ‘:’ character in a database or similar program because it is storing stuff in files per internal software titling.

In answer to your final question: by default Scrivener uses binary optimised XML data storage files internally to increase application write-out performance. Turning on compatibility drops everything back to plain-text XML methods. This can be useful for other purposes as well, for the advanced who like to pick things apart, or 100% emergency recovery (snapshots are binary unless this is turned on, for example).

Hope it’s alright to bring this thread back from the dead. :slight_smile: So I was just reading about the changes to the Scrivener 2.0 file format, and I was wondering – is it a design goal to make Scrivener 2.0 files fully compatible with version control systems? I’ve never quite been able to get this to work quite right with Scrivener 1.5, and I would love to have it working.

If this feature is not on the roadmap, then what sort of bribe do I have to offer to make it happen? Unfortunately, I can’t say, “I’ll definitely upgrade to Scrivener 2.0!” because, well, that’s already a given. Perhaps a fine selection of alcoholic beverages of your choice, shipped all the way from the Great State of California? I’m also willing to entertain counteroffers involving cheeses or other food products.

Hint: Offer American bread.

Certainly beers or Californian wines are always a good bet. :slight_smile:

But no, I’m afraid there’s no goal of making Scrivener 2.0 projects more SVN-compatible. The RTFD files are gone, to be replaced by RTF, but other issues will persist. The goals for Scrivener 2.0’s format are to make it safe, fast, and to add more structure in case the format can ever be opened on other platforms.

I don’t use Subversion so don’t fully understand the problems involved, but I believe they are mainly to do with how Scrivener removes and adds files - is that correct? The thing is that Scrivener needs to be free to manipulate the data inside its packages.

Still, if you describe the exact problems you are having, at least I can bear them in mind, with a view to attaining those alcoholic beverages in the future…

Thanks and all the best,
Keith

If you can put a .hg or .bzr or .svn folder inside your project you can use the scrivener project as a versioned folder.

But does anyone of you really uses a (D)CVS for writing? The problem with scrivener is the file format rtf, which is not very cvs-friendly, in fact the only cvs-friendly formats are plain text formats with a linewidth of 80 chars or so. If a line spans over the whole paragraph you’ll never see what you changed in this paragraph when you diff your file.

I only once used svn when I wrote a book together with an other author in LaTeX/Emacs/Vim where you can customize your project to meet the needs of version control. But we never really had to roll back a file, because it broke “our code”. :wink:

For me the only use case for a vcs is to have a history of your text which can be studied by literature students when you are a dead nobel prize winner. :wink:

Hi Keith,

Yup, that’s right. The main issue with Scrivener and version control is that it’s easy to break things through some combination of adding & deleting sections, and then trying to propagate those changes to checkouts on other machines. The version control system (or some script) needs to be smart enough to know how to handle adds/deletes underneath filename.scriv.

Maybe – and I know this is a crazy thought, I’m just thinking out loud here – but what if activating “SVN compatibility mode” did something different than what it does today? What if flipping this switch converted your document to one giant text file – a single XML file, a single MultiMarkdown file, etc. A number of features would be greyed out or disabled, but the author could still write, rearrange sections, and publish. (I understand MMD plays pretty nicely with Scrivener, but that it’s not really “native” yet, you can’t roundtrip it.)

There are plenty of text-based formats out there for writing, but as far as a novelist is concerned, the editing & publishing toolset around each one is just vastly inferior to Scrivener. I think my dream writing tool is Scrivener wrapped around one of these open formats (or one of these open formats + Scrivener-specific extensions).

Hi juh,

Currently I don’t use version control for writing with Scrivener. I’ve experimented with LaTeX with TexShop and sffms, which is very version control friendly, but the problem is that Scrivener’s UI is just too darned useful to give up. :slight_smile: When I write, I start by producing a big unorganized bag of words. Without Scrivener’s organization features, I’d never be able to pull it all into a sensible manuscript with actual chapters and sections.

I get what you’re saying – a lot of version control features are really targeted towards SW engineers. But still, there’s plenty for novelists to like: the project is backed up remotely, you can work on it from multiple machines very easily, you never have to think twice about deleting material from the text. Even viewing diffs is a nice feature, if your format is some kind of plaintext. As for the literature students of the 22nd century – I hadn’t been thinking about them, but yes, I guess there’s that too. :wink:

I would have used a simple text format - such as XML - from the outset were it possible. But doing so would disable one of the core features of Scrivener - the ability to import research files such as movies, PDF files, images and web archives. You would not want a 500MB .scriv file loaded into memory from the outset. The joy of the bundle format is that it means Scrivener doesn’t have to load files into memory unless it needs them.

All the best,
Keith