C# Versionierung VisualSVN/Tortoise

Hallo Leute,

ich muss mich seit kurzem mit dem Thema Versionierung befassen, da ich mit zwei Leuten eine Projektarbeit an unserer Uni auf die Beine stellen muss.

Unser Prof hat uns hierfür VisualSVN vorgeschlagen.

Das klappt auch alles soweit ganz gut.

Ein schwerwiegendes Problem haben wir allerdings noch nicht lösen können und haben auch per Google nichts gefunden:

1. Unser Prof hat uns an's Herz gelegt, zum gemeinsamen Arbeiten die "Lock"-Funktion zu verwenden.
Das Problem hierbei ist: Wenn eine Datei durch Person_1 gelockt ist, kann Person_2 die Datei nach einer Änderung zwar nicht Commiten. (Soll ja so sein) Hat Person_1 seine Arbeit beendet, commited und das Lock aufgehoben, macht Tortoise logischerweise Probleme, wenn Person_2 seine Arbeit jetzt commiten möchte.
Was mach ich falsch?

2. Wenn ich trotzdem die Branch/Merge-Funktion verwenden möchte habe ich doch das Problem, dass in so einem VisualStudio Projekt jede Menge automatisch generierter Code entsteht. Wie soll dieser Code denn dann gemerged werden?

Ich würde mich wahnsinnig darüber freuen, wenn mir jemand helfen kann!

ape4711 schrieb:

Das Problem hierbei ist: Wenn eine Datei durch Person_1 gelockt ist, kann Person_2 die Datei nach einer Änderung zwar nicht Commiten. (Soll ja so sein) Hat Person_1 seine Arbeit beendet, commited und das Lock aufgehoben, macht Tortoise logischerweise Probleme, wenn Person_2 seine Arbeit jetzt commiten möchte.
Was mach ich falsch?

Zum Vergrößern anklicken....

Habe in meinem Studium im Praktikum auch ein Versionsmanagement aufbauen müssen. Ich glaube der Fehler liegt daran, dass du, nachdem Person_1 seine Daten eingecheckt (commited) hat, eine ältere (und überarbeitete) Version einchecken möchtest.

Wenn du die aktuelle Version (die Person_1 eingecheckt hat) auscheckst, deine Änderungen in dieser nochmal übernimmst, müsste das einchecken funktionieren.

Sgt.Speirs schrieb:

Wenn du die aktuelle Version (die Person_1 eingecheckt hat) auscheckst, deine Änderungen in dieser nochmal übernimmst, müsste das einchecken funktionieren.

Zum Vergrößern anklicken....

Hallo, und vielen Dank schonmal!

Das ist richtig und das funktioniert auch. Das Problem ist allerdings, dass ich ja nur merke, dass eine Datei gelockt ist. Wenn ich warte, bis die Datei wieder freigegeben ist, dann kann ich ja auch kein "Update" mehr machen da Tortoise dann meckert. (oder habe ich das falsch verstanden?)

Davon abgesehen kann ich meine Ändrungen ja nur bei den von uns erstellten Dateien übernehmen. Die beim kompilieren automatisch entstandenen, aber auch versionierten Dateien kann ich ja schlecht "manuell" ändern.

Jeder Eincheck-Vorgang hat eine Änderung der Versionsnummer auf sich. Passen die des Repositorys nicht mit den einzucheckenden Daten zusammen, meckert Tortoise.

Was du machen kannst: Du änderst ja nicht immer alle Daten. Sichere deine bearbeiteten Daten in einen anderen Ordner. Check die aktuelle Version im Repository aus und ändere in dieser, was du in den gesicherten Daten bereits geändert hast.

Dass Objekt-Dateien nicht geändert werden müssen, dürfte klar sein

Also einen grundlegenden Fehler bei eurer Vorgehensweise habe ich gefunden: automatisch generierte Dateien haben nichts im Repository verloren und gehören auf die svn:ignore Liste (bzw. der Parentfolder).

SheepShaver schrieb:

Also einen grundlegenden Fehler bei eurer Vorgehensweise habe ich gefunden: automatisch generierte Dateien haben nichts im Repository verloren und gehören auf die svn:ignore Liste (bzw. der Parentfolder).

Zum Vergrößern anklicken....

Hey - genau das hab ich mir auch schon überlegt.
Ich wollte dann zwei Möglichkeiten ausprobieren:

1. Die Dateien über '"Tortoise -> Delete and ignore list" auszuschließen

oder

2. Nur die "wichtigen" Dateien zu versionieren und den Rest im Projektordner zu lassen, der außerhalb des Repository-Verzeichnisses liegt.

