[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: Moisei <moisei_at_gmail.com>
Date: 2005-05-28 21:10:18 CEST

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,

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,
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

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.