Source Version Control and the project.res file

Source Version Control and the project.res file

How have you solved the conflict issues for the .res files?

   

13 thoughts on “Source Version Control and the project.res file


  1. I usually prefer to put the project.res in the .ignore list to keep it out of version control. In some projects where it is under version control for some reason I just resolve the conflicts manually, “resolve using mine” or “resolve using theirs”, depending on context. (There’s not much more you can easily do with a binary file, anyway.)


  2. By not having it in the SVC. Same for dproj and a variety of IDE files.


    For release builds, the .res is generated from scratch as part of the build process, so the .res isn’t necessary.


  3. I don’t put the .res files into svn and don’t let the ide generate them either. My icon goes into _icon.res the version info goes into _version.res, both are created externally in pre-build events. The .rc and .ico file for the icon goes into svn and also the .ini file used by dzprepbuild to generate the version resource. The version info generation in Delphi has been broken since Delphi 2005. 🙁


  4. Eric Grange Are you sure? IME you won’t be able to compile your projects if they don’t have .res files using MSBuild. And if you can’t build with MSBuild then probably you can’t do proper CI.


  5. The IDE can recreate the .res on its own, what’s in it only applies to the executable you build on dev machines, so it’s not a problem if there is no icon or version info.


  6. Eric Grange Sure IDE can recreate .res file but MSBuild can’t. I don’t know any professional software which doesn’t have icon or version info. Personally I’m commiting .res and .dproj files to VCS because I want my project built successfully on the build server.


  7. Recreating the .res is part of the build process as I said, MSBuild doesn’t do it, it’s just an autogenerated rc + brcc32 call, developers don’t do release builds on their own machines. Also we don’t use MSBuild for final builds anyway.


  8. {$R filename.res filename.rc} doesn’t work to well indeed, but you don’t need it for the IDE to recreate it if you don’t care about the contents.


    Just use {$R filename.res}, with no .rc or other IDE files.


  9.  I certainly agree with not checking in the .res files.


    I like to make use of the preprocessor to factor out common properties for a suite of binaries.


    The only requirement (to avoid the IDE freaking out) is run a build on a fresh checkout before opening using the IDE.


    IMHO – that’s a good idea anyway, so I’ve redefined it as “not an imposition” 😀 


    Here’s an example for a BCB project


     


    https://github.com/patrickmmartin/winampremote/blob/master/source/makefile#L20


    And there’s the old trick of sitting out a generated file  


    https://github.com/patrickmmartin/winampremote/blob/master/source/buildkeys.bat
     


  10. Eric Grange – Using only the .res file sort of misses the point, since the point is that .rc files can be auto merged on changes, and committed to the VCS, avoiding the binary conflict situation.  


    What I’d like EMBT to do:


    – Ensure that the compiler is able to create the .res file from the .rc file if missing – using the {$R filename.res filename.rc} syntax.


    – Move the Icon, Title, and Version content out of the .res file, and into an .rc file.  


    {$R project_resources.res project_resources.rc}

Leave a Reply