On Wed, Mar 23, 2011 at 03:12, Stephen J. Turnbull <stephen at xemacs.org> wrote: > No, software engineering scales up to a point, then it breaks and you > need a serialization scheme. The problem is not the DVCS, it's the > demand for a *centralized*, authoritative, safe, stable version. DVCS > can scale at least to Linux kernel pace if you only ask for > centralized authoritative.<wink> DVCS is "No Silver Bullet", it only > helps with some accidental costs of development. It doesn't help with > the costs of review and testing. Yeah, Linux employs the other solution here (which Mercurial also uses, in fact, for development of Mercurial itself): only one person pushes to the central repository, that person pulls from other "staging" repositories as he is aware of changes being made. > There are in fact problems with the current generation of DVCSes. > Lack of plists on commits, for example. You'd like to have a "tested" > property, in fact two of them (one for the committer, one for the > buildbots). You'd like to have a "checkpoint" property, which commits > would by default be ignored by "log" and "bisect". You'd like to have > an "issues" property, a list of issues applicable to this commit. But > again, these would only reduce accidental costs. Mercurial does in fact have a mechanism to attach arbitrary metadata to changesets (the extra dictionary), but there's no easy access from the command-line. One could also argue that this is basically just a special case of smart commit message formatting, which python-dev already does, and could extend. (For example, Mozilla sometimes closes their tree to general commits, but then has a CLOSED tag that can be put in a commit message to override that.) Cheers, Dirkjan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4