[Versioning] Homedirectory onder revision control

[JeRa]

Wat?

Ik gebruik diverse Windows- en Linuxsystemen op verschillende fysieke locaties door elkaar heen en ik loop daarbij op een vrij simpel probleem: ik heb m'n bestanden niet heel gemakkelijk bij de hand. De oplossing is echter niet zo simpel, aangezien ik een aantal vereisten heb voor die bestanden:

• Mijn bestanden moeten centraal beschikbaar en bijwerkbaar zijn via internet, en dit moet vrij vlot werken zolang de verbinding dit toestaat.
• Ik wil van alle bestanden een volledige geschiedenis bijhouden en dus over 10 jaar precies alle bestanden terug kunnen zien zoals ze op dit moment zijn.
• Zonder internetverbinding wil ik toch nog mijn bestanden lokaal kunnen benaderen en wijzigen (en eventueel lokaal revisies toevoegen die ik later synchroniseer met de centrale locatie).
• Ik wil ook gedeeltes van de directory tree kunnen ophalen in plaats van het gehele ding, zoals dit in Subversion mogelijk is.
• Ik wil lokaal niet veel meer schijfruimte kwijt zijn dan nodig is om de bestanden op te slaan.
• Op de centrale locatie wil ik niet meer schijfruimte kwijt zijn dan nodig; zie bijvoorbeeld git die belachelijk hoge deltacompressies behaalt.
• De bestanden moeten slim gesynchroniseerd worden: een kleine wijziging in een bestand van 300MB moet binnen een paar seconden centraal kunnen staan en opgehaald kunnen worden door andere clients.
• De eigenschappen/rechten van/op de bestanden moeten voor zover mogelijk ook opgeslagen worden; symlinks e.d. zijn niet interessant.
• Het geheel moet werken op tenminste Linux- en Windowssystemen.
• Het systeem moet soepel om kunnen gaan met grote(re) bestanden in de range van 100MB tot ongeveer 4GB (uitzonderlijk).
• Het systeem moet soepel om kunnen gaan met een groot aantal bestanden en moet bijvoorbeeld niet 3 minuten lang alle directories aflopen als ik één bestandje van 4 KB probeer in te checken.
• Het liefst moet het systeem niet in elke directory een subdirectory of -bestand plaatsen.

Dit lijstje met wensen is gegroeid uit ervaring met diverse tools die vaak goed werkten, maar één of meerdere ernstige beperkingen hadden. Een samenvatting van mijn ervaringen:

Unison

Met dit tooltje worden op een slimme manier bestanden gesynchroniseerd met een of meerdere servers, waarbij je gemakkelijk directory- en bestandsfilters kunt instellen.
Afgekeurd: geen bestandsgeschiedenis, geen compressie op de centrale locatie.

Subversion

Deze 'CVS done right' heeft een prima revisiecontrole en mogelijkheid tot checkouts van subdirectories e.d.
Afgekeurd: lokaal wordt 2x zoveel ruimte gebruikt door de zogenaamde 'pristine copies', op de centrale locatie vindt weinig tot geen compressie plaats, slechte ervaringen met grotere bestanden, plaatst in elke directory een .svn subdirectory.

Git

Oorspronkelijk door Linus Torvalds zelf geschreven, onderscheidt deze SCM zich door een bijzonder briljante deltacompressie en performance voor grotere projecten en vele kleine bestanden. Door de opzet van de repositories is het zelfs mogelijk om zonder internetverbinding de bestandsgeschiedenis bij te houden.
Afgekeurd: het is niet mogelijk om een gedeelte van de directorystructuur op te halen.

Dus?

Zo op internet gekeken zijn dit de drie tooltjes die het meest worden gebruikt voor homedir versioning, echter dus nog niet compleet geschikt. Git komt angstvallig dicht in de buurt van de ideale tool, maar de onmogelijkheid om een gedeelte van de repository op te halen maakt het helaas onwerkbaar (als ik even 2 tekstdocumentjes wil aanpassen op een niet-standaard locatie wil ik niet een paar gigabyte aan videomateriaal voor andere projecten binnenhalen).

