Almost 7 years after the first public release, I’m retiring my most successful open source project so far:
Bitbucket Backup will be superseded by SCM Backup.

There will be no further development on Bitbucket Backup, and users are encouraged to switch to SCM Backup instead (which can do everything that Bitbucket Backup could, and much more).

There’s even a special page in the SCM Backup docs, to help longtime Bitbucket Backup users getting started with SCM Backup.

I know that big rewrites are generally considered evil, and I thought a lot about it before finally making that decision. And yes, I’m confident that a rewrite made sense in this case.

There were multiple reasons that made me consider it:

---

Bitbucket only

I wrote the first version of Bitbucket Backup in 2011, when I was using Mercurial/Bitbucket only (at the time, Bitbucket supported Mercurial only).

Later, Bitbucket added Git support, so I added Git support to Bitbucket Backup as well, but didn’t really use Git myself (although others did).

Nowadays, most people are using Git and GitHub, and I started using both, too.
So a) I needed something to backup my GitHub repos anyway and b) probably a lot of other GitHub users need this too, so supporting GitHub would make sense.

But then, the tool is called Bitbucket Backup. So either I’d have to rename it, or else it wouldn’t be clear that it now supports GitHub as well.

Plus, everything in the code is closely tied to Bitbucket, and wasn’t designed for the possibility to support multiple hosters later.

---

Unattended execution is difficult

I created Bitbucket Backup to support my personal backup workflow, which I explained here before - I’m running backups by starting a batch file while sitting in front of my machine. So I didn’t consider the possibility that other people might run Bitbucket Backup unattended.

Some people had problems with that, some with setting their password (Bitbucket Backup asks for it at runtime and saves in encrypted in the AppData folder), and others needed a way to tell whether their backup was successful or not, so someone made a pull request and added sending info mails.

I could just have added some more logging…but I’d probably have to rewrite the whole configuration thing anyway, because if I really supported multiple hosters (see above), entering the credentials for all of them on startup wouldn’t be practical anymore.

---

Windows only

At the time when I wrote Bitbucket Backup, “cross platformness” wasn’t as important as it is today.
Plus, getting started writing cross-platform .NET code wasn’t as easy as it is today, and I’m not sure whether I even knew about the existence of Mono back then, so I didn’t consider cross-platform at all.

In the meantime, some people have tried to run Bitbucket Backup on Mono, and ran into some problems. To fix this, I would either need to try to fix things until Bitbucket Backup runs on Mono, or port it to .NET Core.

---

No tests

Last but not least, Bitbucket Backup doesn’t have any unit or integration tests. Back then, I was just starting to learn about automated testing, and I didn’t feel comfortable enough with it yet to write tests for Bitbucket Backup.

Especially because an application like Bitbucket Backup (which calls APIs and 3rd party command line tools which download stuff from the Internet) isn’t the easiest thing to test when you have no idea what you’re doing.

And adding tests later, in an application that wasn’t designed for testability in the first place, isn’t a great idea either.

---

Conclusion

All of this made me think that starting from a blank slate would probably be best.

The alternative would have been to gradually add support for everything mentioned above…which is basically the same like a big rewrite.

So I wrote SCM Backup from scratch, trying to fulfill all the points mentioned above:

• Support for multiple hosters (at the moment: GitHub/Bitbucket), and it’s designed for adding more hosters
• it has a YAML config file and logging / email output to make unattended execution easier
• .NET Core, so it’s cross-platform (although I didn’t try to run it on a non-Windows machine yet, I still need to test that)
• it has lots of unit and integration tests