Git Virtual File System – Finally, a solution to large Git repos?

Microsoft is all about Git in the last couple of years, and a few days ago they announced an exciting new feature they are working on that should really take Git to the enterprise level.
The GVFS (Git Virtual File System) is a way to make Git “believe” that it is working with the entire repository clone, while in reality all files reside on the server, and are only downloaded the first time something tries to access them.

This means that even for very large repos, clone time is next to nothing, and commands like git status can take a few seconds instead of several minutes. The only payment is the time it takes to run a build, or to open a solution, for the first time.

Somehow I can’t shake the feeling that it was inspired by ClearCase MVFS (Multi-Version File System), which at the time was an excellent way of working against large repositories without spending hours of copying data to the local machine. Of course MVFS has a whole set of problems, but the basic idea of ‘download content only when you actually need it’ was innovative at the time, and apparently has its uses today as well.

I’ll keep a close watch on how GVFS is shaping up in the coming months. It can be a real life saver for companies like the one I work for, which are struggling with the idea of switching to Git, considering a 150 GB repository and over 200,000 files in a typical workspace.

Advertisements

Python and Windows Symbolic Links

Python, like many other popular OSS (Git anyone?), does not support symbolic links on Windows platforms , although they have been around since Windows Vista. Note, I am referring to actual symbolic links, not NTFS directory junctions or shortcuts.

I’m not really sure why is that. Maybe because they do not distinguish between different Windows revisions?

My current approach is to use the OS commands to create/delete symlinks. It’s not very elegant but it works without compatibility issues, unlike other solutions (calling win32 api through DLLs, manipulating file attributes, and other stuff you find in StackOverflow or tech blogs)

For example, to create a symbolic link of directories, one can use:

 child = subprocess.Popen(['MKLINK', '/D', link, target], stdout = subprocess.PIPE, stderr = subprocess.STDOUT, shell = True)
 streamdata = child.communicate()[0]

And check child.returncode for the result (and the output – stdout and stderr combined – available in the streamdata variable)

To remove a symbolic link to a directory, use the windows RMDIR command (os.rmdir or os.unlink won’t work)

 

A ‘browse for file’ dialog using InstallScript

InstallScript provides a built in SelectDir() function, allowing the user can select a directory. However there is no equivalent function to allow the user to select a file. Which is a problem if you want to implement custom dialogs that browse for files (e.g. a dialog that asks for a .pfx certificate file and its password).

As it happens, InstallShield provides a very good knowledge-base article about how to add such functionality, but it is very-well hidden; you have to use very specific keywords in order to find it… So, to save you some time – go ahead and use this link.

CI with ClearCase Base: The Road Less Traveled

We spent the last year or so building and maintaining a Continuous Integration (CI) system for our major development group. And it was incredibly daunting and frustrating, considering we had to build it around a legacy and problematic version control system like ClearCase Base.

In the textbooks it seems pretty simple: every commit (check-in) to the repository triggers a build, which in turn checks out the latest version of the repository from source control, and run the build process. This way, if a build fail, you know exactly who broke the build – the person who performed the last commit – and if it the build passes, you have full traceability between the build artifacts and the source code they were built from.

Now, let’s try that with ClearCase Base.

Continue reading

Why use an installation technology

This is a question that I get asked from time to time, usually after someone who is not familiar with the deployment world encounters problems with a certain installation. “We could just write a script that extracts the files to the right place, what’s the big deal?”

Well, it’s a big deal. Generally speaking, an installation framework (compared to a script) provides a lot of benefits, such as:

  • Modelling the application deployment into sub-modules – allowing to add or remove parts of the applications, define dependencies etc.
  • Built-in support for many deployment actions – from simple things like copy files, edit text files, or run some OS command, to configuring web servers and databases
  • Ability to rollback each action – which gives you the ability to rollback changes in case of installation error, and provide an uninstaller, with (theoretically) no additional effort.
  • Built-in detection of files in use, including the ability (in some cases) to replace such files (upon reboot, or by automatically restart the interfering process)
  • Various levels of UI (from completely silent deployment to a full user-driven interface)
  • Versioning and update management (upgrades/patches)
  • Built-in logging
  • Integration with the Operating System software management tools (such as the ‘programs and features’ in Windows)
  • And more… (your comments are welcomed)

So, it’s so great, so why not everyone love it?

Continue reading

Jenkins User Conference 2016 – Impressions

20160703_161012 20160703_214802

Today I attended the Jenkins User Conference, held in Israel, hosted by JFrog.

First off I have to say the event was very well organized. Great location, everything on schedule, no technical issues, some nice swag, and excellent food and drinks throughout the day (including afternoon beer!). Considering there were about 450 people there, that is no small task…

The guest of honor was Kohsuke Kawaguchi (KK), the creator of Jenkins, who gave an interesting keynote, with overview about the concepts behind Jenkins 2.0, and some anecdotes from the history of Jenkins.

The main theme of the conference was that Speed is Everything, as you can figure from JFrog’s motto, “Release fast or die”. Their view is that software today is about continuous update – you basically deploy your products once, and from there onward you struggle to update them as often as possible, as seamlessly as possible, without negative effects on the user experience. This raises numerous challenges which various vendors and open source projects are striving to solve.

There conference was packed with sessions related to the DevOps world, mostly about making things faster without losing control on the process. Liveperson, for example, discussed how they manage 6000 releases a year, with over 10K builds per week.

Continue reading