I’ve been following the world of distributed source code control since Jesse Vincent convinced me to try out SVK at FooCamp a couple of years ago.
I constantly watch them get better and better - both in the sense of actual code management as well as being able to seamlessly sit on top of a central SVN repo. That last part is one of those things that has its advantages - especially in the event that you work in a team that actually has people who
a) Use an OS other than Linux
b) Are not all developers but need access to the code
The only thing that holds me back from diving back into using SVK, bzr, or git is several of my svn repos make heavy use of externals which seems to be the one feature not well represented in the tools to wrap around SVN. I continue to hold out hope that this problem won’t exist forever….
That being said - now it looks like I have a completely different reason to start using git - and that reason is backups.
At NITI we built a file backup system using what was a pretty clever data structure to speed up file accesses. But we never got around to implementing sub-file deltas, because we couldn’t figure out a structure that would do it both quickly and space-efficiently. With git, they did. To build your own backup system that’s much better than ours, just store it in git instead.
This is a strange thought - especially since the author goes on to show how in some cases git is actually faster than cp.
It is a very strange idea - but could be very useful for some of my odd backup tasks. Now I just need to carve out the time to test it.
Leave a Reply
Moderation Active: Old stuff here... Therefore your comment on this post will be moderated (i.e. don't submit twice !)