Collaborative Distributed Text Editing

Een probleem bij een Wiki dat optreed als je gelijktijdig aan eenzelfde pagina (bijvoorbeeld met notities over een onderwerp) wilt werken is dat verschillende versies niet automatisch samengevoegd worden.
Daar heb je dan (dus) een apart stuk software voor nodig dat alle gebruikers aan elkaar verbind (zoals bijvoorbeeld een InstantMessaging client) en het mogelijk maakt dat ze samen aan een pagina werken.

Tot nu toe was er (voor zover bekend) alleen een applicatie voor Apple gebruikers beschikbaar: SubEthaEdit, maar nu is er ook MoonEdit.


Opmerkingen

Het bovenstaande is waarschijnlijk goed bedoeld maar....

externe linkDit probleem is al jaren geleden ontdekt en opgelost in verschillende vormen zelfs.

Vooral bij software ontwikkeling is het normaal om een document repository te gebruiken die de complete ontwikkelingsgeschiedenis bijhoud, en gedeeltelijk automatisch/gedeeltelijk handmatig (als automatisch niet mogelijk is) document samenvoegt als nieuwe versies door verschillende mensen worden aangeboden.

Je kunt hier aan dus bijvoorbeeld vragen hoe de documenten er 300 dagen geleden uitzagen, wie welke veranderingen heeft doorgevoerd, wie verantwoordelijk is voor een fout. Het is echt verbazingwekkend dat dit niet meer gebruikt wordt.

Er is een externe linkandere alternatief en dat is WebDAV met externe linkDeltaV. Maar tot nu toe heeft nog niemand naar tevredenheid een client geïmplementeerd. Stel je hier bij voor dat je een map hebt waar je niet alleen de huidige laatste versie van de documenten van kunt lezen, maar ook (op de een of ander wijze) kunt aangeven welke historische versie je wilt hebben. Laat het duidelijk zijn dat nog niemand dit in een bruikbare manier heeft toegepast en dat we nog op zoek zijn naar een geschikte interface met de gebruiker.


Ik vind de uitleg waar externe linkhierboven naar gelinkt wordt over locking etc. heel interessant, maar weet niet inhoeverre dat overeen komt met hoe SubEthaEdit werkt. Zo vraag ik me bijvoorbeeld af hoe dat werkt bij (bijvoorbeeld) 5 of 6 gelijktijdige editors. Is dat principe dan ook nog werkbaar? (PierreGorissen)

In de praktijk zal meer dan een conflict tussen twee mensen nooit voorkomen, het systeem staat dat niet toe. In de praktijk, aangezien mensen niet vaak tegelijk exact de zelfde regels aan het bewerken zijn, zijn er echter vrijwel geen conflicten.

Het verschil is dat SEE interactief en direct is, terwijl SVN dit niet is. Met SVN krijg je een eigen kopie van de documenten die je kunt gebruiken en aanpassen en daarna weer samenvoegen met de repository. Dit betekend dat SEE alleen werkt als je gelijktijdig online bent op hetzelfde netwerk, terwijl SVN alleen tijdens het ophalen en samenvoegen van de files een verbinding nodig heeft met de repository.

Vooral in een wereld van Notebook's en medewerkers in verschillende tijdzones die niet altijd (tegelijk) online zijn is SVN een prima aanvulling op SEE, ze dienen ieder een andere markt en behoefte. (GideonKlok)

OK, ik had er namelijk voor het eerste van gehoord in een situatie waar mensen wél tegelijkertijd online zijn (zoals bij een workshop, discussiesessie, etc.) en dan aantekeningen willen maken binnen een Wiki-pagina die als soort gezamenlijke notulen dienst doet. Vandaar. (PierreGorissen)

Daar is SEE, vooral vanwege ZeroConf erg goed geschikt voor. Maar als men denkt aan het schrijven van software in een team dan kan men beter een goede versie beheer hebben zonder dat dit direct betekend dat iedereen tegelijk online moet zijn.

Persoonlijk verbaast het mij al tijden dat Apple of Microsoft niet al lang hun file systems met versie beheer zouden hebben uitgevoerd. Zodat elke map die je opened de huidige toestand weergeeft, maar ook een interface heeft waarmee je de tijd terug kunt draaien en zo direct naar de eerdere toestanden kunt gaan. Zoals page history van een wiki? Technisch zou dat niet zo'n groot probleem zijn (vooral voor Apple niet), vooral niet als je dit alleen in de ~/Documenten/ map doet...

Technisch intermezzo: legacy apps verwachten een lock wat lastig is, maar dat kun je faken door elke read() van de file te doen van een copy van de file in de toestand waarin deze geopend is, en elke write() is een aanpassing van deze file. Pas op het moment dat de file gesloten wordt wordt de nieuw versie toegevoegd aan de repository. Dit lost niet alle problemen op maar wel genoeg zou ik zeggen. Nieuwe apps zouden dan een file_id = open(path, timestamp) en krijgt dan een kopie van de file in die toestand. Voor de rest is het allemaal het zelfde. Wel moet je dan eigenlijk op laag niveau een duidelijk verschil maken tussen files en streams want een file gebruiken als pipe wordt zo onmogelijk.

WebDAV (+ DeltaV) bied deze mogelijkheid zonder dat je een commandline tool moet leren. Ik hoop dus dat dit een succes wordt.


Aangezien SubVersion geen mirror optie ondersteund ben ik gaan zoeken naar een PeerToPeer oplossing die dit kwetsbaar punt (slechts 1 server) niet heeft. Ik vond GnuArch, en het zag er eerst veel belovend uit, maar Arch is gewoon veel te ingewikkeld in gebruik. Daar op kwam ik uit bij Darcs. Darcs is eenvoudig, simple, en het werkt gewoon, het is dan ook mijn favoriete versie beheerssysteem op dit moment.

Pagina's die naar hier verwijzen

Trackbacks (URL)

Er zijn geen trackbacks voor deze pagina.

Reacties

Er zijn nog geen reacties bij deze pagina. [Reactie toevoegen]