Showing posts with label version control. Show all posts
Showing posts with label version control. Show all posts

Monday, February 11, 2008

Not satisfied with your current Version Control System - discussing switching VCS

freebsd_version_control_system_requirementsAt work we are getting increasingly annoyed by the rather old Visual Source Safe we are using. We are going for AccuRev as a replacement. There is an interesting comparison with Subversion. Their Subversion notes might be true, in the sense taht you do need some scripting skills to take full advantage of Subveresion branching and merging. Perhaps this is what you get for the license fee. AccuRev server does on Windows, Mac and Linux, not sure about BSD flavors. It does not come for free:
AccuRev is typically licensed using a named user license model. The
list prices for AccuRev end-user licenses range from $750 to $1,995, depending
on specific products licensed, number of users, and required integrations with
3rd party products (e.g., AccuBridge)

If you want a good reading of version control system discussion and thoughts, I recommend reading the FreeBSD Wiki on the VCS subject. It is very well written, and touches many aspects of version control (also some you probably didnt think about). Of course it is written with reference to the FreeBSD project needs, but if you are a familiar with FreeBSD branches and ports, and working with vendor code for your self, you might get a lot of knowlegde and ideas from reading it. I found it very interesting :-)

In short it is a discussion of open source version control system alternatives, with description of desired and required features, in order to justify the cost of FreeBSD project switching away from CVS. Is similar to our own thoughts on changing version control system here at work.

Most is written by Peter Wemm, who is vouching for Subversion. Here is a snip from Peter's view on why FreeBSD need a new VCS and why Subversion should be the prime target. Should convince you to start reading :-)
Why does my opinion matter? I've been doing this for a while. For the last 13 years, I've been the 'The buck stops here' guy for our repository. I've seen it all. I wrote the rules about what we can and can't do in the repository. I did the hacks to the cvs system to prolong its use for us. I came up with or implemented most of the hair-brained ideas that we live with on a daily basis.
Here are my snips from my reading through all the sections:

Automated or mechanically assisted merging. FreeBSD's development model requires that (unless it's an exceptional circumstance) changes first go in to the HEAD. If they are suitable candidates to go in to stable then they should be merged to the relevant stable branch.
In addition, new features may first be developed on a separate branch, before being merged in to the HEAD.
The VCS should support easy merging of changes from HEAD (or its equivalent) to the stable branches, and from feature branches to HEAD. Merges should also be able to go both ways, and be easily repeatable (e.g., a long lived feature branch may merge changes from HEAD on to the branch several times, and may merge changes from the branch back to HEAD several times)

Branch, Easy & cheap branches (and history-aware merging) and tags to enable parallel lines of development (that is essential for projects like SMPng which have a very big impact on many source files)


SVN Repo Layout: A proposed repository layout if FreeBSD moves to Subversion. This includes a good suggestion of handling Vendor code.

SVN Merging: A walkthrough of merging changes with Subversion and svnmerge.py. This walkthrough of branching and merging is very educational :-)

ACL, Access control: the ability to constrain developers to operating in specific areas of the tree, implement branch-based policy restrictions, as well as to enforce policy such as tagging of commits for developers working outside their normal areas. Implementing these via hooks would not be a regression from what we currently do in CVS.

Offline, Ability to work offline -- like on a plane -- without requiring too much work: not only being able to list differences but also to commit

SVK which brings history-aware merging and distributed features to SVN

There are some really interesting (biased of cource) quotes when it comes to comparing Git and Subversion conversion going from CVS, which are right on, and makes you think:
For us to switch to svn would be an evolutionary step. We could use it
as a better cvs, with the sharp edges fixed. hg and git require more of a
revolution in the way we go about things.

git/hg make it very easy to take stuff offline....Encouraging the
taking of stuff further offline is going in the wrong direction for *us*. If
anything, we need to make it easier for people to get stuff to us and in the
tree in some form.

Linus wrote git to suit his needs for linux. He has one thing going for us that we don't. There is a large cult of personality surrounding Linus. There is intense pressure to "validate" your work by getting it approved (directly or by proxy) by Linus. On the other hand, we already have problems extracting work from people. We can't assume that we'll get the same inward flow that Linus gets.

From http://lwn.net/Articles/246381/ - there are some choice quotes. The topic is the problems the KDE folks had making git work for them.

We're not Linux. A good number of our best supporters stick with us because we're a coherent tree and not like linux' chaos.

Why do you seem to be pushing subversion?It's because I am. I think the whole hg/git thing is a distraction.

  • it works the same way we've become accustomed to cvs working. Except without most of the silly problems/restrictions.
  • there are a huge bunch of tools out there to talk to svn. Things like svnsync (cvsup for svn repository replication) are out there.
  • We can use live changeset based exporting to export the tree to cvs to maintain HEAD and RELENG_* branches. Our end users will be able to keep doing exactly what they've always been doing for getting their "fix" of freebsd.
  • svk, as an optional add-on, gets you the ability to have a private playground, in spite of my encouragement to work on the public servers.

Notes on Git Conversion: Why git is interesting to FreeBSD, is also very educating. From the little bit of Git reading that I have done, it seems to me that Git gives abilities to hide development cycles, not something I would appreciate in the projects I participate in. Some Git quotes:

git is distributed

Now, you can commit as you develop, then test, then push. If
you find things in your testing that are wrong, you can commit fixes before
pushing, or even go back and edit your local history to erase your mistakes,
making you look even more ninja than you really are.

