Having a bit if fun on stackoverflow

[H. S. Teoh]

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

-- 
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford