Lapo Luchini wrote: > http://wikitest.freebsd.org/VersionControl
My personal analysis of monotone vs wanted features" (very rough): > VCSFeatureCVSImport: Ability to import entire current CVS repository, > including history our cvs_import would almost suffice, branch reconstruction would be a plus; NEEDED: find in what revision a file of a specific CVS version is imported into > VCSFeatureVendorBranches: Support tracking vendor sources > (bind, gcc, ...), import/map existing branches. we should have this already (it the "vendor branch" gets updated a "propagate" progapages all the changes to child branches, is that so?) > VCSFeatureAtomicCommit: Atomic commits to get real changesets we definitely got that, we're ACID, and Atomic is just the first letter... > VCSFeatureBranch: Easy & cheap branches (and history-aware merging) > and tags to enable parallel lines of development we got that > VCSFeatureObliterate: Obliterate functionality, to remove complete > content and history from the repository in the event of import > errors, policy decisions to remove content, etc kill_* commands can do that, but a local file sync is then needed to remove unused file content (a command to clean in the background while the server is active would be nice: afterall it could be read-only while scanning it all, locking the file for a few moments at the end, just to DELETE the extra rows) > VCSFeatureFast: Fast system for common operations we have to work on it, with a repository as big as FreeBSD wuold be (I managed to import the kernel in a 500MB database; full import still running after 48h) > VCSFeatureACL: Access control: the ability to constrain developers > to operating in specific areas of the tree, implement branch-based > policy restrictions, as well as to enforce policy such as tagging > of commits for developers working outside their normal areas. > Implementing these via hooks would not be a regression from what > we currently do in CVS. I guess this is a work in progress with the new policy tree stuff, isn't it? > VCSFeatureMerging: Automated or mechanically assisted merging we should comply with it already > VCSFeatureCVSExport: Ability to keep and distribute a reference tree, > knowing that it should also be exported to CVS this lacks, and wouldn't be easy given the single-line of CVS branches, but something could be discussed on the very wiki page regarding it, I guess (judging from what Hg and Git people say there, a "commit on hook" would probably be sufficient) > VCSFeatureRename: Ability to rename files within directories without > losing history we defintiely got that > VCSFeatureSign: Ability to digitally sign revisions or repositories > to avoid file corruption and to detect unwanted modifications well, that's not a feature we support, it's the MAIN feature > VCSFeatureOffline: Ability to work offline -- like on a plane -- > without requiring too much work: not only being able to list > differences but also to commit yup, that's easy! > VCSFeatureDollarFreeBSD: Provide a mechanism to allow end users to > easily see the version of the source code they were built from. > Currently implemented with $FreeBSD$ tags in the repo. this would be tricky... I guess > VCSFeatureLogTemplates: The repo as a whole must support a log message > template. Support for different templates for different paths would be > useful. this should be doable with hooks, isn't that? > VCSFeatureLogReview: Log messages should be reviewed to ensure they > contain the correct information. For example, "Approved by: re" > during code freezes/slushes this is almost there: a certificate could be used, with the "pro" that the approved would also digitally sign the info (though I wonder if would be easy to append it to the log message, if needed?) > VCSFeatureMirroring: It must be possible to mirror the repository > to remote sites. that's the very idea of "distributed", we got that ;) > VCSFeatureGoodRepositoryFormat: The VCS's repository should be stable, > relatively safe during crashes, and small enough for developers to > keep copies. we got that since quite a few versions, I'd say, with no real upgrade hassle after 0.26 > VCSFeatureWebInterface: There should be a way to browse the repository > from a web browser, review changes, and so on. viewcvs.cgi + CVS > export is unlikely to be a long term solution. I'd say: either work on ViewMTN quite a bit or finish MonoTrac is needed > VCSFeatureCommitMail: E-mail messages to one or more addresses should > be generated when a change is committed. Format of e-mail may change > (e.g., doc committer committing to src tree) easy with hooks > VCSFeatureTinderbox: The VCS must provide mechanisms for the tinderbox > to hook in to it. (tinderbox is the auto-building system) an update hook should suffice > VCSFeatureBaseSystem: How is the VCS going to integrate in to the base > system? zlib, iconv, gettext, boost: that would mandate to have it as a port and not in the base system (mainly for boost's size and complexity, I'd say) (SVN and Hg are not in a substantially nicer position regarding to this) > VCSFeatureNetworkSecure: Network operations should be secure. of course they are ;) > VCSFeatureSymlinks: It is desirable to be able to place symlinks under > version control. currently doable via LUA hooks, but would be nice to have as a base feature IMHO > VCSFeatureMIMEType: It is desirable to be able to indicate a file's > MIME type, in the case of binary files in the repository. probably not useful enough to be in base monotone, but could be implemented with LUA, I guess? > VCSFeaturePortable: The replacement must build and operate correctly > across all the architectures that FreeBSD supports. that shouldn't be a problem (i386, x64, ppc, sparc64) END OF TEXT Lapo -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP & X.509) www.lapo.it (Jabber, ICQ, MSN) _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel