29
1.9 Configurationandversionmanagement
Manyofthetypesofstatetrackingdiscussedaspartofthesectiononconcurrencyare
thelogicalvariationsoftheproblemofversionmanagement.Thisproblemhasbeenvery
thoroughlyexaminedinthecontextofsoftwaredevelopment.However,theproblemsofde-
velopingsoftwarearedifferentfromsomeformofcollaborativework,particularlythe
authoringofdocuments.Collaborativeeditingoftextshasanumberofspecializedproperties
thatdifferentiateitfromsoftwaredevelopment:
Theunstructurednatureofmostauthoringtasksmakesitunlikelythatauthorswillad-
heretocomplexandexplicitprocessmanagementprotocols.
Thesmallestunitoftexteditingiseitherthecharacterortheword.Thelineofcodeis
thetypicalunitforsoftware.
Thetimescaleofupdatesismuchmorevariableinauthoringthaninsoftwareengi-
neering.
Mergeandselectiveundoofchangesaremorelikelytobefrequentoperationsintext
editing.
Thewillingnessofauthorstolearncomplexversionmodelsthatenforcehighlystructured
updateprotocolsisprobablylessthanthatforsoftwareengineers.Collaborationinsoftware
engineeringistightlystructuredduetotheexigenciesofcreatingreliableprograms,espe-
ciallylargereliableprograms.Softwareengineeringsupportsystemssystemsmustaddressa
numberofdifficultproblemsofconsistencymanagementthatdonotexistforauthoring,
becauseofthelargenumberofpotentiallymachine-verifiablepropertiesprerequisitetothe
creationofworkingsoftware.Thisisnotbecauseinconsistenciesintextsdon’texist,but
becausethereisnohopeofautomaticallydetectingthem.Ontheotherhand,theproblems
ofchangetrackinginsoftwaresystemsareinsomewayseasier:formalmanagementofthe
process(inwaysthatareunlikelytobeadoptedforwritingtasks)reducesthenumberof
30
conflictsbetweencollaborators.Thehighlymodularnatureofmostsoftwarealsoreduces
conflictssinceaprogramistypicallydividedintomanysemi-independentfiles,eachcom-
posedofmanysemi-independentunits(subroutines,methoddefinitions,datadefinitions,
etc.).
Thegranularityatwhichchangesneedtobetrackedisalsofixedandrelativelylarge,
sincethelineofcodeisanadequate,relativelyuniformunitinalmostallprogramminglan-
guages.
Documenteditors,unlikecodeeditors,mayneedtosupportcollaborationatatimescale
thatisverydifferentfromthatinsoftwaredevelopment.Real-timesharededitingisnot
easilypossibleunderacheck-in/check-outmodel,noriscommunicationbyasharedfilesys-
temnecessarilysensibleforsuchsituations.Real-timeupdatebymultipleauthorsisessen-
tiallyavariationofthemergeproblem;evensourcecodecontrolsystemslikeCVSthatsup-
portautomaticmergingarenotdesignedforthisfrequencyofupdate.Insummary,the
problemsofcollaborativedocumenteditingaresimplydifferentfromthosefacedbysoftware
engineering,despitethesimilarityoftheproblemsandpointsoftechnicaloverlap.
Someofthesedifferenceshaveeffectsonthemostappropriateunderlyingtechnologies;
line-baseddifferencealgorithmsarenotsuitablefortext(Neuwirth,Chandhoketal.1992);
mergeandselectiveundoarerelativelyinfrequentoperationsinsoftwareengineering.Oth-
ersaffecttheuserrequirements:theneedtosupportinformalaccessprotocols,andtheneed
topresentarelativelysimpleversionmodel.Ageneralframeworkshouldalsosupportawide
rangeofpoliciesforversionmanagement,underthecontroloftheapplication.Noone-
versionmanagementmodelwillservealldifferentneeds.Ibrieflyconsidersomeneedsand
approachestoversionmanagementbelow,allofwhich,ideally,shouldbeavailabletoan
applicationdesigner.TheVerSEsystemhasproposedthenotionofuserselectable
“versioningstyles”(HaakeandHicks1996)thataresupportedbyasystemontopofanin-
tegratedframeworkandthatcanevenbeadjustedasthepatternofcollaborationchanges.
Previous Page Next Page