Version Control System Requirements/SVN Responses

The Subversion team went through the requirements and came up with some responses. Brian Behlendorf has offered their and collab.net's help in any migration.

Daniel Berlin is currently working for Google on merge tracking support in SVN (so that Google can move from Perforce to SVN).

Here's their response:

• changesets

To the degree that a single, global revision is a changeset, Subversion has this.

• move/rename files/directories with full history and appropriate behaviour with old branches/pull by date

Check.

• atomic operations

Repository modifications are atomic, yes.

• • every operation versioned: tagging, branching, etc. are part of history (or at least logged)

Check.

• private/local branching
  • sane merging
    • history-sensitive merging

We haven't merge tracking, but it's in active development today. There is a tool called svnmerge.py that today provides some metadata tracking that makes merging slightly more sane today, and its metadata looks like it will be forward-compatible with the core support for merge tracking down the road.

• topic branches
  • with control over when you pull in outside changes into your branch

Sure. Subversion has no automatic policy with branches. You make a branch. If it's a feature/topic branch, so be it. If it's a release branch, so be it. The system doesn't know. Doesn't care, even. You wanna pull in outside changes every day? Go for it. You don't? That's cool, too.

• ability to tag/branch bugzilla/js/etc. subcomponents of a tree without tagging entire tree

You can do this. Subversion's tagging/branching is so inexpensive that that cost of tagging the whole tree is the same as the cost of tagging just a piece of it, so that might be considered. Some feel that tagging the whole tree is far less confusing in the long run.

• tools integration
  • blame (like current bonsai)
  • revision history
  • source browsing
  • source indexing

ViewVC gives you these. See http://viewvc.tigris.org/.

• • tree closure/override

Could we get more details about this requirement?

• • reports/metrics
    • commits, committers, etc.

These can be gained, though not directly with Subversion. For example, the CIA project harvests information like this from open-source projects and has some reporting capabilities.

• access control
  • restrict people to specific areas
  • restrict areas/branches to specific people

Check.

• • group membership

The mod_authz_svn module does this. Apache uses it heavily.

• • being able to query where people have access

The authentication configuration for the open source package maintains auth info in a text config file. Inverting that to ask what parts of the repository a given person has access to is not hard to do from inspection of that file, though a script can easily be written to give a simpler answer.

• • audited ACL changes
  • versioned ACLs

No operating-system-level ACLs in Subversion. You can version ACL changes by keeping your mod_authz_svn configuration file in the repository, though.

• cross-platform (unix/mac/windows)
• open source
• file forking/diverging with history

Yep, yep, yep.

• cherry-picking of changesets

For our definition of 'changeset', yes.

• offline operation
  • offline diff
  • offline commit/merge/etc.
  • partial history pull
    • including zero history

Offline diff, revert, status, mkdir, add, remove. No offline commit/merge unless you are using perhaps SVK (built atop Subversion).

• tree information
  • tree-wide diff
  • selective diff
  • known/unknown/missing files

I think you're covered here.

• selective commit
• work with standard patches

Yeppers.

• stable/reliable/maintained

Oh yeah.

• charset awareness

Can we get more information? Internally, SVN is UTF8 clean, and CollabNet is using it for a number of Chinese and Japanese language projects. You can configure default charsets, but it can also tracked as metadata per-file if desired.

• line-ending conversion
• binary files (efficient)
• GUI tool for basic operations

Check x 3.

• as easy or easier than CVS for checkout/commit/diff/update/merge (on trunk and on branches)

Far easier, because you can refer to atomically committed revision numbers (changesets) instead of individual revisions of individual files when merging. God, what a headache branch-based development in CVS is!

• partial tree pulls (localizers)

Yup.

• import full mozilla CVS repository
  • if we can't, why?

You should be able to. And I guarantee that cvs2svn and/or Subversion developers would be moooooore than happy to help you work through this.

• fast working directory updates
  • (checkout-by-date -> tip, branch -> branch, ...)

Yeah, updates are optimized to transmit only what you need to transform your working copy from state A to state B.

• pull historical version and check in changes to files in historical version

This isn't clear enough, could you describe in more detail?

• integrity checking on repository
  • checksums for error detection

Our backend store does checksumming, as does our network layer, as does our working copy administrative code.

• transit mechanisms
  • ssh
  • https
  • anonymous read-only (http?)

Got 'em all.

• bootstrap local repo via blob pull

You can distribute a local working copy (is this what you would mean?) as a tarball, so as to save some of the overhead involved in an "svn checkout".

• signed commits/changesets

This is not a built-in feature, but a mechanism could be built atop our arbitrary revision property storage system for doing this, I think.

• hooks
  • all repository operations

Only for "write" operations. (Commits, changes to revision properties, locking/unlocking.)

• bugzilla integration
  • automatic notification to bugzilla of what was checked in (add attachment based on changeset)
  • associate bugmail with committer

CollabNet has this kind of thing - if you mention the bugID in the commit message, then a bidirectional link is set up between the web view of that issue in Bugzilla and the ViewVC view of that commit log.

It's not a part of the open source package, but this should not be difficult to write and wire up to mozilla.org's Bugzilla installation.

SCMBug is an open source project that integrates version management systems with bug tracking systems. It does support Subversion and Bugzilla as well as CVS and a number of other combinations.

• keep committer ID separate from the actual person

Actual persons may, of course, have more than one login. Logins are not tied to one's Unix user ID or other local operating system identity.

• arbitrary versioned metadata on files/attributes
  • permission bits
  • key/value pairs

We've got arbitrary metadata for files, yes. And I think there's even a feature branch for doing OS permissioning using exactly that transport mechanism.