Subclipse LiveUpdate?

[Guest]

Hallo.

wir benutzen seit ein paar Tagen Subclipse im Team. Nun fragen wir uns ob es eine Möglichkeit gibt das man sofort sehen kann wenn eine Java Klasse von einem anderen Teammitglied z.B. "locked" ist, bzw. bearbeitet wird oder irgendeine Form von Statusänderung erfahren hat (also ohne das man von Hand Update macht oder alle Klassen von Hand versucht zu locken um dann feststellen zu können welche denn bereits gelocket sind). Die Teammitgleider sitzen nciht direkt beieinander und wir müssen seitdem sehr viel telefonieren.

Gibt es sowas wie ein LiveUpdate das die StatusIcons der Klassen im PackageExplorer automatisch auf den Status des SVN-Servers aktualisiert?


Viele Grüße,
Sabine Janssen

 

[kama]

Hallo,

zuerst einmal scheint Ihr wenig bzw. garnichts über Subversion zu wissen...

Es gibt eine Synchronize View (Context-Menu -> Team -> Synchronize), die man genau dazu verwenden kann zu prüfen, ob was neues da ist...und bei Bedarf dann auch entsprechend übernehmen (mergen).

In Subversion gibt es keinen Status einer Datei (außer man macht sich per Property einen selbst)....
Eine Änderung wird dann für andere Sichbar, wenn eincheckt wurde...fertig....

Ob jemand eine Datei bearbeitet, kann man nicht sehen, da man eine WorkingCopy auscheckt und bei sich lokal auf dem Rechner hat....danach kann man mit dem Rechner spazieren gehen etc. Der Subversion Server weiß nichts davon....Anders ausgedrückt kann man nicht fest stellen, ob jemand eine Datei bearbeitet, sondern nur in der Form, dass man Dateien vorher mit einem Lock versieht, ob der Lock gesetzt ist oder nicht....

Das Locking sollte man unbedingt vermeiden, ausser bei Word und Co....

PS.: Ich empfehle ein Subversion Training bzw. Schulung
MfG
Karl Heinz Marbaise

 

[SlaterB]

das 'locken' im ersten Post klingt tatsächlich etwas ungewöhnlich,
aber selbst wenn man mal voraussetzt, dass man simples Synchronize einsetzt, was man in 5 Min. lernt (statt Training/ Schulung??)
so wäre es doch immer noch interessant, wie bei jeden simplen Chat eine Meldung zu bekommen a la 'XY hat gerade Klasse YZ committed'

gibts sowas?

 

[Wildcard]

Du kannst Serverseitig Hooks einbinden die bspw. EMails versenden.
Ansonsten steht es jedem frei das Eclipse Communication Framework an die eigenen Team Bedürfnisse anzupassen.

 

[Guest]

Danke für Eure Antworten.

Das Locking sollte man unbedingt vermeiden, ausser bei Word und Co....

Wir wollen irgendwie vermeiden das mehrere Leute gleichzeitig eine Klasse bearbeiten (ohne das explizit absprechen zu müssen). Mit dem Merge haben wir bereits schlechte Erfahrungen gemacht. Der Fall sollte meiner Meinung nach erst garnicht zustande kommen. Jede Klasse soll nur von einer Person bearbeitet werden und für diese Zeit gesperrt sein. Was ist denn an Locking schlecht, warum sollte man es nicht benutzen?


Was ich nicht verstehe, wenn ich ein "Update" mache, dann sehe ich doch auch ob jemand z.B. einen Lock gesetzt hat. Kann man das nicht irgendwie automatisch haben? Niemand klickt doch permanent auf "Update" oder "Synchronize". Die Stati der Klassen ändern sich laufend wenn 10 Leute an einem Projekt arbeiten.

so wäre es doch immer noch interessant, wie bei jeden simplen Chat eine Meldung zu bekommen a la 'XY hat gerade Klasse YZ committed'

Ganz genau das suchen wir! Von serverseitigen Hooks verstehe ich leider nichts (was ist das?), um das Eclipse Communication Framework anzupassen fehlt uns fürchte ich die Zeit (ich nehme an das hiesse sich das gewünschte Plugin selbst zu programieren).

Gibt es nicht schon ein Ready-to-Use Plugin für diese Aufgabe (gerne auch kostenpflichtig)?


Viele Grüße,
Sabine Janssen

 

[tfa]

Danke für Eure Antworten.

Das Locking sollte man unbedingt vermeiden, ausser bei Word und Co....

Wir wollen irgendwie vermeiden das mehrere Leute gleichzeitig eine Klasse bearbeiten (ohne das explizit absprechen zu müssen). Mit dem Merge haben wir bereits schlechte Erfahrungen gemacht. Der Fall sollte meiner Meinung nach erst garnicht zustande kommen. Jede Klasse soll nur von einer Person bearbeitet werden und für diese Zeit gesperrt sein. Was ist denn an Locking schlecht, warum sollte man es nicht benutzen?

Es behindert einfach die Zusammenarbeit im Team. Was soll denn ein Entwickler machen, der jetzt gerade eine Datei verändern will, die von einem anderen gelockt ist außer Däumchendrehen? Der andere braucht vielleicht noch Stunden (oder länger) bis seine Änderungen commit-reif sind und er den Lock freigeben kann.

