Hi everybody, welcome this afternoon to session 619, Subversion on Tiger, version control for the rest of us. I am not, in fact, Brian Fitzpatrick. My name is Chris Parker, I work in the Cocoa Frameworks group, and we use Subversion in some of our internal testing and things like that, but I'm just going to give a quick overview of some of the history of version control on OS X. Some of you may remember using CVS on OS X for the many releases. It was the tar-wrappered version, right, the sort of halibut version that was installed by default. The Tiger DVDs that you've got actually have the new version, 1.11 on it, which does not use tar wrappers.

But if you've ever actually tried to do a move of a file in CVS, you've probably started cursing it pretty quickly. So Subversion and Mac OS X work very well together. OS 10 builds a version almost practically out of the box, so you can build a client-side version with very little trouble and the client-server versions with not much trouble after that. And we also have very good integration with Xcode and Subversion through the SCM plugin menu, but I'm not really the guy to be telling you all about that. is, so I'm going to ask him to come up on stage, and he's actually going to tell you the rest of it. Oh, he needs this. Thanks, Chris.

Thanks everybody. Good to see everybody here today. I'm here to talk to you about Subversion, but first, since I'm not an Apple person, I'm going to go ahead and tell you a little bit about who I am. I'm a Subversion developer employed by CollabNet, who is a company funding commercial development of Subversion. And I'm also a member of the Apache Software Foundation that is growing day by day and picking up new sorts of open source projects.

I'm also a co-author of the book called Version Control with Subversion that O'Reilly is just informing they've sold out of out there in the lobby, which is great because I'm glad somebody's selling the book. It's also available free on the Subversion book website. It's the official reference documentation for Subversion, although there are now, I think, four or even five separate books for Subversion. I used to work for Apple. I worked for Apple up until about a year and a half ago, but even while I worked for Apple, I was very involved with open source, specifically Subversion. and I'm also a long time Next aficionado. So, yeah, I knew somebody, I knew I got a woohoo out of somebody for that. But let's talk a little bit about what I'm hoping you'll learn today and what we're gonna cover. We're gonna cover a lot of subversion basics. I'd like to do a quick Q and A of the room here. Who here has used subversion? Oh, this is so great, okay, thanks. And who here has used CVS as well? Okay, oh, I'm so sorry, really.

We're going to cover a lot of the basic stuff that you cover with Subversion. I'm really glad to see so many people raise their hand and use Subversion because I came last year to the open source Birds of a Feather. I don't know if anyone here was at that session. And there was a lot of people there who had heard about Subversion, but very few people had used it. And now I think we're at almost 50% of the room. So we're going to cover the basics. And we're going to talk a little bit about some of the Mac OS X specific goodies. So what are some of the things that you can help find Subversion will help you do on Mac OS X. And we're also gonna cover actually some of the things that Subversion won't help you do on Mac OS X so that those don't bite you.

We're gonna cover some Subversion tips for all you CVS users out there. So Subversion, while it's designed with CVS's development model in mind, as well as mirroring CVS's commands to a great extent, Subversion does not, however, map one-to-one with CVS. There are some small little gotchas that we're gonna hopefully touch on.

But first, a few important Subversion tips. For those of you, if anyone here has used a locking model, or a lock, modify, unlock version control system, Subversion uses the copy, modify, merge model. Those of you who know CVS are familiar with that. It's sort of a melee type of situation.

Everybody modifies a file, and as long as the version control system can figure out who changed what, and there's no conflicts, it'll merge it all in, and everybody's sort of happy. And the mechanism you use for determining who's working on something is human-to-human communication, as opposed to you locking a file and going on vacation and someone else having to, you know, call the administrator to unlock it. However, Subversion 1.2, which just fresh out the door about two weeks ago, now supports file locking, also known as reserved checkouts, which is a great thing to use on those Xcode project files, perhaps maybe some of your JPEGs or binaries or that sort of thing.

So another thing, and this is aimed specifically at you CVS users out there, is that instead of file-based revision numbers, Subversion has repository-wide revision numbers. I think this takes a little bit getting used to because you have the one file over here that you've only edited once and its revision number is 8,917. That doesn't mean it's changed 8,917 times, it just means that that's the repository number. There's a lot of advantages to that too and maybe I'll touch on some of those later on. Lastly, SVN Help is your friend. SVN Help is not an IQ test like CVS Help was.

CVS help was just a fantastic utility. In fact, I had to run CVS help to figure out how to use CVS help to find out what the command was to do something. So SVN help is a lot friendlier and a lot easier to use. And it's good to remember because it's obviously always there at your fingertips.

Now, I do want to touch on a couple of caveats of using subversion on Mac OS X because we've got some special stuff going on in Mac OS X that's different from the way other people do things. For starters, subversion does not recognize resource forks, and the likelihood of it beginning to recognize resource forks is somewhat slim considering that the official Apple position on resource forks is that they are deprecated and you should stop using them. However, Apple still ships the res and the derez utilities in your slash developer directory, And you can use res and derez to pull resource forks out into a data fork and commit those data forks to your Subversion repository.

