Moisei wrote:
>
> 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.
>
Forgive me if my memory is foggy. It's been 6 or 7 years since I
developed with these tools. As I remember, an .rc file is a text file
that is "generated" by the GUI resource editor. One could, if one knew
what one was doing, edit this text file with a text editor. I'm not
recommending this, you understand, but it's theoretically possible. The
important thing is that an RC file is, outside of the Microsoft resource
editor, just another text file, able to be handled by line-oriented text
merge tools such as the one in Eclipse.
OK, now, suppose you DON'T even try to lock files in SVN, but rely on
the merge tools that are available. If Microsoft's IDE doesn't have
these, none of this will work, but shame on them if that's the case.
You might be able to use a third party merge tool or find a better IDE,
otherwise, none of my suggestions will work.
Now, even though your developers may not be used to looking at the .rc
files as text, doesn't mean that they couldn't learn understand what's
going on when they view them that way. It shouldn't be that hard for a
developer to look at a merge screen and see that the difference on the
tab he hasn't been working on should be left alone, while the difference
on the tab he's just been working on needs to be merged into the revised
file.
What I'm suggesting is that lock/unlock is not the only way to go and a
good merge tool in conjunction with SVN might be another way to solve
your problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 28 22:43:37 2005