The way we manage them is to create default setups in the IDE, and store
these in the VC system as "filename.tmpl" (i.e. take the file(s) created
by the IDE and rename them with an extension of ".tmpl" ---> 'template').
Then when a developer needs to use the file, he or she copies it over to
their system and renames it without the .tmpl extension.
The upshot that these files are not actually 'versioned' nor are the
changes to these files interesting to the group-at-large nor the
application's future. What is the usefulness of a 'single' IDE project
file for everyone except to get them started?
David Resnick wrote:
>What is your take on IDE managed files like vcproj, dsp or vcp files? These
>files hold important changing info (which files belong to a project) but are
>constantly being rearranged by the IDE so there is no simple way of knowing
>what has been changed by comparing versions. For larger files, attempting to
>merge 2 versions by hand is practically impossible.
>
>-----Original Message-----
>From: ebridges [mailto:ebridges@eqbridges.com]
>Sent: Monday, May 30, 2005 06:06
>To: Moisei
>Cc: Subversion mailing list
>Subject: Re: New Subversion Book Released
>
>This strikes me as a complete non-issue. There's no point in versioning
>files that are generated automatically, instead the files they are
>generated *from* should be versioned. Then, those files (which are
>human-readable) can be merged by the individuals editing them (if they
>happen to need to edit them at the same time, in the same locations).
>
>--e--
>
>Moisei wrote:
>
>
>
>>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.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 30 15:43:06 2005