Subversion also does not support extended attributes. So I don't know if you can read that on the screen, but it says don't put.underscore files in a Subversion. If you're using UFS and the resource forks pull out a.underscore file, You don't want to be tricky and check that into Subversion because when you get on an HFS file system and you try and check something out, Subversion's going to freak out because Mac OS X's going to handle that file for you in some way or another. So you can use SVN ignore to tell Subversion to ignore those files. Subversion also does not support spotlight metadata. However, fear not, because there's no planned support for any of these features in the near future. However, extended file system attributes, cause extended attributes are definitely something that people are interested in seeing and we may see that feature somewhere down the line in Subversion. No promises, of course. So some tools that use bundle directories can be troublesome, as we all know. The following applications, thankfully, manage your Subversion directories for you. We have Interface Builder, thanks to the Interface Builder team. With Keynote 2, now, you know, I just found this out when I got here on Monday and it would have been a great thing to know like three weeks ago when I started working on my presentation, because Keynote 1 happily ate your.svn directories. Now we have other applications like WebObjectsBuilder and EOModeler that gladly and gleefully eat your.svn directories, although they do know how to deal with CVS directories.

EOModeler, however, has a plug-in, which you can find somewhere on the Internet. TextEditRTFD files also, directories, or bundled directories, do not deal with.svn directories. So what are we going to cover here? We're going to do a brief overview of Subversion itself. Like I said, I'll talk a little bit about the history of Subversion, but I'm glad that nowadays that Subversion is getting much more mainstream. I have very little of the history of Subversion to cover. And what is this Subversion thing?

Why are we doing it? Why haven't you hit 1.0 yet in three years? We'll talk about how to create a repository. It's very straightforward. We'll talk about importing a project. So putting a new project that you don't have version control on something you maybe have been working on for a while.

Working with Subversion. Now this is the part we're going to concentrate on more, it's the daily work cycle. Which is where you come in in the morning, you update, you modify files, and you delete, and that sort of thing. We're also going to cover working with a static website. So a lot of people have talked, use Subversion for source code, and what we're going to do is an example of taking a small website you might have of static pages, or it could be, you know, PHP documents, that sort of thing, PHP scripts, and put those in Subversion. Lastly, using Subversion in OS config directory. We're going to talk a little bit about it. We have an example where we'll show you how to put your Etsy under version control without blowing your machine to bits.

And once I'm done with that, Chris is going to get back up and cover a little bit of Subversion's Xcode integration. Now, this is a hands-on presentation, so don't hesitate to raise your hand and wave at me if I get stuck here. While I'm going through what we're doing here, Fred's going to step up and sort of go through the same hands-on type of things that some of you who have your laptops out and are not surfing the web will be doing.

So let's do just a very quick review. I've got a couple slides here about Subversion itself. Subversion's mission statement, which we came up with back in 2000, very simple, compelling replacement for CVS in the open source community. Well, done. I'm so happy to get up here and say that's done, instead of saying it's coming soon. Not only has it been a compelling replacement, but Subversion's turned out to be way more successful than we ever expected. We're shooting to provide a compelling replacement, but now that we have, we really didn't know what we were going to do about it. Public subversion DAV servers. This is one of my favorite little statistics. There's a website out there called Security Space that monitors Apache modules across the internet, sort of like the NetCraft version of Apache modules. In February of 2004, 1,307 subversion servers existed, and I use this date in particular because that is the date subversion hit 1.0. Since then, we've seen a lot more subversion DAV servers there. Now mind you this is only DAV servers and there's another network way to access your subversion repository which we'll talk about in a bit. And I'm very happy to see this number. This also doesn't include anything behind the firewall. Local repositories people use. So what this tells me is that subversion is catching on pretty well.

So now what are we going to do? This is, we didn't have any exit strategy. We sort of subverted CVS and people are switching over from CVS every day. Our goal now is to develop new features to make it even more compelling. We've worked on, we just finished locking feature, which is something a lot of people have been asking for. A lot of the poor souls, poor, poor souls who are stuck using Visual Source Safe have gladly come over to Subversion. And, thank you.

I paid that guy five bucks. Log message templates is actually one of the very few CVS features that we do not have, but we're working on that right now. We're working on doing it right. Atomic renames. Subversion provides rename capabilities. Copy, move, that sort of thing, but it's not done in an atomic fashion, which gives you a little bit of difficulty when doing some sophisticated merges. So we're trying to improve that. And lastly is sophisticated merge tracking. Subversion branching and merging is already miles ahead of what you had to do with CVS. In fact, I know many people who never branched in CVS because it was too painful. I know several people who copied their whole repository to a separate repository rather than having to figure out how to do a branch in CVS.

We're also helping developers doing tool integration. Now, as Chris mentioned earlier, Xcode supports subversion, and I'm very happy to say that Apple is the very first third-party IDE that claimed full subversion support. So that's been a real huge win, I think, for Mac developers. And lastly, we're continuing to fix bugs. Obviously, there are things in subversion that need to be fixed and improved upon. And we're working on performance, scalability, and reliability. Subversion is faster than CVS in a lot of areas, but it's slower than CVS in other areas, and that has to do with subversion, because subversion's doing so much more than CVS was doing. We're remembering a whole lot of things that CVS just gladly forgot. So, if you're gonna follow along, we're gonna get started now, and Fred's gonna come up here and drive the sort of demo server.

along with us and we're gonna get set up. So if you've got your laptop and you're planning on drawing along on the hands-on part of this, if not, you can just sing along with everyone else, you know. So you should have downloaded the 6/19th subversion tar.gz file from redbeat.com on my website. If you have not done that, I don't know that you'll be able to do it now, so you may want to pull up next to someone else. If you can double-click that, the Finder and Tiger will gladly unwrap that for you and you're gonna want to move that folder into your home folder. And I'm being very specific about where I want these things placed because our examples and demos are going to give you very specific commands to go through.

