Changes between Version 4 and Version 5 of DistributingChanges

03/05/10 10:24:32 (4 years ago)

introduce new terminology, add to requirements, and create explicit sections


  • DistributingChanges

    v4 v5  
    13Abstracting and continuing considerations from: 
    24 - SyncingInstances 
     6= Terminology = 
     8To facilitate discussion here is some clarificatory terminology: 
     10  * Repository: a given standalone instance containing domain objects. 
     11  * Revision: metadata about a particular change such as unique-id, author, timestamp (and maybe more such as: parents, hash ...) 
     12  * Patch: description of the changes to the domain model: e.g. a set of ids for changed versioned objects along with relevant diffs, necessary changes to non-versioned objects etc 
     13  * Changeset: the combination of a Revision and its associated Patch 
     14    * NB: a patch alone can be applied but it can only be applied "blind" (for example one has no idea whether the patch has already been applied earlier in the Repository history) 
     15    * NB: similarly a Revision along can be applied (it is a Changeset with a null Patch) 
     17= Wants and needs = 
    419Apparent wants and needs: 
    5  - to distribute local CKAN changes to foreign CKAN instances 
     21 - to distribute Changesets from one (local) CKAN Repository to a foreign CKAN Repository 
     22   - to do this on a repeated basis 
     23 - to be able to also pull Changesets from a foreign CKAN repository to a local one 
     24   - to be able to do this with a foreign repository that has previously received Changesets from the local (in particular Changesets made on foreign instance can be pulled back without duplication of Changesets pushed from the local repository) 
    625 - to preserve history (perhaps so that normally each instance's Recent Changes resembles the others') 
    726 - to support selective distribution (either by selecting for some logical subset of CKAN records, or by manual approval of changes on a case-by-case basis, or a combination, or otherwise) 
    928Inferred wants and needs: 
    1030 - to support use through firewall (client-server: where client pushes changes on client to server, and client polls and pulls changes on server to client)  
    1131 - to support use across internet (peer-peer: each accepts listeners, each can register to listen for changes, each notifies its listeners of any new changes, each listener pulls changes it doesn't have, etc) 
     32 - for this process to be integrated into the AccessControl 
     34= Comparison between Mercurial and CKAN Situation = 
    1436Highlighted core models of Mercurial and of CKAN: 
    4264 - Export/Import (which BTW causes changes to be applied to the working directory before committing, that is different from Pull which doesn't affect the working directory - also worth noting that import normally aborts if there are outstanding changes in the working directory, which would carry over to CKAN should received changeset patches be queued and progressively applied unless there is a conflict, which [could] normally cause the queue to be held up, and notification to be sent to the site admins to intervene, after the conflicting patch is resolved the queue would continue until the next conflict -- other behaviours could include: automatic merging; automatic skipping; intervention each time) 
    44 Actions needed in CKAN to distribute changes (functional requirements): 
     66= Actions needed in CKAN to distribute changes (functional requirements) = 
    4568 - Changeset patch, creation (on new revision: create serialised diff) 
    4669 - Changeset patch, publication (handle register-get and entity-get, searchable, publish-subscribe)