From 30 seconds to zero in 1 day.

Published Friday May 16th, 2008
7 Comments on From 30 seconds to zero in 1 day.
Posted in KDE, News

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!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in KDE, News

7 comments

Nicolas says:

Just what we need. Yet another VCS.

Elvis Stansvik says:

Why so negative Nicolas? With git, DVCS is just starting to become widespread in the FOSS world, which is a good thing IMO. But as all new tools it suffers from child diseases and judging by a lot of people’s first reactions with git, the user interface seems to be it’s soar spot. What Thomas is working on seems to be exactly what’s needed, and as the only reason I haven’t looked into git yet is because I’m put off by the initial learning threshold, I applaud his work on VNG. So cheer up πŸ™‚

Kurt says:

“The effect is a very powerful command set, as well as very flat learning curve.” – I hope it has a steep learning curve which means I can learn a lot in a short time. πŸ™‚
http://en.wikipedia.org/wiki/Learning_curve

sebas says:

I think what we really want is a mechanism that reliably records when a file is changed. inotify is supposed to do that on Windows, unfortunately you cannot watch a large number of files easily, something that would be required for a VCS. It would solve the problem nicely, though.

James says:

Just out of interest, have you taken a look at Bazaar (bazaar-vcs.org) ?

Nicolas says:

It’s clear everyone has jumped into the distributed VCS hype. In a few years, dozens of DVCSs appeared, and we still have only *two* open-source centralized VCSs: CVS and SVN. SVN is improving, but slowly. And it doesn’t look like we will have a new better centralized system anytime soon.

Saying distributed is better than centralized is like saying KDE is better than GNOME: not true. They are different. Better in different things. Depends on your needs. Etc etc. True, there is no way the Linux kernel could be developed in a centralized way; but that’s just their particular case.

If simple integers to represent revisions is an important enough feature for a particular community/project/developer/whatever, they will stick to SVN. Not like they have the option to move to something better: there isn’t any, and nobody cares about making one, they’re all in the distributed bandwagon.

steffen says:

hi! i really like vng,
can you consider to release a source tarball, so i can create a gentoo ebuild?
i will stay tuned
thanks!

Commenting closed.

Get started today with Qt Download now