And we're using the command line version of Subversion because that's what comes with it. That's the most popular version of it. There is a Finder plugin called scplugin which is does not, I don't believe it's yet been ported to Tiger but I know that the guys are working on it. And as I said also Xcode supports Subversion. But Xcode Subversion support is really aimed at the daily work cycle, which again we'll cover in a bit. So you've moved that to your home folder, and you should already have Subversion installed. If you don't have Subversion installed, that's probably not going to be something you have time for, so you're going to want to follow along with someone else who's installed Subversion. So not like you can move around a lot here, but just pretend like you're following along. Make sure that the SVN binaries are in your path. Now Subversion doesn't ship with just one binary. Like CVS, everything was in CVS. It was a client, it was a server. And if you ever tried to debug CVS, I'm really sorry because I've had to do that. And it's one of the most painful things I've ever done. It makes Windows development look like a joy.

So this is a little, one of your first commands here is, if you're using bash, you're going to want to use export to attack the subversion path. Now, use your local subversion bin is the path that came, that subversion's installed in. If you downloaded the zip file for one, two, off of my website. Now can I just see a quick show of hands, who downloaded that zip file? Okay, all you guys who downloaded that zip file, it says subversion 1.2, but I found out actually after I put it up there that it's not 1.2, it's a release candidate. So if you run svn --version, and you see the word RC2 in there somewhere, be wary that this is something you can use for this, and it's not gonna like, you know, eat up anything, but there's some incompatible changes from our release candidate to the actual 1.2 release. So I'm sorry to say that once you start using it for real production that you should upgrade to the real release version. And there's several different places in the internet where you can grab that.

So, we've got our path set up, Subversion's in there. The first thing we're gonna do is create a new repository that we're gonna work in today. We're only gonna create one repository. Now Subversion, as of 1.1, has two different repository backends where we store our, your data. The first is the Berkeley database backend, and the second one is called FSFS. Berkeley database uses Berkeley database files. FSFS uses just flat file system files. There's no dependencies on any sort of database software. It works fine over NFS as well as your local disk. Now I recommend FSFS on Mac OS X for one reason, that reason is because, actually for two reasons. The first reason is that we've had some problems earlier when version first hit 1.0 with Berkeley DB stability on Mac OS X. Some people had some corrupted repositories. Secondly is that the FSFS implementation is the default as of version 1.2. So it's much simpler, there's less moving parts, it's just got flat files and it's easier to rsync and backup and that sort of thing. So, choose your repository access method is the next thing you have to decide to do after you've created your repository. Which, we're gonna use the local repository access method. And so now we're just gonna go ahead and create it. Use the svn admin command.

which, and you use this create sub command. SVN admin does a whole bunch of different things to your repository. If you run SVN admin help, that will tell you all the different things you need to know. Now, one important distinction that you're running too quickly is that Subversion itself operates on working copy or a URL. If you want to talk to the repository, you can give it a URL, HTTP colon something, file colon something, SVN colon. If you work with SVN admin, it only deals with paths. It's a very common gotcha. People try to feed a URL to SVN admin It freaks out.

Now there's three access methods for subversion. And we started off with a DAV method. But then someone who liked the CVS P server model wrote SVN serve, which you can run as a daemon. And it will also do authentication through SVN serve. Or you can run it over SSH, which is very similar to the EXT method that you're probably familiar with from using CVS.

There's local access, which is if you have a repository on a local disk. Now, some people say, well, can I put a repository on an NFS mount and have everybody mount that and use that? You can, but just because you can, I really wouldn't recommend it. We've got two different network remote layers to use, and local access should really be used for local only access unless necessary. Lastly, there's HTTP access, which is the main remote repository layer that we use. We don't really prefer one or the other, but a lot of different projects, large-scale projects, the Apache Software Foundation, for example, obviously uses the HTTP access because it uses Apache HTTP server.

And that operates over DAV. Now, one of the hugest wins we got by using HTTP access is that you can access your repository from the finder. This is one of my favorite things. You can, and not everybody at once, you can mount the Subversion repository itself at svn.collab.net on your finder. and you can browse all the source code in your finder. You can browse all the tags, you can browse all the branches and all the different releases of Subversion without ever checking it out. So it's a good way to sort of browse without using a web interface. It's sort of a nice, it's a nice win. Now, one thing that's new with Subversion 1.2 is a thing called auto-versioning, where you can not only read your repository through the finder, but you can commit to it through the finder just by opening a file and making some changes and saving it.

Thank you. I didn't actually do that, but thanks. The really nice win about that is you get people who aren't familiar with version control or don't want to deal with it, that sort of thing. You just point your browser at this and save your files over here. You have a designer who's not interested in dealing with version control, wants to drop some JPEGs in or HTML files or whatever or not. The one caveat with that is that the way the finder talks to the file system is kind of chatty. And the finder doesn't know it's talking to a version control server. So one drag file into your Subversion repository is gonna result in like six, seven, eight commits 'cause of the way the finder handles things. So it's a little inefficient from a space point of view. But again, it's still a huge win.

So importing and getting to work. So we've created our repository. Now let's stuff something into it. Now we're going to start off by importing a project and then check out a working copy. And you can also update an existing working copy. This is part of your daily cycle, like I said. Check out is something you do infrequently. In subversion, it's a little slower than CVS. It's a fair bit slower than CVS, but it's not something that you should be doing every day. I know people that do come in every morning and check out a new working copy with CVS. That's mostly because they're afraid that CVS is going to eat their project. Fear not, subversion will not eat your project. Importing. So you choose a directory that you want to import and run the command.

