Do you version "derived" files?

Question

Using online interfaces to a version control system is a nice way to have a published location for the most recent versions of code. For example, I have a LaTeX package here (which is released to CTAN whenever changes are verified to actually work):

http://github.com/wspr/pstool/tree/master

The package itself is derived from a single file (in this case, pstool.tex) which, when processed, produces the documentation, the readme, the installer file, and the actual files that make up the package as it is used by LaTeX.

In order to make it easy for users who want to download this stuff, I include all of the derived files mentioned above in the repository itself as well as the master file pstool.tex. This means that I'll have double the number of changes every time I commit because the package file pstool.sty is a generated subset of the master file.

Is this a perversion of version control?

---

@Jon Limjap raised a good point:

Is there another way for you to publish your generated files elsewhere for download, instead of relying on your version control to be your download server?

That's really the crux of the matter in this case. Yes, released versions of the package can be obtained from elsewhere. So it does really make more sense to only version the non-generated files.

On the other hand, @Madir's comment that

the convenience, which is real and repeated, outweighs cost, which is borne behind the scenes

is also rather pertinent in that if a user finds a bug and I fix it immediately, they can then head over to the repository and grab the file that's necessary for them to continue working without having to run any "installation" steps.

And this, I think, is the more important use case for my particular set of projects.

Thanks all for the replies!

Answer 1

Not necessarily, although best practices for source control advise that you do not include generated files, for obvious reasons.

Is there another way for you to publish your generated files elsewhere for download, instead of relying on your version control to be your download server?

Answer 2

Normally, derived files should not be stored in version control. In your case, you could build a release procedure that created a tarball that includes the derived files.

As you say, keeping the derived files in version control only increases the amount of noise you have to deal with.

Answer 3

We don't version files that can be automatically generated using scripts included in the repository itself. The reason for this is that after a checkout, these files can be rebuild with a single click or command. In our projects we always try to make this as easy as possible, and thus preventing the need for versioning these files.

One scenario I can imagine where this could be useful if 'tagging' specific releases of a product, for use in a production environment (or any non-development environment) where tools required for generating the output might not be available.

We also use targets in our build scripts that can create and upload archives with a released version of our products. This can be uploaded to a production server, or a HTTP server for downloading by users of your products.

Answer 4

I am using Tortoise SVN for small system ASP.NET development. Most code is interpreted ASPX, but there are around a dozen binary DLLs generated by a manual compile step. Whilst it doesn't make a lot of sense to have these source-code versioned in theory, it certainly makes it convenient to ensure they are correctly mirrored from the development environment onto the production system (one click). Also - in case of disaster - the rollback to the previous step is again one click in SVN.

So I bit the bullet and included them in the SVN archive - the convenience, which is real and repeated, outweighs cost, which is borne behind the scenes.

Answer 5

In some cases we do, but it's more of a sysadmin type of use case, where the generated files (say, DNS zone files built from a script) have intrinsic interest in their own right, and the revision control is more linear audit trail than branching-and-tagging source control.