zu 1)
Tortoise löscht hierbei die Dateien immer gleich aus dem Repository und schließt sie nicht einfach aus der Versionierung aus.

zu 2)
Ich habe es in stundenlanger Sucharbeit nicht geschafft herauszufinden, wie man VisualStudio klar macht, dass es Dateien von anderen Orten einbinden soll und sie nicht gleich immer in sein Projektverzeichnis kopiert und von da aus verwendet.

Also an sich ist es nicht grundsätzlich falsch die vom VisualStudio automatisch generierten Dateien auf die Ignoreliste zu setzen, aber:

Das VisualStudio Projekt generiert Dateien die zum Programm gehören und beim Ignorieren dann fehlen, unvollständig oder veraltet sind. Insbesondere seien da die Designer / Ressourcen / Project und Solution Dateien genannt. Also wenn man wie vorgeschlagen, diese ignoriert und nicht in das SVN mit überträgt, dann wird man schnell ein Repository haben, was sich schlicht und ergreifend nicht mehr kompilieren läßt. Also an sich ein gute Idee, nur in der Praxis fatal. Speziell über das Mergen von verschiedenen Versionen dieser Source-Dateien, läßt sich sagen das du 3 Optionen hast:
1. Eigene Änderungen verwerfen und die aktuelle Datei aus dem Repository nehmen
2. Aktuelle Datei vollständig durch eigene Datei ersetzen
3. Beide Versionen zu einer neuen Version verbinden

Die 3. Variante praktiziere ich recht häufig und es macht für mich keinen Unterschied ob es eine vom VS generierte Datei oder eine programmierte Datei handelt, da diese ebenso Quellcode ist, den ein Programmierer lesen kann. Im übrigen ist das auch kein Hexenwerk, was drin steht. Nachdem ich diese Dateien "lokal" gemerged habe, öffne ich einfach nochmal die Solution, öffne das entsprechende Formular im Designer, schau ob die betroffenen Properties nach den Änderungen entsprechend gesetzt sind, kompiliere das Projekt und fertig...

(Umlaute funktionieren bei mir nicht haha)

Also ich bin recht unerfahren was SVN etc. angeht aber entweder macht ihr einen Branch und einer arbeitet auf dem Branch und der andere auf dem trunk....wenn ihr fertig seid Merged ihr eure arbeit....

Ich habe ein Projekt uebernommen von einem Programmierer und sollte hier und da div. aenderungen vornehmen und dabei hab ich diverse Sicherheitsluecken gefunden. (Sowas aehnliches wie Seriennummer generierung etc blabla) jedenfalls hab ich eine andere, sichere Methode vorgeschlagen, da das Produkt aber teils schon im Umlauf war, und der eingriff mehrere tage dauern wuerde, das Programm dann nicht kompilierbar / lauffaehig war
hab ich einen BRANCH erstellt....im TRUNK hab ich dann optische aenderungen vorgenommen und oder bugs gefixed und im BRANCH die neue logik implementiert, als ich im branch fertig war hab ich das einfach zusammen gefuehrt (MERGE) ... dabei sind div. komplikationen entstanden, aber SVN macht dich aufmerksam auf die fehler und du kannst beide dateien vergleichen und entsprechend aendern.



Zu den generierten dateien von Visual, die haben eigentlich NIX in SVN zutun, es sei denn sie sind relevant zum kompilieren. Ein DEBUG ordner in dem NUR von VS generierte dateien entstehen haben NIX in SVN verloren...warum auch?! also einfache regel: alles was nicht benoetigt wird um ein projekt zu kompilieren gehoert nicht in SVN.

Bei mir kommen alle Dateien Ordner in den SVN rein außer

bin

Zum Vergrößern anklicken....

und

obj

Zum Vergrößern anklicken....

Diese sind einfach zu ignorieren. Sonst muss alles rein.

Wegen dem Problem. Ich würde auch vorschlagen die neue Version zu ziehen. Überschreiben aber nicht mit deine eigene. Machst einfach nen WinDiff auf und vergleichst deine mit der neue aus der Repository. Wenn irgendwo nicht stimmen sollten, schreibst deine Methode/Objekte rein und machst nen commit (nach dem alles fertig vergliechen wurde).

Wenn ihr aber an einem gemeinsamen Projekt dran seid würde ich schon von vorne herein abklären wer wo arbeitet, damit sich der Code nicht überschneidet. Erspart Zeit(jeder Programmiert im seinen bereich) und Zeit (man muss weniger Vergleichen falls SVN wieder meckert) und Stress