Select Page


More and more often, I find myself working while away from the office.  My current setup involves an internally-hosted P4 server.  It took a couple days to get the process up and going, but it’s been going for awhile now and has been decent for a large number of use cases.

There is one big issue – and that is accessing the P4 server from outside of my office.  I have run into hurdles with trying to remedy it:

  • My office does not have a static IP, so the software VPN could cut out whenever it changes.
  • Brighthouse (my ISP) has been incredibly unreliable and requires a physical reset to start internet service again.
  • Although I am very technical, I would prefer to focus on the business rather than the infrastructure.

As a result of all this, I figured that a solution in the cloud was the way to go and explored several options.  This rest of this article serves as a way to call out the pros and cons of each as well as the option that I selected.



There are three popular flavors of Git cloud services.  Here is a cursory glance at each starting with the highest popularity:

  • Github: Free public repos, unlimited users,  Popular for open source programs.
  • Bitbucket: Free private repos, limited to five users.  Built by the same team that built JIRA.
  • Gitlab: Their website is very unclear.  Sounds as if you have to host it on your own server, which feels weird to pay for such a thing.

The work I’m largely involved in now has to do with websites.  So, it’s not something I would collaborate on with random people in the open-source community.  As a result, I ended up going with Bitbucket.


  • The absolute best GUI out there for Git is SourceTree.  It’s written by the same people who wrote Bitbucket.
  • Git is a DVCS (distributed version-control software).  That means that I can make submissions (or commits) locally and when ready, push up to Bitbucket.  This makes it so that I can work where Wi-Fi is not available.


  • Not clear how I would go about sharing Ski.Web into BluePrint-Q and how I would share BluePrint-Q across all client sites.  Submodules require a ridiculous-to-remember workflow and subtrees dump all the files, initially, into the root folder when first pulled.  Using external dependency managers turned out to be a lot of rework.
  • There is a 1GB soft-limit and a 2GB hard-limit with Bitbucket, so the media that exists in each website could not live with the code.  I prefer data and code to go together for historical reasons, but this also presented an iteration development issue for me.  Additionally, Git is generally recommended for smaller codebases since it chugs the source gets larger.
  • Although there are GUIs, a large percentage of tutorials deal with the CLI.  There is no way that I am managing large projects with commands that I must memorize and perform the same way each and every time – very prone to human error.


Great for small team, single projects without libraries that are not heavy on large assets (e.g. music, art, etc).  In my case, I passed on it since my requirements were just the opposite.  I also was not thrilled with having to figure out a way to rework the P4 branchspecs I already had to make releases of BluePrint-Q.  My feeling on Git, in general, is that it is super-embraced by the community because it is generally “free” source-control for any platform.



Visual Studio

Although Microsoft has not been at the top of their web development game over the years, a lot of my embedded programming experience is around Microsoft Windows – which typically means using Visual Studio.  So, I decided to look into their offerings and found two:

  • Azure: Microsoft’s cloud technology.  It looks more like Enterprise-level tech, not Freelancer-tech.
  • VS Online: A collection of services and applications that help develop software through collaboration.

I ended up delving into VS Online since Azure appeared to be way too involved for my needs.


  • Visual Studio has a new product called Team Foundation Version Control (TFVC).  It’s a free repo in the cloud for up to five users, similar to Bitbucket, but no obvious limit to how much disk space was available.  This means that code and assets can be coupled together.
  • TFVC is integrated with Visual Studio 2015, so it means easy check-in/checkout procedures.


  • It’s unclear how branching completely works.  There is some sort of synergy between folders and branches, but not clear on the differences.  In my case, I am concerned on how the existing P4 branchspecs would translate into these TFVC branches.  Maybe the Visual Studio Online release mechanism needs more research?
  • TFVC only works with Visual Studio 2015 – it does not work with Visual Studio Code, Microsoft’s newest cross-platform web development offering.  This is really disappointing since VS Code seems to be a straightforward, lean text editor that recognized PHP files; whereas, VS 2015 is bulky, does not natively support PHP files, and a PHP extension forces the use of SLN files, which can litter folder structures.


Having “unlimited space” and keeping code/assets paired together is a huge win.  I really wanted this to work out for my case, but after finding out that the PHP extension to VS has a price tag associated with it and I would have had to figure out how to deal with LESS compilation, documentation generation, and site staging – it seemed like a lot to handle.




P4 technology has two cloud options:

  • Helix: First-party cloud service.  It is not possible to review this because the product is not publicly available yet – instead, there is a mailing list.
  • Assembla: This company was actually recommended as the result of a conversation with a Customer Service Rep at Perforce Helix.


  • Use the same, familiar P4V to access cloud data.
  • Code and data can be placed together.


  • It is not clear what happens when the 40GB max limit is hit.
  • Assembla is very expensive.


Certainly has its place, but I passed on this one too.  Not a fan of a brand that I do not know, which means they could go out of business at any point and my data could be in trouble.  On top of it, I feel that the charge $168 per year for the entry-level service is too expensive.  The $1200 per year for the 40GB is way out of the desired price point – especially when comparing to places like Google Drive.  I’m hoping that Perforce Helix has a more reasonable offer.




After all of this, I ended up going back to my internal Perforce server.  Plan is to see what happens with Perforce Helix, going forward.