Tortoise SVN

Jungs,
ich schließe mich an diese Diskussion an, weil ich mit TortoiseSVN seit 
gestern beschäftige.
Ich versuche gerade das Programm zu benutzen, dennoch ist es mir eine 
Sache aufgefallen, die ich nicht so ganz verstanden habe.
Vorwort: ich habe schon die Tutorials hinter mir. Was mir fehlt ist ein 
echter live Workflow.

Ok.
Also...ich habe mein Projektverzeichnis in einem Netzwerk abgelegt. Zwei 
Rechner - A und B- können/dürfen auf das Verzeichnis zugreifen und den 
Code herunterziehen.
Nun passiert folgendes:
A checkt den Code aus. Ändert einige Dateien und lädt - durch ein Commit 
- die Änderungen hoch (Commit #1).
B aktualisiert sein Arbeitverzeichnis (lokal), so hat er die Änderungen 
von A in seinem Code. B ändert den Code und lädt wiederum alles hoch 
(Commit #2).

Nun...A hat mittlerweile noch seine alte Kopie in seinem Verzeichnis 
(lokal), in dem er neue Funktionen implementiert hat. Er spricht mit B 
nicht, daher hat er weiter gemacht, ohne B zu fragen, ob er seine 
programme mittlerweile eingecheckt hat oder nicht.

Ok. A versucht seinen Code einzuchecken. Nun kriegt er eine Meldung, 
dass sein Code nicht der aktuellste ist. Ok...So aktualiesiert seine 
lokale Arbeitskopie und...findet seine neusten Änderungen neben den 
Änderungen von B!!!!

Warum bin ich verwirrt? Weil ich erwartet hätte, dass A, wenn er 
aufgefordert wird, sein lokales Arbeitsverzeichnis zu aktualisieren, die 
Unterschiede zwischen der eingecheckten Version von B (Commit #2) und 
seinen letzten noch nicht eingechekten Änderungen automatisch gezeigt 
werden. Als ob SVN ihm mitteilen würde: "Du hast die Funktion X und Y 
implementiert. Allerdings diese sind nicht in dem letzten Commit von B 
enthalten. Was willst Du damit machen?"

Also..habe ich eine falsche Vorstellung davon, wie SVN funktionert?
Wie kann ich vermeiden, dass ich immer sehen kann, wo der andere Kollege 
seinen Code geändert hat? Durch log ist es unzureichend. Ich will sehen, 
welche Funktionen bzw. Änderungen in den Dateien er letztlich 
implementiert hat.

Danke Euch für Eure Hilfe.
Gruß

Dave A. schrieb:

> Also..habe ich eine falsche Vorstellung davon, wie SVN funktionert?
> Wie kann ich vermeiden, dass ich immer sehen kann, wo der andere Kollege
> seinen Code geändert hat? Durch log ist es unzureichend.

wieso ist das unzureichend?
Im log Eintrag dieses Commits von B ist eine Liste aller geänderten 
Dateien. Ein Doppelklick drauf zeigt dir exakt, was von B in der 
Zwischenzeit alles geändert wurde.

Dave A. schrieb:

> Ok. A versucht seinen Code einzuchecken. Nun kriegt er eine Meldung,
> dass sein Code nicht der aktuellste ist. Ok...So aktualiesiert seine
> lokale Arbeitskopie und...findet seine neusten Änderungen neben den
> Änderungen von B!!!!
>
> Warum bin ich verwirrt? Weil ich erwartet hätte, dass A, wenn er
> aufgefordert wird, sein lokales Arbeitsverzeichnis zu aktualisieren, die
> Unterschiede zwischen der eingecheckten Version von B (Commit #2) und
> seinen letzten noch nicht eingechekten Änderungen automatisch gezeigt
> werden. Als ob SVN ihm mitteilen würde: "Du hast die Funktion X und Y
> implementiert. Allerdings diese sind nicht in dem letzten Commit von B
> enthalten. Was willst Du damit machen?"

Was interessiert dich das?
Solange es keine Konflikte gibt, ihr beide also an derselben Source Code 
Stelle gearbeitet habt, ist das ziemlich uninteressant. Das du deinen 
Code nach dem UPdate noch mal neu durchtesten musst, dürfte klar sein. 
Denn es könnte sein, dass B's letzte Änderung deine neuen Ergänzungen 
beeinflussen. Die Auswirkungen auf den restlichen Code wurden ja schon 
von B behandelt und die kriegst du beim Update ja auch in deinen Code 
gemerged.

Wir waren 12 Entwickler in einem Projekt. Wenn ich da jeden Tag die mehr 
als 100 oder 150 Files durchgesehen hätte, die seit meinem letzten 
Commit geändert wurden, wär ich zu nichts anderem mehr gekommen.

Und wenn es beim Update Konflikte gibt, dann krieg ich im Update Dialog 
sowieso eine Anzeige in welchen Files es Konflikte gibt, die ich erst 
mal resolven muss. Auch hier wieder: Doppelklick drauf und es öffnet 
sich ein Merge Tool, welches mir erlaubt zu bestimmen, welche Codezeilen 
die gültigen sein sollen. Sind alle erledigt, den Konflikt als resolved 
markieren und weiter gehts.

A spricht nicht mit B. Das geht, wenn beide in verschiedenen 
Programmbereichen arbeiten. Sitzen sie aber an derselben Funktionalität, 
ist es unumgänglich, dass sie miteinander sprechen oder zumindest einen 
kurzen Nachrichtenaustausch pflegen.

Ok,
erstmal vielen Dank für Eure Antwort. Insbesondere Kaj hat mir einen 
guten Tipp gegeben. WinMerge kannte ich nicht.

Dennoch möchte ich nochmal nachhacken, weil ich mir sicher bin, dass ich 
vielleicht nicht so ganz klar habe, wie SVN funktioniert. Ich will das 
Programm lernen und nicht bloß Funktionen einfach abrufen, ohne zu 
verstehen, was hinter den Kulissen läuft.

Angenommen, A unb B arbeiten beide an dem selben Projekt.
Eines Tages implementiert A neue Funktionalitäten in mehreren Dateien 
und will diese einchecken. Doch stellt er nun fest, er habe nicht die 
letzte aktualisierte Version, die B mittleweile schon eingecheckt hatte. 
So wenn A jetzt seine lokale Arbeitskopie aktualisiert, findet er die 
von B entwickelten Programmen. Nun: wie kann A überprüfen, ob er die von 
B eingecheckten Änderungen in seinem Code übernehmen soll oder nicht?
Aktualisiert er seine lokale Arbeitskopie und hofft dass die Änderungen 
von B kein Problem hervorrufen?

Danke

Dave A. schrieb:

> von B entwickelten Programmen. Nun: wie kann A überprüfen, ob er die von
> B eingecheckten Änderungen in seinem Code übernehmen soll oder nicht?

Er hat gar keine andere Wahl.
Die Frage ist nicht "soll ich sie übernehmen oder nicht".
Die einzige Frage lautet: "Inwiefern betrifft mich das"

Man kann sich natürlich vor dem Upate erst mal im SVN-Log ansehen, was B 
denn da eigentlich alles gemacht hat, wenn man dem misstraut. Aber 
grundsätzlich gibt es immer nur einen aktuellen Stand, der das Projekt 
repräsentiert.
(Über so Dinge wie Branches reden wir erst mal nicht)

> Aktualisiert er seine lokale Arbeitskopie und hofft dass die Änderungen
> von B kein Problem hervorrufen?

erst mal ja.
Vor dem Einchecken wird der Teil an dem A gearbeitet hat nochmal 
durchgetestet, wenn abzusehen ist, dass es da mögliche Beeinflussungen 
gibt. Im Zweifel wird auf jeden Fall getestet.

Keine Projektverwaltung kann dir diese Arbeit abnehmen. Das ist nun mal 
so, wenn mehrer Leute an einem Projekt arbeiten. Da wird es immer wieder 
mal den Fall geben, dass sich die Arbeitsbereich überschneiden.

Dave A. schrieb:

> Aktualisiert er seine lokale Arbeitskopie und hofft dass die Änderungen
> von B kein Problem hervorrufen?

Und dann gilt natürlich noch die Politik der Selbstdisziplin, nach der 
jeder Entwickler nicht einfach nach Lust und Laune einchecken darf, 
sonder das eingecheckte muss getestet und für gut befunden worden sein. 
Halbe Sachen einchecken gilt nicht. Und halbfertige Sachen schon gar 
nicht. Der Zustand im SVN muss jederzeit auf einer neuen Maschine 
auscheckbar sein und das entstehende Produkt muss lauffähig sein. 
Zumindest im Prinzip.

In vielen Teams gilt dann auch das Prinzip, dass man seine Änderungen 
vor dem Einchecken von einem Kollegen 'absegnen' lassen muss.
Und dann gibt es natürlich ja auch noch den Projektverantwortlichen, der 
die Arbeiten zuteilt. D.h. B kann nicht einfach nach Lust und Laune 
irgendwas ändern.
In einer Softwarebude geht es zu wie in jeder anderen Firma auch. 
Inklusive Orignaisationsstrukturen. Die Mär, nach der 2 langhaarige 
Kiffer irgendwann am frühen Nachmittag kommen, dann 12 Stunden in die 
Tastatur hämmern, ist schon lange nicht mehr korrekt. Wenn sie denn je 
korrekt war. Software entwickeln ist Teamarbeit und schon schwer genug. 
Eigenbrödlerische Diven haben dabei nichts verloren.

Danke Karl,
mir ist nun alles klarer geworden.
Also: A hat keine Wahl. So aktualisiert er seine Arbeitskopie. ABER 
bevor er seinen Code eincheckt, wird er überprüfen, inwieweit die 
Änderungen von B seinen Code beeinflussen. Er guckt welche Datei B 
modifiziert hat und was er geändert hat. Und zwar genauso so wie du hier 
beschrieben hast:

> Im log Eintrag dieses Commits von B ist eine Liste aller geänderten
> Dateien. Ein Doppelklick drauf zeigt dir exakt, was von B in der
> Zwischenzeit alles geändert wurde.

Richtig?

Ich denke eines deiner Kernprobleme liegt auch hier drinn:
Ein der Aufgaben einer Verwaltung wie SVN ist es auch dafür zu sorgen, 
dass ALLE im Team immer einen IDENTISCHEN Softwarestand haben. Der kann 
kurzzeitig mal von dem der anderen abweichen, weil eine Funktionalität 
gerade in der Entwicklung ist, aber auf lange Sicht sorgt SVN dafür, 
dass die Source-Code Stände aller Entwickler immer auf gleich gehalten 
werden. Deine Änderungen werden in die Source Code Stände der anderen 
eingepflegt und umgekehrt.
D.h. dein Thema "Soll ich oder soll ich nicht" ist eine Fragestellung, 
die du gar nicht haben willst. Denn nichts ist tödlicher, als wenn die 
Source Codes mehrerer Entwickler auseinanderlaufen. Irgendwann will man 
ja dann auch ein verkaufsfähiges Produkt haben. Aber wer hat das denn 
dann? A oder B? Die Antwort lautet: jeder - weil jeder auf seiner 
lokalen Entwicklungsmaschine denselben Code hat wie alle anderen auch. 
Man könnte auch sagen: SVN hat ihn und was du lokal noch an Änderungen 
bei dir rumlungern hast, interessiert niemanden. Aber da du ja keine 
nicht eingecheckten Source Codes hast, ist das ein akademisches Thema.

Dave A. schrieb:
> Danke Karl,
> mir ist nun alles klarer geworden.
> Also: A hat keine Wahl. So aktualisiert er seine Arbeitskopie. ABER
> bevor er seinen Code eincheckt, wird er überprüfen, inwieweit die
> Änderungen von B seinen Code beeinflussen. Er guckt welche Datei B
> modifiziert hat und was er geändert hat. Und zwar genauso so wie du hier
> beschrieben hast:
>
>> Im log Eintrag dieses Commits von B ist eine Liste aller geänderten
>> Dateien. Ein Doppelklick drauf zeigt dir exakt, was von B in der
>> Zwischenzeit alles geändert wurde.
>
> Richtig?

Richtig.
Normalerweise reicht ein Blick in die Kurzbeschreibung um zu sehen, ob 
es eventuell Beeinflussungen gibt. Ist man sich nicht sicher, dann sieht 
man sich die File-Liste an. Ist da nichts dabei, was verdächtig klingt, 
dann wars das schon. Verdächtige Files wird man sich genauer ansehen, 
wobei da wieder die Infrastruktur eines Merge Tools zu Einsatz kommt - 
diesmal aber um die Änderungen zu zeigen.

Erweitert kommt hinzu, dass man tunlichst nicht zu lange wartet, bis man 
seine Änderungen eincheckt. Habe ich einen Bug zu fixen, dann wird der 
Bug gesucht, gefixt und die betroffenen Files sofort wieder eingecheckt. 
Je länger man damit zuwartet, desto größer wird die Chance, dass man 
Code Kollisionen hat. Und die will man nicht haben. Hier ist also 
Disziplin gefragt - schon im eigenen Interesse.

Zitat aus dem Vorwort (!) vom SVN Book:

1

[...] die Arbeit in einem Entwicklerteam ist von Natur aus eine soziale Tätigkeit bei der Änderungen am Quelltext ständig besprochen, durchgeführt, geprüft und manchmal sogar rückgängig gemacht werden. Versionskontroll-Werkzeuge ermöglichen diese Art der Zusammenarbeit.

Soll heißen: das Einsetzen eines SCM-Tools bedeutet nicht, dass ein Team 
nicht mehr zusammenarbeiten muss...

Gruß
Dennis

Karl H. schrieb:
> schon im eigenen Interesse.

Wer zuerst eincheckt, hat den Ärger mit dem Mergen nicht ;)

Karl H. schrieb:
> (Über so Dinge wie Branches reden wir erst mal nicht)

Schade. Ich benutze TortoiseSVN jetzt ein Weilchen für Projekte allein 
und im Team und suche schon seit längerem nach einer guten Beschreibung 
zu einem Brange&Merge-Workflow.

Walter T. schrieb:
> Karl H. schrieb:
>> (Über so Dinge wie Branches reden wir erst mal nicht)
>
> suche schon seit längerem nach einer guten Beschreibung
> zu einem Brange&Merge-Workflow.

Genau das ist meiner Meinung nach das größte Problem. Es gibt tausende 
Tutorials und Anleitung aber kein wirklicher Workflow. Entweder hat man 
Glück und lernt das Tool in einem Team (so ist man in dem Workflow 
mittdrin) oder fragt man einfach nach - wie ich eben gerade -.

Dave A. schrieb:
> Es gibt tausende
> Tutorials und Anleitung aber kein wirklicher Workflow.

Oh, für den Einstieg in normalen Projekten reicht das erste Drittel des 
Tortoise-SVN-Books völlig aus. Die Workflows nach dem Prinzip 
Blockieren/Modifizieren oder der "optimistische" Workflow sind schon gut 
beschrieben. Die beiden zu kennen reicht für die ersten 10 Jahre auch 
aus :-).

Und ich sehe gerade: Im Kapitel "Branch&Merge" hat sich viel getan. Also 
ziehe ich meine Frage erst einmal wieder zurück und lese mir den Teil 
erst einmal durch - ich hatte diesen Teil weitaus weniger umfangreich in 
Erinnerung.

Habt ihr mal überlegt, GIT zu verwenden?
Es ist zwar anfangs etwas komplizierter als SVN, aber durch das 
Branch-Modell hat man (gefühlt) weniger Probleme beim Mergen.
-> Ich kann (sofern ich in meinem eigenen Branch bin) meine Änderungen 
so wie sie sind ins Repository commiten und kann mich danach ums Mergen 
kümmern.

Als GUI verwende ich SourceTree 1.5 von Atlassian und die Kommandozeile.
Früher habe ich auch TortoiseSVN verendet.

(In der Nachfolgeversion 1.6 haben sie das UI "überoptimiert" 
https://jira.atlassian.com/browse/SRCTREEWIN-2271 )

Gruß
Roland

Nachtrag zu meinem obigen Post: hier ist die aktuelle Version des Buchs:

http://svnbook.red-bean.com/de/1.8/svn-book.pdf

Rolf Magnus schrieb:
> Dave A. schrieb:
>> Also...ich habe mein Projektverzeichnis in einem Netzwerk abgelegt. Zwei
>> Rechner - A und B- können/dürfen auf das Verzeichnis zugreifen und den
>> Code herunterziehen.
>
> Das hat zwar nichts mit dem Workflow zu tun, ist aber eigentlich falsch.
> Erstens raten die SVN-Entwickler dringend davon ab, das so zu machen, da
> es bei gleichzeitigem Zugriff auf das Repository oder beim Zugriff vom
> verschiedenen SVN-Versionen zu Problemen kommen kann. Zweitens sollte es
> nie einem Benutzer möglich sein, direkt auf das Repository zuzugreifen
> und es dadurch versehentlich zu beschädigen.

Richtig...und ich weiß es.
Aber manche Entscheidungen werden nicht von mir getroffen.

Stefan schrieb:
> Hi!
>
> Da hätt ich auch gleich eine Frage zum Workflow, vorzugsweise mit Git.

Ich mach es so: Die Änderungen werden in einzelnen Branch(es) gemacht
(Wir hatten früher je Entwickler einen Branch, gehen jetzt aber dazu 
über, je Feature einen eigenen Branch zu machen)

Wenn dann eine neue Version ansteht, wechsle ich in den Master Branch 
und merge vom Dev-Branch. (wenn es nur einen Branch gibt, geht dies als 
Fast-Forward Merge und ohne Konflikte)
Wenn es mehrere Branches von mehreren Entwicklern gibt, dann ist 
durchaus mal Arbeit angesagt, das stimmt :(, hier gehe ich aber den Weg, 
erst mal alles in einen "beta"-Branch zu mergen und wenn Tests etc 
durchlaufen, kommt das in den Master.

Die Feature-Branches sollten nun eigentlich gelöscht werden, bzw. wieder 
mit dem Master gemerged werden.

Zum Umbenennen/Verschieben noch ein Tipp:
- Möglichst weit oben eine zentrale .gitignore platzieren
- Löscht man komplette Verzeichnisse oder benennt diese um, ist es eine 
gute Idee, diese in die GitIgnore einzutragen, da Kollegen sonst nach 
einem Merge oft veraltete Files commiten. Dies ist insbesondere dann der 
Fall, wenn in dem Verzeichnis eine .gitignore enthalten war.

Beim Umbenennen/Verschieben sollte man darauf achten, dass Git die 
Änderungen trackt. Also entweder mit "git mv" verschieben oder vor dem 
Ändern der Dateien einen Commit machen (Git kennt verschobene Dateien 
automatisch, sofern sich noch nicht zu viel Inhalt geändert hat)

Gruß
Roland

Hallo super Freunde,
ich habe eine kurze Frage, die mich gerade beschäftigt.
Ich habe ein Projektsverzeichnis mit den drei Ordner "tags", "branch" 
und "trunk" erzeugt.
Nun ist es soweit, dass ich mein Projekt, das ich unter "trunk" 
entwinkelt habe, als Release unter "tags" kopieren will.

Was soll ich eigentlich machen?
Ich will ich es ordernlich machen, da die erarbeiteten Dateien und 
Programme nicht verloren werden müssen.

Vielen vielen Dank.

Es gibt Fragen, für die Google wirklich alle Antworten kennt. WIRKLICH 
ALLE. Ohne Ausnahme.

In diesem Fall sogar auf Deutsch (auch wenn die übersetzten Begriffe 
schon fast körperlich wehtun):

http://tortoisesvn.net/docs/release/TortoiseSVN_de/tsvn-dug-branchtag.html

Oliver