Thank you, Bill. The separate locking directory is something I did not
ever think,
you definitely won one more reader (and buyer :) ) of your book.
I belive, if the source directory tree structure is duplicated under
locking directory,
the scripting become trivial. I will probably have to prepare our own
lock/unlock wrappers
to help the developers to avoid wasting their time working on the file
locked in the
another branch.
Honestly, as much I think about it, as much it seems to me pretty
general pattern that might work very well.
Dear Steve, I proud you cannot back to the lock/unlock scheme anymore.
Unfortunately, I am not aware about some advanced MFC techniques
that allow regeneration of the resource files. FYI it is mostly the *.rc
files that make the problem, not the resource.h ones.
Thanks again,
Best Regards,
Moisei.
2005/5/28, Steve Cohen <scohen@javactivity.org>:
> Moisei wrote:
> > for the 30 developers team. = the team of the 30 developers.
> >
> > 2005/5/28, Moisei <moisei@gmail.com>:
> >
> >>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?
> >>
> >>Any help is very appreciated,
> >>Best Regards,
> >>Moisei.
> >>
> >
> >
> >
>
> 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
> process?
>
>
--
Best Regards,
Moisei
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 28 21:12:11 2005