1. 1 Revision Control With Subversion An Overview, Targeted at Former-CVS Users

2. 2 Subversion and CVS: Similarities Basic revision control functionality (tracking changes, showing differences, logs, etc.) Uses a local, private working copy for where you make changes, then check those changes into the server – the server acts as the point of coordination between multiple users Uses the Copy-Modify-Merge method (compared to, for example, Lock-Modify-Unlock) Branches, tags, triggers, etc. Open-source with lots of tool support

3. 3 Subversion and CVS: Differences Directory versioning Atomic commits Versioned metadata Choice of network layers Consistent data handling Efficient branching and tagging Hackability

4. 4 Directory Versioning CVS only tracks the history of individual files, but Subversion implements a virtual versioned filesystem that tracks changes to whole directory trees over time. Files and directories are versioned. As a result, there are real client-side move and copy commands that operate on files and directories.

5. 5 Atomic Commits A commit either goes into the repository completely, or not at all. This allows developers to construct and commit changes as logical chunks. All of the files in the repository at a point in time are at the same revision. So you dont talk about the revision of a file, but rather of the repository. (Check out rev 1482 rather than Check out rev 1.24 of foo.txt, rev 1.4.2.21 of bar.html, rev …)

6. 6 Atomic Commits - Transactions This is much more important than many people realize at first. In a very real sense, Subversion doesnt work with files so much as it works with transactions. This has many implications, including atomicity, that things can be grouped logically rather than in time, and cheap copies (much more on this later).

7. 7 Versioned Metadata Each file and directory has a set of properties attached. You can invent and store any arbitrary key/value (text or binary) pairs you wish. Properties are versioned over time, just like file contents. There are standard properties, like svn:mime-type, svn:ignore, svn:keywords, svn:eol-style, etc. You could use a published property to track workflow, icon and attach a GIF, copyright with copyright info, comments, etc.

8. 8 Choice of Network Layers Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversions advanced network server is a module for the Apache web server, which speaks a variant of HTTP called WebDAV/DeltaV. This gives Subversion a big advantage in stability and interoperability, and provides various key features for free: authentication, authorization, wire compression, SSL, and repository browsing, for example.

9. 9 Consistent Data Handling Subversion expresses file differences using a binary differencing algorithm, which works identically on both text and binary files. In CVS, for text files only the diffs are stored. However, for binary files, each check-in appends the entire file to the repository. Do that a few times on a large file, even if only a few bytes changed, and its not exactly efficient. For large binary files, even on a LAN, getting an update from CVS can take a while. Since with SVN only the diffs are transmitted, its fast.

10. 10 Efficient Branching and Tagging The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time. Branching, tagging, copying, moving, etc. are significantly different (and much, much cooler) in SVN compared to CVS, so more on this later…

11. 11 Hackability Subversion has no historical baggage; it is implemented as a collection of shared C libraries with well-defined APIs. This makes Subversion extremely maintainable and usable by other applications and languages through SWIG and other mechanisms. The output is explicitly designed to be easily readable by both humans and parsers. This makes it significantly easier to extend the system. For example, you could add a commit hook that looks in the log message, sees Defect 1247 in it, and creates a reference in the defect tracking system to the URL and revision number of the change.

