When choosing version control, I look for reliability (do things right or don’t do them at all), workflow integration (full IDE integration so I don’t need to think about version control as a separate problem when working), and the ability to work disconnected from the server.
Subversion has been reliable for me so far, and part of the reason why I chose it over some other interesting possibilities (like bzr) is that it is being used by very many other people on large scale projects much larger than my own projects. If problems arise, they will get fixed. I have had no problems with it so far that didn’t stem from not reading the documentation, so Subversion gets high scores for reliability, as expected.
IDE integration has been great, since I’ve been using eclipse and the Subclipse plugin works nicely. I have only seen one major shortcoming in Subclipse so far - it won’t let you assign eclipse shortcut keys to Subclipse functions. This is a peculiar ommission, and I wouldn’t be surprised if it is possible but I just haven’t figured out how to do it yet. Otherwise, the integration with Eclipse is fantastic. Synchronizing with the repository is actually fun.
Working disconnected with Subversion is much more functional than I would have thought at first. With SourceSafe and Perforce, I am used to doing a “Checkout” or an “Open for Edit” on files before editing them. In fact, with SourceSafe and Perforce, if you start editing a file without first asking the server if you can edit, you enter into an undefined bizarro world where nothing will work as intended. When discussing Subversion with a friend who uses only Subversion, I inquired about the ability to have a local repository so that I could check out files when not connected to the Internet. He didn’t understand the question at all - with Subversion, you can just go ahead and start editing, and the changes (including conflicting changes) are worked out later when you are reconnected.
If you get on an airplane with an up to date working copy of a repository, you can modify any file in that repository without connecting to the server, and when you reconnect, things will work as expected. Again, for Subversion users, this is obvious. For SourceSafe and Perforce users like me, this is a miracle.
Subversion also keeps a copy of the latest version from the repository, so while you are disconnected, you can still to a diff on the latest repository version. This is fantastic, as it is the most common thing I do with files under version control - oh no, I broke everything. How? Show me the version that worked, and what I changed. “svn diff” can do this without connecting to the repository, and thus can be done while disconnected.
Similarly, Subversion can tell you all of the files that have been modified locally, again without hitting the actual repository. It just checks every local file against its local head revision copy and reports back a list of the ones that have changed.
To work this magic, Subversion needs to keep a bunch of metadata on the local machine. This is a bit strange at first, coming from SourceSafe and Perforce. With those tools, there is little if any local metadata, so when you are disconnected from the server, the local client has no idea what is under version control and what is not.
With Subversion, detailed information is kept locally, telling Subversion what files are under version control, when the latest version was retrieved from the repository, a copy of that latest version - basically everything needed to browse and examine the status of the entire repository, without connecting to the server. Working disconnected is easy - the local client has all the information it needs about the structure of the repository, so it can tell you what you’ve done since you were last connected.
You can’t commit changes to the repository while disconnected (”commit” in Subversion is like submitting a changelist in Perforce or doing a Check In in SourceSafe). However, I think with a little bit of work, it would be possible to do this. First, you need to understand why I think this would be a convenient thing to do.
Version control is used to synchronize files among many different users. At the same time, it is also used to track small changes from version to version, so that when something goes wrong, you can look back in the history and narrow down the change that caused the problem, or look in the commit comments to find out why a change was made in the first place. Viewing the historical changes to a file can be life-saving on a multi-year project, and let’s face it, every 2-week project has secret ambitions to be a 10 year project.
If commits are made very frequently, then viewing differences from one revision to the next is useful. It is very easy to see what changed and why from one revision to the next. And, if a new change breaks something, there is not much to lose by reverting to the most recent revision.
On the other hand, if commits are far apart, viewing differences between two versions is not useful - there may be 100 differences, all completely unrelated. It is not obvious which changes can be reverted and which cannot, or which ones might be the cause of a problem. If a local modification is very different from the head revision from the repository, and the local version is completely broken, reverting to the repository means losing large amounts of work, so it just won’t be done.
So, to make revision control useful in this sense, it is important to be able to frequently commit changes. When working disconnected, even if I’m only disconnected for four hours, I may make 20 incremental changes and choose to commit each change once I have tested it.
Even when I am connected, I may want to “commit” small changes so that I can view the differences from one version to the next, but I may not yet be ready to expose those changes to everyone else who uses the repository. I may make a small change in preparation for a larger change, a small change that I am not ready to “commit” to and may choose to revert later, but I want to put a stake in the ground after that small change, before going on to make further changes, so that I can locally revert and compare revisions before commiting to the repository.
read more in “Proposal for Local Commit in Subversion“
0 Responses to “Using Subversion Disconnected”