Wiki-filer för Windows?

[janno]

Har man diskplats så fungerar det väl ok. Git sparar hela binära filen. Men det är ju inte varje ändring man gör som sparas utan du behöver själv tala om att nu vill jag spara mina ändringar som en ny master och har man en git server (det går att göra detta helt lokalt också, men du får automatiskt backup med en server) så gör du en avgrening när du börjar dina ändringar fixar och donar lokalt och gör commits när du tycker att du vill spara ändringarna. Sedan gör man sync till servern så flyttas alla ändringar och commits till servern.
Det finns humdratals sidor på nätet som behandlar hur git fungerar, de flesta är dock fokuserade på källkod där det verkligen är ett oumbärligt verktyg.

Lite om hanteringen av binära filer
https://opensource.com/life/16/8/how-ma ... git-part-7

[TomasL]

Förmodligen är svn lättare att sätta upp, eftersom svn stöder binärfiler per default.

[janno]

Nja, tveksamt.
ladda ner och installera git.
skapa ett bibliotek eller gå till ett existerande.
vid kommandoprompten skriv.

Kod: Markera allt

git init
git add
git commit

init - skapar gits versionshantering för foldern
add - lägger till alla filer i det (binärer, textfiler och vad som finns där)
commit - sparar ändringarna i foldern i versionshanteringen

[TomasL]

Nu använder jag iofs sedan lång tid tillbaka svn, till i princip allt som skall versionshanteras.

[AndLi]

Jag hängde länge kvar vid svn, men tillslut blev jag övertvingad... jag undra bara varför jag inte bytte tidigare...

[guckrum]

Ingen skall börja versionshantera med svn år 2019, git är överlägset. (Sitter man med gamla system är det en annan sak.) Beträffande binärfiler så finns det ingen magisk lösning, de sparas som binärblobbar. Bildfiler är typiskt hårt entropipackade med avseende på det mänskliga ögat, och göra enkla diffar av dem är ett (mig veterligen) olöst problem. Olika filer är olika, helt enkelt. (I min värld är många bilder grafer eller diagram, och då versionshanterar man "källfilen" och "receptet" som skapar bilden ur källfilen, aldrig själva bilden. Och då fungerar diffbaserad versionshantering effektivt.)

Beträffande dokumentationsmjukvara så tycker jag att org-mode i emacs är svårslaget. Det funkar på alla platformar och är snabbt på i princip all hårdvara. Med org kan man skapa anteckningar, olika todo-listor, kalkylark med obegränsad komplexitet, kalendrar med mera. Allt kan "taggas" med valfritt antal tags, och man söker, länkar och sorterar enkelt på tags. Givetvis textbaserat så att man kan läsa, söka och skapa med valfri texeditor/pager och versionshantera med sin favoritversionshanterare.

[Spisblinkaren]

Om du sparar i OneDrive och kör Word senare än 2016 så kan du återgå till gamla versioner. Kör du Libre/Open office writer istället för Word så får du versionshantering utan att behöva spara i OneDrive.

Men då skiljer det sig från kollegieblocket! I kollegieblocket kan du inte få tillbaka saker du raderat. Och skriver du med kulspetspenna (för att inte kunna radera) så kan du inte ändra på nåt du redan skrivit.

I Word så om du lägger till en ny sida på slutet har du ju alla gamla sidor kvar före? Du sitter och jämför "lägga till en ny sida" (vilket funkar i både Word och kollegieblocket) med "redigera en sida" (vilket bara fungerar i Word).

Du verkar jämföra kollegieblockets sidor med hela Word-filer, men det är ju ett felaktigt resonemang. En Word-fil har flera sidor, lägger du till en ny sida finns alla de gamla sidorna fortfarande kvar.

Du är trevlig att diskutera med!

Precis en sådan antagonist som jag behöver.

Jag har läst alla andras inlägg ovan och finner dom intressanta men tyvärr hänger jag inte alls med i jargongen.

Tänkte jag skulle be om ursäkt idag för jag fick ångest i morse över min framfart igår.

