How to avoid string IDs allocation collisions

The resource string table is not team-friendly
It's a flat table where all developers add entries randomly, usually picking the next available index. Devs usually have their own copy of the .rc file and add strings to the table using the same new IDs as their teammates, resulting in painful indexes collisions. Since the resource script (.rc) is just a flat file, it doesn't provide locking or transaction capabilities as a full-blown DB would. Locking access using version control is hardly ever a solution : Since the .rc file being unique, members of the team very often need to access some part of it, making exclusive check-out a real bottleneck.For other resources, it's usually not such a big problem: Devs usually don't work on the same resource simultanously.

The problem with the string table is that it's global and multi-purpose: It holds strings as different as listview column headers, error messages, prompts and all kind of custom texts. Therefore devs need almost constant write access to it.

A simple trick to avoid string IDs allocation collisions
There's a very simple way to avoid indexes collisions: Assign each developer his/her own range of indexes in the table.

e.g.:

1. Mike gets the range 5000-5999,
2. Goran gets 6000-6999,
3. Serge gets 7000-7999,...

To make it even clearer, start each range by a string mentioning the dev's name and the range.
This way, people don't step on each other's toes anymore.

Of course, this trick works for small and medium size teams only. Large teams probably need stronger policies.