I'm getting increasing pressure to provide Fossil with "drive-by-patch workflow" capabilities. By this I mean capabilities that make it easier for random passers-by on the internet to contribute changes to a project. GitHub provides that capability using pull-requests, for example.
I've started a new branch "DBP-workflow" to work on these ideas. Among the enhancements I mgiht experiment with this week (assuming I am not pulled off to work on SQLite problems that pop up unexpectedly) are the following: (1) Bundles. A bundle is a single file (another SQLite database, of course) that encapsulates one or more check-ins. An unprivileged user can clone a repo and make their own local changes, then package those changes into a bundle to email to a developer for consideration. The developer can then import a bundle into a provide branch for examination. Then either purge that private branch or publish it, as appropriate. (2) The ability to push/pull/clone individual branches. (Currently, Fossil push/pull/clone syncs absolutely everything). Part of this will be the ability to clone just a single branch beginning at a recent date, rather than the entire history of the project - so that people who do not care about the ancient history of a long-running project don't have to download it all. Another aspect to this is the ability to auto-sync with multiple repositories, so that a user can auto-sync with branch A on repo X and with branch B on repo Y, automatically and at the same time. (3) The ability to purge individual checkins and/or branches from a repository. Purging is different from shunning. Purged checkins can be added back later, if wanted. Purging is important to DBP workflows, I think, in order to keep the amount of cruft in a repository under control. The oft-requested "fossil uncommit" command would be just a special case of purging. (4) The ability for anonymous users to push their own prospective changes as a new branch. Anonymous pushes would be restricted to check-ins only (not wiki or tickets or other artifacts) and only check-ins on new branches - in other words anonymous users would not be allowed to push changes to trunk or push tags against preexisting check-ins. Anonymous pushes might be held for moderation before being publicly accessible. Anonymous pushes might require the pusher to also submit repository-specific identification information for verification purposes. The identification information might be just an email address, or it might include full contact information and/or scans of signed copyright releases and/or scans of proof-of-identity such as passports/id-cards, configurable according to the policies of individual projects. Identification information would be held privately by repos and not synced or cloned, just as the "user" table is currently private to a repo. (5) A non-synced "graveyard" table containing purged and shunned artifacts, in case those artifacts ever need to be resurrected. This is a safety mechanism that allows for an "unpurge" and also to recover lost content in case a bug in the "purge" command removes more than intended from the repository. The foregoing is just an outline of my ideas, in case people are wondering what the new DBP-workflow branch is all about. It remains to be seen how much of the above I actually manage to get done... -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-dev mailing list fossil-dev@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