Ik ben op zoek naar het ideale tooltje en tegelijkertijd van gedachten met jullie wisselen over het wel en wee van deze manier van bestanden opslaan en backuppen (want dat is het in feite, naast dat de centrale locatie natuurlijk ook extra wordt gebackupped). Wie heeft er suggesties?

[djluc]

Zorg voor een goede beveiligde webinterface voor als je een keer een paar bestandjes wilt hebben en ga git gebruiken?

[JeRa]

djluc schreef op woensdag 04 maart 2009 @ 22:01:
Zorg voor een goede beveiligde webinterface voor als je een keer een paar bestandjes wilt hebben en ga git gebruiken?

Dat is op zich een goede optie, dan zou ik echter geen 'bare' repository kunnen gebruiken op de centrale locatie. Dit houdt in dat ik naast alle gecomprimeerde bestanden en de geschiedenis van die bestanden ook de ongecomprimeerde bestanden beschikbaar moet hebben (en ruimte laat wegvreten) en ik aan de serverkant commits moet gaan uitvoeren.

Het is zeker een optie, maar niet de meest praktische imho

[djluc]

Een simpele tool die je bare repository kan tonen als echte tree moet wel lukken toch?

Toevallig vandaag flink aan het GIT automatiseren geweest vandaar dat ik dat idee heb. Als het command line kan is een simpele interface niet zo'n klus?

[JeRa]

djluc schreef op woensdag 04 maart 2009 @ 22:12:
Een simpele tool die je bare repository kan tonen als echte tree moet wel lukken toch?

Toevallig vandaag flink aan het GIT automatiseren geweest vandaar dat ik dat idee heb. Als het command line kan is een simpele interface niet zo'n klus?

Tja, het probleem met git is dat je over het algemeen geen losse files of directories kunt pullen en vervolgens weer pushen. Maar het idee klinkt goed, dus ik heb even wat nagezocht

WebDAV middels nginx

And currently this is a showstopper. nginx http_dav_module does not support PROPFIND method yet, and git-http-push requires it. I am working on extending http_dav_module to support the missing methods but it’s complicated and I do not have much time for this. For now see comments for possible workarounds.

Lijkt geen optie dus.

git over http(s)
Dit is alleen een methode om te pushen en pullen over HTTP(s), niet voor losse bestanden dus.

Ik geloof dat het wel mogelijk is om losse bestanden uit een repository te trekken (webclients voor git kunnen dit immers ook) maar het pushen kan alleen als je de gehele repository binnengehaald hebt (of aan de serverkant de hele repository pullt en de bestanden er overheen kopiëert). Het valt wel te automatiseren, maar snel of efficiënt is zoiets weer niet

[!null]

Hoe gaat het met bestanden van een paar honderd MB in SVN? Want tja, bij 4GB, dan ben je het voor het verkeerde doel aan het gebruiken, eigenlijk bij heel veel tools. Daarvoor heb je FTP. Ik weet niet wat voor bestanden dat zijn, maar van DVD's of images wil je toch geen bestandsgeschiedenis etc.
Ik wist overigens niet dat bij SVN lokaal 2 maal zoveel gebruikt werd.

Ik zeg eigenlijk nog steeds SVN en voor de rest (S)FTP. Maar dat hangt af van je gebruik, en wat voor bestanden die grotere bestanden zijn. En het lijkt me een verschil in ervaring tussen 200mb of 4GB, dus ook daar onderscheid in.

[JeRa]

GreenSky schreef op woensdag 04 maart 2009 @ 22:41:
Hoe gaat het met bestanden van een paar honderd MB in SVN? Want tja, bij 4GB, dan ben je het voor het verkeerde doel aan het gebruiken, eigenlijk bij heel veel tools. Daarvoor heb je FTP. Ik weet niet wat voor bestanden dat zijn, maar van DVD's of images wil je toch geen bestandsgeschiedenis etc.
Ik wist overigens niet dat bij SVN lokaal 2 maal zoveel gebruikt werd.

