Comment On The Best-est Version Control

ok that's a wtf.

I've seen some people who don't get along with source control do this too. It's great fun to as whether foo_oldold.c or foo_realold.c is older.

Outstanding and oh-so-easy to install. No worries about your database dying and you losing everything. No complex CVS-style commands. Clean, simple and easy to use. Until you reach the limit on the number of letters your filesystem lets you use in a file name.

VSS blows. CVS (https://www.cvshome.org/) or Subversion (http://subversion.tigris.org/).

Hey I've done worse than this in production for a fortune-1000 that apparently doesn't believe in version control. In order to cover my butt in case of emergency, I wound up writing a script that would zip up my entire source tree, rename the last 9 "zips" and put the new one at the top of the stack. Not that I'm agreeing with this guy, but it might be that he had no choice. The method used, however, is reason enough to keep him from ever breeding :)

I have done this many times and i will continue to do it, until someone point me a way to have in the same debugging session the results of

addOLDEST.aspx
addOLDER.aspx
add.aspx

side by side

btw if the Bernhard Hofmann's colleague is using subversion he may commit only add.aspx and for the rest have an ignore rule

If you use Editplus as your text editor, it automatically creates .bak files when you save unless you turn off this option, so I am not sure that this person is actually manually creating .bak files as a version control method as much as the editor he is uses is doing this for him

Peter: I sympathise, and when I last found myself in that situation, I did the same thing - but not by hand. I set up a CVS repository on my own workstation.

"Along with using ".inc" for include files and any other file-type not registered with IIS or whatever webserver you are using,"

Of course you could register .inc with IIS and keep using the meaningful file extension.

" it opens up the potential for someone to see your source and (possibly) thereby discover enough information to help them hack into your system and do something evil"

You're missing a logical step there. You should have said:
"it opens up the potential for someone to see your source and maybe it's really incompetently written and contains priveledged information, and thereby discover enough information to help them crack your system".

It's reasonable (sometimes) to be paranoid and assume that the source contains some flaw of this nature and act accordingly, but keeping those flaws out is far more important than keeping people out of the source (after all one can read the entire source of some webservers and operating systems any time one wants, and it doesn't seem to be a problem, now does it?).

Hassan: I fully understand that saying "I see nothing wrong with this" doesn't imply that you would do it. What I can't fathom is how you can bring yourself to say "I see nothing wrong with this".

It is a bad thing to do since it will cause the following problems as the history grows:-
a) filename length
b) difficulty in reading which version you are looking at, i.e. you'd have to count the occurrences of 'EST'
c) increasing overhead in renaming EVERY FILE each time a new version is created.

If I saw someone doing this I would immediately tell them to use an alternate method of naming their historic versions, e.g. using a datetime 'add.20040929.0916.aspx','add.20040930.1345.aspx' or incremented numbering 'add.000001.aspx', 'add.000002.aspx' or something else sensible.

Of course, I'd recommend the use of a commercial source control system if possible.

I wonder, given you assertion "I see nothing wrong with this", you would do the same?

In my mind, if something is being done using a method which brings no benefit and/or causes problems when compared to an alternative method of equal cost, then the method being used is, most definitely, wrong.

I used to have to email my code to my manager to be included in his copy of the code. The manager would then proceed to change the code and blame me when it stopped working properly. Mind you, the manager's way of backing up his copy was by making a copy onto a USB drive and copying it to his "other" machine, which happened to be a personal laptop that he bought. Visual Source Safe was too "complicated" and was seen as an unnecessary complexity to the process.

Just a small quibble: SourceGear is the name of the company, and their main product - now - is called Vault (the name is supposed to suggest that it's more secure than a SourceSafe). Previously their main product was SourceOffSite, basically a server front-end to SourceSafe.

We never used SourceSafe because I was horrified by the suggestion that you had to run the online repair tool every night, otherwise the corruption got too bad for the repair tool to fix. Yuch. The main problem was the absence of reliable blocking distributed file locks, to prevent two instances of SourceSafe running on different machines, accessing the same shared store, acquiring the same file at the same time and trying to make different changes to it.

Prior to obtaining Vault, which we did recently, we worked on a system where you typically worked on a local copy of a project and at the end of each day, or at a suitable point, you would make an archive of your current progress in a new folder with the current date (and serial if making multiple archives in a day), to a shared Work-in-Progress volume. Due to the lack of automated builds and decent cleanup tools, we'd leave the binaries in, so you'd often see a 64MB tree being archived each night. This eats massive amounts of disk space and makes it really hard to work on subcomponents independently. Sometimes people would begin zipping up the tree before copying, which then makes it harder to see the current version of any given file.

The advantage of the separate-folder-for-each-version is that you can easily do a folder comparison to see what changed, and you can always rebuild a particular version. The disadvantage is the terrible waste of disk space as every file is included in every version, even if it hasn't changed.

We don't (or, at least, some of us don't) entirely trust Vault yet. A colleague wrote a tool that runs as a scheduled task and checks projects according to a configuration file. If the project has had any checkins or additions (checked using the Vault Client API), it creates a new folder with the current date and performs a complete Get of that project to that folder. This is backed up every night (differentially), along with all the other work-in-progress not yet in Vault, in addition to the transaction log for the Vault database. Weekly we do a full disk backup and a full database backup.

