[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

versioning generated files

From: Ulrich Eckhardt <eckhardt_at_satorlaser.com>
Date: 2005-06-15 10:39:12 CEST


I'm facing a problem which I'm not 100% sure how to tackle. The thing is that
from a purists point of view, only the source files belong under versioning
control. From a pragmatic point of view though, it might be difficult,
time-consuming or even impossible to re-create some files from source and
therefore it is sometimes reasonable to store generated stuff under version

I'm currently facing the status quo that we're simply checking in generated
sources and binaries, but I somehow dislike that, because checking out and
building a project already creates changes in the workingcopy. Also, when I'm
using a locally modified, experimental version of a library, it is just too
easy to accidentally check in a version that is not at all suitable for my

Merging of binaries is impossible, too, so you always either use this version
or that. What I haven't even tried yet is to merge changes made in a branch
into the trunk (or vice-versa) in the face of versioned binaries - I suspect
utter failure.

What is clear to me though, is that we simply need these generated files. When
we ship product X and it contains 20+ libraries and executables, I can't be
bothered to first check out the appropriate versions, check out dependant
libs, setup my environment accordingly and only then start trying to
reproduce the bug someone reported. Even generated files are valuable
information that deserve the bit harddisk storage.

I'm currently thinking about changing our scheme a bit in that we'll stop
checking in binaries as parts of our normal working copies. Only when making
a release, we'll first branch the project, run necessary tests on the
generated libraries and then add them to the release-branch in version

I haven't tried the above yet, so I don't know how it works out in practise. I
just wanted to get a few other opinions first.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 15 10:38:40 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.