SVN. Kollisionen bei optimistischer Versionsverwaltung

[NikeAir]

Hallo Leute,

ich habe eine kurze Frage. Ich befasse mich gerade mit SVN und ich habe eine kurze Frage zu Kollisionen. Ich habe mich gefragt, wann genau es zum Konflikt kommt. Hier ein kurzer Szenario:


1. Paul: checkout <Projekt>
2. Beate: checkout <Projekt>
3. Beate: ändert Transaction.java
4. Beate: commit Transaction.java
5. Paul: update
6. Paul: ändert Transaction.java
7. Paul: commit <Projekt>
8. Paul: ändert TransactionList.java
9. Beate: ändert Transaction.java
10. Beate: commit Transation.java
11. Paul commit TransactionList.java


Kommt es hier an Stelle 4 zum Konflikt, wo Beate commited, oder erst an Stelle 11, weil die Datei hier ja bereits geändert wurde, ohne dass geupdated wurde? Mein Verständnisproblem liegt an einer Wissenslücke. Darf Beate die Datei comitten, obwohl Paul die als erstes den Checkout gemacht hat?

Ich bitte euch um eine kurze Rückmeldung.

Viele Grüße
NikeAir

 

[NikeAir]

Oder wird er nicht an der 10 Stelle ausgelöst, weil Beate vor der Bearbeitung nicht geupdated hat?

 

[calousy]

Hi,

also File-Konflikt gibt es in deinen Beispielen keinen. Paul kann nur an Stelle 11 nicht committen, da seine File-Version (File-Revision) nicht der aktuellen vom Server entspricht.
Einen Konflikt (auf File-Ebene) würde es geben, wenn du 5 und 6 vertauschst und an gleicher Stelle (z.B. Zeile) was geändert wurde:

4. Beate: commit Transaction.java // alles OK
6. Paul: ändert Transaction.java // noch kein Problem, SVN bekommt davon ja nichts mit
5. Paul: update // hier Konflikt, manueller Merge notwendig

daher kann man ja immer erst ein Synchronize machen, dann sieht man wie's aussieht