- My application formats a string containing a CVS command.
- It passes that string to a shell running in a sub-process.
- That shell starts another process to execute the
cvsprogram (unless the
PATHvariable has been mangled too badly by all this forking and exec'ing).
cvsprogram calls a bunch of C functions (some of which might actually starts sub-shells of their own, but that's another story) to extract information from the versioning files and metadata in the repository.
- My application reads that command's output as a list of strings and runs it through a handwritten parser that (hopefully) extracts dates, user IDs, and commit messages.
svnadmincall these functions, but Subversion also provides adapter libraries to make them available to Python, Java, and other languages. As a result, programmers don't have to fork sub-processes, or parse strings; they can instead call a function, and get a data structure as a result. All right: what information do project members actually want about their project's repository and its contents? "What's there?" (i.e., a listing of available files) is pretty obvious, along with what's in particular files, what used to be in them, and a list of change sets. If we're showing what used to be in files, we ought to show the differences too; and if we're showing change sets, we ought to provide a multi-file view of the overall differences. Hm... What about access control? How are we going to ensure that only people who are members of a project  can view the contents of the project's repository? And what exactly do we mean by "the project's repository", anyway? Is there going to be one repository for each of the projects DrProject is managing, or would it be simpler and/or safer to partition one big repository into project-sized chunks? Subversion supports the latter: you can create an access file that gives particular users read and/or write permission for sub-directories within a repository. However, this is what Joel Spolsky famously called a leaky abstraction. To see why, consider a situation in which Olga can read and write both the
greendirectories in a repository, but Maxim can only read and write the
greendirectory. If Olga commits changes to updates
green/greenish.javain a single operation, what should we show Maxim when he asks to view the change set? We can hide the contents of, and changes to, the file he's not allowed to view, but he'll still be able to read Olga's commit message, which may (if Olga is conscientious) tell him a lot about what's going on in parts of the world he's not supposed to know anything about. We therefore decided to use one repository per project. Each of these repositories has its own access file; when users are added to or removed from the project, DrProject modifies the access file appropriately . This means that even if people bypass DrProject, and try access repositories using Eclipse, command-line programs, and other clients, their access rights will always be what we want them to be. One thing DrProject does not provide is a way for users to modify the repository over the web. In particular, users cannot edit or commit files through their browser. We left this out for several reasons:
- It opens up a channel for attack: if the DrProject CGI is able to modify the repository, then anyone who subverts the CGI can do a lot of damage to the project's core resource.
- We didn't believe anyone would ever actually do any significant code editing through an HTML text editing box. (This may change in future, as rich editing controls become common; even today, it'd be nice to be able to add comments to commits after the fact.)
- Implementing it---in particular, implementing conflict resolution---would have at least tripled the complexity of this part of DrProject.
- Nobody else's system has it, so we figured there couldn't be a crying need ;-)
 Yes, Subversion is written in C, for both execution speed and portability. The last may seem like an oxymoron, given the bajillions of
#ifdefs programmers have to use to actually make their C portable, but these have the advantage of being well understood. Getting C++ or Java to work on multiple platforms is actually no easier. More specifically, have a role with respect to that project that includes the capability to view the contents of the repository.  This is only true if administrators use the functions in DrProject to edit user permissions. If someone edits the underlying database directly via SQL, it obviously won't have the desired side effect of updating the Subversion access file.