Fog Creek Software
Discussion Board

Tools in Source Control

So I'm taking the plunge and setting up source control for the few projects I'm working on. Yes, it's taken a while, but then I still haven't put up the artwork in my apartment that I rented almost a year ago. I'm a unrepentant procrastinator.

My question is pretty simple. I've got a bunch of tools I've written, for example, to generate c# wrappers from t-sql script at build time. I use these tools across across my multiple projects. I want to put these tools under source control.

I've got two basic options:
1) Put these tools in a "tools" project which would function just like a "bin" directory. I'd set the PATH to allow any project to access these tools.
2) Put a copy of the tool into each project.

I'm strongly leaning towards #2 because I'm a big believer in the idea that you should have everything needed to build a project checked into source control for that project. If I chose route #1 then If I ever updated the tool for Project X I could unintentionally break Project Y. It would seem that I'd have to rebuild (and retest?) every project whenever I changed a tool.

However, the obvious drawback of #2 is that if I do enhance the tool for one project then the others won't get the benefit. Perhaps this is ok, and that I should explicity choose to upgrade my tools on a project-by-project basis anyway?

Do any of you have any thoughts? Any options I haven't considered here?

Thanks for any input.

Thursday, June 17, 2004

IMO option #2 is the only options for the "not break other projects" reason.

If you use a good source control system (not SourceSafe :-) then you just place the tools in on directory and then branch it to all other places. This way you don't increase the source control database (it's just a logical link) and you can migrate changes between branches very easily.

Miki Tebeka
Thursday, June 17, 2004

You can do this in Source Safe too - share the folders you want to use in both projects - that creates logical links. If you need to upgrade in one project, then you can branch.

That's not a recommendation for Source Safe though.

Matt Freestone
Thursday, June 17, 2004

Duplication is never a good idea, neither in your code nor in source control. Just put Tools in their own project and tag it when you checkin application releases.

Say, you just finished CoolApp 2.0. Check-in the final code for both your project and tools. Now tag both the CoolApp and Tools code with "CoolApp2_0". Whenever you need to revert back to CoolApp 2.0 just check-out CoolApp and Tools using that tag.

Jan Derk
Thursday, June 17, 2004

Neither of the above. Put the source code for the tools in source control and build the tools from their. Consider creating a "build script" for each of the other projects which then creates the correct version of the tool(s) required to build that project.

Thursday, June 17, 2004

It cuts both ways...

If you have them as its own project and you make a change, you must retest all of them... unless you use versioned branches.

Alternatively, if you have an update that has to be made, you have to update *each and every* instance of the stuff in every project and have to retest.

And you'll run into the same problem because you'll never have a definitive copy when you start your next project.

Thursday, June 17, 2004

Treat such tools the same as you'd treat a shared library or other any other component.  Give it its own single place.  Use labelling (or whatever such mechanism your revision tracking system provides) to define which version of that tool goes with which version of each product.

Hint: you'll perhaps find the organizing gymnastics easiest if you also give to your tool its own version number scheme as you make feature improvements to it, and also apply labels for that scheme to the tool's files as you do so.

Thursday, June 17, 2004

I am not  sure what a project is. Usually we have
a branch. A branch may build many products. The
tools would be in the branch and they would be shared
by all products.

Or, treat the tools like 3rd party code. Have their own
branch. Release them with a version. Then add them
to any branch that needs them. You wouldn't have
the soure or anything, just the "install package,"
if that makes sense in your world.

son of parnas
Thursday, June 17, 2004

Duplication can be a very good idea.  I've had some large productivity numbers from copying a piece of my code, modifying 10% of it, and re-delivering for a new purpose.  Programmers have long had "the library drawer" of code they use again and again. 

This approach has some negatives, however.

I like your approach of copying the current tool (lets call it Ver_1), and including it in the 'set' used to build the code.  As you realize, when you 'copy' the tool and then modify it to make Ver_2, for the next code set, you can have 'broken' or 'removed' some of the needed Ver_1 functionality.

If you never intend to use Ver_2 functionality to do Ver_1's job, this is not a problem.  If you discover (through making Ver_2) some bugs in Ver_1, you have the CHOICE of propagating them backward into Ver_1 or not.

The negative of this approach is how hard it becomes to insure fixes to discovered bugs do get propagated back to earlier versions.  Source-code control systems give you tools for achieveing this more easily -- but you still have to do the work of identifying what fixes go into what source chains.

I just wanted to say that stating "Duplication is always bad" is too simplistic.  We do want to reduce redundancy.  Eliminating it entirely is not always valuable.

Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home