# Maven Release mit SVN Locks



## dermoritz (15. Mai 2012)

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

```
[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?!


----------



## kama (15. Mai 2012)

Hi,

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

Gruß
Karl-Heinz Marbaise


----------



## dermoritz (16. Mai 2012)

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.


----------



## kama (16. Mai 2012)

Hi,



dermoritz hat gesagt.:


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



dermoritz hat gesagt.:


> 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


----------



## dermoritz (22. Mai 2012)

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


----------



## maki (22. Mai 2012)

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


----------



## tfa (22. Mai 2012)

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.


----------



## kama (22. Mai 2012)

Hi,



dermoritz hat gesagt.:


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



dermoritz hat gesagt.:


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


----------



## dermoritz (22. Mai 2012)

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)


----------



## maki (22. Mai 2012)

> 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 (22. Mai 2012)

dermoritz hat gesagt.:


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


----------



## kama (22. Mai 2012)

Hallo,



dermoritz hat gesagt.:


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



dermoritz hat gesagt.:


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



dermoritz hat gesagt.:


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



dermoritz hat gesagt.:


> - manuelles mergen nervt


Noch nie 100te Branches gemerged...klappt einwandfrei...Wo ist das Problem?



dermoritz hat gesagt.:


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


----------



## dermoritz (23. Mai 2012)

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


----------



## tfa (23. Mai 2012)

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


----------



## kama (23. Mai 2012)

Hallo,



tfa hat gesagt.:


> 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


----------

