[TortoiseSVN/Subversion] Data loss na een SVN update

[Verwijderd]

Big mistake! Mijn collega heeft documenten in zijn working copy gewijzigd, en ik koos voor SVN Update om mijn wijzigingen door te voeren naar zijn versie...
Hij had die code nog niet gecommit, dus alleen lokaal op zijn computer stond zijn gewijzigde bestand.
De code werd in TortoiseMerge op 1 regel weergegeven, omdat het bestand origineel in Mac formaat is opgeslagen, kennelijk kan TortoiseMerge daar niet mee overweg, hij herkende de EOL tekens niet.

Na de update zijn al zijn toevoegingen helemaal weg, omdat die ene regel is vervangen door andere code en is opgeslagen over zijn gewijzigde working copy exemplaar..... Omdat zijn toevoegingen niet zijn waren gecommit (omdat de repository versie nieuwer is door mijn commit), kan ie zijn dingen niet meer terughalen uit de repository.........

Is er een manier om de data terug te halen??? Het gaat om 8 uur programmeerwerk, dus ERG klote als het helemaal kwijt is...

Alvast bedankt!

[ Voor 15% gewijzigd door Verwijderd op 15-11-2005 11:16 ]

[Nick_S]

Ik werk zelf met Eclipse (icm met Subversion, maar dat is hier niet van belang) en die houd ook een lokale history bij.

Als de gebruikte editor dat niet ondersteunt, is het inderdaad verloren zaak. Bij Eclipse kun je je project synchronizen en onstaan er conflicten, dan is het altijd goed opletten wat je van de twee verschillende versie overneemt.

[Verwijderd]

Ik vind het trouwens echt suf dat je helemaal niet kan kiezen wat je wel en wat je niet wilt overnemen van de nieuwere versie in de repository als een SVN update uitvoert...

Echt erg klote als het helemaal weg is, is er niet een tooltje waarmee ik oude clusters van de harde schijf kan checken of zo? Of werkt dit alleen als er bestanden uit de prullenbak verwijderd zijn?

[bakkerl]

Wat je dan gedaan heb is niet geheel duidelijk.
Een tortoiseSVN update overschijft normaal namelijk geen bestanden die lokaal al aangepast zijn.
Die file met aanpassingen had dus niet overschreven mogen zijn met alleen een SVN update.
(tenzij jou editor zo brak is om de timestamp van de file niet aan te passen na een save actie)

Dit niet overschrijven van lokaal al aangepaste bestanden is bijna standaard voor elke SVN client, omdat een lokaal aangepast bestand alleen met een "Update to revision" of een "revert" overschreven wordt

Maar als de bestanden echt aangepast zijn, dan zul je die niet meer terug kunnen halen.

Omdat zijn toevoegingen niet zijn waren gecommit (omdat de repository versie nieuwer is door mijn commit), kan ie zijn dingen niet meer terughalen uit de repository.........

Daar is SVN dus juist voorgemaakt. Hij had juist een commit kunnen doen. Had de code namelijk geconflicteerd, dan had de client dat aangegeven.
Je kan altijd een commit doen, ook al loopt jou code achter op wat gecommit is (na dat jij heb eruit gehaald heb).

[ Voor 42% gewijzigd door bakkerl op 15-11-2005 11:51 ]

[ShadowLord]

Vreemd verhaal dat TortoiseSVN/Merge alles maar op 1 regel liet zien en dat hij (en daarbij ook Subversion) dacht dat de file maar 1 coderegel had. In die staat zou ik het systeem uberhaupt niet gebruiken want een concurrent versie systeem werkt dan helemaal niet!

Waarom niet? Omdat je geen (goede) merges kan doen. Alle changes zijn op dezelfde regel en zullen dan een merge conflict geven als er in je lokale kopie is gewerkt en de server een nieuwere reviesie heeft. Het lijkt me dan ook dat je collega hierover een melding heeft gehad.

Als hij de merge niet heeft gedaan staan zijn bestanden nog gewoon op zijn PC, maar met een extra extensie. Als hij de merge wel heeft gedaan is hij z'n spullen kwijt.

Mocht hij een revert hebben gedaan, of een update to revision (waarbij Tortiose niet merged omdat het geen zin heeft) zal hij in ieder geval een waarschuwing gehad hebben.

Daarom 3 tips:
1) Zet Mac formatted files om naar Unix of Windows formaat. Dit zijn de LF en CR+LF zijn de enige 'goedgekeurde' line endings volgens de ASCII standaard. Apple is dan ook van hun eigen CR-only formaat afgestapt.
2) Leer geod werken met je versiesysteem. Versiesystemen zijn erg veilig en maken het heel moeilijk om code kwijt te raken, maar dan moet je wel weten waar je mee bezig bent.
3) Backup, backup, backup... Oh ja, backup!

