| 

.NET C# Java Javascript Exception

2
Gibt es in Mercurial oder Git auch die Subversion-Probleme, dass eine Datei, die gelöscht wurde, dafür sorgt, dass man nicht mehr committen kann? Ich überlege ernsthaft, Subversion ins Nirvana zu schicken.
News:
01.02.2011
tack 294 1 8
3 Antworten
2
Jein.

Das Problem an sich besteht in der gleichen Form: Du löschst eine Datei, ohne der Versionsverwaltung zu sagen, dass Du das machst. Darüber stolpert *JEDE* Versionsverwaltung, weil es sich letztlich um einen Bedienfehler handelt.

Die Frage ist, wie sie damit umgehen. Subversion lässt Dich dann (aus gutem Grund!) nicht mehr committen, hier musst Du dann das Löschen rückgängig machen (entweder per Undo im Explorer, oder per "Revert" im SVN), und die Datei dann über SVN löschen.

Mercurial lässt Dich beim Committen entscheiden, was mit der fehlenden Datei passiert ist - machen musst Du es aber trotzdem.

Git kenne ich persönlich nicht.

Insofern: Ja, Mercurial hat das gleiche Problem. Und nein, es ist nicht exakt das gleiche Problem, weil es anders gehandhabt wird.

Dennoch gilt IMHO: Wenn Du heute damit Probleme hast, in SVN "richtig" (= so wie vorgesehen) zu löschen, wirst Du die gleichen Probleme auch überall sonst haben. Der IMHO korrekte Ansatz wäre, hier beim User anzusetzen, nicht beim Tool.
01.02.2011
Golo Roden 2,7k 3 9
Vielen Dank für den Hinweis. Wobei ich nicht verstehe, dass die VCS damit Probleme haben. Sie sollen immer den Stand der Ding speichern. Fehlt eine Datei ist die in Version X noch da, in Version X + 1 nicht mehr. Das ist ja wohl die Entscheidung des Committers. Mache ich einen Checkout von Version X in ein neues Verzeichnis, sollte die Datei da sein. Bei Checkout von Version X + 1 sollte sie nicht mit dabei sein.
tack 01.02.2011
Das SCS weiß nicht was es mit der Datei machen soll. Das eigendliche Problem ist, das dem SCS nur die Dateien geschickt werden die sich geändert haben und nicht eine Liste aller aktuellen Dateien (aus welcher dann ersichtlich wäre welche Dateien fehlen / gelöscht wurden). Das reduziert den Protokoll-Overhead und die übertragenen Daten. Deswegen musst du dem SCS seperat sagen, das eine Datei gelöscht werden soll. Letztendlich könnte dein SCS-Client das Problem lösen (so wie bei Mercurial).
Floyd 01.02.2011
Ehrlich gesagt ist das aber ziemlich übel. Eine Liste der Dateien und Verzeichnisse wäre jetzt nicht so die Menge an Daten. Aber Floyd hat recht: Das liegt dann wohl an dem Client.
tack 01.02.2011
2
Git behandelt eine gelöschte Datei wie jede andere Änderung, die du letztlich dann committen kannst, aber nicht musst. Es spielt für Git keine Rolle, ob die Änderung ein "new file", "modified file", "untracked file" oder "deleted file" ist. Wenn du eine solche Änderung committen willst, dann staged du sie und machst den commit. Anderenfalls lässt du es einfach.
06.02.2011
Matthias 208 4
1
Golo hat ja schon die wesentlichen Punkte zusammengefasst. Ich wollte noch hinzufügen, dass bei einer Entscheidung zwischen Git und Mercurial sicherlich zu berücksichtigen wäre, wie die Integration ins OS realisiert ist. Git wurde ja von Linus (Torvalds) ins Leben codiert und der hatte auf seiner Prioritätenliste "Muss schön unter Windows laufen." extrem weit unten ;-)

Ich verwende sowohl Git als auch Mercurial sehr gern, wobei ich mich persönlich von Perforce als Primär-VCS nicht trennen kann. Unter Windows würde ich jedoch zu Mercurial greifen, denn das ist weitestgehend in Python implementiert und Du brauchst Dir keinen mit einer CygWin-Umgebung abzubrechen.
19.02.2011
Torsten Weber 691 1 8

Stelle deine Datei-Frage jetzt!