On Mon, Nov 24, 2014 at 1:35 PM, Richard Hipp <d...@sqlite.org> wrote:
> 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: > And here i always thought all problems in sqlite are unexpected! > (1) Bundles. A bundle is a single file (another SQLite database, of > course) that encapsulates one or more check-ins. ... > i like the sound of that a lot. > (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 > Holy cow. Won't not having parent artifacts cause us grief somehow, or are those simply added as phantoms (or a similar "light" representation)? > (3) The ability to purge individual checkins and/or branches from a > repository. Purging is different from shunning. > i can't believe we never thought of it before when discussing uncommit, but removing a single branch "should" be fairly tri^H^H^Hstraightforward, provided it doesn't merge back in anywhere (and we choose to prune any sub-branches which branched after the deletion point). > 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. > How is purging undoable? (edit: nevermind - answered below) > (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. > Do they have one big shared branch or does each have his own? If the latter, how do we differentiate the N anonymous users? Maybe give each one a token (a UUID) unique to his branch? He can share that token with others to allow pushing to that (anonymous) branch. That would give us a "mob-branch" style of workflow: a branch using a public login token where anyone could push to. > 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. > Then why is he anonymous? i.e. why not simply use his own credentials? (5) A non-synced "graveyard" table containing purged and shunned artifacts, > in case those artifacts ever need to be resurrected. > That answers my question above about recovery. i like this. > 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... > Anxiously awaiting this round of discussion. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-dev mailing list fossil-dev@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