Now, in your 6.19 subversion directory, we've put a little sample directory in there that's got some files in it, and you can go ahead now and import that. Now, for those of you who feared CVS import, and, you know, that's me, I would go through crazy things to not have to CVS import because I never could remember the syntax for it. So version import is very straightforward. You give it the path you want to import, and you tell it where to put it in the repository. And you can even put it in a parent directory. There's different options you can pass along to it.

So, now we want to check out our working copy. And actually, do you want to back up? Do you want to show them your import? Did you already import that? - Yep. - Okay. So, is your screen not cleared yet? Let's switch to demo two for a second here. Let's show what Fred's import went ahead and did. You can see that subversion tells you of all the different files that it went ahead and added to the repository. Okay, if we could switch back to the slides.

Thanks. Now we're gonna go ahead and check out our working copy. Since this is our sort of first start in this project. We're gonna use local access, so we're not gonna set up SVN server, Apache HTTP server, there's really not time for that today. And this is a project you're working on yourself, so we're gonna check it out. Notice you're giving it a URL, and we're cheating here, we're using your dollar sign home variable. What's that? Did you see something? Okay, we're using your dollar sign home environment variable, and we're taking SVN repos, and we're putting it in a working directory called svnwc. So if you go ahead and check that out and you do an ls to that directory, you'll see there's a single directory in there called sample.

So that brings us to the basic work cycle. Now this is what you're going to be doing with Subversion 90% of the time. 90% of the time is not import. It's not checkout. It's update, diff, add file, remove file, that sort of thing. So you start off your day. So the basic work cycle, you come into the office, you update your working copy, you go out to get a cup of coffee. You come back, you make changes to your project. You add files, you delete files, you add directories. It's subversion. You copy files, directories, move them around, that sort of thing. You examine what you've done, and then before you commit and send your changes to the repository, you're going to want to take a look at what other people have done. So you merge other people's changes into your working copy, check everything out, make sure it still works. I mean, you really want to make sure that, and you might want to bill in case someone's changed some files that you're working on. And then lastly, you commit your changes to the repository for other developers. Now, some people make this work cycle a day-long work cycle. Some people update in the morning, and they don't commit anything at the end of the day. Some people don't commit anything to the end of the week. For best practice with subversion, we recommend you choose a small granularity for your work cycle. Choose a particular feature, a particular bug fix, or that sort of thing, and roll through this work cycle frequently during the day. It seems a little onerous at first, but it's something that you definitely get used to pretty quickly, and Subversion is optimized speed-wise for these sort of operations and tries to do as much as it can without going over the network. Thank you.

So we got our working copy, we checked it out, now we're gonna update our working copy. We're gonna bring changes from other developers in. Now, right now, so we see the end of the working copy, and we're gonna run the update command, and it says you're at revision one, nothing's happened, there's no one else working on this project. So it's pretty straightforward at this point, no surprises.

So then we're gonna go ahead and make changes. Now it's a version, you're obviously gonna edit files, you're gonna add and delete files or directories, and when you delete a directory, it goes away. Now it's like CVS where the directory just keeps coming back, it's like, you know, the directory that just wouldn't die. You can also move and copy files and directories.

And remember to use the Subversion command line client, or some Subversion client, when moving or copying things. If you use the Finder, or if you just use Unix CP or Move to move things around, Subversion is going to get confused. It's not going to know what happened. So you definitely want to remember to let Subversion know to do this. So it will take a little bit of a change to do that, changing your developing patterns. So here, for example, we're going to start off removing the file afile.txt to foo.txt. Thank you.

and which is moving a file, which is great. We're going to copy images to photos. And I look forward to the day where I'm not walking around here going, "God, this is so cool, I can move a file." You're gonna copy the images directory to the photos directory. So we're gonna wind up with two directories there.

And I used open command here, 'cause another file.txt, that'll pop open text edit, or whatever you have on to that, to that mime type. So open up another file.txt, and you'll make some sort of change and save it. Now, I'm saying this again for CVS people, don't forget you can move and copy things. I have sat in day-long meetings determining how a product's going to be laid out before importing it because you can't move things. It really is the kind of thing where you're -- it took me quite a while to get used to the fact that I could move things, you know. Eventually you get all cavalier and you're like, "Oh, just move this over here and then over there," and you wind up rearranging your project. People who do development where you're constantly refactoring, this is a huge win.

So we've made some changes, now we're going to examine those changes. Again, like I said, review what you've done before committing. View the files and directories that have changed. So here we run the SVN status command. It puts out one line per file that's modified or changed. Notice it only shows you interesting files. You can pass the verbose option to subversion status, and it will show you every file. You can also tell it to be non-recursive.

There's a bunch of other options that SVN help will tell you about. But for starters here, you can see that we have foo.txt, which is added, as photos, which is also added. Now photos is a copy from the images director as we know, and foo.txt is a move from afile. So you can see afile.txt has been deleted, and foo.txt has been, is added. So the little plus signs mean that this has some sort of history. Subversion's gonna remember where these things came from. It's gonna remember where they came from when you run subversion log on them. And lastly, another file.txt isn't terribly interesting, it's just been modified. So again, for CVS users, Stop using the update command to see what's changed in your working copy. SVN status does not change your working copy. It does not contact the server. It uses data that's stored in your.svn directories to figure out what's going on. So it's the kind of thing you can run without network access. Thank you.

