The .RC files ARE the source files. They are "generate
automatically" from a visual GUI layout tool. It is the structure of
the files and the way they are used by the tools that make merging
them with a standard diff impossible.
It's been a long time since I did UI with Visual Studio, but I
beleive it works something like this:
The initial version of the file might look like:
#define NEXT_COMPONENT 1004
#define CHECKBOX_A 1000
#define CHECKBOX_B 1001
#define TEXTFIELD_A 1002
#define TEXTFIELD_B 1003
So if the file is checked out and modified by two users X and Y you get
#define NEXT_COMPONENT 1005
#define CHECKBOX_A 1000
#define CHECKBOX_B 1001
#define TEXTFIELD_A 1002
#define TEXTFIELD_B 1003
#define BUTTON_X 1004
and:
#define NEXT_COMPONENT 1005
#define CHECKBOX_A 1000
#define CHECKBOX_B 1001
#define CHECKBOX_Y 1004
#define TEXTFIELD_A 1002
#define TEXTFIELD_B 1003
which would be merged without conflict as:
#define NEXT_COMPONENT 1005
#define CHECKBOX_A 1000
#define CHECKBOX_B 1001
#define CHECKBOX_Y 1004
#define TEXTFIELD_A 1002
#define TEXTFIELD_B 1003
#define BUTTON_X 1004
Where CHECKBOX_Y and BUTTON_X are using the same ID #
Basically the unique IDs can't be guaranteed if you allow multiple
checkouts, so it makes sense to require locking on those files.
Scott
On May 29, 2005, at 11:05 PM, ebridges wrote:
> This strikes me as a complete non-issue. There's no point in
> versioning
> files that are generated automatically, instead the files they are
> generated *from* should be versioned. Then, those files (which are
> human-readable) can be merged by the individuals editing them (if they
> happen to need to edit them at the same time, in the same locations).
>
> --e--
>
> Moisei wrote:
>
>
>> Hi,
>> I setup the development process with subversion for the 30
>> developers team.
>> A big part of them are using MFC and I am just wondering about the
>> management
>> of the resource files (*.rc) generated automatically. How to
>> prevent the case
>> wheen 2 developers are working on the same dialog at the same time?
>> I've waited for 1.2 locking to prevent such a cases at least in
>> the trunk,
>> but I do not find a good branching strategy.
>> Is it covered in your book in some way?
>> Or may be another resources,use-cases are known to somebody?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 30 06:16:38 2005