1

Revision Control With SubversionAn Overview, Targeted at Former-CVS Users

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

Subversion and CVS: Differences

• Directory versioning• Atomic commits• Versioned metadata• Choice of network layers• Consistent data handling• Efficient branching and tagging• “Hackability”

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

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 don’t 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

Atomic Commits - Transactions

• This is much more important than many people realize at first. In a very real sense, Subversion doesn’t 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

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

Choice of Network Layers

• Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversion’s “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

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 it’s 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, it’s fast.

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

“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

Branching, Tagging, et-al(Quoting Patrick Peralta’s 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

Branching, Tagging, et-al(Quoting Patrick Peralta’s 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 won’t use up any more disk space than it has to.

14

Branching, Tagging, et-al(Quoting Patrick Peralta’s 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

Branching, Tagging, et-al(Quoting Patrick Peralta’s 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

Branching, Tagging, et-al(Quoting Patrick Peralta’s 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 heart’s 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

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 there’s a conflict, it won’t let you check it back in until you explicitly say you’ve resolved the problems with the “svn resolved” command.

18

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

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 CVS’s $Log$ keyword, it doesn’t 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 doesn’t work well if your working-copy is on a network share.

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” it’s 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 doesn’t make as many assumptions as CVS.

– Because it doesn’t 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

References

• Subversion: 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 O’Reilly.

23

&ANSWERS

QUESTIONS