Ah, understood. Thanks for the explanation. We've had very similar
issues around complex XML files. Though, the fact that these are
auto-generated is not really an issue is it? Basically you're just
looking to have more control of when merges must be done, no?
A suggestion that we've used for parallel scenarios is whenever
developers do work, they create a branch and do their work there.
Commits to trunk (including merges) must be done via a change request in
our ticketing system to the build engineer.
Admittedly somewhat bureaucratic, but we've a group of 40-45 developers
that (in the past) were all committing to trunk (in a CVS based
system). In our situation, anything in trunk is on a direct path to
production (since release branches are cut from trunk). Since everyone
used to be committing to trunk, this usage pattern left us with no
deterministic way to guarantee what was in a release and what wasn't.
Lastly, I would suggest that locking won't prevent these sorts of merges
but would simply delay their eventual occurence (to a time when it's
easier to do it, admittedly). Branching will give you a much cleaner
separation of work, and allow for a more controlled way to know what
goes into a release (if that is what is important to you in your scenario).
Thanks
Ed
Scott Palmer wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 30 15:58:54 2005