Suche: Best Practice - *.dproj und SVN

[WiPhi]

Hallo liebe Community,

wir wollen gerne unsere Delphi Projektdatei mit in unser SVN Repository einchecken, um Versionseinstellungen bei allen Entwicklern gleich zu ziehen.

Wir haben uns vorab über den DPROJ Splitter von Uwe Raabe informiert und für gut befunden. Leider splittet dieser nicht unterschiedliche Ausgabe-Verzeichnisse für Units, Packages usw. ab.

Da einige Entwickler der Meinung sind, das das Standardausgabeverzeichnis

Code:

.\$(Project)\$(Config)

ihnen nicht passt (...), suchen wir eine Möglichkeit diese

• auch mit abzusplitten
• oder die Datei im SVN so zu halten, dass nur ein Benutzer die Datei einchecken darf (Version ändern) und alle anderen Änderungen der Entwickler dürfen nicht übertragen werden

Über Anregungen und Vorschläge würde ich mich sehr freuen!
Vielen Dank :)

[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. :stupid:

[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. :stupid:
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

[Uwe Raabe]

Zitat:

Zitat von WiPhi (Beitrag 1383157)

Wir haben uns vorab über den DPROJ Splitter von Uwe Raabe informiert und für gut befunden. Leider splittet dieser nicht unterschiedliche Ausgabe-Verzeichnisse für Units, Packages usw. ab.

Standardmäßig werden folgende Einträge in den Property-Groups gesplittet:

Delphi-Quellcode:

    
    Debugger_RunParams
    Debugger_RemoteRunParams
    Debugger_HostApplication
    Debugger_RemotePath
    Debugger_RemoteHost
    Debugger_EnvVars
    Debugger_SymTabs
    Debugger_Launcher
    Debugger_RemoteLauncher
    Debugger_IncludeSystemVars
    Debugger_UseLauncher
    Debugger_UseRemoteLauncher
    Debugger_CWD
    Debugger_RemoteCWD
    Debugger_RemoteDebug
    Debugger_DebugSourcePath
    Debugger_LoadAllSymbols
    Debugger_LoadUnspecifiedSymbols
    Debugger_SymbolSourcePath

Du kannst dieses Standardverhalten aber überschreiben, wenn du eine Datei namens DprojSplitter.cfg im Verzeichnis %AppData%\Roaming\Embarcadero\BDS\19.0\ (für Tokyo) anlegst, in der die gewünschten Einträge zeilenweise aufgelistet sind.

Um also z.B. das Unit-Ausgabeverzeichnis ebenfalls zu splitten, müsste diese Datei die obige Liste ergänzt um die Zeile DCC_DcuOutput enthalten.

[Rollo62]

Trifft vielleichtn icht ganz deine Frage:
aber die .DPROJ könntest du auch ausserhalb des SVN halten,
z.B. indem du das Projekt ein Unterverzeichnis tiefer verschachtelst.
Hat natürlich den Nachteil dass das "ganz" Projekt dann nicht im SVN ist, man könnte aber ein Backup der DPROJ innerhalb des SVN anlegen, wenn Änderungen kommen.

Rollo

[TigerLilly]

Vielleicht das auch als Input:
Wir haben bei manchen Projekten im Team das so gehandhabt, dass wir per SUBST ein Laufwerk eingebunden haben + das war das Projektlaufwerk, egal, wo auf einer HD das nun physisch war. Alles, was mit VCS oder Skripts des Projekts zu tun hatte, benutzte dieses Laufwerk.

[WiPhi]

Zitat:

Zitat von Uwe Raabe (Beitrag 1383390)

Du kannst dieses Standardverhalten aber überschreiben, wenn du eine Datei namens DprojSplitter.cfg im Verzeichnis %AppData%\Roaming\Embarcadero\BDS\19.0\ (für Tokyo) anlegst, in der die gewünschten Einträge zeilenweise aufgelistet sind.

Um also z.B. das Unit-Ausgabeverzeichnis ebenfalls zu splitten, müsste diese Datei die obige Liste ergänzt um die Zeile DCC_DcuOutput enthalten.

Das wusste ich gar nicht, das das geht. Ist das auf der Projektseite dokumentiert? ;) Wir werden das auf jeden Fall versuchen. Mit unserem Package-Installer kann ich die Datei auf jeden Entwickler-Rechner problemlos aufspielen. Vielen Dank!