Slightly OT: best way to store Visual Studio files
Steve Borho
steve at borho.org
Mon Nov 16 10:00:18 CST 2009
On Sun, Nov 15, 2009 at 11:45 PM, Kurt Granroth
<kurt.mercurial at granroth.com> wrote:
> On 11/15/09 8:41 AM, Greg Ward wrote:
>>
>> As many of you are no doubt aware, old versions of Visual Studio are
>> rather picky about line endings in "project" and "solution" files.
>> (IIRC, a "solution" appears to be a collection of related "projects".)
>> Specifically, those files *look* like text files, but heaven help you
>> if you let plain LF sneak into one.
>>
>> This seems to be a bugaboo for VC systems and line endings. Just play
>> the "oh yeah, well how are you gonna deal with Visual Studio files?"
>> to anyone proposing a grand unified line ending solution and watch as
>> their face falls. ;-)
>
> In fact, project and solutions files have never presented any particular
> challenge for us. We just imported the files with CRLF from the start and
> since they are never edited in Linux, it was never a problem.
>
> What *was* a problem was the way that Visual Studio 6 edited source files.
> We initially imported all source files in LF format and that worked as long
> as all editing was done via PSPad or some other (relatively decent) Windows
> editor. VC++6 recognizes LF format just fine.
>
> HOWEVER, if you edited a LF file in VC++6, then it would change all of the
> lines that you edited to CRLF. Not the whole file, mind you... just the
> lines you edited.
>
> This wreaked havoc on quite a few aspects of our overall system. As a
> result, we mandated win32text installation and setup on all Windows system.
> Now, all text files are auto-converted back to LF before committing and
> there are no problems.
Even more OT, our group uses an open source tool called XPJ that
generates the sln and vcproj files from an xml input file that
supports wild cards and other niceties. Only the input xml files are
versioned.
Along with being easier to write, having machine generated vcproj
files makes it a lot easier to have consistent compilation rules for
all targets, etc.
--
Steve Borho
More information about the Mercurial
mailing list