My former boss used to shout: "You cannot type that fast!" I know! It was in the floppy disk days and I asked for a new floppy. What my boss really meant to say was: "Hey! Nobody can type more than one megabyte of code in a year! So why do you need another floppy?"
So, if nobody can type that fast, a source control database – with ASCII text in it – cannot possibly grow more than a gigabyte over a week. Even if we had a thousand programmers working for us. Not even in a year!
TFS has been made too easy
Here’s my statement: “It has been made too easy to check-in a new project or solution into the TFS (Team Foundation System) version control system”. And, because of this, the source control database ‘explodes’ with unwanted objects and generated half products. Assemblies, DLLs, executables and other objects that were never meant to be entered are cluttering the TFS databases, taking up gigabytes. As a result, serious maintenance effort is required on the part of the system administrators for backup and database cleaning. And TFS administrators have to spend a lot of time contacting all project teams to help clean up the source control databases.
How does this happen, all these unwanted objects in the source control database of TFS? One day, I came across a project that had grown 5 Gigabytes over the previous week. That was the moment I decided to go find out what was behind all this. After finding the project and, through the history lists, the “scene of the crime” and the person “who-done-it”, I sat down with the culprit to review what had happened.
Basically, this is what he had done:
• he had gotten (past tense of the “get” operation) the source code
• built it completely
• added a story by changing some source code (i.e. programming) (so far so good)
• added the complete project tree back to source control at check-in time
Obviously, the problem was in the last step where the programmer added the whole shebang –’. Including libraries, intermediate link results, executables and everything. All those things that are ‘the result’ of the source code.
Asked why he did this, he essentially told me that:
• nobody told him otherwise, nobody was available for guidance
• nobody checked on him afterwards
• it was the only way he was sure he was getting everything/not forgetting something
And it’s quite easy to do. Simply add everything using the “add files” command as shown in the figure below. Far too easy! Just hit that button and then, even when TFS tries to keep out the executables, just add the excluded items.
A floppy is too big
How to explain to anyone how to solve this? In my mind, I zoomed back to the floppy disk days. Isolating the “real” source code that this programmer had in terms of plain ASCII text files did the trick. I gathered all those files into one subdirectory and zipped them. Voilà – less than 1 MB of ZIP file. Fits on a 1.44 MB floppy disk.
Comparing that to that last check-in it was less than 0.001 per cent of what was put into the TFS database!
Review your projects
Let’s sit back and consider: what does this mean for our corporate TFS database? Given the fact that it’s more than 400 Gigabytes of database. And viewing the size of source code of our various products, isn’t that a bit too big? Or do you think it’s just right?
Maybe we cannot fit the complete TFS on a floppy, but we sure can try for each individual project.
1 juni 2017 Iedere organisatie heeft te maken met het integreren van systemen en applicaties. Maar welke technologie zet u in bij welke vorm van integratie? Guy Crets bespreekt de verschillende oplossingen voor integratie. Integratie van IT-sys...
13 t/m 15 juni 2017Driedaagse workshop over requirements management door James Archer. Opstellen, testen en ondubbelzinnig vastleggen van requirements. Unieke driedaagse workshop over requirements management op basis van de Volere methodiek door Jame...
2 november 2017Praktisch seminar waarin Sander Hoogendoorn u laat zien hoe u microservices kunt inzetten in uw softwarearchitectuur.Het nieuwste architectuurprincipe microservices lijkt veelbelovend: verkorte time-to-market, schaalbaarheid, autonomie...
medio mei 2018 Praktische tweedaagse workshop met internationaal gerenommeerde spreker Alec Sharp over herkennen, beschrijven en ontwerpen van business processen. De workshop wordt ondersteund met praktijkvoorbeelden en duidelijke, herbruikbare ...