Hallo zusammen! Verwende seit gestern Tortoise SVN und habe eine Frage dazu. Habe mit commit schon einige Änderungen eingestellt und habe mir jetzt mal das log angesehen. Dort sehe ich meine bisherigen Versionen und in der Spalte action ein rotes Ausrufezeichen und ein blaues plus Zeichen. Kann mir jemand erklären was diese beiden bedeuten und wie ich das rote Ausrufezeichen weg bekomme. anscheinend stimmt etwas nicht. was habe ich falsch gemacht? vielen dank für euere antworten! mike
Wenn du das Logmeldungen-Fenster siehst, gibt es unten rechts den Button 'Hilfe'... wenn du den drückst, dann kommt (nach etwas runterscrollen) folgendes: > 5.9.2. Aktionen im Revisionslog > Der obere Bereich enthält eine Aktionen Spalte, in der Symbole die > Änderungen einer Revision zusammenfassen. Es gibt vier verschiedene > Symbole, die jeweils in einer eigenen Spalte angezeigt werden. > > > (!) <--das rote Ausrufezeichen > in der ersten Spalte zeigt an, dass in einer Revision eine Datei > oder ein Ordner geändert wurde. Die Bedeutung der anderen drei Symbole musst du jetzt aber selbst ermitteln. ;-)
morgen zusammen! hänge mich mal hier mit dazu... habe folgende frage: ich habe insgesamt 22 revisions und bin nun mittels "revert to this revision" auf revision 20 "gewechselt". hat alles wunderbar funktioniert. nun möchte ich aber wieder auf revision 22 wechseln. kann mir einer erklären, wie ich das realisiere? Vielen dank schon mal! josef
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ß
Wenn du unter Windows bist, z.B. WinMerge installieren und in svn einstellen das WinMerge das standard diff-tool ist. Unter Linux benutze ich Kdiff3. Dann kannst du auch sehen was wo geändert wurde und das ganze mergen.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Hi! Da hätt ich auch gleich eine Frage zum Workflow, vorzugsweise mit Git. Ausgangspunkt wäre eine Library zu der es laufend Aktualisierungen gibt. (Releases zum Download) An dieser habe ich jede Menge Änderungen gemacht. Ich würde gerne Up-to-date sein, aber auch meine Änderungen eingepflegt haben. Zurzeit führe ich ein Git-Repository mit der unveränderten Library im master branch. In einem anderen branch habe ich die angepasste Version der Library. Zum Updaten wechsle ich auf den master branch und committe die aktuelle Version. Dann wechlse ich auf den anderen branch und gebe "git merge master" ein. Das funktioniert aber nicht immer gut, vor allem wenn Dateien umbenannt oder gelöscht wurden. Kennt Ihr eine bessere Möglichkeit? Gruß Stefan
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.
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
:
Bearbeitet durch User
Roland P. schrieb: > Habt ihr mal überlegt, GIT zu verwenden? Wo kommen eigentlich immer all die Leute her, die Git in Großbuchstaben schreiben? > 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. Also völlig genauso wie in Subversion. Oder gar in CVS, Gott hab es selig.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.