Mit welchem VCS habt ihr denn die schlechten Erfahrungen gemacht? Die Merges bei Subversion (und auch bei CVS) funktionieren doch vollautomatisch. Einfach vor dem Commit ein Update machen und die Änderungen der anderen werden in den eigenen Workspace übernommen. Konflikte, die man von Hand lösen muss, treten nach meiner Erfahrung extrem selten auf -- vielleicht 1-2 mal im Jahr.

Von serverseitigen Hooks verstehe ich leider nichts (was ist das?)

Im /hooks-Verzeichnis der Repository-Installation befinden sich einige Skripte, die bei bestimmten Ereignissen aufgerufen werden, z.B. vor oder nach dem Commit, beim Locking etc. Dokumentation und Beispiele findet man in diesem Verzeichnis.

 

[byte]

Wenn alle Entwickler die Klassen locken, an denen sie grade arbeiten, ist das eher kontraproduktiv fürs Team. Du kannst dann z.b. nicht mehr verünftig Refactorings durchführen. Ausserdem gibt es immer zentrale Klassen, die für für Baustellen relevant sind. Sind die gelockt, kann an anderer Stelle evtl. nicht weitergearbeitet werden.
Ihr solltet also lieber etwas koordinierter arbeiten (teilt die Aufgaben sinnvoll auf die Entwickler auf). Dann kann jeder an seiner Baustelle arbeiten und die Überschneidungen werden gemerget. Im übrigen ist es häufig auch gar kein Problem, wenn zwei Entwickler an er gleichen Klasse was ändern. Und wenn es doch mal Konflikte gibt, muss man halt von Hand mergen. Das ist erstmal gewöhnungsbedürftig, gehört aber nun mal dazu. Durch viele kleine Commits kann man die Anzahl an Konflikten auch minimieren.

 

[ms]

Wir wollen irgendwie vermeiden das mehrere Leute gleichzeitig eine Klasse bearbeiten

Warum wollen mehrere Leute gleichzeitig an ein und der selben Klasse arbeiten?
Kann es sein, dass euer Klassendesign nicht ganz sauber ist?
Jede Klasse sollte eine bestimmte Aufgabe/Zweck erfüllen.

Vor ein paar Monaten hatten wir dieses Thema schon mal ...

ms

 

[Lim_Dul]

Wenn zwei Entwickler an der gleichen Datei arbeiten wollen, dann gibts eigentlich zwei Fälle:

Fall 1:
Entwickler A entwickelt diese Klasse weiter.
Entwickler B muss eine Kleinigkeit an der Klasse ändern (Kleiner Bugfix oder weitere getter Methode oder ähnliches)

In 99% der Fälle funktioniert der Merge problemlos, selbst wenn nicht sollte es meistens eine Kleinigkeit sein, den zu resolven.

Fall 2:
Entwickler A entwickelt diese Klasse weiter.
Entwickler B entwickelt diese Klasse weiter.

Dann knallts natürlich beim Merge, aber dann ist irgendwas in der Organistation im argen. Denn eigentlich sollte es in größeren Teams, insbesondere wenn sie nicht im gleichen Büro sitzen, eine klare Aufgabenzuordnung geben. Und diese Aufgaben sollten so zugeordnet sein, dass sie sich möglichst nicht überschneiden. Dafür sollte es einen Projektleiter geben, der dieses organisert und beispielsweise Bugs zuweist.

Sollten trotz disjunkter Aufgabenpakete die Leute an gleichen Klasen arbeiten, dann sollte man mal das Klassendesign kritisch hinterfragen.

 

[Guest]

Vielen Dank für Eure Antworten. Wir werden uns also nochmal Gedanken über die Organisation machen.

Eines habe ich jedoch immer noch nicht verstanden. Wie entscheide ich ob ich ein Merge oder ein Commit machen muss? Ich kann ja schliesslich nicht sehen ob jemand anders die Klasse verändert hat...?

Gibt es wirklich kein Plugin das anzeigt welche Klasse aktuell von welchem SVN User bearbeitet wird? Das wäre einfach allein deshalb sehr schön damit sich das Team besser daran gewöhnen kann. Der Übersicht würde es ja auch keinesfalls schaden.

 

[tfa]

Das merkt Subversion. Wenn Du ein Commit machst, gibt es drei Möglichkeiten:

1. Niemand hat die Datei inzwischen verändert. Der Commit funktioniert sofort.

2. Jemand anders hat die Datei zwischenzeitlich geändert - aber an anderen Stellen. Bei einem Commit sagt SVN, dass Du nicht die aktuellste Version im Workspace hast. Du machst also einen Update, die Änderungen werden konfliktfrei in Deine Kopie gemerget und Du kannst committen.

3. Jemand anders hat die Datei an der selben Stelle geändert. Es kommt zu einem Konflikt, der manuell behoben werden muss. Bei einer vernünftigen Organisation kommt so etwas extrem selten vor.

 

[Wildcard]

Am besten du machst nie direkt commit, sondern synchronize with repository.
Dann siehst du was sich geändert hat und ob Konflikte bestehen. Die meisten Konflikte lassen sich automatisch beheben, da zwei unterschiedliche Stellen editiert wurden.
Im extrem seltenen Fall das sich Änderungen gegenseitig überschreiben muss dann manuell gemerged werden.