So we're going to also view the contents that you've changed. So you've seen the files. Maybe you've made changes to the structure of your project. But what if you changed files? So svndiff, by default, outputs what's called unified diff format. Now, if you look here, the very first file has a minus one line that's been deleted. That's the file, afile.txt, that's been removed.

Or actually, it's been renamed to foo.txt, I believe. And then we see another file.txt that has one line that's been modified. We change that. It says this is a sample file, eek, instead of boo. So that's what svndiff will give you the changes. Now svndiff is not going to show you changes to binary files, but it will say that a file is changed with binary content. Now I use the word merge here because, although we're not actually running the merge command, which Subversion does have one, but you're going to pull changes from the repository into your working copy. Undoubtedly, if you're working on a busy project with a larger team, you're going to have other people making changes and committing them throughout the day. So this will pull any other changes from the repository into your working copy. Now you can get a preview of what the update command will do by running status with -u. Unlike running straight SVN status, -u will make a trip to the server because it's going to find out what files will be updated and it will mark those accordingly in the status output. So again, we're working on this big exciting project here all by ourselves on our laptop, update, and we got nothing. So we're still at revision one.

So now we're ready to go ahead and commit. Write a log message. Now, this seems kind of silly. A lot of people will just, you know, provide an empty log message. But if you're working by yourself, that's fine. You can probably remember what you're up to. But if you're working with teams, a team, I do highly recommend coming up with a log message policy and convincing people to stick to it. The Subversion Project has over 50 developers from across the world, and they're all, aside from myself and my colleagues at CollabNet, they're all volunteers. None of them are paid to work on Subversion full-time. and they follow a crazy amount of rules for log messages. They put the file name in the log messages, the function name they've changed, any sort of variable they've changed, that sort of thing. And this sort of thing helps when you're trying to find out information about what changes happen when and why. So now commit's going to send your changes to the repository. So if you run the commit command and you give it a little message with the dash M flag, you can also tell it to use a file as a message, or if you don't pass a message at all, will pop up your editor of choice on the command line, which would be set to, yeah, emacs or something like that. You can also use subeth, I believe, has a binary you can set to be your little editor, default editor from Unix. So remember that in subversion for your CVS users, commits are atomic. If you ever had a commit of 30 files going and your network dropped and half of it gets in and half of it doesn't and you've broken the build and that sort of thing, This is going to be a huge relief. It's pretty much all or nothing. There's no other part to that.

Any questions so far? Is anyone lost? Is anyone following along here? Everyone? Okay. So other subversion commands we've got. We have a number of others. Subversion has many commands. We've done our best to keep the command set small in subversion. The more commands we have, the more difficult it's going to be for people to learn and use. And I know it's a command line application.

It's not some sort of beautiful Cocoa app or anything like that. But we do put some effort into the UI of our command line binary. One thing I will point out is that options can go anywhere in the line. In CVS they had global options that went before the command and local options that went after the command and -d meant one thing under one command and another thing under another.

We don't do that anymore. An option is global period the end. So let's start talking about svn revert. Now this is a great little helpful command. It discards any changes that you've made in your working copy and goes back to the base revision of a file. Now I'm very specific on saying base revision and I'll go through this example and explain why. For example, here we're gonna cat the mati file into our file foo.txt. Okay?

Can we switch to demo two now? Actually, I'll go ahead and let Fred show this live. Can you make that a little bigger? Thank you. Anybody read that? Okay, so Fred's gone ahead and tossed that into there. So now you take a diff, and you can see that he's changed the file. So if you want to go ahead and get rid of your changes, you're going to run svn revert. Thank you.

and you have to provide the file name. It does not, by default, choose a path, choose your dot as path, your current directory. It does not, by default, act recursively. It knows that it can blow away data that you've made, local data that you've made, so that that command is very careful about it. As you can see with diff, nothing happens here. You can go back to the slides now. Now, one thing I want to point out about SVN revert, CVS revert consists of two commands, as you all know, which is delete the file and then run CVS up. Now the big problem with doing that, and it's a habit you might go ahead and continue to do while you're in Subversion, the big problem with doing that is that you might not get the same version of the file you had in your working copy.

Your working copy has a revision we refer to as the base revision of your working copy, and when you update, you're going to get the head revision of the server unless you specifically tell it to give you a different one. So revert the file instead of deleting it and update it. It's hard to remember these little sort of things at first, I think. So SVN resolve, CVS, when you've got a conflict in a local file, you'd have to go ahead and fix the conflict markers and get rid of it and try and remember which part of it was yours and which part of it was not. Subversion resolve not only will tell subversion you've fixed the conflict, but it will also remove any temporary files that were created. So here we have a file, foo.txt is a conflict. Obviously this isn't something you can sort of play along with here because you're working by yourself, but in this scenario, the foo.txt file has a conflict. So what Subversion does is it creates three new files. One is the original file, foo.txt, which has all the funny little greater than, less than conflict markers in it. And then the next file is.mine, which is the file you were working on just now. And then it has the base revision of your working directory. And then it also has the revision that it just pulled down from the repository. So you can feed those files to an external program. You can feed it to FileMerge or whatever, and look at what happened and go ahead and make your changes. If you're really feeling cavalier, you can copy.mine back to foo.txt and blow away somebody else's changes. I recommend being careful doing that because if your coworkers are dangerous or carry heavy weaponry, you might get hurt. So once you've gone ahead and figured out what you can do with your conflict, you run the svnresolved command. And on the file, again, this requires a specific path. So there we go. it got rid of all of our extra files. SvnInfo file, now SvnInfo corresponds pretty closely to CVS status. You get a lot of info about a file. Again, this command does not go over the network. It does, it deals straight with the working copy directory metadata, and it tells you all sorts of info, which I'm not gonna go into depth, but you know, go ahead and, I'll let you do that at home for fun, you know, tonight. Manipulating and viewing properties.

