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.

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 has just informed me they've sold out of out there in the lobby, which is great because I'm glad somebody is 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 versions. 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.

I'm also a long-time Next aficionado. I knew somebody. I knew I got a woo-hoo out of somebody for that. Let's talk a little bit about what I'm hoping you'll learn today and what we're going to cover. We're going to cover a lot of Subversion basics. I'd like to do a quick Q&A of the room here. Who here has used Subversion? Oh, this is so great. Okay, thanks. Who here has used CVS as well? Okay. 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 going to 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 going to 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 going to 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.

Chris Parker, Brian Fitzpatrick 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 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.

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 used 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 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, 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 show us a little bit, 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.

Chris Parker, Brian Fitzpatrick 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. Chris Parker, Brian Fitzpatrick 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. Chris Parker, Brian Fitzpatrick In February of 2004, Chris Parker, Brian Fitzpatrick there were 1307 Subversion servers existed.

And I use this date in particular because that is the date Subversion hit 1.0. Chris Parker, Brian Fitzpatrick Since then, we've seen a lot more Subversion DAV servers out 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.

Chris Parker, Brian Fitzpatrick And I'm very happy to see this number. This also doesn't include anything behind the firewall, local repositories people use. Chris Parker, Brian Fitzpatrick So what this tells me is that Subversion's catching on pretty well. Chris Parker, Brian Fitzpatrick So now what are we going to do? We didn't have any exit strategy. We sort of subverted CVS and people are switching over from CVS every day.

Chris Parker, Brian Fitzpatrick Our goal now is to develop new features to make it even more compelling. Chris Parker, Brian Fitzpatrick We just finished locking feature, which is something a lot of people have been asking for. Chris Parker, Brian Fitzpatrick A lot of the poor souls, poor, poor souls who are stuck using Visual Source Safe have gladly come over to Subversion. Chris Parker, Brian Fitzpatrick Thank you.

Log Message Templates is one of the 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, sophisticated merge tracking. Subversion's 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 is 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 going to follow along, we're going to get started now, and Fred's going to come up here and drive the sort of demo server.

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, and that reason is because, actually for two reasons.

The first reason is that we've had some problems earlier when Subversion 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 Subversion 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. We're going to use the local repository access method. And so now we're just going to go ahead and create it. Use the svnadmin command.

Subversion is a very common gotcha. People try to feed a URL to the SVN admin and it only works with paths. very common gotcha people try to feed a URL to the SVN admin and it freaks out. There are three access methods for Subversion. We started off with the DAV method, but then someone who liked the CVS Pserver model wrote SVN serve, which you can run as a daemon. 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.

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 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 dragged file into your Subversion repository is going to result in like six, seven, eight commits because 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 619 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 fine.

That's me. I would go through crazy things to not have to CVS import because I never could remember the syntax for it. Subversion 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.

Okay. 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? Can we 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 going to go ahead and check out our working copy. Since this is our sort of first start in this project, we're going to use local access. We're not going to 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 going to check it out. Notice you're giving it a URL. And we're cheating here. We're using your dollar sign home variable. Is that? Did you say 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 SVN WCV. So if you go ahead and check that out and you do an LS of 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, you, in 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 build 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.

So, we've got our working copy, we checked it out, now we're going to update our working copy. We're going to bring changes from other developers in. Now, right now, so we see the end of the working copy, and we're going to 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 going to go ahead and make changes. Now, in Subversion, you're obviously going to edit files. You're going to add and delete files or directories. And when you delete a directory, it goes away. And that was like CVS, where the directory just keeps coming back. It's like the directory that just wouldn't die. You can also move and copy files and directories.

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.

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, God, this is so cool, I can move a file. You're going to copy the images directory to the photos directory. So we're going to wind up with two directories there.

and I used open command here because another file.txt that'll pop open text edit or whatever you have 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 project is 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, "I'll 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 directory, 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 added. So the little plus signs mean that this has some sort of history. Subversion is going to remember where these things came from. It's going to 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.

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 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.

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 it a little bit. Go through this example and explain why. For example, here we're going to cat the mati file into our file foo.txt.

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? Fred's gone ahead and tossed that into there, so now 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.

You have to provide the file name. It does not by default choose your dot as path in your current directory. It does not by default act recursively. It knows that it can blow away local data that you've made so that command is very careful about it. As you can see with diff, nothing happens here. You can go back to the slides now.

Chris Parker, Brian Fitzpatrick You have to provide the file name. It does not by default choose your dot as path in your current directory. It does not by default choose your dot as path in your current directory. You can go back to the slides 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. Chris Parker, Brian Fitzpatrick 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 version.

Chris Parker, Brian Fitzpatrick 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. Chris Parker, Brian Fitzpatrick So SVN resolve, CVS when you 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.

