Den heldige uheldige udvikler

Jeg så lige en Facebook-update fra en kær udvikler-veninde, der var blevet reddet fra at miste 100 timers arbejde af sin backup - rigtige kvinder (m/k) tager jo altid backup, eller har værktøjer, der klarer det for en. Med mindre altså at disse værktøjer altså heller ikke kan finde tilbage i fortiden...

For nylig sad jeg og havde arbejdet på noget kode, som jeg ikke havde checket ind endnu - efter en halv dags arbejde - men endelig havde fået til at virke, som det skulle. Så skulle jeg bare liiige lave en Subversion rollback på et par andre filer inden jeg ville committe. Og selvom jeg er næsten 100% sikker på, at jeg kun havde valgt de rigtige filer at rulle tilbage, var alle mine ikke-modificerede filer pludseligt væk. Helt helt væk.

IntelliJ plejer ellers at have en god local history, som kan redde en, men der var de heller ikke. Nej nej nej neeeej!! Jeg nåede vist at hamre i bordet og jamre tilstrækkeligt til at påkalde mig mine kollegers ynk, mens jeg prøvede at tage mig sammen til at skulle gen-kode noget, jeg allerede havde lavet én gang; det er faktisk temmelig svært at tage sig sammen til, skal jeg hilse og sige.

Indtil jeg kom i tanke om, at jeg jo havde en kørende udgave af programmet inklusive min ny-kodede (og nu forsvundne) feature. Altså måtte der jo eksistere en .class fil et sted, i hvert fald. Så den fik jeg gravet frem og hældt igennem en decompiler, og outputtet var faktisk jævnt hen brugbart. Kommentarerne var selvfølgelig forsvundet, men koden var der da endnu. Omend i en lidt modificeret udgave; enkelte steder havde turen gennem først en compiler og dernæst en decompiler resulteret i, at man i stedet for f.eks.

if (b) {
// do something
}

stod

if (!b) {
return;
}
// do something

Naturligvis logisk korrekte transformationer, men som også visse steder resulterede i noget mere ulæselig kode, så det tog da lidt tid at rette op på samt gen-kommentere, men alt i alt var det da en betydeligt mindre (og mindre frustrerende, ikke mindst) opgave end at starte forfra.

Nogle gange gælder det gamle mundheld om held i uheld altså.

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Mens jeg studerede arbejdede jeg deltids hos et firma, der lavede grafiksoftware. De brugte Fortran 66, da de skulle kunne køre på systemer, der endnu midt i 1980'erne ikke kunne bruge F77. Det blev jeg i længden lidt ked af, så jeg meddelte, at jeg ville holde op, når jeg var færdig med det projekt, jeg var i gang med, som var interface af et GKS system til producentens eget system. Og det gjorde jeg så.

Et par uger efter blev jeg en fredag aften ringet op af firmaet, som fortalte, at de havde en kunde til produktet, som gerne ville se det om mandagen. Uheldigvis havde de mistet den seneste udgave af produktet og havde kun en backup af ældre dato, så ville jeg ikke nok komme ind i weekenden og forsøge at genskabe så meget som muligt af det tabte.

Det gjorde jeg så (mod god betaling), og fik det meste til at virke. Men det lærte mig vigtigheden af første regel omkring ophørte medarbejdere: Tag øjeblikkeligt backup af alt, hvad denne medarbejder har lavet, og gem det et sikkert sted.

  • 1
  • 0
Anne-Sofie Nielsen

Nej, Subversion er ikke et backup-værktøj, men da jeg sjældent har ikke-committet kode liggende i mere end en dags tid eller to, nedsætter det behovet for at foretage egentlig backup af koden på min maskine.

Det er vel ikke "i utide" at sørge for, at man det meste af tiden har koden i en tilstand, hvor den godt kan committes uden at ødelægge noget for andre?

  • 0
  • 0
Benjamin Balder

Hvad enten du bruger SVN, rsync eller andet, så har du sandsynligvis en masse kilder og destinationer. Selv et SVN repository kan være nødvendigt at backe op, da man ikke har historikken bevaret i et checkout.

Jeg havde brugt lang tid på at lave et rigtig godt script, som gjorde tingene for mig. Jeg tog ofte backup, og en dag, jeg skulle anvende den, opdagede jeg til min rædsel, at jeg aldrig havde taget en backup af mit backup-script. Resultat: Jeg havde alle mine data intakt men fik efterfølgende ikke taget backup i flere måneder, da jeg ikke havde tid til at sætte mig ned og skrive et backup-script igen.

  • 1
  • 0
Peter Lind

Jeg må indrømme at jeg har svært ved at se det vigtige skel i versionsstyring vs. backup - versionsstyring kan også bruges som backup, det er primært et spørgsmål om hvordan man sætter det op.

Personligt committer jeg adskillige gange i løbet af en dag, hellere en gang for meget end for lidt, da man netop med versionsstyring kan rulle ændringer tilbage eller kopiere tidligere versioner eller etc.

