Single file scripts are fairly easy to manage.  If you notice a new version of your script is released, then simply replace your file with the new version.  Likewise, it’s very easy to remove the script if you want to just try it out.  However, scripts spanning multiple files are much harder to manage.  For one, the script’s files get merged in with all of your other script files.

To help know what files are apart of what plugin, I manage my vim scripts in git.  Another way to keep track of things is to use a vimball.

What Are Vimballs?

Vimballs are essential vim script installers.  Each vimball contains all of the files that are needed for the script to work.  Not only that, but it also has a hook for you to easily uninstall the script as well.

Tail Bundle is a script that mimics tail -f for vim.  The downloadable artifact is a vba file.  That file is the vimball.  To actually install the file:

1. vim tail-03.vba
2. :so %
3. :q

So what that all means is that you’re opening the vimball in vim.  From there, you’re executing the instructions that are in the file.  Lastly, you’re just quitting.  You see, a vimball is a vim script in of itself.  So executing it writes everything out to where it’s supposed to go.

While the tail bundle makes use of the vimball, not every script does.  Luckily, it’s easy to make vimballs out of most script downloads.

Converting Scripts to a Vimball

In order to make a vimball, it’s quite easy. List out all of the files you want to include in your bundle, relative to where your current directory is.  For instance:

doc/myawesomeplugin.txt
plugin/myawesomeplugin.vim
syntax/myawesomeplugin.vim

Next thing, while in visual mode, type ggVG:MkVimball myawesomeplugin. The ggVG is a akin to doing a “select all”.

This will create your install file named myawesomeplugin.vba.  Now just install it like any other vimball.

You don’t have to just make vimballs for your own scripts.  I love xpt, but there are so many files to manage.  Well, you can make the vimball script even when the author does not.

Open a new buffer and use the command :r! find . -type f.  This will find all of the files and print them out into the buffer.  If you want to do any cleanup, like remove blank lines and removing the extra ./ before each entry, feel free to do so.  Now that you easily got a list of all the files, create the vimball from that.

Now you have records of what went in with the script and you have a super easy way of uninstalling the script too.  Speaking of which…

Removing Scripts

To remove a vimball script, simply execute :RmVimball myawesomeplugin.  That will go through and delete all files created by the plugin.

After figuring this out, I now know that when I want to use and install vim scripts, I’m going to do so via vimballs.  It’s too easy not to, and the benefit of having a way to back-out scripts is just too tempting.

With multiple programmers, you can probably expect a versioning system, perhaps a centralized versioning system like SVN or Perforce. With that system, each programmer would make his/her changes and then would check in his/her changes into the repository. From there, the programmer’s peers would review the code.

What’s the problem with this system? The code is already checked in. The pressure is on the peers to ensure that the code is good, and it’s likely that this could slip through the cracks. I mean, those peers are working on getting 10 features complete themselves.

Enter Git

Well, I would argue that Git has a strong code review process built right in. This is due to the process of how distributed version control works.

Programmer A creates a fork of the master project. A makes his changes and commit his code; however, the code is committed to his local repository and not the master origin. This is because A does not have write access to that repository.

A has to contact programmer B, who has write access. A tells B that he should pull his code. Since B has to pull the code, this means that B has to review the code coming in.

It’s this workflow that promotes code review. Now that’s not to say that you can’t do code reviews in a centralized model, it just fits a little better in a distributed model

Ticgit takes a simplistic approach to issue tracking as Lighthouse has done. You can comment, add tags, manage the state of an issue, save views, and change to whom an issue is assigned. There is still more planned, like keeping track of milestones and syncing the tickets to Lighthouse.

As mentioned, there is a web interface to ticgit; however, it wasn’t my cup of tea. So I have started my own web interface, tiwatchtower It’s still a little rough around the edges, but I would love to hear any thoughts.

Conclusion

So far, I like it and it’s exciting to see how git can be pushed. It’s great for keeping track of things that are on my mind without worrying about having to setup trac or having to use up a Lighthouse project. It’s simple, effective, and worth a look at.

