Back to Blog home

From 30 seconds to zero in 1 day.

Published on Friday May 16, 2008 by Thomas Zander in News KDE | Comments

Its been a while since I introduced 'Vng'. Vng is still under production and innovation is happening :)

As a quick intro can be read here, which will tell you that vng is a version control system made to be usable by humans.

So, what has happened since my last blog. Well, I've been polishing a lot. This means that I have added various options to the major commands. Like adding all files in a dir recursively to the repository. Which you really miss if you need it.
Another thing I added was a matcher. The most obvious place where this is visible is in watching past changes. The changes command will naturally list things like commit-message, author etc. Using the various matchers it becomes trivial to do some more intelligent interrogation of your repository.
vng changes --match zander #show all the records which 'zander' made.
vng changes --last 10 #show 10 records
vng changes --from-match 'fix assert' #Find the record with 'fix assert' in the message and start showing changes from there.
vng changes --to-patch 'Add.*Command' # show only changes until one that matches the regular expression.
Naturally you can combine all those without problems.

Most of these things you probable just have to try out to see how it works for you. I'm someone that really cares about the tiny details so you'll find things like showing when you changed whitespace at the end of the line with a colored marker, or being able to type 'vng what' instead of the full command 'vng whatsnew' since, well, vng knows you must have meant the full one, naturally.

Back to the "what happened" point. I always get a bit excited when I have a tool that is just smart in visualization etc. But I actually started writing this blog for a reason;
The main complaint I have heard from people trying git on the Qt repository (specifically on Windows) is that its slow. Now, we know that git has some scalability problems on Windows, and the git people are working on that. But in my interviews with various perforce users that actually made the above claim I noticed a very different problem.
The way that perforce works is that your checkout has all files checked out as read-only. Whenever you want to edit a file you have to tell perforce. Which tells the server you are editing this file.
The effect of this is that doing a 'p4 diff' will first ask the server which files you have opened and then do a compare of only those files with your local copy. This is substantially different from git or darcs or many others which all use the file-date to check if you have edited a file. Using a filedate has the big disadvantage that for a repository the size of Qt (or KDE) you have to stat 30000 files if you ask your app to give you a diff. This is disk-access and thus slow.

So, no matter how much the file-access is optimized and duplicate statting is reduced, the concept of making the user keep track of which files to diff will always be faster then letting the tool auto-detect this.

This conclusion then lead me to investigate in what manner it would be practical to re-use this concept for the people that now have very good reason to complain about slowness. I mean; instantaneous diff, or waiting 30 seconds on cold caches to do a diff of Qt...
I have used my creative-Friday today to work on this in vng and have for the most part finished the implementation. I have added 'vng edit' and 'vng opened'. Edit will ask the user if he wants to switch to the way of working that he has to mark files for editing. After which any whatsnew / record etc will only happen on the files that are being edited. The biggest change, naturally, is the speedup. The results will be on screen instantaneously since we already know which files are changed and we avoid any file listing or statting.
Next step is to make the perforce integration that virtually all tools have work for vng. This integration is in most editors, in diff and various other tools already. They will detect a file that is read-only and will call p4 edit on the file prior to writing out your changes. If we can fool those tools into doing the same but then call vng edit instead we get a huge speedup virtually for free.

Are you interrested in trying out vng; see vng.googlecode.com or just download the sources from repo.or.cz/w/vng.git. Note that the speedups are not in the downloadable executable posted on the projectpage. I'll have to rebuild that one soon.

Have a good weekend!

Subscribe to Our Blog

Stay up to date with the latest marketing, sales and service tips and news.

We are updating our comment system and you could face some issues. Please write to us at feedback@qt.io to report issues/bugs.