There are times when you will have a project that multiple clients will be using and some of them may have permanent minor changes that need to remain even if bug fixes or code updates are made. Initially branches in CVS seem to be able to fulfill these needs, but the examples that the CVS documentation used had branches to separate to its own entity. Basically branches were only used as a bug fix branch for a particular early version. This way the bug fixes from the branch could be applied to the HEAD. I have found a relatively simple way to synchronize multiple clients each having their own changes using a single common HEAD as the generic project. Current development can be made against the head and when major releases are tagged, the release can be propagated to the clients at their own speed. The only requirement is that certain standards must be followed in order to be take advantage of the ability, but a certain amount of standardization should be performed anyway.

I have found patch files to be very helpful while using FreeBSD. Although I only use patch for altering program code, it could essentially be used in many other areas. Since not everyone is able to use CVS or Subversion because of skill level or have no write access to the repository, patch files are a basic, low level means of communicating changes to a particular file, without having to keep track of these changes yourself. This is especially important in code, since quick changes can quickly become out of hand. Patch files are also useful for the person implementing those changes. The patch file format that I currently use for tracking changes easily shows the differences between whole directory trees. This way you have a central location to view the changes that you’ve made. Another advantage is that patch automatically creates backup files for you so that if something goes wrong, you do not have to dig through the changes to fix the problem. This should get you started with using patch.

I really like using Vim in FreeBSD, so when I became more than proficient in it, I decided that I needed a version for Windows. For this I had two realistic options. First, I could use the text based version in Cygwin. For those that are unfamiliar, Cygwin is a Unix implementation that sits on Windows. Although this is very possible, it doesn’t offer the benefit of being graphical and won’t respond to mouse input. The second option is the best, it uses a Windows implementation of Vim called gVim. It has the benefits of using the mouse, copies to the Windows clipboard, and has the option of writing file EOL types in either Windows or Unix format. This works very well, and I have used it for a while, but it had one funny side effect. Any file that was modified with gVim, will automatically create a backup file named ~filename. This started to become very irritating because with almost all files, a backup file is not needed. Using the settings window, I’ve discovered that there is a set nobk option. This works well for the current file, but it resets the option when gVim is restarted. This describes the easiest way to go about fixing the problem while keeping the nice gVim features such as Ctrl+c copying to clipboard. It also points out the .vimrc file for gVim.