Poking through some offshored VB.NET code to fix a few bugs, I found this gem:

qry = "select max(b.idimage) from image a, image b where a.image_name=b.image_name and a.idimage=" & imageid

 It was inside a function called "getID"...

So let me get this straight, this function, you pass in an ID... and it gives you an ID back... what exactly is the point of that anyway? The only use I could imagine is that since it calls a max function on the second instance of the image table, that it's some sort of hacky "version control" system - you put in an ID, it gives you the newest item with the same name!

You may laugh, but I have seen SQL-based version control for source code before.  Turns out the dev thought CVS and SVN were too confusing, so he just inserted a row containing the filename in one column, the entire file in a TEXT column and an incrementing version number in a third.  To get the latest version, he just selected MAX(version_number) WHERE filename = "foo".

henke37:

The sad part is that I think that some version control software actually uses a database for the file storage.

Seeing as how filesystems are by their very nature databases, I would think that all RCS are database-oriented.

You have a set of objects, and some relation of those objects one to another, and a set of operations on those objects.

Sounds like a database to me.

henke37:

The sad part is that I think that some version control software actually uses a database for the file storage.

Using a database for revision control is not a WTF (and if done properly is actually a smart idea).

Heron:

Using a database for revision control is not a WTF (and if done properly is actually a smart idea).

I actually have an SVN hook on commit that keeps track of the repository, revisions, files changed per revision and optionally, depending on whether the project is flagged for it, an actual diff for each file at each revision (for big changes a text field actually isn't big enough - the damn thing had to be bigtext). This information then gets cross-referenced with the databases behind our bugtrackers, and builds a series of references based on the commit messages and any comment text in the diff itself. This is all then tied into the time and billing system - so we instantly know everything productive that a given user did while they were working.

 Would've saved me some effort if SVN could be told "Here, use this database server"

Weng:

I actually have an SVN hook on commit that keeps track of the repository, revisions, files changed per revision and optionally, depending on whether the project is flagged for it, an actual diff for each file at each revision (for big changes a text field actually isn't big enough - the damn thing had to be bigtext).

Dear God, why the diff?  Why not just use SVN's built-in revision comparison tools?  Why create an entire copy of the SVN repo and risk one being out of sync with the other?

morbiuswilters:

You may laugh, but I have seen SQL-based version control for source code before.  Turns out the dev thought CVS and SVN were too confusing, so he just inserted a row containing the filename in one column, the entire file in a TEXT column and an incrementing version number in a third.  To get the latest version, he just selected MAX(version_number) WHERE filename = "foo".

DOA:

morbiuswilters:

You may laugh, but I have seen SQL-based version control for source code before.  Turns out the dev thought CVS and SVN were too confusing, so he just inserted a row containing the filename in one column, the entire file in a TEXT column and an incrementing version number in a third.  To get the latest version, he just selected MAX(version_number) WHERE filename = "foo".

Why is this not an OP? Better yet, did you hurt him or is he still out there doing this crap?

I just really love threadjacking.

I've got so many WTFs that if I were to post them all it would take months.  This particular dev is still doing this kind of stuff, but I think he's mostly retired by now.  Unfortunately, most of the horrible devs I've known are still active in some capacity.  One of the worst works for $LARGE_SEARCH_ENGINE.

morbiuswilters:

One of the worst works for $LARGE_SEARCH_ENGINE.

morbiuswilters:

I've got so many WTFs that if I were to post them all it would take months.  This particular dev is still doing this kind of stuff, but I think he's mostly retired by now.  Unfortunately, most of the horrible devs I've known are still active in some capacity.  One of the worst works for $LARGE_SEARCH_ENGINE.

drachenstern:

Seeing as how filesystems are by their very nature databases, I would think that all RCS are database-oriented.

You have a set of objects, and some relation of those objects one to another, and a set of operations on those objects.

Sounds like a database to me.

Remind me to get old threads locked before I link them.

bstorer:

morbiuswilters:

One of the worst works for $LARGE_SEARCH_ENGINE.

He works for Baidu?

belgariontheking:

Ghost of TDWTF Past here, this has already been argued, and you are welcome to rehash it, but keep that discussion in this thread.

Also, you should get that old thread locked ;)

morbiuswilters:

Dear God, why the diff?  Why not just use SVN's built-in revision comparison tools?  Why create an entire copy of the SVN repo and risk one being out of sync with the other?

Because a fat ugly hard drive with a fat ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

And yes, it makes sure it didn't miss a revision (and if it did, it currently alerts a human to schedule a rebuild or catch-up) every time it runs - and if it stopped running altogether, we'd notice rather quickly because it integrates into the system that prints our checks.

Weng:

Because a fat ugly hard drive with a fat ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

FAT? NOOOOOO

FAT baaaadddd, use a journaling system...

</joking>

Actually, in this case, I think journaling wouldn't work as effectively, but this is so far OT that it's barely worth anyone replying to... <cue-regulars-to-mock-me>

Oh right. The word "fat" isn't supposed to be used for large things and people anymore. Obama made that law, right?

Weng:

Because a obese ugly hard drive with a obese ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

Totally fixed.

Weng:

Weng:

Because a horizontally challenged ugly hard drive with a horizontally challenged ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

Totally fixed.

Spectre:

Weng:

Weng:

Because a horizontally challenged ugly hard drive with a horizontally challenged ugly full text index on the diff column makes generating cross-references based on diff content about a million times faster. Disk space is cheap. Real cheap.

Totally fixed.

TRFTFY.

That makes me think of penises.  A better phrase might be "gravitationally challenged" or "fast-food-made disaster".  Everything wrong with the world is to blamed on big business and capitalism, not personal responsibility, right?