So subversion is a concept of properties, which is file metadata. Think extended attributes, but it's not really extended attributes. And it allows you to set those attributes in any way using any of these commands, as well as retrieve them back from the repository. Now, the great thing about these properties is that there are properties that Subversion uses internally, as if you can ignore, to tell Subversion what to ignore, file patterns to ignore in a directory. Subversion, you can also use it to tell Subversion to set the end-of-line style if you're working cross-platform with people. You can tell Subversion to expand keywords in a file. Subversion doesn't do any of that by default because it's not going to munch up your data. So manipulating properties. PropSet, PropEdit, and PropDel are the way you can manipulate properties. So if you want to set a property, for example, the MIME type property. Now, as we talked earlier, you can serve your Subversion repository through DAV. Now, if you drop an HTML file into your repository and then you go and you look at it in Safari, it's going to be served up as text and you're looking at HTML tags. However, if you set the MIME type of an HTML file, in this case a JPEG, then Subversion will happily set that as it feeds it out to-- through the web server.

So, now another thing you can use is prop edit, which is the kind of, prop edit's what you want to use if you're going to edit a multiple line property like SVN ignore, which is a new line separated list of patterns of files you're going to ignore. So in my case, I used Emacs here, and it waits for it, and then it was done and it says it set a new value. So we can take a look at what that value, SVN diff is going to show you the differences in the properties, and then SVN status will show you that the status has been changed. Are you ready for that, Fred? Can we go back to demo two here? Just take a peek at what Fred's got there.

Okay, notice it shows you up here that you've got the new properties, the property set, property changes on dot. It's set your ignore, as Fred said, it's a star, tilde, I believe. And we also have the new mime type image JPEG on the other file. Back to the slide, please.

So you can manipulate properties. You can also manipulate revision properties. Now this is an interesting concept. Properties correspond in Subversion to files or directories. However, Subversion also ties properties to a revision. Every revision gets an author, which is the person who made the revision, and it also gets a log message. And there's some other things, I believe date and whatnot. But these are non-version properties tied to revision, and they can be changed by using the --revprop option to SVN prop set, or prop edit as well. Now here, for example, running --revprop, and I say, "Please change the revision property SVN log on revision one," and change it to the words "new file." Unfortunately, actually not unfortunately, very carefully, that is not enabled by default. So by default, Subversion does not allow you to change this revision property data because it's not in version data, and it's a repository administrator's decision whether or not they want to change that. So, however, Subversion even tells you how to go ahead and change that, so it's pretty easy for your administrator to do that. And that's, you can find out in the book how to do that pretty easily. So viewing properties, if you want to look at properties or examine properties on a file or directory, you can use prop get or prop list. Prop get, here for example, we say prop get svnmime type foo.jpg and it returns, big surprise here, image/jpg.

If we run prop list on an S, on, and we say I wanna see the Sfinignore, prop list also will show you that sort of thing. Prop get will also show you that as well. So there's other commands that I'm not gonna go over here. I just wanna, I do wanna take a quick peek here at them. We have svncat, which is for concatenating a file. Cleanup, which is to clean up your working copy.

Your working copy's got a whole lot more stuff going on. It journals every command it does, it's going to do before it actually does it to make sure that it doesn't lose any information and keep your working copy in a sane state. Again, Subversion does its best to be atomic, both in the client and server. Export is pretty much what you'd expect. exports a file, list is a way of looking at, of browsing a directory without actually checking it out.

Lock, unlock, or do you know the locking stuff, SVN merge. So these are some of the other commands. There's still, there's other sub commands and there's other options and whatnot, but you can, and you can find out what those are, but I just sort of wanted to point out that there's still other stuff that we're gonna skip across here so we can get on a little more hands-on information. So, using Subversion for a website.

There's a number of different ways you can publish your website if you want to put it in Subversion. Now, typically here I'm talking about a website, a static collection of pages, or PHP scripts, or CGI scripts, or that sort of thing. I'm not talking about web applications or web objects or stuff like that.

You're going to put these files in there, and you're going to then serve them off your web server. So one way to do it is you just put a Subversion working copy in Document Reader of your web server, and you go in there and you run SVN update every once in a while, and it pulls changes in the repository and then serves them up. Excuse me.

Another way of doing it is to use a post commit hook to update a working copy on your web server. However, your repository and website have to be on the same machine, the same server to do that, or at least have access to the same file system. So that's sort of an automatic way. So you make a change and boom, immediately it goes live to your website.

You can also, if your web server's in another machine, have it occasionally pull the repository for updates. Maybe you have a cron job that runs every hour that updates the working copy. It's working copy based on what you've committed to the server. Or, lastly, and this is, you know, if you're feeling cavalier, you can serve your site right from your server version repository. You need to make sure your MIME types are set properly on your files, and it also does require that you use HTTP server and not SVN serve.

And, again, this is only a static site only. if you serve your site from subversion, you can't serve PHP scripts from your subversion repository and expect PHP to parse them and hand them off to the users. What you're going to get out of that is just raw PHP scripts. So that's sort of a shortcoming of the way that the Apache modules are laid out.