Chris Parker, Brian Fitzpatrick Subversion resolve not only will tell Subversion you fixed the conflict but it will also remove any temporary files that were created. Chris Parker, Brian Fitzpatrick So here we have a file foo.txt as a conflict. Chris Parker, Brian Fitzpatrick Obviously, Chris Parker, Brian Fitzpatrick 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. Chris Parker, Brian Fitzpatrick So what Subversion does is it creates three new files. Chris Parker, Brian Fitzpatrick One is the original file foo.txt which has all the funny little greater than less than conflict markers in it.

Chris Parker, Brian Fitzpatrick And then the next file is .mine which is the file you were working on just now. Chris Parker, Brian Fitzpatrick 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.

Chris Parker, Brian Fitzpatrick So you can feed those files to another to an external program. Chris Parker, Brian Fitzpatrick You can feed it to file merge or whatever not and look at what happened and go ahead and make your changes. Chris Parker, Brian Fitzpatrick If you're really feeling cavalier you can copy .mine back to foo.txt and blow away somebody else's changes. Chris Parker, Brian Fitzpatrick I recommend being careful doing that because if your coworkers are dangerous or carry heavy weaponry you might get hurt.

Chris Parker, Brian Fitzpatrick So once you've gone ahead and figured out what you can do with your conflict you run the svn resolved command and on the file again this is a Chris Parker, Brian Fitzpatrick This requires a specific path. Chris Parker, Brian Fitzpatrick So there we go. Chris Parker, Brian Fitzpatrick It got rid of all of our extra files. Chris Parker, Brian Fitzpatrick svn info file now svn info corresponds pretty closely to CVS status. Chris Parker, Brian Fitzpatrick You get a lot of info about a file.

Chris Parker, Brian Fitzpatrick Again this command does not go over the network. Chris Parker, Brian Fitzpatrick It does it deal straight with the working copy directory metadata and it tells you all sorts of info which I'm not going to go into depth but you know go ahead and I'll let something I'll let you do that at home for fun tonight.

Chris Parker, Brian Fitzpatrick Manipulating and viewing properties. Chris Parker, Brian Fitzpatrick So subversion is a concept of properties which is file metadata think extended attributes but it's not really extended attributes. Chris Parker, Brian Fitzpatrick And it allows you to set those attributes in any way that using any of these commands as well as retrieve them back from the repository.

Chris Parker, Brian Fitzpatrick Now the great thing about these properties is that there are properties that subversion uses internally as vn ignore to tell subversion what to ignore files to file patterns to ignore in a directory subversion you can also use it to set tell subversion to set.

Chris Parker, Brian Fitzpatrick So subversion is a concept of properties which is file metadata. set the end of line style if you're working cross platform with people you can use it as you can tell us the version expand keywords in a file so version doesn't do any of that by default because it's not gonna munch up your data so manipulating properties prop set prop edit and prop dollar 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 and if you drop an HTML file into your repository then you go and you look at it through in in a Safari you're gonna it's gonna be served up as text and you're gonna look and be 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 you 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, 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 that. It 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 slash jpg. If we run prop list on an S, on, and we say I want to 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 going to go over here. I do want to 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'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. It 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 subcommands and there's other options and whatnot, and you can find out what those are. But I just wanted to point out that there's still other stuff that we're going to 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.

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 is 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 Subversion 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 that, 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... Subversion 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. So you can see all the A's there. Right up there. Here's the load. Go ahead.

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.

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 going to do here, we'll do a quick review of what we're going to do. We're going to add a directory to your Subversion repository. We're going to check out the empty directory. And then we're going to 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, you know, 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 colon slash slash URL. Notice that I'm creating a directory on the repository 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 can check it in a temp or whatever or not, but we're going to check it in our home directory slash svnetc.

Now we cheat. We move the .svn directory over into your configuration directory. Now, I've given you a dummy Etsy directory in the 6.19 Subversion directory, so if you go ahead and move the .svn directory into there... You run SVN status and you're going to 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? Want to 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 dash dash 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 a prop edit. That was a prop edit? Yeah.

Okay, well go ahead and commit it then. So, you don't necessarily want to check in your host key file, so like this is an example of something you might want to add to your ignore if you're doing that here, or, you know, Fitz files. That kind of thing. Okay. So, now when I do SVN status.

The SSH host key files, the pub key is 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. 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 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-- 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 a file here that says maincontroller.m.

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.

And 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 do is 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 want to 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 maincontroller.m source 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 Fitz. 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 Fitz 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 going to 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. And that's it. If we could get the slides back here. Fred Heslick-Clicker.

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. And you can also buy the book from O'Reilly & Associates.