Meget cool du fik din kode tilbage på den måde :) Ville nok selv overveje arbejdsprocesser, der ikke kræver rollback på den måde - såsom test-branches, hvor man committer de dele der skal bruges og så merger tilbage til sin arbejdsbranch og derefter smider resten væk ... eller committer og lader ligge lidt tid til man er sikker på det ikke skal bruges. Blot en tanke :)

  • 0
  • 0
Klaus Elmquist Nielsen

Jeg skrev på et tidspunkt et script til at lave snapshots og releases med. Det ligger på min hjemmeside:

http://klauselmquist.dk/save.html

Kik på savetool manualen for nærmere forklaring.

Jeg har typisk sat det op således at jeg skriver "make save" når jeg vil tage et snapshot af kildeteksterne i projektet.

For større projekter kan det være upraktisk at gemme hele projektets kildetekster hvorfor man kan nøjes med at tage backup af de kildetekster der er checket ud. Dette er baggrunden for "savecvs" kommandoen i samme release. Denne trænger dog til et kærligt eftersyn.

Disclaimer: Denne kommentar er skrevet mens jeg lyttede til Veronica Mortens "Mondays".

  • 0
  • 0
Henrik Schmidt

Jeg må indrømme at jeg har svært ved at se det vigtige skel i versionsstyring vs. backup - versionsstyring kan også bruges som backup, det er primært et spørgsmål om hvordan man sætter det op.

For mig er forskellen, at hvis jeg har sat min maskine til at backe up en gang i timen, så kan jeg i værste fald miste en times arbejde. Hvis jeg ikke har backup, så skal jeg huske at committe en gang i timen, og min commit-log bliver desuden meningsløs. Udover det, så bruger jeg primært Git, som ikke nødvendigvis er tilknyttet en central server.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jeg sidder her og forsøger desperat ikke at skrive noget om, at centraliserede repos er "sooo last year". Det de unge vil have er værktøjer som Hg, Git og andre.

(og de er i øvrigt imo langt bedre værktøjer end SVN)

:o)

  • 1
  • 0
Nikolaj Brinch Jørgensen

Jeg må indrømme at jeg har svært ved at se det vigtige skel i versionsstyring vs. backup - versionsstyring kan også bruges som backup, det er primært et spørgsmål om hvordan man sætter det op.


Der er en vældig stor forskel (i hvert fald når vi snakker centraliseret versionsstyring a la SVN). Det er uskik at committe kode overhovedet som ikke kan compile eller virker (breaker unit tests osv.). Med mindre du arbejder i et personligt branch hvor du kan gøre hvad du vil.

Sagen er en anelse andeledes med f.eks. git, hg osv. da man her kan committe til sit lokale repos, og så siden videre til central repos.
Det er netop også derfor at det er en god idé at komme af med SVN. Eventuelt benyt git-svn mod SVN repos, så har du også et lokalt repos, hvor du kan ødelægge koden uden at forstyrre andre.

Jeg er glad for min TIme Machine, den sørger for at der automatisk er backup, så jeg kan gå tilbage til tidligere versioner. Vær ligeledes opmærksom på at man i eclipse kan stille på antallet af kopier der skal bevares i local history, og det kan man roligt skrue op for med de harddisk størrelse vi fumler rundt med i dag. Det er hurtigere at hente tingene her, end at rode med backups. Også selvom Time Machine er frygteligt nemt at benytte.
Time Machine - endnu en årsag til at benytte en Mac til udvikling :-)

  • 0
  • 0
Peter Lind

For mig er forskellen, at hvis jeg har sat min maskine til at backe up en gang i timen, så kan jeg i værste fald miste en times arbejde. Hvis jeg ikke har backup, så skal jeg huske at committe en gang i timen, og min commit-log bliver desuden meningsløs. Udover det, så bruger jeg primært Git, som ikke nødvendigvis er tilknyttet en central server.

Mjah, jeg tror nu nok man kan scripte sig ud af de fleste problemer der - og derudover kan du uden videre sætte en git proces op, der pull'er fra dit lokale repo, så du ikke selv skal pushe en backup (ligesom du også skal have en ekstern backup for at dit argument giver mening).

Min pointe var primært at versionsstyring også kan bruges til backup, til en vis grad. Spørgsmålet er hvad man har brug for.

  • 0
  • 0
Henrik Schmidt

Mjah, jeg tror nu nok man kan scripte sig ud af de fleste problemer der - og derudover kan du uden videre sætte en git proces op, der pull'er fra dit lokale repo, så du ikke selv skal pushe en backup (ligesom du også skal have en ekstern backup for at dit argument giver mening).

Det hjælper jo ikke noget, når dine ændringer ikke er committet. Jeg laver nogen gange fejl, såsom at reverte et repositorie, hvor der var ændringer, som jeg ikke skulle have fjernet. Så redder min backup mig.

Anyway, folk må jo gøre op med sig selv, hvor fummelfingrede de er, og hvor meget arbejde de er parat til at skulle gøre om på den konto.

  • 0
  • 0
Log ind eller Opret konto for at kommentere