[Monotone-devel] Re: FreeBSD's requirements for its future VCS

[Lapo Luchini]

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
address@hidden (OpenPGP & X.509)
www.lapo.it (Jabber, ICQ, MSN)