You had me at delete.
It’s been a while since my last post about Subversion, and since then, I’ve actually gotten to use Subversion on a project and see how it solves various problems. Hopefully now my rants and raves will be a little more informed…
I set up Subversion on my own server, for a pretty large-scale software project that needed a significant amount of restructuring. That by itself is pushed as one of the big plusses of Subversion, and I think I have appreciated the value of that. However, something else grabbed my attention right away, the ease of using svn delete!
One of Joel Spolsky’s big UI rules is that a user interface needs to expose the same model that the user internally wants to follow, because any differences are going to lead to aggravation for the user. I have always had that problem with CVS’ delete command, because you have to go and physically delete the file from the filesystem before you can tell CVS to remove it! So, if the file you are deleting happens to have a really convoluted filename, your life just got a whole lot harder. It takes a one-step process and turns it into two steps, one of which is now a lot harder because you don’t have tab-completion to help you out anymore.
Subversion makes one simple change to this: svn delete will take care of removing the file from the filesystem for you. And that instantly made my life easier, compared to CVS. To me, that by itself is enough to make me like Subversion. Not quite enough to turn me into a rabid anti-CVS crusader, but I definitely don’t dislike Subversion anymore. (How’s that for an endorsement?)
Besides svn delete, everything else so far has mainly been different from, not necessarily better than, CVS. Here’s a bit of a rundown:
- Like I said earlier, I do like the ability to move stuff around in the repository, but
svn moveseems to suffer from a pretty big weakness: It doesn’t seem to handle moving multiple files to a single target directory. This is aggravating! If I have 20 files in one directory, and I need to move eight of them to another directory, I don’t want to typesvn moveeight times, especially if I can specify a glob pattern to select out those exact files. What gives?!CVS can handle multiple files…
- Subversion’s mechanism for specifying configuration properties is… different from… CVS. All of it is done via
svn propsetorsvn propeditcommands (there are a number of others besides those two). So, you want to tell Subversion to ignore certain files in the current directory, you have to do something like this:svn propedit svn:ignore .Honestly, I like CVS’ simple little
.cvsignorefiles better.
And I still have one major beef about Subversion, and that has to do with tagging and branching. I want to create a tag on a particular version of my codebase, so I dig into the Subversion manual for the answer. And lo and behold, the manual says, “You don’t really want a tag. What you really want to do is to make a copy of your repository, with a special name. See? They’re virtually the same! You just have to create a special directory for your tags, and …”
NO. I don’t want you to force me to fit my need into your over-generic abstraction… I want you to give me the abstraction that makes sense for my problem. Go try again.
OK I’m glad I got all of that out of my system. I’ll probably write another post when I’ve tried some things like creating tags (er, I mean, “tags”) and the like. I am having a lot of fun learning this new tool, because it’s always interesting to see how different projects solve a particular problem. I’m just a little pickier than usual because of Subversion’s marketing…
May 5th, 2006 at 10:49 pm
Donnie, if you think about it, there is nothing really “simple” about all the CVSisms you are used to — it’s just that you are used to them
For example, there is nothing simple about .cvsignore. It probably takes the same effort to track down and use .cvsignore as it does to use svn propset. The end result is the same — as soon as you develop new habits, they are equally easy.
As for tagging being a copy of the repository in subversion, that is kind of goofy, I have to admit. And the imposition of the directory structure sucked too. But after getting used to it, it is transparent. To do work on a branch or tag, you have to check out using special flags or switch your sandbox using a special command I’d have to look up to remember it. In subversion, I change to a different directory. It’s all half a dozen of one, 6 of the other in the end.
May 11th, 2006 at 10:03 am
No I completely agree with you - I am used to the CVS way of doing things, and I’m sure that biases me to some extent. In fact, Subversion is at a disadvantage because somebody just told me these things about CVS, but I had to look up the Subversion stuff myself. (Already “more work.”)
I feel like Subversion might have missed the real opportunity to contribute something revolutionary to the whole space, by really presenting a clean, powerful abstraction for branching, tagging, and merging between branches. That is always one of the most difficult problems in SCM, but most people don’t realize it because only a relatively few people grapple with it, and only on projects with an actual “maintenance phase” to the cycle. I want to rant about that too, but I want to think about how it “should be done” before I go off half-cocked…
September 15th, 2006 at 7:56 pm
I’m glad you got this “straightened out” in your head, because cheap copies are pretty much as good as it gets unless you want to have the SCM start to understand the content it maintains. That, or you change the data metaphor to something besides files and directories… or, I guess, both.
You can look at Arch and BitKeeper and a few of the alternatives to see the realm of possibility, but essentially the ultimate pain — merge — does not magically go away. Maybe some information theorist can give us something analagous to a Shannon limit for maximal merge simplicity.
February 24th, 2008 at 10:31 pm
The lack of globbing for delete sure seems like a nuisance, but xargs to the rescue…
Eg: to remove all the (uppercase) jpegs…
ls *.JPG | xargs svn rm