Dock kom jag på att min ide' ju inte bara är revolutionerande, den är briljant (säger jag med glimten i ögat).

Men varför är den det?

Jo, samtidigt med ångesten kom jag på att min ide' kan appliceras på precis ALLA filtyper i en dator!

Och vad är poängen med det?

Jo, ta en filtyp bara som .txt, .doc. xls .bat osv, dom är INTE avhängiga ett revisionshanterande eller ej, de kan lika gärna revisionshanteras de också.

Med andra ord behövs inte "vanliga" filer överhuvudtaget, bort med den filtypen bara!

Istället kör man "wiki-filer" på ALLA filtyper.

Och vad är vitsen med det?

Jo, man kan gå in och ändra i mer eller mindre alla systemfiler/drivrutiner efter vad man känner för (rekommenderar dock inte att man ändrar i drivrutinen för hårddisken...) OCH om ändringen blev ett misslyckande så är det bara att backa (rekommenderar dual boot med DOS 6.22 här ).

Man kan liksom leka mer safe med datorn då än vad man kan idag, nästan som barnungar leker med teknik (de kan ofta mycket mer än vad jag kan för jag vågar inte "leka" med datorn samtidigt som trial-and-error är en erkänd, om än primitiv, inlärningsmekanism)

Idag måste man ju liksom spara en kopia av filen, döpa om till nåt obs (jag brukar hänga på _bak), sen provändra i ordinarie fil och spara.

Vilket jävla meck!

Samma, om inte värre, meck är det när man sitter och utvecklar nåt i säg paint, personligen vill jag kunna backa åtminstone en gång per dag vilket får till följd att jag ökar löpnumret på projektfilen VARJE kväll.

Ett lite mer komplext projekt såsom mitt oscilloskopbygge kan då innebära 30-talet filer innan man känner att man kan göra nåt slags avstamp.

För att hitta den senaste filen så kan det bli lite problem när man även döper om saker till kortare namn men TomasL har lärt mig att man kan nyttja datumkolumnen vilket jag tycker funkar relativt bra.

Men bara relativt bra för min ide' skulle göra att det funkar perfekt.

För föreställ Er att jag istället för 30 filer bara har EN fil!

Vad mycket renare och mer lättarbetad mappen skulle se ut då!

Nej, dagens filsystem suger.

MVH/Roger
PS
Svar till Nerre:

Du verkar jämföra kollegieblockets sidor med hela Word-filer, men det är ju ett felaktigt resonemang. En Word-fil har flera sidor, lägger du till en ny sida finns alla de gamla sidorna fortfarande kvar.

Det verkar som om det var länge sedan du använde ett kollegieblock Kollegieblocket, när man skrivit ett antal sidor, är ju PRECIS som Word-dokumentet. Idag (obs) finns det ju inte ett spår av skillnad! Att lägga till en sida, det är väl bara att vända på bladet, eller? Ponera sedan att du skrivit 20 sidor i Word, sen får du för dig att ändra sidan 10 fullständigt. Och sparar. Sedan kommer du på att fasen också "det gamla var ju bättre". Men då kan du inte backa för det är överskrivet, OMM du inte sparar med löpnummer skapade med nån stokastisk och ganska oprecis metod för du kommer aldrig lyckas spara just den dokumentversionen du vill tillbaka till samtidigt som man inte orkar skapa löpnummer hela tiden. Och det är här filsystemet av idag brister.

[guckrum]

Istället kör man "wiki-filer" på ALLA filtyper.

Om du kör något UN*X/Linux-liknande är i princip alla intressanta filer textfiler. Majoriteten av resten av filerna är kompilerade binärer som är skapade ur just textfiler. Wiki-filer är också textfiler.

Och vad är vitsen med det?

Jo, man kan gå in och ändra i mer eller mindre alla systemfiler/drivrutiner efter vad man känner för
...
Idag måste man ju liksom spara en kopia av filen, döpa om till nåt obs (jag brukar hänga på _bak), sen provändra i ordinarie fil och spara.

Vilket jävla meck!

Och eftersom de är textfiler kan man göra just det. Idag eller för 30 år sedan, det såg likadant ut då. Jag versionshanterar operativsystemets konfigurationsfiler med git. Full koll.

Samma, om inte värre, meck är det när man sitter och utvecklar nåt i säg paint, personligen vill jag kunna backa åtminstone en gång per dag vilket får till följd att jag ökar löpnumret på projektfilen VARJE kväll.

Vettiga program sparar i text så att man kan versionshantera sina filer på ett vettigt sätt. Jag versionshanterar till exempel mina Eagle CAD-filer i git så att jag kan backa, ändra eller rent av ta bort ett steg i mitten som jag ångrar senare. På köpet får jag en dokumentation av designprocessen via git-loggen.

[janno]

Jag vara bara tvungen och testa lite och det du eftersöker med att ha en fil som du kan ändra på och hämta vilken version du vill av. Kan du göra med git.
Exempel samma fil i två versioner, du kan ha så många du vill.

diff bmp.png

[Spisblinkaren]

Låter väldigt bra det där med git.

Men jag tycker det är fel väg att gå.

Alla filtyper borde ha en revisionshantering från början dvs felet sitter i OS och inte i vilket program man kan ladda ner, installera och köra.

Det är vad jag tycker i alla fall.

Men jag ska inte tråka ut Er mer.

MVH/Roger, signing off

[Nerre]

Det verkar som om det var länge sedan du använde ett kollegieblock :) Kollegieblocket, när man skrivit ett antal sidor, är ju PRECIS som Word-dokumentet. Idag (obs) finns det ju inte ett spår av skillnad! Att lägga till en sida, det är väl bara att vända på bladet, eller? :humm: Ponera sedan att du skrivit 20 sidor i Word, sen får du för dig att ändra sidan 10 fullständigt.

Varför ändrar du sidan 10? det gör du ju inte i kollegieblocket, så varför gör du det i Word-dokumentet? Du lägger väl till en sidan 21 istället och "vet själv" att den gamla sidan 10 inte längre är aktuell?

Och det är här filsystemet av idag brister.

Och det beror historiskt sett just på att varje version av en fil tar upp utrymme.

Tänk dig t.ex. systemfiler som kanske ändras flera gånger i minuten... Är det verkligen vettigt att ha versionshantering av dem?

Men det finns operativsystem som har versionshantering av alla filer, VMS t.ex.

[Spisblinkaren]

Tänk dig t.ex. systemfiler som kanske ändras flera gånger i minuten... Är det verkligen vettigt att ha versionshantering av dem?

Tänkte inte skriva mer i det här ämnet men den här kommentaren är så bra att jag känner att jag måste.

Kodeffektiv programmering existerar inte överhuvudtaget idag.

På Atari-tiden kunde man sånt men inte idag.

Idag tankas det hem färdiga moduler från nätet som kanske har 20 ingångar och 20 utgångar samtidigt som man bara behöver 3 ingångar och 3 utgångar MEN nyttjar HELA den här modulen säg TUSEN gånger i programmet, allt för att "minne finns det gott om", nåt sånt gissar jag.

Det är i vilket fall känt att programmerare inte bryr sig om minnesåtgången idag för det behövs liksom inte.

Så vad spelar då några enstaka filers extra minnesåtgång för roll?

MVH/Roger and out

[hummel]

Det var väl ändå att dra alla programmerare öven en kam. Det är skillnad på utveckling av exempelvis stora system och inbyggda system. Inbyggda system brukar kräva rätt hög kunskap om begränsningarna i systemet. Där kan du inte bara "ladda hem saker och stoppa i".

[Nerre]

Tänk dig t.ex. systemfiler som kanske ändras flera gånger i minuten... Är det verkligen vettigt att ha versionshantering av dem?

Tänkte inte skriva mer i det här ämnet men den här kommentaren är så bra att jag känner att jag måste.

Kodeffektiv programmering existerar inte överhuvudtaget idag.

Det handlar ju om att operativsystemet behöver hålla reda på saker. På Atari-tiden låg allt i RAM; vid minsta strömavbrott var allt förlorat. Och nån versionshantering var ju bara att drömma om.

