Maven Release mit SVN Locks

dermoritz

Bekanntes Mitglied
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 reslase😛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
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?!
 
Hi,

da würde mich zuerst fragen warum pom Dateien needs:lock property haben? Macht bei source überhaupt keinen Sinn...

Gruß
Karl-Heinz Marbaise
 
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.
 
Hi,

insgesamt ist need lock sehr hilfreich um Konflikte zu vermeiden - bei Java-Dateien erspart uns das ne Menge Arbeit.
Habt Ihr mal analysiert warum Ihr konflikte habt ?

Das wiederspricht aber völlig der Idee von SVN und anderen VCS...

Wenn Ihr zu viele Konflikte habt läuft was anderes schief...

Das Konzept von SVN (und anderen VCS) ist nun mal: Copy-Edit-Modify-Merge ...

Locks sollte man nur bei nicht mergbaren Dateien anwenden (typische Kandidaten binär Dateien a la Word, Excel, Grafik)...

Also wenn du sagst es ist nicht möglich für pom/mvn release dann sei es so, ansonsten würde es nix schaden.
Bei den POM's geht es deshalb nicht weil während des Release Prozesses die POM's geändert werden...für den Rest ist das kein Problem...

Gruß
Karl-Heinz Marbaise
 
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.

Nochmal danke kama für die Aufklärung
 
Hi Moritz,

"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.
"strong code Ownership" hat gar nix damit zu tun, ob man Files lockt oder nicht, Kommunikation, Arbeitsteilung und Organisation dagegen schon.

Nun hab ich ihn für meine Projekt eingeführt und die Entwickler sind sehr dankbar.
Hmmm... das klingt gar nicht gut...
 
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.
 
Hi,

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.

..Nun hab ich ihn für meine Projekt eingeführt und die Entwickler sind sehr dankbar.
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....;-)

Gruß
Karl-Heinz Marbaise
 
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)
 
Also bei uns kann jeder an jeder Datei rummachen (es gibt kein Eigentum)
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 🙂
 
tfa - hast du schonmal mit needs-lock gearbeitet die meisten ide's unterstützen das hervorragend!
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.
 
Hallo,

- 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...

Ich hab das wie gesagt schon bei anderen Firmen und Projekten gesehen. Die Argumente waren immer die gleichen:
- Auto-Merge funktioniert s*****e
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...

von alleine macht Subversion keinen Merge...;-)

- manuelles mergen nervt
Noch nie 100te Branches gemerged...klappt einwandfrei...Wo ist das Problem?

- 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...

Gruß
Karl-Heinz Marbaise
 
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 .
Theorie? Also bei mir ist das "nicht-Locken" gelebte, gut funktionierende Praxis. (Und ich unterstelle mal bei den anderen hier ebenso).
 
Hallo,

Theorie? Also bei mir ist das "nicht-Locken" gelebte, gut funktionierende Praxis. (Und ich unterstelle mal bei den anderen hier ebenso).

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...

Gruß
Karl-Heinz Marbaise
 

Zurück
Oben