Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Gibt es eine Möglichkeit ein Release auf einem Projekt zu machen bei dem alle pom.xml die svn Eigenschaft "needs-lock" haben?
"-DuseEditMode=true" nützt übrigens nichts. Letztendlich müsste maven selbstständig "svn lock pom.xml" ausführen.
Falls ich das manuell vorher mache läuft reslaserepare aber auch nicht durch, denn kurz vor Schluss wird ja die neue pom-Datei committed, was zu einem erenuten Lock führt und dann zur Fehlermeldung
Code:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.2:prepare (default-cli) on project project: Error writin
g POM: \pom.xml (Zugriff verweigert) -> [Help 1]
Die einzige Möglichkeit die ich sehe ist needs-lock zu entfernen?!
insgesamt ist need lock sehr hilfreich um Konflikte zu vermeiden - bei Java-Dateien erspart uns das ne Menge Arbeit.
Bei den pom-Dateien ist das tatsächlich etwas anderes. Es kommt aber vor, dass jemand die Dateien anfässt und es kam auch schon vor das mehrere gleichzeitig sie angefasst haben (oft nur marginalste Änderungen - mergen war kein Problem).
Needs-lock löst das Problem komplett und es zwingt die Leute öfter zu comitten - bzw. sie werden von den anderen gefragt bitte ein Datei freizugeben.
Also wenn du sagst es ist nicht möglich für pom/mvn release dann sei es so, ansonsten würde es nix schaden.
Das Problem ist das "Merge" in der Philosophie. Letztendlich werde ich immer gerufen und soll die Konflikte Lösen. Bin ja schließlicch auch der PManager und könnte durch strikte Arbeitsteilung Konflikte verhindern.
"strong code Ownership" ist aber bei uns nicht praktikabel und de Lock-Modify-Unlock Ansatz hab ich schon öfter in anderen (nicht Maven, .net, c++) Projekten gesehen. Nun hab ich ihn für meine Projekt eingeführt und die Entwickler sind sehr dankbar.
Was die pom-Dateien und "Release" betrifft: Theoretisch könnte Maven automatisch auch lock-modify-unlock auf den pom-Dateien durchführen - aber das machts wohl nicht, is aber auch nicht schlimm.
"strong code Ownership" ist aber bei uns nicht praktikabel und de Lock-Modify-Unlock Ansatz hab ich schon öfter in anderen (nicht Maven, .net, c++) Projekten gesehen. Nun hab ich ihn für meine Projekt eingeführt und die Entwickler sind sehr dankbar.
Also wir sind hier ca. 15 Entwickler. Committet wird viele, viele Male täglich. Hier Dateien zu locken wäre eine mittlere Katastrophe. Einen echten Konflikt erlebe ich höchst selten, vielleicht alle paar Monate.
Das Problem ist das "Merge" in der Philosophie. Letztendlich werde ich immer gerufen und soll die Konflikte Lösen. Bin ja schließlicch auch der PManager und könnte durch strikte Arbeitsteilung Konflikte verhindern.
Zuerst einmal. Konflikte müssen von denen gelöst werden, die sie verursachen...und nicht:Oh..sch...da ist ein Konflikt ...ach Rufe ich mal Kollege XY der löst das für mich...
Also mal Grundsätzlich: 100%ig vermeiden kann man Konflikte nicht aber die sollten dann nicht von Dir als PM gelöst worden sondern von den Leuten selbst...man Sollte mal eher Überlegen, ob hier das Verständnis der Leute nicht richtig vorhanden ist wie man ein VCS ordentlich Nutzt und abgesehen davon je nachdem wie Ihr arbeitet ist vielleicht auch mal darüber nachzudenken, ob man eine Branching-Strategie einsetzt etc.
Klar sind die Dankbar. Die brauchen sich damit dann nicht zu beschäftigen...und können sich gemütlich zurück lehnen....Ich habe ja einen "Sklaven" dafür...sorry....;-)
tfa - hast du schonmal mit needs-lock gearbeitet die meisten ide's unterstützen das hervorragend!
Also bei uns kann jeder an jeder Datei rummachen (es gibt kein Eigentum) und aller paar Wochen gab es immer mal Konflikte. 99% der Konflikte waren aber unnötig:
- Der erste (z.b. müller) der die Datei geändert hat ist eigentlich schon fertig es fehlt nur noch das commit
- hätte der 2. (z.b. mayer) der die Datei öffnet gewusste, dass sie irgendwo geändert wurde hätte er zunächst was anderes gemacht
Mit needs-lock wird diese Situation komplett umgangen: Müller öffnet die Datei zum ändern, die IDE macht popup auf, mit ok bestätigen - lock ist gesetzt (bei comit wird lock automatisch entfernt)
Mayer will was ändern und sieht, dass müller dran ist. Mayer fragt Müller "bist du fertig, kannst bitte comitten?" - egal was die Antwort ist man hat keinen Konflikt mehr
Das einzige was sich also ändert ist beim öffnen zum ändern das poup was man mit ok bestätigen muss - die Entwickler stört das nicht. Was die Entwickler aber freut, ist die Gewissheit, das es keinen Konflikt geben kann.
Ich hab das wie gesagt schon bei anderen Firmen und Projekten gesehen. Die Argumente waren immer die gleichen:
- Auto-Merge funktioniert s*****e
- manuelles mergen nervt
- echtes gleichzeitiges arbeiten an einer Datei ist meistens nicht nötig - damit sind Konflikte und mergen aber auch nicht nötig und "needs-lock" synchronisiert recht komfortabel (zumindest bei dem was ich kenne visual studio, eclipse)
Das ist ja auch richtig so, deswegen muss man aber nicht zu locks greifen...
- Der erste (z.b. müller) der die Datei geändert hat ist eigentlich schon fertig es fehlt nur noch das commit
- hätte der 2. (z.b. mayer) der die Datei öffnet gewusste, dass sie irgendwo geändert wurde hätte er zunächst was anderes gemacht
Da sind die eigentlichen Probleme, mit Locks bekämpft man nur das Sympton
Wenn erst durch einen Lock klar wird wer da sonst noch daran arbeitet ist was faul.
Mayer will was ändern und sieht, dass müller dran ist. Mayer fragt Müller "bist du fertig, kannst bitte comitten?" - egal was die Antwort ist man hat keinen Konflikt mehr
Was macht denn Mayer bis Müller committed hat?
Däumchendrehen und warten bis Müller fertig ist bzw. aus dem Urlaub zurück ist?
Ich hab das wie gesagt schon bei anderen Firmen und Projekten gesehen. Die Argumente waren immer die gleichen:
- Auto-Merge funktioniert s*****e
- manuelles mergen nervt
- echtes gleichzeitiges arbeiten an einer Datei ist meistens nicht nötig - damit sind Konflikte und mergen aber auch nicht nötig und "needs-lock" synchronisiert recht komfortabel (zumindest bei dem was ich kenne visual studio, eclipse)
Diese Argumente sind IMHO sehr schwach und widersprechen sich teilweise..
- Automerge funzt sehr gut wenn die Entwickler kommunizieren.
- Manuelles mergen nervt nicht, geht sehr schnell falls mal nötig (IDE Unterstützung ist sehr gut zB.. mit Eclipse Subversive), meistens reicht ein einfacher update
- wenn echtes gleichzetiges arbeiten an einer Datei meist nicht nötig ist, wozu dann überhaupt erst locken?
Echte Konflikte gibt es doch nur, wenn meherere Entwickler eine Zeile gleichzeitig ändern... warum machen die das?
Diese ganze Diskussion ist uralt, Tatsache ist, dass man mit "modernen" Arbeitsweisen kein Lock braucht.
SVN hat das Locking erst sehr spät unterstützt, auf Druck von "alten" Entwicklern die nicht mit modernen Arbeitsweisen zurechtkommen.
Schon klar dass man nunmal mit den Entwicklern zurechtkommen muss die man hat, aber locking hat mehr Nachteile als Vorteile IMHO.
Hab schon bei ein paar Umstellungen von CVS oder MKS auf Subversion mitgemacht, das gejammere über die fehlenden Locks (wurden verboten ) kam meist nur von Leuten die sich nicht umstellen wollten, bis sie sich dann umgestellt haben
Nein, hab ich nicht. Warum sollte man sich von einer IDE hervorragend dabei unterstützen lassen, sich unnötigerweise selbst zu behindern?
Ich würde empfehlen, das Locking wieder abzuschaffen. Wenn es dann zu Konflikten kommt, sollte man den Grund analysieren und die Ursache des Problems beseitigen.
- Der erste (z.b. müller) der die Datei geändert hat ist eigentlich schon fertig es fehlt nur noch das commit
- hätte der 2. (z.b. mayer) der die Datei öffnet gewusste, dass sie irgendwo geändert wurde hätte er zunächst was anderes gemacht
Warum hat Müller dann nicht committed. Das ist nämlich eines dieser typischen Probleme: Oh ha...committ das ist was gefährliches...Wie eine Bombe...Die haben eine VCS noch nicht verstanden...und weiterhin häufiges committen von kleinen Änderungen...
Mayer will was ändern und sieht, dass müller dran ist. Mayer fragt Müller "bist du fertig, kannst bitte comitten?" - egal was die Antwort ist man hat keinen Konflikt mehr
Genau hier würde ich Fragen: Warum hängen die beide an der Datei ? Aufgabenteilung...
Weiterhin ist anzumerken, dass ein Lock nur für einen Pfad im Repository gilt und somit sinnlos im Zusammenhang mit Branches wird....also wird hier nur mit trunk entwickelt...was ein weiteres Indiz dafür ist, dass hier das Verständnis eines VCS fehlt bzw. die Nutzung und wie der Umgang damit ist...
Was ist ein Auto-Merge ? Meinst Du hier ein Update ? oder meinst Du den Merge bei einer Änderung innerhalb einer Datei OHNE Konflikt ? Kann ich leider nicht bestätigen...selbst mit 200 Entwicklern klappt das...
- echtes gleichzeitiges arbeiten an einer Datei ist meistens nicht nötig - damit sind Konflikte und mergen aber auch nicht nötig und "needs-lock" synchronisiert recht komfortabel (zumindest bei dem was ich kenne visual studio, eclipse)
Somit ist auch needs-lock nicht notwendig. Also wiedersprichst Du Dir hier selbst...
Typischen Kandidaten wo Konflikte auftauchen können sind Datenbank-Konfigurationsdateien oder ähnliches. selten bei Sourcen...
Was soll ich sagen ihr habt ja alle Recht. Nur macht die Praxis da einfach was anderes als die Theorie. Nun haben die Entwickler eben keine Angst mehr vorm comitten. Ihr könnt gerne vorbeikommen und den Entwicklern die Theorie erklären .
Das Lock ist für die wie eine flauschige Kuscheldecke: update vergessen - nicht so schlimm, commit vergessen - nicht so schlimm.
Und wenn jemand im Urlaub ist gibts nen break lock - Ansonsten gibts immer genug Aufgaben für alle. Die Testabdeckung ist zum Beispiel eine sehr beliebte die immer übrig ist ;-).
Nur macht die Praxis da einfach was anderes als die Theorie. Nun haben die Entwickler eben keine Angst mehr vorm comitten. Ihr könnt gerne vorbeikommen und den Entwicklern die Theorie erklären .
100%ig Ack...Locking ist von vorgestern...Zu zeiten von RCS hat man das gemacht...aber heute ist Locking schlicht nicht notwendig bzw. Kontraproduktiv (bis auf die von mir genannten Ausnahmen).
Wie kann es denn sein, dass DVCS OHNE Locking auskommen ? Müsste ja dann eine Katastrophe sein...
repare aber auch nicht durch, denn kurz vor Schluss wird ja die neue pom-Datei committed, was zu einem erenuten Lock führt und dann zur Fehlermeldung