I bought a Flex book to, well, teach myself Flex. The book right now is taking me though one application and is building it out piece by piece. So I began to think: “What if I just keep track of all my changes through git?”

For one, Flex is nice because it’s all XML, so that makes revision tracking fairly easy. Also, git is very easy to get started because you don’t have to do any server setup. Just issue a git init command and get going. Then after each chapter, I can tag the repository for posterity’s sake. And I have to say, it’s been great to see how the code has changes, especially since Flex Builder generates code.

That’s one thing I love about git, and mercurial, it’s so easy to start using version control for even the littlest of tasks.

Setting Up ~/etc

Since /etc contains any configuration file, why not have the home directory mimic this?

So I have moved a bunch of files into ~/etc:

• .bash_profile
• .bashrc
• .irbrc
• .subversion/
• .vim/
• .vimrc

When I moved the files, I renamed them to not include the dot in front of the name, that way the files would not be hidden.

So that everything still works correctly, I make a bunch of symlinks for the files in my etc directory to the home directory, i.e. ln -s ~/etc/bashprofile ~/.bashprofile. This is so that the configuration files work like they used to.

The Subversion Repository

By moving these files into a directory, that directory can now be put into a repository. This is the beauty of it all. Once in a repository, the etc directory can be checked out anywhere. This means that anytime I want to change a config, like a new wim setting, I can make sure that vim behaves the same no matter what machine I’m using by committing that change and then performing an update.

Because I’m using subversion, I can use properties like svn:ignore on something that I don’t want have shared between my machines. I committed etc/subversion/ because I want to share the config file located in that directory. As for all other files, I don’t want to share it. So i put an ignore of * on that directory.

You can also use svn:externals. I use Tim Pope’s rails vim file. He keeps his work in subversion, so by using the externals, I can make sure that I have his most up-to-date work at any time.

Where To Go From Here

If you keep a repository of your configuration files, you could also keep script files in there, like perhaps a script which will create all of your etc symlinks for you :). You could also keep a copy of your firefox bookmarks in sync. The sky’s the limit.

I first used CVS(Client Version System) and it does it’s job. There are somethings I wish that were easier. That’s where SVN comes in. A lot of the commands are the same. svn add or svn commit is not that much different from that of cvs add or cvs commit, unless you get to some of the other features.

svn add allows you to put a --force parameter along with your add. This will recursively add all the files for a given directory. Even if files have already been added in a given directory, those will be skipped and only the new ones will be added.

The other thing that I love is svn move file_old file_new. Finally, it’s easy to move files. No need to delete a file from the repository and add it back to the repository with a new name like in CVS. Now don’t get me wrong, if you watch the output of this SVN command, you will see that it will do something like this:

D old_fileA new_file

So what’s the difference? Isn’t this just a shortcut then really? Well, no. SVN keeps track that the newly added file is actually apart of the deleted file. And it’s not just files, directories also can be moved and copied.

Finally, there is svn resolved. So let’s say that two people have checked out some code. Person A makes some changes and submits it. Person B also has it checked out and makes some changes to the same files. SVN will attempt to merge the files if it can do it safely, which by the way has been pretty good; no complaints yet. But sometimes there are conflicts which arise when the code cannot safely be merged. So Person A commits his/her changes back to the repository. Now Person B commits his/her changes. Upon doing so, he/she should see a message something like:

C same_file

It is up to Person B to resolve this conflict because his/her code will not be able to go into the repository until that happens. SVN will create a few extra files; same_file.mine, same_file.rXX, same_file.rXY, for when you want to see what you did, what the code was like before you edited it, and what the code is like now that someone made changes to it. So Person B merges the code so that all is well in the world. All he/she has to do now is run svn resolved same_file and the conflict will be removed so that the file can now be put in the repository. The other nice thing that this does is remove those extra files that SVN created when it found the conflict.

While this is an overview, nothing beats the comprehensive list of commands