Keith Fahlgren (Publishing Technology Consultant, Threepress Consulting Inc), tidigare anställd på O'Reilly Publishing, och Adam Witwer (Publishing Services Manager, O'Reilly Media, Inc) berättar om hur O'Reilly har arbetat med olika former av versionhantering och vad som varit lyckat och mindre lyckat.
O'Reilly utgår från ett serverbaserat versionskontrollsystem som deltagarna i ett bokprojekt (författare, readaktörer, sättare etc) kan checka in och ut material ur.
Systemet är open source och heter SVN (Subversion).
Några lärdomar de har dragit under införandet av SVN på O'Reilly är följande:
Lås inte materialet för hårt (då någon arbetar med det)
Förr i tiden låste de flesta versionshanteringssystem material helt medan en medarbetare arbetade med det. Det kan ge problem om låsningen är stenhård - vad händer om någon blir sjuk eller någon viss läsa något samtidigt som någon annan arbetar med att redigera det? Det är enligt Keith bättre att checka in och ut ofta, samt meddela att någon annan kan tänkas jobba med materialet.
Hur mycket ska man begränsa användarrättigheterna?
Vem ska få tillgång till att visst material eller vad man får göra med det? Det är enklast att börja "promiskuöst" och låta de flesta komma åt det mesta (inom ett bokprojekt de är med och jobbar i) och därefter begränsa rättigheterna om/när man märker att det behövs.
Allt material behöver inte versionskontrolleras
Det kan bli för mycket administration/irritationsmoment (automatiserade meddelande om förändringar etc) om allt råmaterial för en bok versionskontrolleras (t.ex. varje enskild bild).
Definiera överlämningspunkter i projekt noggrant
Det är viktigt att definiera olika faser i bokprojekt och sätta rättigheter därefter. Har författaren lämnat in slutmanus, kanske han inte ska ha skrivrättigheter till manus därefter, istället får korrekturläsaren skrivrättigheter etc.
Arbeta med Word
Använd samma version och funktionen spåra ändringar
XML
Använd ett verktyg som Oxygen XML editor. (Det gör vi redan i vissa XML-projekt på Studentlitteratur.)
Email är ett urdåligt sätt att versionshantera
Att bara spara email med nya versioner av manus etc, brukar vara ett rörigt sätt att versionshantera.
Email + hooks till versionshanteringssystem = bra
Ett versionshanteringssystem (t.ex. webbaserat) som håller reda på datum, vem som redigerat vad kan bli ännu bättre i kombination med e-mail - och skicka meddelanden om att saker hänt.
Var försiktig med webbaserade lagringssystem
Webbaserade lagrings/kollaboreringssystem du inte själv kontrollerar (utan betalar en månadsavgift för) kan tyckas billiga per projekt, men kan vara dyra i längden, dessutom måste saker flyttas därifrån om du vill sluta betala månadshyran. Bättre att satsa på egen infrastruktur.
Adobes InCopy - är det bra?
Adobes versionshanteringsystem för InDesign, InCopy, var enligt Adam tämligen dåligt fram till och med CS3, men från och med CS4 är det ett hyfsat verktyg, dock inte lika bra som SVN på vissa punkter. Dessutom fungerar det bara med InDesign.
Hur kommer man igång med att använda verktyget SVN?
Enklast är att göra ett pilotprojekt. Alla i detta projekt måste vara överens om att använda SVN (författare, redaktörer, sättare, utgivningsansvarig etc).
Tilläggsverktyg som behövs
TortoiseSVN är det mest använda grafiska användargränssnittet för SVN (som är ett serverbaserat system utan egen front end). Alternativt kan man använda WebDAV (ser ut som vanliga mappar i ett filsystem) som ett enkelt gränssnitt mot användaren.
Inga kommentarer:
Skicka en kommentar