Now I've started using Vault I really couldn't imagine going back - so much so that the first thing I do now on picking up an existing project is clean it up, make sure it builds correctly, then add it to Vault. Even for one-person projects. For the multi-person project we've just completed, I don't see how we could have done it without source control.

Sorry if that sounded like an advert ;-)

LOL. Whatever. This renaming convention suxx, i want to see the same on Delphi files :P I usually zip all my files in the project when work is done for the day, name it productnameYYYYMMDD.zip and send it to a multisession CD. Donez. Good to be a 1-person ISV :)

It's a little known fact that this method is *exactly* how VSS handles revision management under the hood. ;-)

Wouldn't it be better not to keep the source code in files. Ever heard of ENVY (IBM VisualAge)? There everything is kept in a central repository. One does not need to use files or even think about file names, you just make a new version of class, save a method, ... all objects, all the time. It is a shame that the ENVY approach didnt catch up and that people are still using files for storing source code.

It's also a shame that Smalltalk didn't catch on.

But can you imagine people who name their files fooOLDOLD.bak appreciating Smalltalk?

While we're at it, whatever happened to versioned filesystems like those that existed for VMS, ITS, and various Lisp-machines?

If you have a script like:
ren oldest oldestest
ren older oldest
ren old older
ren bak old
cp xxx bak

then you would only add a new first line and rerun

if you take time out to write a script to maintain your idiocy instead of taking the same amount of time to install even something as simple as tortoisecvs (windows based gui cvs client which allows you to maintain local repositories without running a server) then you dont deserve to have a job.

Sometimes, before you setup a sourcesafe database, you might copy a file before you change it. I reckon this is what's happened here. He's then setup source control for it, and just added EVERYTHING in the directory, forgetting that he 'backed up' his files earlier.

This is not a WTF. This is a "Dude you could use a source control system". As long as the programmer knows his way around these files, I see nothing wrong with this.

It's all starting to make sense: Each progressively older version of each file has more letters than the next newer one. THIS is the intended use of that compareTo function that sorted longer strings first.

Seems perfectly reasonable to me.

testing

I'm afraid to even speculate what the contents of these files might look like. Would it be too loathsome to imagine that the author may have also tried to manually implement labels and branches? The horror...

WTF? This must be a real pain when you have to make a new version of a file.
addOLDEST.aspx -> addOLDESTEST.aspx
addOLDER.aspx -> addOLDEST.aspx
add.aspx.bak -> addOLDER.aspx
add.aspx -> add.aspx.bak

This is nothing. On my first project 7 years ago, the Lead Consultant - a professor at a university - put x's in front of old files to indicate their age. It got pretty funny watching him count them up after 6 x's were placed next to each other.

To me the real WTF part of this is that apparently he spends the time to go back to the old files and rename all of the previous ones.

Hassan, I sincerely hope you're joking and I just didn't catch it. The WTF here is 2-part.

1) Simple souce management tools are immediately available, like how MS tries to cram SourceSafe in with every programming language installation.

2) I'm just repeating what others are saying, but how much time does this guy waste renaming the old files? And what does he do in the example shown when another version is created? Does the oldest one turn into "blahDetailsOLDESTESTEST.aspx"?

Just because his method works doesn't make it right. The mentality "As long as it works" is a newbie approach. If this is just a screenshot of a guy's home computer as he's working on his blog, then it's not a WTF. My guess is that this is supposed to be a paid programmer working on a company website, which means the potential exists for other people to need to work on this code simultaneously. Version control systems are a necessity in those cases.

wow. now that's a great WTF. Though if given the choice of using that naming convention and using Visual Source Safe... I'm not sure which style of agony I would choose.

ThePainIs
ThePainIs.bak
ThePainIs.OLDER
ThePainIs.OLDEST
ThePainIs.OLDESTEST

That is just too funny. But I'm mostly laughing at myself; having done this on occasion. Ugh, I even know that it is better to do these "backups" by zipping the whole directory. Oh the shame.

