Sorry that this will break threading, my mail client doesn't appear to have a 'join-thread-from-web-archive facility'.
I'd like to give you a quick overview of where bzr is at at this point, and how I expect it to perform in the light of your analysis. I'm told that the demo version you have packaged up is 0.6.x which will also have some significant bearing on this. bzr is currently finalising the disk storage facilities for the next years or so of end user use; this is based on designs from our last conference in Montreal late last year. We expect to release 0.8 with a number of key performance improvements based on this. (Our 0.8 plans are at http://bazaar.canonical.com/ReleaseRoadmap). Specifically the VersionedFile branch implements the planned 'knit' format and has been tested at downloading ~2000 revisions a minute when making a brand new branch with no history available locally; incremental operations like publishing commits, committing to shared repositories and pulling new revisions from related branches are proportional to the size of those revisions. I don't know your time frames here, but I'd really like to have your performance tests executed on a versionedfile branch of bzr, or 0.8 once we enter pre-release mode. 0.8 is releasing in early to mid March. Now, for my [biased] review of where I hope you will consider bzr compared against your requirements.. E0: Open source Yes, bzr uses the GPL licence. E1: Unbiased and disconnected distribution Yes to all points. E2: Networked operation bzr uses a VFS layer for its current network operations - that is it operates over vanilla FTP/SFTP/HTTP/unix file system. For readonly access, all that is required is to place the branch on a web server or ftp server etc. For write access, you simply need write access as a normal SFTP/FTP user or via a mounted file system of any sort. In other words no nonstandard services or special configuration is required. We are planning to implement a smart server in the future, but the current VFS facilities will be retained, and the smart server will be able to operate via ssh tunnelling. On performance we have a known performance issue in all current releases: Versions before 0.8 operate poorly: read and write operations to repositories scale with the size of the repository (number of commits and number of files) rather than with the size of the delta involved. 0.8 corrects this with the 'knit' format weave allowing for data transfers proportional to the size of the missing history. E3: Interface stability and completeness Should be compliant. Firstly a side issue: we have put in place careful disciplines and supporting infrastructure in bzr to allow storage and library improvements to be rolled out to the user community without causing significant disruption or mandatory upgrades: Any newer client will write to older repositories (with a cut-off below format '5' repositories). That we deliver this level of compatability is a requirement of Canonical who pay the wages of Martin and I - so even if there is not sufficient community interest in long term legacy format support, there are resources to deliver it. Likewise from 0.8 we have an API stability contract: api changes will not break previous supported API's, they will mark them as deprecated and they will be removed at a later date. We haven't pinned down 'later date' but it is at least a year. With that in mind, storage representation is being locked down at the release of 0.8 for the next year or so: the default format will not change for at least that long. We consider the command line interface a primarily user interface and subject to change to improve the user experience. We take this cautiously - noone likes their muscle memory being regularly disturbed. Our primary scripting interface is the 'bzrlib' python library that is developed along with bzr. A number of tools and plugins [http://bazaar.canonical.com/PluginRegistry] use this library today with good success. All the storage systems bzr uses have minimal requirements from the file system: data is written in such an order that the repository is always consistent - the worst side effect of restoring from a system snapshot or partial backup is that the revision[s] being written will not be present and will need to be pulled again from the remote store, or in the case of commits, commit needs to be run again. This follows from our support of write-over-sftp: with a network in the middle, no file system sequences are guaranteed to succeed, so any single operation must leave the repository in a consistent state. One corollary of this approach is that system snapshotting is completely compatible with bzr. For specific documentation on the internals of a specific repository format we have design documentation and comprehensive comments in the library api. E4: Standard operations and transactions File and directory renames are fully supported. Renames are tracked by assigning unique identifiers within the repository when files and directories are added to the system. This allows renames to be trivially identified, and for conflicting renames to be reliably detected. E5: Per changeset metadata. Yes. We call these revision properties. C6: Ease of use Insallation: bzr minimally requires python 2.4 and provides local, FTP and HTTP repository access. Additional capabilities are added with the presence of * paramiko (a python SFTP client), * gnupg (for digital signing of revisions), * pycurl (increases performance of HTTP repository access and provides better http cache interactions). * celementTree (a C extension for the python XML library elementree that increases processing performance. This is strictly not required!) bzr can be installed by simply adding a symlink to the 'bzr' script in the root of its source tree (i.e. ln -s ~/source/bzr.dev/bzr ~/bin/bzr). Or you can install it and bzrlib using setup.py. Plugins - python programs that extend bzr and are accessed via its user interface - are installable by symlinking or copying them into either ~/.bazaar/plugins/PLUGINNAME or bzrlib/plugins/PLUGINNAME (for per-user and system-wide installation respectively). We consider user interface to be our primary driver - bzrs mission is to be lovable [and user feedback so far indcates we are achieving that :)] 'meld' has support for bzr, which can aid with conflict resolution, and we use <<<. ====, >>>> markers to record conflict regions within files. We also write a 'base', 'other' and 'this' file to disk to allow the use of third party tools that might provide better/different conflict resolution to bzr itself. (bzr uses a history aware merge, not simple 3-way). For example, this can be used by the emacs ediff/emerge/smerge tools. A typical example of use is "gvim `bzr conflicts`". I don't know if this is relevant at this point in time, but bzr never automatically commits the results of a merge as some other SCM tools do: there is always a space for human or automated review before the merge is committed to a branch. This allows for conflict resolution to be 'lazy' - the merge will complete whether or not conflicts are resolved immediately (though they all need to be resolved before committing the result of the merge because bzr guards against committing unreconciled conflicts -- you must use a 'bzr resolve FILE' as each is resolved, or 'bzr resolve --all' when you have resolved them all.) There is a plugin that implements a plain-text serialisation of the changes between two revisions, which allows exchange of bzr metadata via mailing lists etc. You can also generate arbitrary 'unidiff' diffs directly from bzr - i.e. between two branches, between two revision number or identifiers, between two dates. I think that http://goffredo-baroncelli.homelinux.net/bazaar/hgweb-plugin-dev is the leading candidate 'source code web browser' for inclusion in bzr. bzr does not currently ship with such a tool however. The demonstration site for this starts at http://goffredo-baroncelli.homelinux.net/bazaar/. bzr can download directly from the urls displayed in there when they are local to the server - i.e. 'bzr branch http://goffredo-baroncelli.homelinux.net/bazaar/hgweb-plugin-dev' will work even though it is all the web source code browser url. we have two commands to backout commits, they are 'revert' and 'uncommit'. The former can be used to change the working tree to any revision, (but the default and most common operation is to use this to undo any local changes by changing the working tree to be the same as the last commit). 'uncommit' is used to removes one or more changes from the history of the source branch [defaulting to the single most recent change]. This is done without affecting the consistency of the distributed SCM database. We use these two commands to record the two separate user intentions: 'revert' is "prepare to record a new revision, reversing a change", and 'uncommit' means "i never wanted to do that". C7: "No dedicated server" operational mode Yes. There is no dedicated server for bzr today, and thus there is no concurrency or performance degradation when using 'dedicated server-less' mode. As noted above the release of version 0.8 will bring performance up to anticipated acceptable levels, it is known to be unacceptable with large trees or long histories prior to 0.8. C8: Tool community health Yes. You will need to assess this yourself, but minimally: there are 3 full time employees of Canonical working on the tool or the community: James Blackwell is our primary community liason, responsible for user support, documentation, assisting with migrations etc. Martin Pool is the architect and project leader of bzr, and I am the 'Bazaar' team leader within Canonical. We are the thin edge of the iceberg though - the user and developer community of bzr are a huge strength - Martin and I can barely keep up with the community momentum. I recommend that the OpenSolaris community establish a 'liason' of their own, who would aim to understand the OpenSolaris communities needs and the facilities and planned features of bzr to meet those. Within bzr I dont think a liason would be needed - but I am confident that James Blackwell would be delighted to be such a liason if desired. (James just attended http://drupal.org/conference-vancouver-2006 as such a liason (and on his own time no less!)). bzr was designed from the ground up to be suitable for distribution-level usage, and having as many of the community members as possible see your defect reports and feature requests will allow them to catch peoples eyes. We have a support tracking and bug management at https://launchpad.net/products/bzr/+tickets and https://launchpad.net/products/bzr/+bugs. C9: OpenSolaris community implementation expertise No answer, I'm not in the OpenSolaris community ;) C10: Interface extensibility Yes. Bzr supports extension via three primary mechanisms. * Plugins can add, replace or extend commands. (they can also add new transport protocols, storage formats or even run the web source code browser server). * hooks can run named python functions at key points in operations like commit. We have a very small selection of key points 'hooked up' [pun intended] today, but it is very easy to add new hooks as use cases for them are identified. * New tools can be written using the bzrlib library - every aspect of bzr's operation is divided into 'ui' and 'library' portions, so that uis can be trivially written for domain specific tasks. C11: Transactional operations and corruption recovery Yes. Please see the E3 reply for details. C12: Content generality Yes. bzr tracks execution bits, symlinks, text files and binary files. O13: Partial trees Not yet. This is a planned feature, but will be post our '1.0' release. O14. Per-file histories Yes. bzr meets E5, and also implements per-file histories. (changes to a file result in a link between that file and the changing revision, so one can report from the files history by looking up the changing revisions.) 3.1. Representational and performance criteria I have not run tests of this at this point, my primary concern was to highlight the importance of our 0.8 release to your evaluation process. 3.2. Implementation criteria No answer - I'm not an OpenSolaris contributor. 3.3. Tools criteria Support for bzr is already present in 'meld' - a standard graphical merge program. bzr does not have plans to ship its own graphical merge program at this point. While the following are not part of the required tools capability, you may be interested in them anyway: DVC: http://bazaar.canonical.com/DVC. This provides Emacs VCS-mode like support for the bzr version control system (as well as some others). gannotate: http://bazaar.canonical.com/gannotate. This is a graphical file annotation viewer. (A screenshot is available http://bazaar.canonical.com/BzrScreenshots). Neither Martin nor I are on the tools-discuss list at this point, we'd be happy to respond to any questions raised, if you'd be so kind as to cc: us :) Cheers, Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tools-discuss mailing list [email protected]