You can also push your
changes up to a personal repository for others to access. They can merge it to a
personal tree of their own, do repeated merges all sorts of directions, and have
it just Do The Right Thing.



I am a fan of Subversion, and it works on many platforms. So far Subversion has fitted all my needs for version control, automation, documentation, management etc!

After reading the above articles I am even more convinced Subversion will continue to meet my needs, so I am not changing :-) SVK is something for me to try though. And AccuRev might prove useful for the enterprise, we will see.

Friday, September 28, 2007

IRC bots and announcements

I am still in some IRC channels where it would make sense to have announces from work related stuff, eg:
  • Nagios monitoring alerts.
  • Subversion commit messages. And other post/pre-commit hooks.
In an ONLamp article about subversion and traq on FreeBSD, there is also an example with a irc announce using RSS feeds, which is implemented with http://supybot.com/. This seems interesting, maybe it is useful for my other needs, I will have to check it out.

On top of the Nagios alert messages, it would be nice to be able to send a query from an IRC bot to the Nagios service to get current state of a service monitor.

Wednesday, September 12, 2007

Comparing files and folders

When it comes to comparing files, I have been used to a perform this on text files only, always wondering if similar functionality is availble for Word documents or even images. The tools i have used in the past:

  • diff -y --suppress file1 file2, very usefull for checking changes to config files, eg. in scripting if you want to make only a certain number of lines are changed. Adding something like MKS Toolkit or GnuWin32 will give you similar tools on your Windows platform.
  • Total Commander has a built in compare files.
  • My favorite is WinMerge which is freeware and can recursively compare folders!
  • WinMerge can also magically replace the builtin side-by-side compare functionality of TortoiseCVS and TortoiseSVN which are my favorite Subversion and CVS version control Windows interfaces.
  • FreeCommander can compare files if you set it to use WinMerge. Without WinMerge FreeCommander can recursively compare files and folders (Syncronize).

I dont recall needing to merge a lot of files, so i dont know how the tools above will compare to Araxis Merge.

So at my new job i was pleasently surprised to learn of Araxis Merge, a new tool, that also can compare pictures! I do not have any particular use for it right now, but i am sure i will think of something :-) Unfortunately it will cost me some bucks, so i will probably stick with WinMerge for the time being.

Starting a blog, handling knowledge management

Welcome to my blog, thanks for visiting!

I have started this blog to improve my knowledge management system! In short this blog will contain all information i feel like saving! For more details of the entire system, see later.

The need for an improvement to my knowledge mangement came up this month, when I got a new job! At my new job I can no longer commit/checkout my personal Subversion or CVS repositories. And I dont have access to Firefox, so I am also missing my bookmark sync-and-sort plugin!

Things you wont find here are real personal information or notes that are confidential, which will have to stay on my PC or in a special Subversion repository for that.

So to summarise my knowledge management system as of today, it consist of the following:
  • Ideas/readme/snip commits used to be saved in Subversion, but probably this will go into this blog from now on!
  • Personal scripts will still go into personal Subversion repositories, as it is easier to deploy to servers. Snippets from those will go to the blog when appropriate.
  • Howtos/working notes probably will stay in the appropriate CVS/Subversion repositories for a while. This is not optimal for sharing with more than a few people, so snippets will be in this blog!
  • Pictures go to appropriate flickr accounts: personal or family, available to anyone, family or friends.
  • Videos unfortunately can not be put into flickr. A place like flickr, with video power like youtube would be nice! Any ideas.
  • E-mail will probably move more and more into gmail, as that will hopefully be availble anywhere i ever need it.
  • The few websites i help o webmaster, are saved in a Subversion.
  • Instant messaging logs are not central or searchable, this would be nice to see.
  • I dont contribute to any particular Wiki anywhere, neither do I have one of my own.
  • I dont contribute to a particular forum, neither do I have one of my own.
  • I have not yet started using VoIP or mobile technology beyond low-tech personal use.
  • Daily top urls to visit (bookmark management) will stay in Sync-and-sort for now, but should not grow into a mess like recently. Instead i will post on this blog, including my thoughts of a particular url. I have a few ideas for better bookmark management so i dont have to use sync-and-sort.
  • Book reviews and notes will move from Subversion to this blog.

Search capabilities within all systems is of great importance, and if I was to share knowledge i tend to say good search possibility is the most important requirement of a knowledge system! Otherwise you will risk the system never gets used.

For my own setup above, a generic search across all systems is not available to me, I have to search each of the knowledge system parts in what ever I can. This is one of the reasons i prefer any format that is text based, because then at least i can grep for one word. I would really like to have a single point of entry search engine which can crawl any of the above! Limiting access to see and perform searches within certain data would be paramount! I am not aware of a product that can do this. For the enterprise at work we will take a look the Google search appliance, but for my personal usage i hope to find something similar that is available in some open source project?

The IBM quickr approach is appealing to me, at least from a coorperate knowledge sharing point of view. It seems perfect for Notes environments, but unfortunately i have not had a chance to try it out yet! I wish there was an open source alternative with similar functionality i could play with. A google search got me to Sun portal server but it 1) it might not be what i want and 2) has some pretty hard technical requirements for me to get started, so i will probably never know about the first issue.

I dont know how other technical people cope with the difficulties of handling job and personal knowledge management systems? Undoubtedly it must raise problems with regards to people loosing their notes if they change job or job position, and it goes without saying that you can not mirror work knowledge mangement systems off for your personal usage! As work and personal life keeps merging, this issue will keep popping up.