Re: Versioning/Variant Authoring Design Team meeting

     In the following is a quick outline of a high-level approach to doing 
     parallel development.  I'm offering this as an example to see how 
     WebDAV versioning can support it.  A second issue is whether we can 
     support it efficiently.  By this I mean that the work that can be done 
     on the server is actually done on the server.  To what extent can 
     WebDAV servers overload the functioning of CHECKOUT and CHECKIN with 
     additional semantics?  It is not my intention to suggest that we build 
     in, let alone require, such high-level semantics in the WebDAV 
     versioning model. 
     
     --Sarge
     
     
     Versioning example:
     
     Parallel development for dummies:
     As an example, imagine a dispersed team is developing and maintaining a 
     web site (or anything else).  Each team member is responsible for a 
     different aspect of the site.  Most are content experts and not web 
     developers per se.  Normally each developer's changes are in different 
     files or different parts of common files.
     
     The team works in collaborative mode most of the time.  When close to a 
     release date they switch to the end-game mode.  The purpose of this 
     scenario is to illustrate these two modes of development.
     
     Collaborative Mode
     This is a parallel development style of the simplest kind.  Simple for 
     the users that is.  The check in and checkout commands are overloaded 
     and perform higher level functions than in a typical serial development 
     model.
     
     Each developer does a checkout of the files they want with a lock.  
     This always succeeds. They modify the files and check them in as a unit 
     (a set of changed files).  If there are no conflicting parallel changes 
     then all files are checked in, comments applied, labels set or moved, 
     etc.
     
     If there are conflicts, say one file of five, the non-conflicting files 
     are not checked in.  The one conflicting file is automatically checked 
     in on a branch (for safe keeping), and then automatically checked out 
     with a lock on the tip (latest revision of the original line of 
     decent).  Then this tip revision of the file is automatically merged 
     with the branched revision in the working area, but not checked in.  At 
     this point the developer, having been told that conflicts existed and 
     need resolving, is free to examine the conflicts and the merge hints 
     that the system may have suggested.  More editing and testing may be in 
     order.  When the developer has resolved the conflicts the check in is 
     performed again.  If the merge step is also done with non-exclusive 
     locks then this step may need to be repeated.  Optionally, if exclusive 
     locks are used for the merge step, then the auto-merge step will fail 
     if another user is already doing an exclusive merge on the tip.
     
     Notes on Collaborative Mode:
     1. Checkouts are done within the context of a particular line of decent 
     (branch), normally the mainline (trunk). 
     2. Works well with lots of small changes performed over a short period 
     of time in different parts of the system (with relatively few 
     conflicts).
     3. Does not work as well with major changes diverging over a long 
     period (with many or complex conflicts).
     4. Very popular with content oriented developers.  Reduces the 
     conflicts and blocks with getting files changed.
     5. Differs from the usual parallel development style in that users do 
     not normally have to deal with creating and managing branches.  The 
     system does this for them.
     6. This mode does not provide all capabilities manual branching can 
     accomplish.  Rather, it is a way for providing simple support for 
     safer parallel development.
     7. The automerge functionality is optional, and can simply provide both 
     copies of the file to be hand merged.  It can also do real merging, 
     identify conflicting records, and allow the user to choose.  BTW, 
     binary merging can also be done in a general way, as long as there 
     is a general way of specifying the record boundaries.  But I think 
     this is beyond the scope of what WebDAV needs to worry about.
     
     End Game Mode.
     When approaching a release it becomes important for the development 
     team to stabilize the system. Exclusive locks are used to prevent 
     conflicts in individual files.  Fixed labels are applied to all files 
     as part of a process to create baseline configurations of the system 
     for evaluation.  Essentially, during the end game the development style 
     becomes more sequential, less parallel.
     
     Both styles of development can be used on the same project at the same 
     time.  The assumption being that one group is in process of releasing, 
     while the other is pushing forward with new development.  However, if 
     the end game mode developers hit conflicts from the collaborators they 
     will end up creating branches.  These branches generally turn into 
     dead-ends, with selective merging back to the mainline.

Received on Thursday, 6 August 1998 20:54:21 UTC