#SOURCETREE APP STORE PRO#
#SOURCETREE APP STORE CODE#

That’s still cheaper than Git Tower and probably I’ll start at a much lower price in early revisions and steadily approach that target price as I fix bugs and add features to the app. How much? I’m thinking around the areas of $40 or so. Yeah, it’ll be a paid app, but it’s not going to be expensive (promise!). If you share a similar pain point as I do, speak up! Let me know if this is a problem worth solving and I’ll certainly solve it.

(Better yet if I can retire on it and move back to Indonesia – of course, that’s my wishful thinking). Since this venture isn’t funded by a large company like Atlassian (for which SourceTree is), I need to make up for the time I’ll be spending to develop and support it. Why not a desktop app? If this is made into a desktop app, it would compete directly with other git apps already present on the desktop – many of them free. Moreover when you’re zipping at 80 kph in a cross-country train with a spotty 3G connection – waiting for a few seconds for each keystroke as you type is a real bummer.

You won’t want to type all those git commands via terminal apps like iSSH when all you want to is a few quick fixes while on the road.

Cloning an entire git repository would only make sense an all-in iPad-based IDE.

An iPad doesn’t have a user-accessible file-system and thus there is not much sense to “checkout” an entire repository into the iPad.

#SOURCETREE APP STORE PRO#

An iPad still have much longer battery life than a Mac – about 10 hours vs 7 hours for a MacBook Pro (and the particular MBP models that can last for 7 hour are much heavier than an iPad).A tablet is the better form-factor for computing while standing – in the subway and other public transports – and you don’t have access a desk to put your laptop on.This shell application would fit nicely as an iPad app, mostly to be used “on-the-go”. Thus the repository can remain on the server and the app’s purpose is to save you from remembering many of git’s arcane commands and give you a nice-looking view of your repository. I’ve been toying with the idea of a GUI “shell” app that connects to the server via ssh and runs the git command line program remotely on it. Those can only be done via the terminal using the git executable located on the server. There is no support for rebasing, squashing commits, pulling changes from other branches, and that kind of intermediate-level source control tasks. It can only add edited files to git’s staging area on the server but not much else. Our custom Eclipse-based IDE does help with git somewhat, but not much. Activities like committing parts of a file, determining a file’s changes through different revisions, and resolving merge conflicts is a huge PITA when the command-line is the only way you can do it.What makes things worse is that just about every Git GUI applications need the entire repository to be accessible locally and not much usable if you can’t clone the entire repo to your computer. Simple tasks that are easily done using a GUI application like SourceTree or Git Tower becomes a chore because we couldn’t access file repository locally. My biggest pet peeve of this setup is with our source control system – which is git. Some are contempt to use vim and edit the source files directly on the server itself. We also have a custom IDE (based on Eclipse) that handles this rsync-ing.

#SOURCETREE APP STORE CODE#

Not to mention that we couldn’t frequently commit source files due to how code reviews are being done – but that’s another story fit for an entire post in itself.Įditing the source files are done by rsync-ing our working set back and forth between our workstations and the repo/build servers. Locally cloning the repositories to our workstations aren’t much workable since it needs a case-sensitive file system and the files need to be on the server to be compiled.

We keep these git repositories on the repo/build Linux servers. We have a number of custom-made scripts that are part of a distributed build system to compile and link these source files on the server and make use of the computing power of other servers in the data center. We keep binaries such as image and sound files in their own (separate) git repositories, which are also large.īecause of their size, building these projects also requires immense system resources. In any case the majority of the population are text source files. Also there are some Java sources and various scripting-language files. Mostly they contain C++ source files and some XML files for generating other source files. In my dayjob we have these big (tens of gigabytes each) git repositories that houses the company’s flagship product.

Sourcetree app store