Having a bit if fun on stackoverflow

[Idan Arye]

On Tuesday, 25 June 2013 at 12:17:24 UTC, H. S. Teoh wrote:
> On Tue, Jun 25, 2013 at 08:55:04AM +0200, monarch_dodra wrote:
>> On Tuesday, 25 June 2013 at 06:46:28 UTC, Jonathan M Davis 
>> wrote:
>> >On Tuesday, June 25, 2013 08:38:01 Marco Leise wrote:
>> >>Am Mon, 24 Jun 2013 08:45:26 -0700
>> >>
>> >>schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
>> >>> http://stackoverflow.com/questions/17263604/i-have-a-c-repository-but-gith
>> >>> ub-says-its-d
>> >>> > Andrei
>> >>
>> >>This is why you don't put automatically generated files in
>> >>version control ... Especially when they have the file ending
>> >>used by an indexed PL on GitHub ;)
>> >
>> >Yeah. That was the great faux pas of that question. I'm not 
>> >aware of
>> >any good reason to put generated files in version control 
>> >unless they
>> >were only generated once and will never be generated again.
>> >
>> >- Jonathan M Davis
>> 
>> Well, depends how you use the version control I guess. You 
>> *can* use
>> it for more than just going back in time or concurrent edits: 
>> You can
>> use it as a redistributable network folder.
>> 
>> The company I work for does it that way. It means when you 
>> checkout
>> a project, you don't have to run 10+ different tools to 
>> generate
>> whatever it needs to generate: You are ready to roll. You save 
>> on
>> time and headaches. Whenever someone changes the xml, you 
>> don't have
>> to regenerate everything every time you resync. The overall 
>> time and
>> overhead wasted by a few guys checking in their generated 
>> files is
>> more than made up for everyone else not having to worry (or 
>> even
>> know) about it. But to each their own of course, this works 
>> for _us_.
> [...]
>
> This can backfire in ugly ways if not used carefully. At my 
> work, there
> are some auto-generated files (tool-generated source code) that 
> get
> checked into version control, which generally works fine... 
> then we got
> into a state where the makefile builds stuff that requires the 
> generated
> files before they're actually generated. When somebody then 
> modifies
> whatever is used to generate said files but forgets to check in 
> the new
> version of the generated files, you get into nasty 
> nigh-untraceable
> inconsistencies where part of the build picks up an old version 
> of said
> file but the rest of the build picks up the new version.
>
> To make things worse, official release builds are always made 
> from a
> fresh checkout, so release builds sometimes have bugs that 
> mysteriously
> vanish when you build the same version of the code locally. Very
> frustrating when trying to track down customer-reported bugs.
>
> Not to mention, sometimes generated files have formats that 
> include
> timestamps that get updated every time they're rebuilt, which 
> produces
> spurious "revisions" in version control that stores the exact 
> same
> versions of the files, just with different timestamps.
>
> In general, this practice is the source of a lot of needless 
> grief, so
> I've come to be of the opinion that it's a bad idea.
>
>
> T

I guess that depends whether or not F5 is your build 
process(http://www.codinghorror.com/blog/2007/10/the-f5-key-is-not-a-build-process.html).

If you rely on your IDE to compile and run your project, then you 
usually want to check in those auto-generated files - because 
when you generated them for your local copy, you had to use 
different tools, download some libraries, configure your IDE etc 
- and you want to save other people(or yourself on another 
computer) the trouble of doing it all again - not to mention to 
save yourself the trouble of documenting exactly what you did so 
others can follow.

On the other hand, if you use a proper build system, you can - 
and should - configure your build file to auto-generate those 
files using external tools, and maybe even use a dependency 
manager to download those libraries.

Not only does the build system's ability to easily generate those 
auto-generated files make checking them in redundant - it also 
makes it more troublesome. If you had to manually configure and 
invoke a tool to generate a file, chances are you'll only do that 
again when you really have to, but if the build system does that 
for you - usually as a part of a bigger task - that file will be 
updated automatically by many people times and again. Having the 
SCM handle such files will add redundant burden to it and even 
worse - can cause pointless merge conflicts.