So inside your lovely sample tarball, there's a dump file. It's named website.dump in this SVN dump files directory. And we're going to go ahead and load it into a Subversion repository and take a look at how the MIME types are set in that. So this is an example. What I've used here is Subversion's website itself. So you've got a copy of Subversion's terribly exciting website on your laptop there. And what that is is a Subversion dump file. Subversion dump files are a way of exporting your Subversion repository from the repository into a flat file format that you can then load into another repository. So if you're going to transition from, let's say, Berkeley database on G5 processor to Berkeley database on an Intel processor, you would want to dump your repository and then load it into the new repository, the new machine. If you're using FSFS, there's no cross-platform issues to deal with there. It's also, so version dump is a great thing to use for, the dump is a good way to back up your repository, that sort of thing. So, we go ahead and run this, and it's going to start adding stuff, and doing all these sort of things, and then we can go in our work and copy and update, and we'll go ahead and see that.

And then by doing prop list, once we're back in the working copy, you can take a look at all the different things. So let's switch over to demo two and see what Fred's got. Are you keeping up with me here? Yeah. Yeah. So you can see all the A's there. Right up there. Here's the update and the working copy. And then here comes typo.

There's all the properties. So you can see everything's got its property set. PNGs are set right. EOL style, you might see on one of those. It's patch.txt in there. There's a EOL style set to native so that it comes with the proper end-of-line markers for Windows and Unix. Okay, we can go back to slides. Thanks, Fred.

So managing OS config files, that's managing a website. Like I said, it's nothing exciting, but it's good to know a few tips about it. But managing OS config files is kind of a neat thing. When we wrote the Subversion book, all the authors would hang out in the Subversion users IRC channel, and we wrote the book based on questions people asked and approaches that people took to dealing with Subversion, to learning Subversion, that sort of thing. Now the one problem that we ran into frequently was that some user would come in and be like, "You know, I went to my machine and I wanted to put 'etsy' in subversion and I moved it aside and I tried to check it out and, you know, next thing you know their machine is booted." So there's a couple of different tricks that you can use with subversion. First of all, it's definitely possible, but you're going to want to be careful. You don't want to blow your Etsy directory away and you certainly don't want to make your machine unbootable.

So what you're gonna do here, we'll do a quick review of what we're gonna do. We're gonna add a directory to your Subversion repository. We're gonna check out the empty directory. And then we're gonna take the.svn directory inside of that directory and move it into your config directory, which is in this case, etsy.

We're not going to put it in your real Etsy directory. I want to say that. So please don't get ahead of me here. This is just a demo. You're going to run SVN status, and then you're going to see magic happens, basically. So then once you've done that, you can go ahead and add files and directories that you want to manage under version control and just ignore the rest. So we'll start one step at a time here and go ahead and do this. So you start off by adding a new directory to your subversion repository, and then you're going to check it out. I'm doing this here, we have the svn make dir command to create a new directory, and I'm specifically using the file:/usrl. Notice that I'm creating a directory on the repository with no, in the repository, without a working copy. You have to pass a log message to this because you're actually changing the repository. There's no two steps, there's no make directory, then commit, this is a one step, sends everything in.

So once we do that, then we're going to go ahead and check this out into a new directory in our home. And this is a temporary checkout. So you could check it in a temp or whatever or not. But we're going to check it in our home directory slash SVN ETC. Thank you.

Now we cheat. We move the.svn directory over into your configuration directory. Now, I've given you a dummy Etsy directory in the 619 subversion directory. So if you go ahead and move the.svn directory into there, You run SVN status and you're gonna see all sorts of crazy stuff. So if we can switch over to demo.

I did the wrong move, sorry. You didn't put that in your real Etsy directory, did you Fred? Wanna try it again? Yeah. Okay, so let's go back here. Let's watch Fred struggle here for a minute. I don't have any jokes prepared or anything, so I don't know that I can cover for you.

Fred switched into the fake Etsy directory and he's going to run status. Now you see just a bajillion different question marks. Those sort of apply to every file and directory in Etsy. So you can, at your leisure, add files and directories to version control. You're working in your live Etsy directory. Again, you're going to want to be careful when you're in there just as you'd be careful while you're in there as well. Now, if you have a server that you're sharing with different users, Subversion has a dash-dash username switch that you can pass to it. So if you have different people operating on files in Etsy as root, you get to tell them to remember to use the --username switch so that they can commit things as their own username and pass their own-- obviously, their own credentials.

So as you can see, Fred went ahead and added Etsy print cap and FTP users, and now he's going to write a quick log message for some of the changes that he's made. And notice he's using, he didn't pass a log message in the command line, so it popped up in editor form. - That was prop edit. - That was a prop edit?

Okay, well go ahead and commit it then. - So you don't necessarily wanna check in your host key file, so like this is an example of something you might wanna add to your ignore if you're doing that here, or you know, if it's files. That kind of thing. So now when I do SVN status... the SSH host key files, the pub key's there, but the private keys are not showing up as something that I want to check in for you. Excellent. And now, if you're really crazy like myself, you can put your home directory under version control.

It's, I've never had to do so much pruning and cleaning up in my life before I did it. If we could switch back to slides. But the one nice thing that that gets you is you get a new machine and you're set up in no time flat. All you gotta do is check out your home directory and kind of move it into place, log in again, and you've basically got your whole environment you've come to expect. And in addition, you've got your home directory backed up on your server somewhere, which you're also backing up, right?

