Mercurial and command line tools

I have recently fallen in love with Mercurial (aka hg), and would like to start using it for my projects. Unfortunately, there are a few problems with this, mostly relating to the IDE:

  1. I’ve had some difficulty in the past with gnome-inform7, which doesn’t seem to like it when files change behind its back.
  2. Extensions don’t get their own folders, so I have to do something clever with them. I suppose I could use symlinks (from Extensions/My Name/foo.i7x to ~/hg/foo/foo.i7x), but see point 1 above. An alternative, if Inform supports it, would be to just give them their own directories (Extensions/My Name/foo/foo.i7x), but I doubt Inform does support this.
  3. I’m not sure if it’s safe to put a .hg directory inside a .inform directory. Will this confuse the IDE? Also, hg’s more extravagant features will litter the project directory with dotfiles (files beginning with “.”). Will those confuse the IDE?
  4. I suspect there’s lots of transient stuff in the .inform folders that hg shouldn’t track (e.g. temporary I6 files, possibly the Skein and/or Index, compiler output, etc.), as well as permanent things that don’t need to be tracked (e.g. the IFID). hg does have native support for “ignoring” files, but to do that I need to know where those files live.
  5. Materials cannot be reasonably tracked in the same repository as the source. This is less of an issue since I don’t really need to track Materials, but it would be nice. I suppose this could be circumvented by putting both directories in their own “project” directory, and I think gnome-inform7 would support this, but I might be missing something obvious.

Ultimately, I’m thinking about switching to pure command line tools. I’m on Ubuntu and have gnome-inform7, but i7 doesn’t appear to be available from the command line (“i7: command not found”). Can I safely install it in addition to the graphical version, or do I need to choose between them?
Also, does anyone have any recommendations for integrating hg with gnome-inform7, or at least dealing with the issues above?

Put your .hg folder in the parent of your .inform and Materials folder, so you can include both of those. If you have multiple projects you can always just move them down a level, Inform doesn’t require projects to be in Inform/Projects/.

Unfortunately there’s no good way to do extensions at the moment. Hopefully a future version of Inform will allow project specific extensions.

You should include these files:
uuid.txt
Settings.plist
manifest.plist
Skein.skein (if you want to preserve the skein)
Source/story.ni
Everything in the Materials folder except the Release folder.

I have not used gnome-inform7 yet, but in Windows, there’s a “ni.exe” file which IIRC is what converts the story file into something usable with the Inform compiler.

You may be interested in this related discussion.

[*]I’ve had some difficulty in the past with gnome-inform7, which doesn’t seem to like it when files change behind its back.

restart ALL the things!

[*]Extensions don’t get their own folders, so I have to do something clever with them.
no idea again, if the issue is to track chosen files in a directory and hg doesnt do this, try git;)

[*]I’m not sure if it’s safe to put a .hg directory inside a .inform directory.

im sure its ok

[*]Ultimately, I’m thinking about switching to pure command line tools. I’m on Ubuntu and have gnome-inform7, but i7 doesn’t appear to be available from the command line

dpkg -L gnome-inform7

[*] Can I safely install it in addition to the graphical version, or do I need to choose between them?

i keep it installed in home

[*]Also, does anyone have any recommendations for integrating hg with gnome-inform7, or at least dealing with the issues above?

my recent post on integrating with git

hg does that just fine. But what if I need to track multiple extensions independently?

Thanks, I’ll look it up.

git user here, obviously:) u could use more branches and switch between them with --soft or somesuch that wouldnt mess with the files

Indeed, but its options aren’t documented (and it relies on the HOME environment variable, which shouldn’t be an issue on Linux). The Guncho source code has an example of invoking NI.

As for Mercurial compatibility, there’s another reason to recommend putting your projects inside a parent repo instead of running ‘hg init’ on the project itself: Mac OS X deletes and rewrites the whole ProjectName.inform directory when saving changes, so any Mac users you share with will find their .hg disappearing all the time.