[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New Subversion Book Released

From: Steve Cohen <scohen_at_javactivity.org>
Date: 2005-05-28 19:55:20 CEST

Moisei wrote:
> for the 30 developers team. = the team of the 30 developers.
> 2005/5/28, Moisei <moisei@gmail.com>:
>>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?
>>Any help is very appreciated,
>>Best Regards,

It's been many years since I used MFC and resource files, and this was
using Visual Source Safe. I do remember that there were big problems
with resource.h, and there was always lock-contention over it.

However, now I use SVN and sometimes CVS and it seems to me that the
GUIs have evolved to the point where it is quite practical to ask even
inexperienced developers to work in a non-lock situation and force them
to merge changes rather than just overwriting them. I haven't used the
Microsoft toolset recently, but would be surprised if they haven't kept
up with this trend. It's pretty standard now. I don't think I could
ever go back to a lock/unlock system.

If the problem is with automatically generated files, why not avoid
storing them in SVN and instead make their generation part of your build

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 28 19:56:56 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.