>> 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.
No chance to auto-merge the rc files, Steve.
IDE numbers every new component you add to the dialog,
and this number is used everywhere in the code where the
component is referenced. so in case of any merge,
there are another source files that should be changed accordingly.
also it keeps the max number of the used component
and increments it every time new component is added,
so again, it is too much complicate for any tool.
>> but shame on them
you told that! :)
Moisei.
2005/5/28, Steve Cohen <scohen@javactivity.org>:
> 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.
>
--
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 22:53:46 2005