12. 12 Branching, Tagging, et-al (Quoting Patrick Peraltas blog) part 1 In CVS, branching and tagging are two different operations. If you tag something and later want to go back and edit something in the version that you tagged, you have to create a whole new branch based on that tag. Using SVN, the concept is called copying. There is no technical distinction between tagging and branching; all you have to do is make a copy of your repository. However, convention says (you don't have to follow this convention but it makes maintenance easier) that you have separate directories for branches and tags. For example, the titan- server project looks like this: titan-server branches tags trunk

13. 13 Branching, Tagging, et-al (Quoting Patrick Peraltas blog) part 2 The main development happens in the trunk, tags go in the tags directory, branches in the branches directory. One might ask if branching and tagging are the same, then why bother with two directories? As mentioned before, it would just be a matter of policy. Looking at this project, it is obvious that there are no active commits going on under the tags directory, only the branches and trunk. When I say copy in quotes, it is because SVN is not really making a copy of the project; it is just tracking the differences. Therefore, you can make as many branches/copies as you want… it wont use up any more disk space than it has to.

14. 14 Branching, Tagging, et-al (Quoting Patrick Peraltas blog) part 3 As an example, I wanted to take the current version of titan- server (which is 1.5.0.8) and place it under the branches directory. This is because Titan 3.12 will be using this version of the server, which means that there is a possibility of finding bugs that will have to be fixed during the 3.12 beta period. However, I want to start on 1.6 of the server, and I want to do it under the trunk. Therefore, I created a branch like this: svn copy http://astsrc.veritas.com/svn/titan-server/trunk http://astsrc.veritas.com/svn/titan-server/branches/1.5.0.8 -m "" (The -m is the comment for the branch. In this case, I decided not to provide one, so I just used an empty string.)

15. 15 Branching, Tagging, et-al (Quoting Patrick Peraltas blog) part 4 If you think about it, this is the way that most of us did version control on projects before putting them in a version control system. How many of us have made a backup copy of a project before trying something new? This command is doing exactly that, except that it is not making an actual copy (as mentioned previously) and it is done on the server side. If I decide later that no more work is going to be done on 1.5.0.8, I can move it to the tags directory (since it is not being worked on but I still want it tagged in case a bug is discovered down the line). It is also possible to remove a tag/branch by using the svn delete command. Of course this won't remove the actual version from SVN, it will just remove the tag/branch in case you don't need it anymore.

16. 16 Branching, Tagging, et-al (Quoting Patrick Peraltas blog) part 5 For instance, when Jim goes on coding binges (this usually happens over a weekend) he will create a personal branch of Titan and raise all sorts of hell. If he did that on the main branch and checked all of that stuff in, the rest of the Titan developers would be less than thrilled that the current version of Titan is broken on Monday morning. However, with a separate branch he can code to his hearts content until everything is working, and then merge it with the main trunk. After that is complete, he will never use that personal branch again, so it makes sense to delete it in order to keep the branches directory somewhat clean.

17. 17 Conflict Resolution In CVS, you can do a cvs update followed immediately by cvs checkin (not a good idea for lots of reasons!) and even if there are conflicts, those unresolved conflicts are checked in. In SVN, if theres a conflict, it wont let you check it back in until you explicitly say youve resolved the problems with the svn resolved command.

18. 18

19. 19 Binary Files and Translation While CVS has a good list of file extensions that it assumes are binary, unless you explicitly use the -kb flag, it will usually check it in as a text file… The problem is, CVS does newline translations on text files, as well as keyword substitutions. Your binary file just got rewritten! SVN is much more paranoid and assumes that the file is binary unless you say otherwise (with the svn:mime-type property). Even when you enable keyword substitution for a file, the substitution is made in your working copy only – the server is always kept pure. One thing this enabled them to do was prevent bogus conflicts due to keyword substitutions.

20. 20 Butterflies and Rainbows? A few gotchas: –The plug-ins for some IDEs are not ready for prime-time. –If converting from CVS using the cvs2svn utility, be sure to use the - -mime-types and --set-eol-style options. Another possible problem is not using --encoding=latin1 –If you rely on CVSs $Log$ keyword, it doesnt exist in SVN. But the CVS manual tells you not to use it, because it can cause too many problems. –No way to (easily) do exclusive locks. For most things, this is a feature. However for some things, like office files, multimedia, etc. this can be a pain. –SVN assumes that it has local access to its control files and the like, so it doesnt work well if your working-copy is on a network share.

21. 21 Speed Trade-offs Speed trade-offs: –Because it has to create a transaction and ensure that the data is safe (any time there was a choice between safety and speed, the developers always chose safety), that can take some time. With normal usage its not noticeable, but it can odd that it takes three seconds to check in 500 bytes of changes in one file. (However, it is very bandwidth friendly.) –Tools like TortoiseSVN can be a little slow when refreshing a directory display because SVN doesnt make as many assumptions as CVS. –Because it doesnt have to hit the wire in order to show diffs and other changes, it can be significantly faster when working over a slow connection like a WAN or broadband connection. Since it can do extremely fast diffs, SVN never looses its mind on whether or not a file has been modified. It guesses based on time stamps (like CVS does), but it then diffs the file just to be sure that it has really changed rather than give a false positive

22. 22 References Subversion: http://subversion.tigris.org/http://subversion.tigris.org/ Large parts of this were taken directly from the excellent book Version Control with Subversion. The latest copy can be found at http://svnbook.red- bean.com/ though a paper copy can be bought from OReilly.http://svnbook.red- bean.com/

23. 23 & ANSWERS QUESTIONS