So now I'm going to hand over the demo here to Chris Parker to talk a little bit about using subversion in Xcode. And then hopefully we'll finish up a couple minutes early because for these sort of hands-on sessions with subversion, I tend to see a lot more Q&A than usual, so we'll have plenty of time for Q&A.

So if we could have demo two up here, I guess. So I've opened up the sample app Xcode project that Fitz put in your-- tarball there. And the first place to look here in Xcode, if you haven't already turned on the SCM stuff, is to look in the project info tab here where it says general. And down here where it says enable SCM, you'll have which SCM system you're going to use. In this case, we're using subversion.

And you may, if you've configured things differently, you may have to edit the path here to the subversion binary. In this case, it's installed here on Fred's machine at that location. So once you've got that set up and enabled, all of the SCM operations that are available here in the menu work with subversion.

So we can take a look at, for instance, a file here like maincontroller.m. And if we ask it to get SCM info here, we'll see that we've got the revision numbers down here on the left, the authors who committed the files in the middle here, what date it happened on, and the message. And there's even more information down here about, well it's actually the same information about the file names and things like that. So this is a good graphical way just to be able to see a whole list of all the changes that have happened. We can also take a look at maincontroller.m itself and when it's up or when it's selected in the project thing, everybody's probably done this, right? One of the options you can do is update to latest. you can compare with different revisions. But one of the things you use get annotations for, CVS has this command called svn annotate, right? Which shows you that whole list of things. Let's be honest, who's actually ever looked at that and said, "Hey, I wanna know who wrote that really nifty "bit of code, you're really interested in the guy "who broke the build last night."

So when you check out get annotations for latest, you can see that for this file, we've got the revision number down here, the author down the side here, and then the lines of the text. And I can look at, for instance, this NS log that fits as left in the file that says clearing count field. Oh gee, let's get rid of that because we don't want to put that in production code. So we'll go back to the main controller.msource file here. We can just select it and delete the file. And now we can do things as soon as we've saved it and say, compare with, that should say latest, but let's see.

We can update the entire project and compare with latest. And this actually launches Xcode and goes ahead and does a comparison and oh look, we see that in the old version, it's got the log in it, but in the new version, it doesn't. So now we've verified that that is actually the change we wanna make. And I can actually say from the SCM menu here, commit changes. And it pops down a little sheet where I can type the log message. So instead of firing stuff up from the command line client, I can do this. So remove log from fits. Oops. spell his name right.

And when I commit it, the SCM information is updated. And now if I look at things like the SCM info, I see that, well, I'm actually Fred committing this. So when somebody looks back and finds out who broke the bill, it'll look like it was Fred. But we removed the log from FITS, and then we can also take a look at the annotations, and we'll see that, you know, that line that was there is gone, and it looks like this is all my file again now.

So there are a lot of other features here, but mostly the things that are in the SCM menu in Xcode deal with the day-to-day things, right? So tagging and branching and stuff like that are things that you'll probably do with a command line client unless new menu options show up here in Xcode at some point.

But this is mainly the copy, modify, merge kind of stuff. You check something out, you work on it, you commit it back up, and that lets you update the entire project with all your stuff. So for your basic workflow, you can stay in Xcode for a lot of the things that you're gonna do day in and day out. And for a lot of our internal testing projects and stuff like that, we actually use this here at work. So, and that's it. If we could get the slides back here and, okay. Fred has the clicker. - Howdy, what's up? Thanks, Chris.

I hope you all found that to be productive and useful for you. Some five years ago, I got this document via an email. It was written by a fellow named Carl Fogel out in Chicago, and it was talking about a new revision control system at the time called Inversion, and it had a whole list of all the things that it was going to solve and what problems it was going to address specifically, and I nearly cried because every single thing that I hated about CVS, And I managed CVS for the CoreOS team at Apple at the time. It was fixed in this. You can manage your directories, move them around. You can actually access things over the web natively, which was really pretty cool. And we were coming up with this WebDAV file system at the time, so that kind of fit in nicely. And it just does all the things right.

And I think it's going to fit in nicely with a lot of the things that developers want to do. I think it's going to grow into something that's going to go beyond the developer community and actually be useful to people who are kind of your Joe Schmo regular users with things like the SC plugin thing that Chris Pavicich is working on that will let you actually manage your subversion repository or working copy from Finder or being able to auto-version your repository and mount it in Finder and use it to manage your, say, Photoshop workflow in a group that's not used to using a command line tool like CVS. And I think that's going to have a lot of utility.

I actually set up a web server for my ex-girlfriend's sister once upon a time. And she lives in Brazil. And she manages the website, which is on my home machine behind a DSL link over in Santa Clara, California. She lives in Brazil. And she uses a Windows, whatever you call it, mouthy, crazy web dev file system feature in Windows. Web folders. And write an explorer. And she can actually drag files in and out of that. and I can back that with a subversion repository so that when she accidentally deletes everything, I can go, oh, let me revert that to yesterday's version for you. And at some point, it's going to become simple enough that she'll be able to do that sort of thing herself. There's a lot of room for growth here. There's a lot of opportunity for better integration with Mac OS and perhaps with the new features that are coming out in Tiger with respect to extended attributes and so on and so forth. But this is a top-quality product. I think it's one of the most important things to come out of open source in the past few years. And I am, for one, quite excited about it.

If you want more information about Subversion, that's the WWC Uber URL for all things related to anything in WWC. You can also go to Subversion.Tigris.org, which is the homepage for the site. You can Google it if you forget the actual name. You can also buy the book from O'Reilly & Associates. you