|
Should source control control more than source?
My coworkers are going nuts and gradually turning our source control system into a full-fledged backup system.
For some reason it really turns my stomach to have generated files (exes, pdbs, dlls, etc) in source control, and worse, some installer binaries for support apps, etc.
Sure, they say, it will waste a little hard drive space to have lots of versions of your exes in there, and it might be some extra manual overhead, but it would be nice to be able to do a checkout and have all your exes ready to go.
My objections are more philosophical, and I can't come up with any really good practical arguments against.
Just curious if anyone out there uses their source control in a similar way. Am I being irrational to fight this?
j
Friday, April 16, 2004
Sort of, we used to keep all the builds in a seperate set of normal directory structures, i.e.
OurProduct V1 B1
OurProduct V1 B2
OurProduct V1 B3
...
This was very useful for tracking bugs since we could figure out which day a bug was introduced and hence get closer to the solution.
Colin Newell
Friday, April 16, 2004
What is their reasoning for keeping compiled DLLs and PDBs in there? (By PDB, I'm assuming you're referring to .NET debugging files.)
I can somewhat understand sticking a 3'rd party DLL in there to make it easy to pull a full working set from source control, but I can't understand why someone would put debugging files or a compiled version of the project under source control.
Mark Hoffman
Friday, April 16, 2004
Mark ->
I think the main "reason" is that it's easier to throw the whole directory in and ask questions later.
Yeah, I was refering to the .net pdb files. So, if you wanted to do a checkout from a clean machine and run some exe's, having the pdb there would make it easier to debug.
j
Friday, April 16, 2004
> Just curious if anyone out there uses their source control in a similar way.
Think of it as version control, not source control.
In a system with a million lines of code and a 100 or more executables, we would keep the *.LIB and *.DLL as well as *.EXE under source control so that someone could build something without having to rebuild everything on which it depended.
Also (a less good reason) the source control database was the interface from developers: QA wouldn't build things, they would test the executables that were built and placed into version control.
Christopher Wells
Friday, April 16, 2004
"For some reason it really turns my stomach to have generated files (exes, pdbs, dlls, etc) in source control, and worse, some installer binaries for support apps, etc."
I school, we were always told to store everything you can. The ultimate goal is, that at anytime, you can pull out an old version -- run it, compile it, send it out.
So 10 years later, you want to pull out version 2.0... If you only have the source, you might be out of luck since it might not compile on VisualStudio.NET XP 2014 SP7.
Almost Anonymous
Friday, April 16, 2004
Philisophical objections arn't really objections. You should have a reason before wanting to object to something. Otherwise you are just being difficult.
Oren Miller
Friday, April 16, 2004
I generally store any compiled EXE or DLL with associated PDB in by source code control database. I have developed several large scale component based systems in VB and VC++. In my experience, there are whole classes of problems that you will only be able to reproduce by loading and registering the exact executables that were in use when the user's problem was encountered. Rebuilding old versions from source is simply not a practical solution because your development machines are likely to have changed since those versions were built.
Even if you use VB, the PDBs come in handy when you can reproduce a problem in an old binary but not in a new one. It gives you an opportunity to drop into the VC++ debugger to try to find the cause. This isn't easy to pull off, but it's less painful than searching endlessly for a problem without these tools.
As a side note, I also store third party components in a separate folder in my source control system, for much the same reason.
Craig
Friday, April 16, 2004
Sorry, but I have to agree with the majority here, it is really version control. I have even worked on project were associated requirements are stored as documents too. This meant any version's definition, source and execution could be retrieved in total.
Disk space is cheap, as long as the structure is clear, don't worry about it.
MSHack
Friday, April 16, 2004
From my perspective, if there's something you might possibly ever want an old version of, there's no reason not to put it into version control. Break things into a reasonable directory structure and check in whatever's not throwaway -- disk space is cheap.
I've seen SourceSafe corrupt large binary files, if that's what you're using.
Jeremy Statz
Friday, April 16, 2004
You might want to store all this stuff in a release
space of the tree rather than the source part
of the tree. That way you'll always have the
release around and it doesn't muck up the build process.
Your install package will have all this junk so you may
just need to version your install package.
Some issues:
* On a build you must checkout derived files for
writing so they can be written over. You won't know if build items were properly produced because they could be left over from the check-out. You get a lot inconsistency issues. If some files aren't generated anymore you will have to delete them. Libraries that are updated for each object can get out of sync.
* You have to check the files in after a build which means your change number or label is not the same one you started with, which means you can't reproduce the build.
* are you storing objects files too? Why not? If you have a lot of derived files it can slow everything down and make the storage huge.
son of parnas
Friday, April 16, 2004
"You should have a reason before wanting to object to something."
I disagree. (ha ha!) Seriously, if you've got good judgement in some area, then having a bad feeling about an idea is something you should pay attention to. Later you'll likely find that there's a real reason behind your discomfort.
Exception guy
Friday, April 16, 2004
How much source could source control control, if source control could control source?
That is the question.
My Cousin Vinniwashtharam
Friday, April 16, 2004
I think its useful to check the binaries (DLL's EXE's) into a directory sturcture separate from the source code. Having these things live in the same location as source is a major annoyance.
hoser
Friday, April 16, 2004
Remember that (good) source control software will store diffs for text files instead of storing a copy of each version. With binary files, exploiting redundancy is not as trivial, and naïve implementations will (quite reasonably) store a copy of each version of binary files. So, if you are storing many builds a day into your repository, you'll burn through HDs pretty fast.
I believe that Subversion has a way to do diff-like redundancy exploitation on binary files (among other benefits). It recently hit the 1.0 milestone.
In future, I am seriously considering storing my entire home directory (except 'noise' files like temp files and auto-backup files) in (probably) Subversion on my home machine. The benefits of being able to version files at the same time as having a backup (the repository) *and* being able to migrate to new computers easily is very appealing. Has anyone done this -- if so, how's it going?
C Rose
Friday, April 16, 2004
Wow, thanks for all the input. I feel a lot better about it after hearing some good points. I think my doubts probably had to do with automatically overwriting files that are under source control.
I first cut my teeth on source control at school, in an academic setting... I think I've probably been hanging on to that a little too hard. Truely, hard drive space is cheap, and it is *version* control after all.
This is a great forum. Thanks again all.
j
Friday, April 16, 2004
CRose - I was just thinking about that today as well.
As hard drive space gets cheaper, and source control systems become better, and backup systems become better... can source control and a file backup system eventually become the same thing?
Is there any product that pitches itself as a file backup solution *and* source control?
Many backup systems do binary differencing, store old versions of files, etc. How are the two ideas fundamentally different?
j
Friday, April 16, 2004
"How much source could source control control, if source control could control source?"
A source control wouldn't control sources, because source control does not control source (but versions).
Yeah those were the graphical adventures golden days...
(Sorry for the off-topic, is the other-me who is posting this)
Jose Juan Montes
Friday, April 16, 2004
We store *everything* in source control.
The source code, the generated binaries, any referenced libraries or binaries (these are especially hard to chase down for old versions as they're updated, it comes in handy to have them in source control so when they're needed, simply check them out.) We source control the build scripts -- gotta know which script builds which version!
We then add in all docs -- user docs (they change from version to version), requirements docs (they change from version to version), tech/developer docs (they change from version to version). We add in our project tracking documents. Correspondance from customers relating to changes requested to the next version.
We keep our testing docs, and especially the logs -- it's a requirement in our shop to keep the test logs and make sure all tests pass before check-in. We keep our NUnit testing code with the source code -- you guessed it, in source control. The tests have to change as new features are added/deprecated, so the testing code needs revision management too.
If it's related to a project in *any* way, we keep it in source control.
We've been doing it this way for about 4 years and, in my experience, it's generally considered by all to be a GoodThing as it's saved everybodys butt at one time or another.
Sgt. Sausage
Friday, April 16, 2004
I've gone so far as to store entire 3rd party applications into source control (Vault in our case). Ideally, someone should be able to check out a source tree for a given version and have EVERYTHING needed to build. This includes installshield, code obfuscators, exe compressors, etc. I exclude Visual Studio for obvious reasons (size).
One benefit to this is that I can run into the office with a laptop, do a "get", and not get back home and say "oh crap, I need such-n-such".
Bill Carlson
Friday, April 16, 2004
My experience is pretty much the same as Sgt. Sausage. Unless it's something you really just don't have any reason to keep, check it in. Just make sure you've got a reasonable directory structure in place so it doesn't turn into a big mess.
My view might be colored on this some, since I've primarily worked on gaming projects, where content absolutely dwarfs code... and you'd be crazy not to keep backups and past versions of it. We have something like 3.5 gig of files under version control at the moment, I believe.
Jeremy Statz
Friday, April 16, 2004
Keeping production releases of EXEs and other compiled files in version control is useful when you need to respond to a problem a user has. But there is little value of keeping the intermediate versions of the compiled files.
T. Norman
Saturday, April 17, 2004
Being able to get ahold of the exact binary that a customer is using is useful for customer service reasons, but there are plenty of ways to achieve that without checking those binaries into the source control system.
There isn't a one-size-fits-all answer to this question. For any project that's going to last more than a couple of months or involve more than a handful of developers, it's useful for someone to actually sit down and map out a process for how builds will be performed and, based on that, a policy for what should go into the source control.
.
Saturday, April 17, 2004
2 things:
1)
The comment: "Philisophical objections arn't really objections. You should have a reason before wanting to object to something" is misplaced. Philosophical objections *are* reasons, they are reasons rooted in broader context than more 'practical' objections, but nevertheless they are reasons. T
Their scope and impact may be be revealed over a longer time frame perhaps, and yes, many people hide half baked prejudices behind the moniker of 'philosophical' reasons, but that does not justify dismissing the category.
2)
In particular, about use of source/version control from non-source items: 'source' can be interpreted to include binary or other non-text sources. For example, icon files, or 3rd party components. The basic idea is to put under version control the basis for building a finished work-product. Done correctly, there simply shouldn't be a need to put such built artifacts under version control, so long as the repository is managed in such a way (with labels, branches, etc) that it is straightforward to retrieve and build an arbitrary 'finished' version.
That is the true strength of version control systems; too many immature developers & organisations simply use version control systems as a generic back up mechanism, and sloppily enough that it is near impossible to every retrieve or recreate an earlier version.
(Also, version tools have capabilities to compare differences, a benefit which is lost with binaries.)
And finally, I have been in shops where a dll or other binary component was under version control, along with source, and inadequate discipline led to the situation that it was impossible to build the only binaries which actually worked correctly from the source in the system. So the source under version control loses much of its value, and the vcs itself is just a cumbersome backup for the binaries.
This won't happen under correct version control management policy; having the built binaries in the system simply opens the door for confusion.
!
mv
Thursday, April 22, 2004
 Recent Topics
Fog Creek Home
|