Exempel på filer som ändras flera gånger i minuten är ju loggfiler. Skippar man loggningen har man ingen aning om vad som har hänt.

[Spisblinkaren]

PS

Tänk dig t.ex. systemfiler som kanske ändras flera gånger i minuten... Är det verkligen vettigt att ha versionshantering av dem?

Idag kom jag på ett bättre motargument angående detta.

Rätta mig om jag har fel men är det inte som så att dessa systemfiler du beskriver ALDRIG sparas annat är när programmet eller datorn stängs av?

Och revisionshanteringen vi diskuterar handlar ENDAST om att varje save blir en ny version.

Så enligt mitt amatörässiga sätt att se på saken så kan det loggas, som du säger, hur många gånger som helst så länge filen är öppen ty det enda som är intressant är vad som sparas på hårddisken när programmet stängs.

Man kan exempelvis titta på temp-filer som dyker upp när man typ öppnar wordpad, dessa filer finns bara så länge dokumentet inte är stängt/sparat för att då försvinna.

Jag gissar att det är "samma" vad gäller dina systemfiler (skillnaden är bara att de istället sparas vid stängning).

Vad jag vill ha sagt är att citatet inte innebär några problem för min ide'.

Sen en annan sak, du rättade mig ju när det gäller att bider inte kan diff-hanteras.

Jag vill påstå att det är riktigt MEN Wikipedia lagrar heller inte bild-diffar, de lagrar LÄNKEN till bilden som ju aldrig ändras!

Eller jo, jag ändrar mina wiki-bilder ibland men då ger jag dom också ett nytt namn för jag har inte riktigt fattat hur man skriver över en gammal bild UTAN att tappa den beskrivande texten man knåpat ihop.

Bilddiffar funkar inte, jag är överrens med Nerre om det.

Så om man vill revisionshantera dokument med bilder i så har man bara två val:
1) Man gör som Wikipedia dvs har en separat server (eller mapp? ) med bilder man länkar till
2) Man sparar alla bilder varje gång man skapar en revision (dvs trycker på save)

2 är osmidigt för nuförtiden tenderar folk vara så kåta på högupplöst att dokumenten snabbt blir stora minnesmässigt och att då spara varje nytt dokument med alla bilder kommer att generera stor "stack-fil", fördelen är att implementationen blir mycket enkel.

1) Wikipedia har som sagt lösningen redan, man har alltså bilderna på en annan server (eller ärligt, varför inte i en mapp på datorn, finns ju redan en special-mapp som hanterar bilder dvs My Pictures så varför inte göra den ännu mer special?) och länkar bara dit (commons) viilket får till följd att den diff-procedur som Nerre talar om fungerar ypperligt för nu handlar det BARA om text, ja tom bara om skillnadstext om jag förstått saken rätt.

Jag har tänkt en del på detta och det kommer inte riktigt fungera om man inte delar ut en offentlig server för dom bilder jag skapar till mitt dokument kan visserligen länkas MEN om jag vill skicka dokumentet till någon så måste ju mottagaren också kunna länka till bilderna.

Fast detta är "live", alternativet är att man importerar bilderna när man är helt klar med dokumentet som alltså innebär att bilderna inte längre länkas utan hela dess minnesstorlek inkluderas i dokumentet.

Jag lekte med tanken att man borde kunna sätta upp en server i sin egen dator där adresseringen sker via ens eget IP-nummer, typ adressinformation ut och adressinformation in, man länkar till sig själv helt enkelt.

Detta skulle göra att man bara behöver inkludera bildernas länkadresser när man skriver ett dokument, jag vet att länkar faktiskt fungerar i typ Word men jag vet inte om man kan sätta [img]-taggar runt adresserna som man kan här, dvs att på så sätt även visa bilden i länken (har jag lärt mig via EF).

Annars finns shortcuts som man kanske kunde vidareutveckla, varför inte typ klistra in en shortcut i dokumentet som då på nåt sätt visar bilden?

Jag ser således inga som helst problem med min ide' när det gäller varken Word/bilder eller "systemfiler" enligt citat.

MVH/Roger