And I've been looking for a reason to change from CVS to something else...

Would this take less time than tagging in CVS? ;-)

Everybody has made the assumption that these files are not being used. A site I inherited has both default.aspx and default_old.aspx used on the site.

i myself like to keep versionnumbers of filenames instead, like test1.fla ... test16.fla where test16 is the newest :)

Yes, even though the 'programmer' here picked a bad way to implement version control, by renaming the files, he/she also picked the WORST way since the names of the files have to be changed every time a new one is made...he/she could have at least concatenated the date on the end of the files:

foo_080904.aspx
foo_011003.aspx
foo_112902.aspx

I admit that when I was a n00b I did this with my asp.old pages a few years ago...but I was doing the asp pages for my personal site and was not getting paid for it so I guess it wasn't too bad.

Well...about the renaming problem...have anybody imagined that this guy could write a little program to do the renaming for him and that he may create a page and spread his outstanding idea to the world? Hey, Jeff Lewis, maybe that´s what you´re looking for to replace CVS! hehehehehehhehehhe

By the way, why bother using a good version control if u can create a more complex of your own?

Well, we'd hope that the .bak file isn't being used. I think he'd be well worthy of an ass-kicking if he renamed it .bak, then mapped that extension in IIS so it would run through the .Net ISAPI filter.
Although, for some reason, I don't think that it would surprise me.

I use dates for old files on a regular basis. My system is similar to skicow's with two significant differences:

1. Use YYYYMMDD so that the lexicographic sort order is the same as the actual date order.

2. Put the date after the functional suffix so that old files can't even be recognized as being valid for use unless they are recopied back to a useful name.

So, those files would be named

foo.aspx.20040809
foo.aspx.20030110
foo.aspx.20021129

Well, it seems that he is not using VS as I dont see code behind files, so maybe we can assume he doesnt have VSS either.
Lets go a bit further and assume he doesnt have a source control system at hand. If so then maybe in his working environment he figured out that a file naming scheme was good enough to get track of a couple of asp.net pages.
But hey!, you sure must know what's best for this poor guy, isn't?
But let's talk about this programmer, I don't know him but strangely I can clearly picture him.
This particular programmer may find comfort using a naming schema like that. You know, maybe he is alone, maybe he doesn't have friends, maybe his life sucks... maybe naming the files that way makes him forget about how the dreams he had when he was a geek kid (when he used to love technology) has gone. No more dreams, he has an insipid job, computers' cool factor is gone. He hates his job, his boss, his life, and you are making fun of how he needs to rename every previous version of the page once a change it's made. Maybe finding a way to express that something is older than oldestest is what keeps him from going one day to his job with a semi-auto rifle and lots of ammo.

If anybody doesn't see a problem with this you have a problem... People who need to maintain this crap later are screwed... (Unless this is well documented... which I would love to see)
I mean the least you could do is move the files not being used to a new directory...

DAMN!!!

>> As long as the programmer knows his way around these files, I see nothing wrong with this.

I know what you mean but still how is someone supposed to take a look and improve or see what they were trying to do. Programmers that do this also do not comment.

I've done a version of this on the directory level in the past, usually using dates instead of "old" (although I did lapse into that occasionally).

Source control is necessary and useful, but in a team of one (or even two) people the setup overhead isn't always worth it--especially if you're going to join source control in a month, and you don't want to have to migrate everything out of your existing (in my case, skunkworks) system before you can use it.

At least that was my experience--I putzed with CVS a bit and knew other source control systems pretty well, but in the day-to-day it wasn't worth the bother (granted, I was a bit offended at having to wait to use the mainline source control, but that's another matter).

I couldn't imagine doing it on the file level like this guy, though. That has to be Hell.

Wow, watching evolution take place all over again. He must be pretty close to inventing some sort of roman numeral system, and if he gets enough time, he may even find a base-x like way of counting with actual numbers. Coool

I hate to be one of the ones justifying this, but to those who say this creates a maintainability problem and that if he uses this, it needs to be documented, I say: WTF?

It couldn't get any more self explanatory than it is. Assuming he is consistant, OLDEST is the oldest, OLDER is older, and OLD is newer than both of those, but not the current version.

I agree that it's a boneheaded way of doing it. Concatenating the dates on at the end, or even incremental numbers (myPage.aspx.1, myPage.aspx.2) etc would make more sense as you don't have to re-re-re-rename everything.

>It couldn't get any more self explanatory than it is. Assuming he is consistant, OLDEST is the oldest, OLDER is older, and OLD is newer than both of those, but not the current version.