Het valt ook niet op bij het maken van een checkout, maar de uiteindelijke grootte is inderdaad vaak meer dan 2x zo groot

Ik zeg eigenlijk nog steeds SVN en voor de rest (S)FTP. Maar dat hangt af van je gebruik, en wat voor bestanden die grotere bestanden zijn. En het lijkt me een verschil in ervaring tussen 200mb of 4GB, dus ook daar onderscheid in.

Die 4GB zal echt een uitzonderlijk geval zijn, sterker nog, ik wil alleen de optie openhouden. Sommige SCMs (zoals ook oude versies van git) hebben problemen met repositories groter dan 4GB (in totaal!) en dat is niet iets waar ik graag tegenaan wil lopen.

En wat betreft de inhoud: ik werk soms met grote hoeveelheden aan (meet)data, soms in de vorm van veel tekstuele gegevens, soms in de vorm van video- of audiomateriaal. Die wil ik dan ook niet zozeer in de repository hebben vanwege de geschiedenis van de inhoud, maar wel omdat ik het af en toe nodig heb. Ik wil voorkomen dat ik twee of meer losse systemen moet gaan gebruiken voor één set bestanden.

--- edit
Een nieuwe mogelijkheid waar ik zojuist op kom is een combinatie van unison en git: unison gebruiken om de bestanden te synchroniseren met een centrale locatie, en git op die locatie gemakkelijk aanspreekbaar maken om een repository bij te werken met veranderingen.

Nadeel aan deze methode blijft dan wel dat op de centrale locatie veel meer schijfruimte benodigd is en dat er een interface gemaakt moet worden om git aan te spreken, maar het lijkt me op dit moment wel de meest reëele optie

[ Voor 14% gewijzigd door JeRa op 04-03-2009 22:53 ]

[!null]

Hmm ja dan is het voor te stellen, ik dacht meer aan iso's etc, van films of OS images etc, dingen die in een andere set vallen als je normale werk. (ik backup dat soort dingen niet eens, een beetje films backuppen of Ubuntu image zoveel backuppen, niet erg nuttig)

Ik zou eigenlijk gewoon SVN gaan gebruiken en kijken waar je tegenaan loopt. Want ik vraag me ook af, als je ergens anders bent en je wilt dus een update doen bijvoorbeeld, dan heb je sowieso een probleem doorgaans, met grote bestanden, vanwege de internetverbinding.

[JeRa]

GreenSky schreef op woensdag 04 maart 2009 @ 22:56:
Hmm ja dan is het voor te stellen, ik dacht meer aan iso's etc, van films of OS images etc, dingen die in een andere set vallen als je normale werk. (ik backup dat soort dingen niet eens, een beetje films backuppen of Ubuntu image zoveel backuppen, niet erg nuttig)

Nope, dat zijn dan ook dingen die ik per systeem lokaal houd. Films, images van cd's en dvd's, backups etc zijn allemaal niet interessant om te backuppen óf de bestandsgeschiedenis van bij te houden.

Ik zou eigenlijk gewoon SVN gaan gebruiken en kijken waar je tegenaan loopt. Want ik vraag me ook af, als je ergens anders bent en je wilt dus een update doen bijvoorbeeld, dan heb je sowieso een probleem doorgaans, met grote bestanden, vanwege de internetverbinding.

Subversion valt voor mij eigenlijk al af vanwege het hoge gebruik van schijfruimte en traagheid bij grote bestanden. SVN moet namelijk bij een commit het bestand naar een tijdelijke locatie kopiëren (dan heb je het dus 3x op je schijf staan!) en vervolgens een tijdrovende binary diff gaan doen die daar eigenlijk niet voor gemaakt is (daar is unison weer beter in). Bovendien is de storage aan de serverkant mijns inziens ook niet echt ideaal (een niet-gecomprimeerd bestand per revisie met delta's op basis van één bestand ipv meerdere bestanden zoals git).