handling resource files

[Adrian Buehlmann]

On 11.08.2009 23:12, Cory Riddell wrote:
> I've been playing with Mercurial now for a couple of days to see if it
> is a good replacement for SourceSafe and I have a question (I hope this
> is an appropriate forum).
> 
> Our app is a Windows (MFC) application. All "resources" get a unique
> idea. Resource ids are allocated for dialogs, controls (buttons, edit
> boxes, etc...), strings, bitmaps, etc.... The file looks something like:
>   #define IDS_PROPSHEET_CAPTION             218
>   #define IDB_SPLASH                      224
>   #define ID_TOOL_CTRL                    225
>   #define IDC_PUSH_PIN                    227
> 
> By convention the prefixes indicate the resource type (IDS=string,
> IDB=bitmap, ID=window id, IDC=control, etc...)
> 
> In a DVCS, what can you do to prevent conflicts from multiple people
> editing resources at the same time? For example, if I add the string "foo":
>   #define IDS_FOO  1234
> and if my coworker defines a string "bar":
>   #define IDS_BAR 1234
> we have a problem. The changes will merge, but now a logical conflict
> exists.
> 
> With SS, we do an exclusive checkout of resource files to avoid this
> problem. I'd like to know how this is handled in Mercurial shops.

Not a total solution, but you could consider doing the following:

Don't write numbers manually into such files.

We've used build steps that automatically assign number series to name
piles.

Basic idea is (leaving out the implementation details): have files that
just contain the names without any numbers, plus some minimal steering
commands as first words on the lines.

In your example, write something like the following into a file:

start 218
id IDS_PROPSHEET_CAPTION
id IDB_SPLASH
id ID_TOOL_CTRL
id IDC_PUSH_PIN

then run a build script on that file which assigns increasing numbers
to the names (and tacks '#define' in front of the lines), creating the
header file as part of the build process.

We don't edit such generated header files and don't track them in the
repos (that is, we don't 'hg add' them).