So where does OLDESTEST fit on that scale then? What happens when you have 7 iterations of a particular file. Do you now start appending REALLYFREAKINGOLD, SUPERDUPEROLD, and SOOLDITWASAROUNDDURINGTHECIVILWAR to files?

That's awesome. I think the guy who did that deserves a "I had so much crack one day that I made it on thedailywtf" t-shirt

Don't tell me about that. I used to work with self-made-webmasters that didn't understand a thing about naming...

file1.png
file2.png
file2_final.png
file2_final_2.png
old_file1_final.png
file1_fina.png
file1_with_something_great_you_need.png

Who knows what's the real lastest version?

I was on a project once that used an Access file called Master.mdb as the backend database. One day I was looking through the project's shared file system and found stuff like this:

\Master.mdb
\Master (2).mdb
\The REAL Master.mdb
\The REAL Master (2).mdb
\Project\Master.mdb
\Project\Master (2).mdb
\Project\The REAL Master.mdb
\Project\Code\Master.mdb
\Installed\Master.mdb
\Installed\Master (2).mdb

Guess which one was the most recent version and which were backups.

(And yes, there were actually copies that used "The REAL" in the name to distinguish them from the other copies.)

Ok - this is a nice and proper wtf :)

At least that guy's sure that his sources won't be eaten by Visual Source Shredder. It's very funny when you see a whole project dissapear - I can tell you. Actually we got 0-bytes files, but there's not much difference with "dissapearing" and that, now is there?
It gets even more funny when you hear that that system had totally NO backup at all, the RAID5 should be enough... *oops*

It really gets hilarious when you know every developer had been trained to do an full update every morning he logged in, and no-one really noticed this problem cause we had a team-meeting first thing in the morning. What happened? Everybody logs in, syncs his sources with the ones on the server, checks his Outlook, goes for a cup of cofee, and enters the meeting room.

Around noon, the first-one wants to start coding... Open file... Uh? Empty? Hmmm resync, oh and let's commit all the locked-ones also immediately, not a bad idea huh? Sync done. Hmmm? all files 0-bytes? Wtf? Delete/move/... local fubarred tree and get complete new tree. Damn - still 0-bytes... O_o all of them... By that time, most of the development team had noticed the problem, and tried various hyper-intelligent stuff (at least I did :D), like getting trying to get an older version, but all older versions seemed to have dissapeared. Closer inspection on the server itself told us - eeh well - that the VSS repositry was a bit fubarred. Finally some activity in the building...

Too bad some collegue spoiled the fun by having a backup at home from 2 days before, but he only thought of that after 2 days of scraping bits & pieces together, so we still had *some* fun. Anyway, VSS out, CVS in :)

I surely hope VSS improved, cause that was really a point where even the biggest MS-fanboy at work cursed MS for making buggy soft (I think it was the 98 version, not sure though, long time ago, don't really wanna remember :D)
Right now, I can laugh with it, but you really don't wanna proposes to use VSS for a project to me :)
I probably have some VSS-terms wrong, but this incident was like 4 years ago, and I only used it for about 2 months, and never touched it again :)

HELLO! MCFLY!! To all the people saying this isn't a problem..... wait until a sysadmin who didn't even know your project existed DELETES THE WHOLE DIRECTORY with all your "backup" versions. I saw a perl ".oldest" source-control fan lose 6 months work on the server through this, apparently their lack of common-sense extended to a lack of communication. Apart from all the other issues raised here, external database-driven source-control systems like PVCS, ClearCase, perforce etc at least guarantee the data is backed up as well.

I'm so pleased to see so many of you not only defending this technique, but also suggesting ways to improve it. You must also be glad to see that the assault rifle ban has lapsed, so you can all repeatedly shoot yourselves in the foot far more productively these days.

I must admit my guilt in having done similar things with Access databases. In my defense, I was young and foolish :-)

To the poster who suggested putting the date after the file extension (eg foo.aspx.20040809 ) this is a bad idea if the file is on a server.

Along with using ".inc" for include files and any other file-type not registered with IIS or whatever webserver you are using, it opens up the potential for someone to see your source and (possibly) thereby discover enough information to help them hack into your system and do something evil like reset your minesweeper high score table.
(eg discovering the full path to your database file, or your collection of .inc files).

This was in fact just one of a string of minor "offences". Another was the "New Folder" folder in the root of the website that, as it turned out, was actually part of the website.

The developer did/does not have source control. My major issue was not the method but the implementation. I would understand appending date, and possibly time, to the filenames. But as so many have understood, the problem lies in the fact that every history has to be renamed when a new version is “checked in”.