EDIT:
Oh en voor ik het vergeet:

Ik vind het trouwens echt suf dat je helemaal niet kan kiezen wat je wel en wat je niet wilt overnemen van de nieuwere versie in de repository als een SVN update uitvoert...

Dat vraagt SVN (en dus ook TortoiseSVN) dus wel als er eem merge conflic is. Dat is dus wanneer hij een update zou moetn doen die conflicteerd met huidige wijzigingen. Je kan ook individuele files en folders updaten door hun naam op te geven bij een update, ipv de hele repository. Bij TortoiseSVN is dat dus rechts-klikken op de file/folder die je wilt updaten.

[ Voor 19% gewijzigd door ShadowLord op 15-11-2005 16:59 ]

[Verwijderd]

Blijkt dus het volgende:

De file was opgeslagen met Mac newlines (CR-only), TortoiseMerge ziet alles dan als 1 line. Ik weet eerlijk gezegd niet meer of er conflicts waren.
Conflicts of geen conflicts, die ene line is overschreven (het zou kunnen dat ik Resolved heb gedaan), daarna heb ik het bestand in Textpad geopend en opgeslagen als PC (CR+LF) waardoor TortoiseMerge (met Diff) alle code weer op meerdere lines zag.

De voorheen gewijzigde working copy was niet gecommit...

TortoiseSVN vergelijkt per regel, dus als alles op 1 regel staat gaat het heel makkelijk mis...
De uiteindelijke combinatie van alles op 1 regel en gecommit te hebben hebben ervoor gezorgd dat het niet goed is gegaan.
Ik had natuurlijk de boel kunnen exporteren vòòr de commit, maar ja, dat is meestal overhead, eigenlijk zou TortoiseSVN misschien wel een backup moeten maken of zo.

Mijn punt is eigenlijk dat wanneer je bijvoorbeeld op een gewijzigde enkele file in je working copy een SVN Update doet, dat je niet echt kan kiezen dat ie sommige regels gewoon moet laten staan.
We hebben bijvoorbeeld heel vaak dat er configuratie files in het versiebeheer staan, en sommige regels verschillen per computer, dus dat bestand wordt aangepast door iedereen. Best irritant als je die telkens weer aan moet passen na een SVN Update of uitvinken bij een SVN Commit... Je kan die file ook niet op ignore zetten volgens mij, omdat hij in het versiebeheer staat.

Ook wil ik wel eens een soort merge versie maken van 1 file die lokaal en in de repository gewijzigd is, maar als ik dan TortoiseMerge gebruik voordat ik update kan ik het niet opslaan lijkt wel...

Bedankt voor de hulp!

[NetForce1]

Verwijderd schreef op donderdag 17 november 2005 @ 09:48:
Mijn punt is eigenlijk dat wanneer je bijvoorbeeld op een gewijzigde enkele file in je working copy een SVN Update doet, dat je niet echt kan kiezen dat ie sommige regels gewoon moet laten staan.
We hebben bijvoorbeeld heel vaak dat er configuratie files in het versiebeheer staan, en sommige regels verschillen per computer, dus dat bestand wordt aangepast door iedereen. Best irritant als je die telkens weer aan moet passen na een SVN Update of uitvinken bij een SVN Commit... Je kan die file ook niet op ignore zetten volgens mij, omdat hij in het versiebeheer staat.

Wij hebben dit opgelost door voor elke configuratiefile een template-versie in de versioncontrol te zetten, iedere developer kan dan zelf een configuratiefile maken, met specifieke instellingen.

[djc]

Je moet eigenlijk svn:eol-type op "native" zetten, dan zorgt SVN er zelf voor dat line ends tussen verschillende platforms (LF op *nix, CRLF op Windows, CR op Mac) geconverteerd wordt. Let wel: dit property moet je dus niet op binaire bestanden zetten, die worden erdoor verneukt.

[Darkvater]

Inderdaad erg vreemd. SVN Update overschrijft helemaal niks. Als hij het niet uit kan vogelen geeft ie een conflict en heb je de lokale wijzigingen altijd erbij staan.

Voor de line-endings doe je gewoon: "svn propset svn:eol-style native file1, file2, file3", etc. Of je zet een commit-hook in je server die dit automatisch doet bij het toevoegen van een nieuw bestand.

[Verwijderd]

Nice, bedankt allemaal!