Tag Info

Hot answers tagged

45

I am a programmer in real life, so using a version control software was a no-brainer for me. I write stuff in plain text, with each chapters in a separate text file. I use Subversion on them, with TortoiseSVN on Windows, and also use a Dropbox for backing up my repository. This way I have my changes versioned, I can comment the changes I commit, and if ...


25

You should really just grab and try any version control software presented on the market. This soft is not really more than controlling text files, and text files is what we do. I use Mercurial and I am very happy about it. It's easy to use for writing alone, as Mercurial tracks all your changes through local repository, and easy to use when collaborating, ...


20

If you are one of those rare people who can write, straight through, without any major refactorings or changes of direction along the way, more power to you. But for many people, and IMO any long-running project, source control is a major benefit. Here are some of the reasons: When you realize the path you're going down is a bad idea, you can roll back ...


13

I use git. There are a number of popular GUIs for it, though I tend to prefer the command line. My backup service of preference is Rsync.net because they are reliable, fairly priced, support (and encourage) you to encrypt your stuff and not give them the keys, and really care about their users' privacy.


10

You still need backups. Version control and backups are orthogonal concepts and should be used together, one is not a replacement for another. Yes, version control will persist the change history in the repository, but the repository itself is not protected just as any computer file is not protected. If the drive where the repository is stored dies the ...


9

For internal documentation I've found wikis to be quite useful. A wiki has several useful features for this task: built-in change-tracking doc can be structured as several pages (e.g. one per major section) for easier management; individual pages can then be edited without any need to merge changes into a master document some (most?) wiki platforms detect ...


9

There are two concepts in git that can help: branches and tags. Tags. Think of a tag as a name for a specific revision. Any time you want to remember a version, create a tag for it. For example, when you finish a draft, you can tag it like this: git tag first_draft When to use tags. Tags are good for marking any version that you might want to remember ...


8

There are a large number of version control systems out there, but I think that Git might be the best choice for you for a number of reasons. The biggest reason is that everything is in a single folder, you don't have to check things out to work on them or rebuild anything. You can just keep a full live copy on a pendrive and it just works. You also don't ...


8

I use Google Docs revision history. True version control systems like SVN and GIT are too complex, requiring knowledge of the command line, and are really designed for collaborative teams, working on dozens of different files, all at the same time. They're overkill for writers. I use Microsoft Word for writing, and every time I save Google Cloud Connect ...


7

The first scenario is check pointing to safe guard against those moments (and I've had them) where you come to realize a section of the document is missing. This happened when accidentally, without me noticing, as well as when one of my kids happened to hit the keyboard and I had a section of text selected. The other use though is before I'm going to rework ...


5

Flashbake is a command line interface for a git repository that had some potential but I think it never really took off. It works in the background and is designed to record ambient data as well like the weather at your physical location and the music playing on your computer at the time you are writing. It is the brainchild of Cory Doctorow and was ...


4

Personally I'm not interested in this particular feature, but I know people that are. It's obvious why writers haven't used version control systems: until recently, they were all terrible. Svn? CVS? God help you. Mercurial isn't so bad, but it is designed around programming, and it's still pretty arcane for your average user. I think Versions might bring ...


4

Yes, you still need backups. However, the form that backup can take can vary. Version Control might include it If you are using git, then every time you "push" to an off-site repository, you have created a backup of your project in its entirety - including a catalog of your changes. This may be sufficient for your needs. In this case, you have two copies ...


3

There is no advantage. Most people in this forum are from a technical background, so they automatically look for technical solutions. You don't write a book how you write code. When writing code, you dig in, change a line here, add a function there. This can break the whole system, which is why you have version control and testing and continuous ...


3

I've been playing around with Scrivener (for Windows) for a few days now because of * ahem * Lauren Ipsum's almost evangelical zeal regarding the product ; I must admit I'm quite impressed with it so far, and am seriously considering using it permanently. Scrivener 2 does have a form of version control in the form of "Snapshots". I haven't used it as yet, ...


3

I use Celtx as my main writing tool and have subscribes to their Celtx Studio which gives version control. It's not exactly great because you have to be connected to the internet all the time (there is no "Work locally and sync when you have internet again") and it's slow if you add tons of graphics/media to the file (because everytime you save the entire ...


2

Fossil because it's light weight and easy to backup by just copying the database file to a new location.


2

Celtx offered version control several years ago. I got excited about that, and then I never used it. Version control systems are popular in software because rolling back in time is not uncommon (and, at worst, frequent). Writing, though, usually pushes forward. You almost never roll back to an early version of a file. Draft, perhaps.


2

The principal reason would be to easily collaborate on a document with multiple authors and avoid overwriting each others copy. It would also help you open up your book to public contributions, corrections and suggestions if you used a social platform such as github.


2

I can think of one reason: If you have a co-writer, it gives you the confidence to revert to a previous form if you don't like their writing. Or combine conflicts if both of you are writing the same section. This is the original purpose of version control in programming. As I've said in a comment, very often it's best to rewrite back to a previous draft ...


1

In the past, I've used a wiki for this type of work. However, a tool doesn't organize itself. The best wiki sites are heavily edited from every level from copy to development.


1

I write when I can. (Full-time job, family, house, church, etc. takes up most of my time.) Currently working on a book series with a complicated plot, so I often don't write linearly. (Heck, the plot's not even linear!) Once or twice per week I save under a new version number. It's been invaluable, because I've often cut a section (to paste elsewhere), ...


1

As a coder and blogger ( http://create-build-execute.com ) I am using Git for version control. Actually my whole blog is run on it and I can recommend it a lot. As you are on Mac and do handle text files mostly, I'd recommend using the great github mac UI ( http://mac.github.com ) it makes it really easy to use and you don't even need any github account - ...


1

A version control repository IS a backup. But you really should back up the respository. As always, back ups should be to a different device than the main file: a hard drive on another computer, CD, thumb drive, whatever. A backup on the same disk drive is worth something, but the most likely reason to need a backup is because the hard drive failed. For ...


1

While another answer is correct in saying that version control and backing up are orthogonal concepts, your local repository can have a remote repository synched with it to effectively provide a backup of your local history in the cloud. If you don't already have a remote repository, you can set one up on http://github.com or http://bitbucket.org. In this ...


1

I've been using Celtx for writing screenplays, since it takes care of all of those messy formatting details. And it's free. I had to manually incorporate version control in my writing process, since it doesn't appear that Celtx is capable of version control at this time. I use mercurial for version control. Every time I commit changes to the repository, ...


1

I put some of my writing work in a git repository, but because my colleagues use msword, that's not terribly helpful. I solved that pub putting a directory called plaintext in the repository root, and use a pre-commit script to dump a plain text version of the file into the plaintext directory, so that I get good diffs. It's not perfect, but for the most ...


1

I'm not the only one—cool! I've thought about buying a developer membership to get access to the public beta of Lion just for this feature alone. I figure that if Tower (a popular Git client) is $60, it's worth paying another $40 to get so much more.


1

Try Scrivener for this. You're able to make "snapshots" of a piece of work before you make any drastic changes. As well, Scrivener makes backups for you and auto saves while you are writing. Not having to use multiple programs for version control is nice.


1

If I'm writing something in a plaintext format, like LaTeX or HTML, I'll generally use version control. For example, when I wrote my undergraduate thesis (in LaTeX) I used Mercurial. For stuff written in a word processor, I generally don't. I do keep backups (using Apple's Time Machine software) so I can jump back in time to any day. And if I start another ...



Only top voted, non community-wiki answers of a minimum length are eligible