Tải bản đầy đủ - 0 (trang)
Chapter 2. Subversion's Delta Editor: Interface As Ontology

Chapter 2. Subversion's Delta Editor: Interface As Ontology

Tải bản đầy đủ - 0trang

2.Subversion'sDeltaEditor:Interface

AsOntology

KarlFogel

Examplesofbeautifulcodetendtobelocalsolutionstowell-bounded,easily



comprehensibleproblems,suchasDuff'sDevice

(http://en.wikipedia.org/wiki/Duff's_device)orrsync'srolling

checksumalgorithm

(http://en.wikipedia.org/wiki/Rsync#Algorithm).Thisisnot

becausesmall,simplesolutionsaretheonlybeautifulkind,but

becauseappreciatingcomplexcoderequiresmorecontextthan

canbegivenonthebackofanapkin.

Here,withtheluxuryofseveralpagestoworkin,I'dliketotalk

aboutalargersortofbeauty—notnecessarilythekindthat

wouldstrikeapassingreaderimmediately,butthekindthat

programmerswhoworkwiththecodeonaregularbasiswould

cometoappreciateastheyaccumulateexperiencewiththe

problemdomain.Myexampleisnotanalgorithm,butan

interface:theprogramminginterfaceusedbytheopensource

versioncontrolsystemSubversion(http://subversion.tigris.org)

toexpressthedifferencebetweentwodirectorytrees,whichis

alsotheinterfaceusedtotransformonetreeintotheother.In

Subversion,itsformalnameistheCtypesvn_delta_editor_t,

butitisknowncolloquiallyasthedeltaeditor.

Subversion'sdeltaeditordemonstratesthepropertiesthat

programmerslookforingooddesign.Itbreaksdownthe

problemalongboundariessonaturalthatanyonedesigninga

newfeatureforSubversioncaneasilytellwhentocalleach

function,andforwhatpurpose.Itpresentstheprogrammer

withuncontrivedopportunitiestomaximizeefficiency(suchas

byeliminatingunnecessarydatatransfersoverthenetwork)

andallowsforeasyintegrationofauxiliarytasks(suchas

progressreporting).Perhapsmostimportant,thedesignhas

provedveryresilientduringenhancementsandupdates.



Andasiftoconfirmsuspicionsabouttheoriginsofgooddesign,

thedeltaeditorwascreatedbyasinglepersonoverthecourse

ofafewhours(althoughthatpersonwasveryfamiliarwiththe

problemandthecodebase).

Tounderstandwhatmakesthedeltaeditorbeautiful,wemust

startbyexaminingtheproblemitsolves.



2.1.VersionControlandTree

Transformation

VeryearlyintheSubversionproject,theteamrealizedwehad

ageneraltaskthatwouldbeperformedoverandover:thatof

minimallyexpressingthedifferencebetweentwosimilar

(usuallyrelated)directorytrees.Asaversioncontrolsystem,

oneofSubversion'sgoalsistotrackrevisionstodirectory

structuresaswellasindividualfilecontents.Infact,

Subversion'sserver-siderepositoryisfundamentallydesigned

arounddirectoryversioning.Arepositoryissimplyaseriesof

snapshotsofadirectorytreeasthattreetransformsovertime.

Foreachchangesetcommittedtotherepository,anewtreeis

created,differingfromtheprecedingtreeexactlywherethe

changesarelocatedandnowhereelse.Theunchangedportions

ofthenewtreesharestoragewiththeprecedingtree,andso

onbackintotime.Eachsuccessiveversionofthetreeislabeled

withamonotonicallyincreasinginteger;thisuniqueidentifieris

calledarevisionnumber.

Thinkoftherepositoryasanarrayofrevisionnumbers,

stretchingoffintoinfinity.Byconvention,revision0isalways

anemptydirectory.InFigure2-1,revision1hasatreehanging

offit(typicallytheinitialimportofcontentintotherepository),

andnootherrevisionshavebeencommittedyet.Theboxes

representnodesinthisvirtualfilesystem:eachnodeiseithera

directory(labeledDIRintheupper-rightcorner)orafile

(labeledFILE).



Whathappenswhenwemodifytuna?First,wemakeanewfile

node,containingthelatesttext.Thenewnodeisnotconnected

toanythingyet.AsFigure2-2shows,it'sjusthangingoutthere

inspace,withnoname.

Next,wecreateanewrevisionofitsparentdirectory.AsFigure

2-3shows,thesubgraphisstillnotconnectedtotherevision

array.

Figure2-1.Conceptualviewofrevisionnumbers



Figure2-2.Newnodewhenjustcreated



Figure2-3.Creationofnewparentdirectory



Wecontinueuptheline,creatinganewrevisionofthenext

parentdirectory(Figure2-4).

Atthetop,wecreateanewrevisionoftherootdirectory,as

showninFigure2-5.Thisnewdirectoryneedsanentrytopoint

tothe"new"directoryA,butsincedirectoryBhasn'tchanged

atall,thenewrootdirectoryalsohasanentrystillpointingto

theolddirectoryB'snode.

Figure2-4.Continuingtomoveup,creatingparent

directories



Figure2-5.Completenewdirectorytree



Nowthatallthenewnodesarewritten,wefinishthe"bubble

up"processbylinkingthenewtreetothenextavailable

revisioninthehistoryarray,thusmakingitvisibletorepository

users(Figure2-6).Inthiscase,thenewtreebecomesrevision

2.

Thuseachrevisionintherepositorypointstotherootnodeofa

uniquetree,andthedifferencebetweenthattreeandthe

precedingoneisthechangethatwascommittedinthenew

revision.Totracethechanges,aprogramwalksdownboth

treessimultaneously,notingwhereentriespointtodifferent

places.(Forbrevity,I'veleftoutsomedetails,suchassaving

storagespacebycompressingoldernodesasdifferences



againsttheirnewerversions.)

Figure2-6.Finishedrevision:linktonewtree



Althoughthistree-versioningmodelisallbackgroundtothe

mainpointofthischapter(thedeltaeditor,whichwe'llcometo

soon),ithassuchnicepropertiesthatIconsideredmakingit

thesubjectofitsownchapter,asanexampleofbeautifulcode.

Someofitsattractivefeaturesare:



Easyreads



Tolocaterevisionnoffile/path/to/foo.txt,onejumpsto

revisionn,thenwalksdownthetreeto/path/to/foo.txt.



Writersdon'tinterferewithreaders

Aswriterscreatenewnodes,bubblingtheirwayuptothe

top,concurrentreaderscannotseetheworkinprogress.A

newtreebecomesvisibletoreadersonlyafterthewriter

makesitsfinal"link"toarevisionnumberintherepository.



Treestructureisversioned

Theverystructureofeachtreeisbeingsavedfromrevision

torevision.Fileanddirectoryrenames,additions,and

deletionsbecomeanintrinsicpartoftherepository's

history.

IfSubversionwereonlyarepository,thiswouldbetheendof

thestory.However,there'saclientside,too:theworkingcopy,

whichisauser'schecked-outcopyofsomerevisiontreeplus

whateverlocaleditstheuserhasmadebutnotyetcommitted.

(Actually,workingcopiesdonotalwaysreflectasinglerevision

tree;theyoftencontainmixturesofnodesfromdifferent

revisions.Thisturnsoutnottomakemuchofadifferenceasfar

astreetransformationisconcerned.So,forthepurposesofthis

chapter,justassumethataworkingcopyrepresentssome

revisiontree,thoughnotnecessarilythatofthelatestrevision.)







Subversion'sDeltaEditor:InterfaceAsOntology>

VersionControlandTreeTransformation



2.Subversion'sDeltaEditor:Interface

AsOntology

KarlFogel

Examplesofbeautifulcodetendtobelocalsolutionstowell-bounded,easily



comprehensibleproblems,suchasDuff'sDevice

(http://en.wikipedia.org/wiki/Duff's_device)orrsync'srolling

checksumalgorithm

(http://en.wikipedia.org/wiki/Rsync#Algorithm).Thisisnot

becausesmall,simplesolutionsaretheonlybeautifulkind,but

becauseappreciatingcomplexcoderequiresmorecontextthan

canbegivenonthebackofanapkin.

Here,withtheluxuryofseveralpagestoworkin,I'dliketotalk

aboutalargersortofbeauty—notnecessarilythekindthat

wouldstrikeapassingreaderimmediately,butthekindthat

programmerswhoworkwiththecodeonaregularbasiswould

cometoappreciateastheyaccumulateexperiencewiththe

problemdomain.Myexampleisnotanalgorithm,butan

interface:theprogramminginterfaceusedbytheopensource

versioncontrolsystemSubversion(http://subversion.tigris.org)

toexpressthedifferencebetweentwodirectorytrees,whichis

alsotheinterfaceusedtotransformonetreeintotheother.In

Subversion,itsformalnameistheCtypesvn_delta_editor_t,

butitisknowncolloquiallyasthedeltaeditor.

Subversion'sdeltaeditordemonstratesthepropertiesthat

programmerslookforingooddesign.Itbreaksdownthe

problemalongboundariessonaturalthatanyonedesigninga

newfeatureforSubversioncaneasilytellwhentocalleach

function,andforwhatpurpose.Itpresentstheprogrammer

withuncontrivedopportunitiestomaximizeefficiency(suchas

byeliminatingunnecessarydatatransfersoverthenetwork)

andallowsforeasyintegrationofauxiliarytasks(suchas

progressreporting).Perhapsmostimportant,thedesignhas

provedveryresilientduringenhancementsandupdates.



Andasiftoconfirmsuspicionsabouttheoriginsofgooddesign,

thedeltaeditorwascreatedbyasinglepersonoverthecourse

ofafewhours(althoughthatpersonwasveryfamiliarwiththe

problemandthecodebase).

Tounderstandwhatmakesthedeltaeditorbeautiful,wemust

startbyexaminingtheproblemitsolves.



2.1.VersionControlandTree

Transformation

VeryearlyintheSubversionproject,theteamrealizedwehad

ageneraltaskthatwouldbeperformedoverandover:thatof

minimallyexpressingthedifferencebetweentwosimilar

(usuallyrelated)directorytrees.Asaversioncontrolsystem,

oneofSubversion'sgoalsistotrackrevisionstodirectory

structuresaswellasindividualfilecontents.Infact,

Subversion'sserver-siderepositoryisfundamentallydesigned

arounddirectoryversioning.Arepositoryissimplyaseriesof

snapshotsofadirectorytreeasthattreetransformsovertime.

Foreachchangesetcommittedtotherepository,anewtreeis

created,differingfromtheprecedingtreeexactlywherethe

changesarelocatedandnowhereelse.Theunchangedportions

ofthenewtreesharestoragewiththeprecedingtree,andso

onbackintotime.Eachsuccessiveversionofthetreeislabeled

withamonotonicallyincreasinginteger;thisuniqueidentifieris

calledarevisionnumber.

Thinkoftherepositoryasanarrayofrevisionnumbers,

stretchingoffintoinfinity.Byconvention,revision0isalways

anemptydirectory.InFigure2-1,revision1hasatreehanging

offit(typicallytheinitialimportofcontentintotherepository),

andnootherrevisionshavebeencommittedyet.Theboxes

representnodesinthisvirtualfilesystem:eachnodeiseithera

directory(labeledDIRintheupper-rightcorner)orafile

(labeledFILE).



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 2. Subversion's Delta Editor: Interface As Ontology

Tải bản đầy đủ ngay(0 tr)

×