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:
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
- atomic operations
Repository modifications are atomic, yes.
- every operation versioned: tagging, branching, etc. are part of history (or at least logged)
- 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?
- 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
- 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
- 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)
- 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
- 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.
- 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.