Working in a team? DprojSplitter might be helpful!

Some of you are probably already using my DprojNormalizer plugin for Delphi, which tries to reduce the unwanted differences disturbing your version control system. It does this by forcing a dedicated order of the entries found in the dproj file.

Unfortunately it doesn’t help for those cases where you make changes to the project configuration but don’t want to spread these changes into the version control. For example, changing from Release to Debug configuration or switching to another target platform are some of these changes, but usually all the settings found under the RunParameters menu belong into this category. These settings often reference folders or files local to your machine or are in some way not suited for your colleagues systems.

So let me introduce DprojNormalizers little brother: DprojSplitter!

DprojSplitter takes care of these settings mentioned above and stores any changes you made to them in a separate local file with a dproj.user extension (sorry, dproj.local was already occupied). The corresponding settings in the plain dproj will be reverted to the state when it was loaded. When opening a project, DprojSplitter looks for such a dproj.user file and, if found, merges it into the project settings found in the plain dproj file.

This way you can have your local settings private to your system and so can your teammates.

DprojSplitter is similar to DprojNormalizer: if it is loaded it does its thing. If you don’t want that you have to remove it from the installed packages. This might be necessary when you have to make some changes that actually shall go into the version control this time.

You can download DprojSplitter here:  DprojSplitter

As always: if you find any error or problem, please tell me.

About Uwe Raabe

Addicted to Pascal/Delphi since the late 70's
This entry was posted in Delphi, Programming. Bookmark the permalink.

12 Responses to Working in a team? DprojSplitter might be helpful!

  1. Alexander says:

    Tokyo 10.2 not available for installation. It is right?

  2. Alexander says:

    What about Params?

    • Alexander says:

      Sorry, wrong comment. I mean Debugger_RunParams Params

      • Uwe Raabe says:

        So what about them?
        DprojSplitter handles the current build configuration and current plattform. In addition these settings are handled, too (found in CommonOptionStrs):

        sDebugger_RunParams,
        sDebugger_RemoteRunParams,
        sDebugger_HostApplication,
        sDebugger_RemotePath,
        sDebugger_RemoteHost,
        sDebugger_EnvVars,
        sDebugger_SymTabs,
        sDebugger_Launcher,
        sDebugger_RemoteLauncher,
        sDebugger_IncludeSystemVars,
        sDebugger_UseLauncher,
        sDebugger_UseRemoteLauncher,
        sDebugger_CWD,
        sDebugger_RemoteCWD,
        sDebugger_RemoteDebug,
        sDebugger_DebugSourcePath,
        sDebugger_LoadAllSymbols,
        sDebugger_LoadUnspecifiedSymbols,
        sDebugger_SymbolSourcePath

      • Uwe Raabe says:

        BTW, mind that DprojSplitter takes the settings found in the dproj when loading a project as the desired common settings. Only changes done between loading and saving a project are regarded as user settings.

        • Alexander says:

          When I change Debugger Run Params, test.dproj.user and test.dproj changes both. I think test.dproj should not change anyway

          • Alexander says:

            For example:

            test.dproj.user –

            [code language=”xml”]

            Debug
            Win32

            /TEST_PARAM

            [/code]

            from test.dproj –

            [code language=”xml”]

            Debug
            /TEST_PARAM

            [/code]

          • Uwe Raabe says:

            Argh! Typical error that doesn’t happen in DEBUG mode. Please try again with V1.0.2. Really sorry about that.

  3. Alexander says:

    Everything is working, thank you!

Comments are closed.