monoxide

Are you trying to skip a dimension that doesn't actually exist? Because that won't work...

Version 1.1.2 is released. This is purely a version bump to 1.5.2.

http://forum.feed-the-beast.com/threads/feed-the-beast-redpower-and-1-5-x.18827/

http://forum.feed-the-beast.com/threads/feed-the-beast-redpower-and-1-5-x.18827/

Also, FYI, the FTB Ultimate pack should be updating to 1.5.1 within the next week or so, sans RP2.

Also, FYI, the FTB Ultimate pack should be updating to 1.5.1 within the next week or so, sans RP2.

The git mechanism is very much a proof of concept/experiment at this point. It was an initial attempt at incremental backups since git only stores diffs. If it doesn't work well for you, then I'm sorry and try something else.

The git mechanism is very much a proof of concept/experiment at this point. It was an initial attempt at incremental backups since git only stores diffs. If it doesn't work well for you, then I'm sorry and try something else.

Currently there's no way to turn off the default backups. I may look into that for the 1.5 version. You could use the bz2 method for the normal backup and set it up to backup daily and keep 3, and then no daily backups in the archives. Or just use bz2 regular backups all round. There's a reason the git option is an *option* and not required. With regards to rsync, I have no issue with it per ce, except that rsync excels at keeping two copies of a filesystem in sync, however the idea here is to create many copies at different points in time. If you rsync to an empty directory, you gain nothing. The two seem to be aimed at different tasks, so I'm not sure how rsync would help. I will look into the weekly backups issue, thanks for the bug report there.

Currently there's no way to turn off the default backups. I may look into that for the 1.5 version. You could use the bz2 method for the normal backup and set it up to backup daily and keep 3, and then no daily backups in the archives. Or just use bz2 regular backups all round. There's a reason the git option is an *option* and not required. With regards to rsync, I have no issue with it per ce, except that rsync excels at keeping two copies of a filesystem in sync, however the idea here is to create many copies at different points in time. If you rsync to an empty directory, you gain nothing. The two seem to be aimed at different tasks, so I'm not sure how rsync would help. I will look into the weekly backups issue, thanks for the bug report there.

Looks like I may have to retract my previous statement. Thanks to the wonderful work of cjo9900 we now have a 1.5.1 version working! I haven't done much testing on it myself, but he assures me it's working and there honestly wasn't too much to update the released version. This is essentially a straight port of the 1.4.7 version with a minor bug fix.

Looks like I may have to retract my previous statement. Thanks to the wonderful work of cjo9900 we now have a 1.5.1 version working! I haven't done much testing on it myself, but he assures me it's working and there honestly wasn't too much to update the released version. This is essentially a straight port of the 1.4.7 version with a minor bug fix.

Yea, git is funny in how it deals with submodules, and ForgeBackup doesn't know about them at all so expect weird behaviour in that situation. I might relax that behaviour so that it only requires a clean index, but I'm not sure about that. Also, the git folder you've already done there would still not get backed up at all. Got a few interesting ideas how to deal with all that, but don't want to promise anything just yet. Sadly, I won't be able to update any time real soon I don't think. Work has been hectic and I've just had a bunch of hardware blow up recently, including my Jenkins server.

Yea, git is funny in how it deals with submodules, and ForgeBackup doesn't know about them at all so expect weird behaviour in that situation. I might relax that behaviour so that it only requires a clean index, but I'm not sure about that. Also, the git folder you've already done there would still not get backed up at all. Got a few interesting ideas how to deal with all that, but don't want to promise anything just yet. Sadly, I won't be able to update any time real soon I don't think. Work has been hectic and I've just had a bunch of hardware blow up recently, including my Jenkins server.

The git backup is likely upset at the fact that the repo isn't clean when it tries to run a backup. The easiest way to verify that would be to check the actual server console which should tell you exactly what's wrong. What is in ftb2/computer? Did you add that folder/file yourself after the fact? ForgeBackup will only do a backup if the repo is currently completely clean and should commit everything it adds into the repo. It will also delete any files in the repo before adding a complete updated copy for the next commit. This means that it's a poor choice of location for you to be adding your own stuff to. For now at least, the messages reported in chat can be generic/poor, but looking at the console should tell you exactly what's going on.