Suche: Best Practice - *.dproj und SVN

[Der schöne Günther]

Wären dafür nicht die "Optionsgruppen" gut?

Jeder der den Standard-Ausgabepfad nicht mag kann seine eigene Optionsgruppe darüber pflanzen, da es eine separate Datei ist muss er sie aber auch nicht einchecken.


PS: Ich habe schon lange nichts mehr mit Subversion gemacht, aber seit 1.8(?) konnte man doch auch einzelne Zeilen vom Commit ausklammern. So könnte man doch die Zeile welche das Ausgabeverzeichnis ändert einfach nicht committen. Oder hat SVN nicht mittlerweile auch so etwas wie einen "stash" (Git) bzw. "shelf" (Mercurial) ist?

[TigerLilly]

a) 4.4.4. Excluding Items from the Commit List
Sometimes you have versioned files that change frequently but that you really don't want to commit. Sometimes this indicates a flaw in your build process - why are those files versioned? should you be using template files? But occasionally it is inevitable. A classic reason is that your IDE changes a timestamp in the project file every time you build. The project file has to be versioned as it includes all the build settings, but it doesn't need to be committed just because the timestamp changed.

To help out in awkward cases like this, we have reserved a changelist called ignore-on-commit. Any file added to this changelist will automatically be unchecked in the commit dialog. You can still commit changes, but you have to select it manually in the commit dialog.

b) Für die Konfig-Files einen eigenen Branch anlegen, der nie gemerged wird.

[himitsu]

ignore-on-commit funktioniert, aber es gibt einen winzigen Nachteil:
Diese Liste wird nicht im Server, sondern im ClientVerzeichnis verwaltet.

Also jeder muß das bei sich selber erst dort reinschieben, nach jedem einzelnen neuen Checkout,
und wenn es jemand vergistt, dann wird es natürlich schnell mal hochgeladen.

[WiPhi]

Vielen Dank für die ganzen Inputs.

• Optionsgruppen sind mir zu lästig und empfinde ich auch nicht besonders gut, aber vielleicht habe ich das Prinzip dahinter auch nicht ganz verstanden.
• ignore-on-commit ist eine gute Idee, aber in jedem Verzeichnis das ausgecheckt wird, das erneut einzutragen, ich kenne unsere Pappenheimer, die vergessen das
• einen stash auf svn zu machen, ist auch wieder Handarbeit, weiß auch gar nicht, ob das im SVN so geht
• Klar kann ich jedem sagen, dass er die DPROJ nicht hoch zu laden hat, aber das vergisst auch mal schnell jemand.

Ich habe eine andere Möglichkeit gefunden, welche evtl. funktioniert:
Wir haben einen eigenen Benutzer der permanent die Sperre auf die DPROJ Datei hält, so kann ich von diesem Benutzer aus die Version aktualisieren. Diese wird dann in die einzelnen Arbeitskopien gemergt. Sollte ein Entwickler versuchen seine DPROJ hochzuladen, sollte die Sperre das verhindern. Mal sehen wie lang das gut geht.

Falls jemand noch eine andere Idee hat, würde ich mich sehr freuen.

Viele Grüße!

[himitsu]

Im SVN gibt es serverseitige Skripte, die man bei verschiedenen Aktionen ausführen lassen kann.
Da könnte man leicht ALLEN, bis auf Einen/Wenige, das einchecken solcher Dateien verbieten.

Ich hab bei uns so ein Script eingespielt, damit jeder SEINE Log-Messages nach dem Commit nochmal ändern kann,
falls er Diese vergessen oder etwas falschgemacht hat.

Standardmäßig sind im SVN-Log alle Messages nicht veränderbar, selbst wenn man im Kontextmenü ein sogenanntes "Edit log message" entdeckt.
https://www.visualsvn.com/support/sv...evprop-change/
https://www.splashsoft.de/artikel/su...p-change-hook/
https://tortoisesvn.net/docs/nightly...ory-hooks.html