None of the IF engines that I use have built-in version control. (Or, if they do, I don’t know about it!)
To save my files and my sanity, I’m using an external version control system, Mercurial with TortoiseHg. It plays nicely with Inform 7, ChoiceScript, Twine, OpenOffice, and any other game dev system that natively lives on my computer.
I thought other people might find it helpful, so I wrote up a detailed explanation of how I use it here.
I’ve been using Git for a long time - do you think I should try Mercurial? Are there any particular advantages to it, or is it more of a preference thing? I’ve never used Subversion or another SVN type system, though - I understand Mercurial is built to be more familiar to people used to SVN?
Also: BitBucket is a really useful alternative to Github for people using Mercurial or doing small game dev. It allows unlimited free private repositories, unlike Github, which are really useful for backing up your game and if you want to work on it from multiple different machines.
If you know either Mercurial or Git, stick with it. The other one will just annoy you.
I second the recommendation of BitBucket for non-open-source projects. (BitBucket supports both Mercurial and Git.)
I used BitBucket for my game Last Day of Summer, so that I could keep the repo private until the comp ended. I used Mercurial because they didn’t support Git yet, and I liked it; it seemed easier to use than Git, and both were clearly better than Subversion. Then I had to learn Git & GitHub for work, and I got very familiar with those. A few years later, I made some changes to Last Day of Summer in two places in parallel (my desktop and my laptop), but when I tried to merge changes from one into the other, I just could not figure out how to do it. Git warped my brain, I guess, because I found the Mercurial docs for merging branches kind of incomprehensible.
Anyway, I agree with zarf & Sequitur that BitBucket’s free private repos are nice, and that Mercurial and Git are comparable and neither is particularly better than the other (especially for non-power-users). But Git and GitHub are far more widely used, and I think it’s pretty useful to be familiar with those. In particular I think there’s an advantage to being on GitHub if you ever plan to make your repo public, just because of network effects, i.e. everyone else is on GitHub so that’s where people expect to find stuff.
I’ll second that for solo work.
But as Doug noted, GitHub is more widely adopted, and it’s really useful to know GitHub if you anticipate working with a team.
I use git with SourceTree for everything, work and personal. Usually I don’t even push to an external repo for my private stuff, just ”git init” to get version control locally, and make sure to back stuff up now and then.
I can use both Mercurial and Git. I prefer Git because Mercurial is irritating in several regards.
Belatedly, thanks for this! It is definitely relevant to my interests ^.^
Would people still say “use Git for team projects” even if the team consists of two or three people who are all equally clueless about version control systems?
I would say so.
The first source control system I used was Perforce, which is sufficiently different from Git that I had trouble wrapping my head around Git later. (It is also a subscription model of $320/month, which is not ideal for small-team development.) I recommend learning Git now, just because it will be so valuable when you’re working with anyone else later on.
As long as you’re using something, though, you’ll be in pretty good shape. This may seem like a no-brainer, but I was once part of a studio that handled version control via Dropbox, IM, and a checkout spreadsheet. No matter how frustrated you get - don’t do that.
If you don’t know any version control system at all, Git is probably equally hard to learn as Mercurial and much more valuable. But any VCS is better than no VCS at all.
A VCS is actually helpful in solo projects too. It lets you experiment in a relatively risk-free way because you can revert your changes easily if they don’t work out, and it lets you maintain separate branches of the code base to work on experimental features. A lot of people have something (Often just “fuck”) aliased to “git reset --hard HEAD”, ie “undo everything since the last commit.”
Thanks for this discussion – it prompted me to set up a system for myself. As a person clueless about this subject, Bitbucket and Source Tree is what I settled on. Pretty easy to figure out, at least for the simple stuff.
My work here is done. bows, vanishes in a puff of blue smoke
Seconded. Ryan and I used Dropbox/email/IM for Robin & Orchid. It wasn’t completely awful - it helped that we were on opposite sides of the world so we rarely wanted to work on the code at the same time. But we did have a couple of instances where one of us accidentally left unsaved changes open on their computer and we had to merge them manually after we realised. Also, Ryan’s computer persistently ate the Skein, so a regular part of my workflow was asking Dropbox to revert back to the last non-empty version of the skein file. (We lost the skein entirely at the end of the IFComp, because I thought I’d backed up the project with the skein included and I hadn’t and it was past Dropbox’s 30-day file history when I got round to looking at the code again.) Anyway, using Dropbox was bad enough that I swore a solemn oath to use a real VCS for any future collaborations. Dear readers, learn from our mistake.
To be fair, we also didn’t expect/intend R&O to get half as huge and complicated as it did. If we had, we might have considered starting with something more robust.
In the past I’ve been led to understand that Mercurial is easier to learn than Git? One advantage that turned up in my limited research is that TortoiseHg is a nice, reasonably simple GUI that’s available cross-platform. (Important if I ever need to help someone else with no VCS experience get started.) I haven’t found anything comparable for Git yet.
All that said, yesterday I went through Bitbucket’s tutorial for setting up a Git repository, cloning it, pushing to it and pulling from it, and it wasn’t too bad. Or at least, I hadn’t got to the awful bits by the time I stopped. Also, now my WIP (or at least the beginning of a first-draft script for a future WIP) is version-controlled.
SourceTree (Made by Atlassian, the same company that owns BitBucket) is a pretty reasonable GUI for using Git. Though I’m a bad standard for those things; I’m pretty acclimated to the command line.
A lot of the real differences between hg and git get flattened when you use a GUI, though. One of the major differences between Mercurial and Git is that Mercurial has more subcommands that do less, whereas Git has less subcommands that do more. This is totally invisible to you if you’re using a GUI frontend.
Carolyn, your post got me to wade into “real” version control as well. Thanks! I’m trying out Git with Git Extensions.
I think Mecurial is simpler in that it doesn’t have a “staging” area like Git - every change is automatically committed.
The Git command line commands really aren’t that hard. Once you change text editor away from vim and set up remotes (which you have to do in a gui too) it’s pretty routine.
I have been inspired to download SourceTree! Which, I can’t help but notice, doesn’t have a “Getting Started” feature, and when I type “Getting Started” in Help I get things like this:
The bridge to Subversion in Git is provided by the in-built git-svnwhich assumes I know things I don’t know.
So, I need to independently download Git? Or create a GitHub account?
Someone who started learning about this earlier than a few days ago can answer this better, but I think that SourceTree is essentially a GUI for Git. There’s no need to download Git separately. What I’m not sure about is whether SourceTree does anything on its own without being connected to an online account. In my case, the online account is one of the attractions, because I wanted another way of backing up my projects. It turns out that the free version of GitHub doesn’t allow for private projects, so anyone can see all your code. That’s why (following the advice of Sequitur further up the thread) I settled on Bitbucket, which is free for small projects and private.
I found it pretty easy to connect SourceTree to the Bitbucket account. The work flow is basically this: from the Bitbucket account you clone your project to SourceTree, which downloads all the current files into whatever folder you tell it to. Then you work on the project. Then in SourceTree, you commit and label all the changes you made. Then at a certain point, you “push” the commits to the master, incorporating all the changes you made.
What I haven’t quite figured out is how to effectively use this with Inform. In Inform I basically save and compile after each tiny change to make sure I haven’t broken anything – if I’m tracking changes to just the source file, will each save show up as a separate commit, meaning I have hundreds of commits to label?
All the changes you make between commits are condensed together. So, if you start from the initial commit, then save 500 times, then commit again, you just have one commit.
But you can only roll back to the last time you committed - not the last time you saved. Those 500 saves are essentially a single change from the version control perspective.
For I7 projects, it’s a good idea to exclude the project.inform/Index and project.inform/Build directories from your source-code repository. These are large directories which are rebuilt on every compile, so there’s no reason to back them up.
(I also exclude Skein.skein because I don’t use that feature.)
I don’t know how SourceTree or Tortoise handles exclusion. I did it by creating a .gitignore file:
*.inform/Build
*.inform/Index(But if you’ve already added a complete I7 project to Git, the .gitignore file won’t stop those directories from being committed. You have to delete them from your repository.)