xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/01/90)
yam@cbnewsi.att.com (toshihiko.yamakami) writes: >I was just back from IFIP WG8.4 Multi-User Interfaces and Applications >Conference(Sep 24-26), Crete, Greece. >There were three design policies which I was interested: >(1) Multi-user hypertext design which is intended for multi-user application > platform > My most favorite paper in this conference is 'Platform and Application >Issues in Multi-User Hypertext'(L.M.Berlin & Vicki L. O'Day; HP Lab; >pp.293-304). [...] > I am also interested in their arguments that multi-user versioning may >just move the problem from concurrency control to 'merge management'. > I agree with the fact that it is easy to produce many versions, >however, it is difficult to merge them to produce a single shared artifact. That was indeed an astute observation. I worked for a short time (ten months) in a shop that used a working paradigm of branching a version per worker (six of us) and then prior to a product upgrade release, assigning one worker full time to the merge task, with assistance from the rest as needed. It took as long, calendar time, for the one worker to merge the work as it had taken for the six workers to create it, and the remaining five were tasked about half time with helping resolve conflicts outside the expertise of the worker doing the merge, which puts the overhead for doing the merge at about 60% in programmer time or 100% in schedule time, whichever seems more important. The unquantified savings came from letting each worker proceed without the (usually very high) overhead of incessant consultation during the premerge development portion of the effort. I saw enough merges to make this (cost) seem reasonably constant, so it might be a good place to start for planning purposes when considering this paradigm of operation. FYI. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>