- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
While not completely true, this is at least a good first order approximation.
Admin
There are two kind of people: those who use backups, and those who will be using backups ;-)
Admin
Admin
Given that Jared worked for a month without checking anything into source control, and Stephen knew that's what he was doing... do they have a right to be upset, or even surprised, when some idiot deletes it?
Admin
Suffix rules and wildcards are NOT the same thing.
A suffix rule says "if at any point I tell you about a .cc file, run cc with these flags to build it" or "if I ask you for a .o file and you can find only a .cc file, run cc with these flags to build it".
A wildcard rule says "if you find a random .cc file lying around, build it (using the suffix rules) and link it into the executable without question".
Wildcard rules are doubly dangerous. First, they might import stray files into builds that are present in a developer's sandbox but not present in source control. Second, wildcard rules fail to detect when files are missing from the build directory (i.e., because they were not added to source control), and therefore missing from builds on any machine other than the original developer's (there might be link errors, but most compilers will not give good diagnostics for these, and these errors will not occur until much later in the build, and maybe not at all if any kind of dynamic linkage or binding is used).
Admin
A while back an intern nuked my dev. server because he figured a checked in script must be functional... otherwise what would it be doing in svn.
Plus there's always ghetto code, stuff that runs but is usually an abomination of $index12, $foo3 like variable names, and if not run under the correct but undocumented conditions will end up being anti-productive.
Admin
When I get into an argument with a spouse I tend to work them up real good. Just in the way that comment would do. Just because I pretty much never lose my cools. And well, so far, most of the people I've been living with have come back after they cooled down and given me an excuse for their behavior. Even if they werent the ones to be wrong. Then again, I spent most of my teens studying people and being a GM just to learn how to handle people. ;)
Admin
Seconded. Common sense should prevail over religious aspirations. You come to build for Windows, you build for Windows. But leaving your options in plaform open, specially with Java, is part of the common sense too. If you're to have a Java app welded to Windows why not use something that wont need a resource hog middle-ware to work?
Admin
Admin
Bingo
Admin
We got here a guy which probably only add his executable files to source control because adding the source directly is: horrible and stupid.
Admin
Teh linux trollz are horriblez and stupidz and need to be calmed down with .50 gunz
Admin
Raises hand
We had a company wide virus infestation in December (spread from our virus scan server ironically enough). Took 2 weeks for our IT guys to clear it out, but many systems still havn't been returned to normal.One of those systems is our source control server, so until that is fixed we can't commit any changes. And ofcourse we're not allowed to play with the server settings ourselves...
Admin
Admin
The real WTF is that somebody can be this clueless and still prefer Linux.
Admin
Q branch. I never check in my code, 007.
Admin
WILL EVERYONE JUST CALM THE F*** DOWN!!
Admin
-"You have any experience with Java?" -"No." -"OK... Welcome aboard the sinking ship of Initrode as Java developer!"
I think that pretty much covers it.
Admin
When manipulation and control come in the door, love flies out the window...
Admin
I love the Romeo and Juliet part. Really nice written :)
Admin
Admin
Admin
Well, yes, of course.
Admin
Ok, I don't have time to read all the comments, but feel the need to explain the situation a bit better.
When I got to the company, they hadn't even heard of source control. I implemented tortoise SVN specifically for that project so that each time I finished a core piece of functionality I could "check it in". I backed up my code daily with Norton Ghost. Apparently they only keep the ghost files for one week, and it was a while before they realized just what he had deleted, and by then it was too late.
Yes, I know I was using SVN incorrectly. I didn't know anything about SVN or how to use it properly. I'd only been out of college for a year, and they don't teach source control to "New Media" majors getting a programming certificate.
Anyways, I forgot to check the source in before I left (which I had planned to do) because four days into my two weeks notice they told me to pack up my crap and leave. It sort of slipped my mind as I was cleaning my personal files out of the computer and boxing my things up (they don't wipe computers for the new guy. My computer still had personal files from the last two programmers on it). As I was driving home I remembered and called "Stephen" and asked him to check the files into source control. For some reason he said he'd just let the new guy do it whenever they hired someone. I thought this was a bad idea, but since I didn't work there anymore, it fell into the "not my problem" category.
When they finally did hire someone (about a month later) and Stephen told him that the files needed checked in, the new guy said (and I quote), "Nah, I'd rather just have a fresh copy of the last working version." and then RIGHT CLICKED ON THE TOP DIRECTORY AND REVERTED ALL CHANGES. WTF!?!?
Admin
absolutely, it's like therapy with someone who was there. A cry for help so someone who understands can say, "just calm down".
Admin
sorry I should have hit "quote" instead of "reply" Don't worry I back up everything i do!
Admin
He probably realized it was embarrassingly bad and would possibly never work. He didn't want to commit his mistake for all eternity.
Admin
Source control is Horrible and Stupid.
Admin
If you have a wife, you lost a long time ago.
Admin
Still, lovely to know that paratus, who I assume is an (ex) Marine, spent his malformative years studying people, much like Alexander Fleming studied fungus. Rather puts us humble programmers to shame, doesn't it?
Admin
Admin
Unfortunately not. The really skillful manipulators often end up having the manipulated fall in love with, even if that wasn't even their intention. It's not going to be a mutual thing, though.
Admin
The last part is very true. Today people first learn about those things from practical experience, and many people never seem to learn it correctly at all. Your post as others have already pointed out proves it. Suffix rules does not compile all *.c -- only those with a corresponing *.o depended upon by a target.
Admin
Oh ... wait...
Admin
Ken is more brillant than Paula!
Admin
The trouble is not every CVS can do branching, and not every manager is ready to do such "complicated and potentionally dangerous" things.
And even if it was, it is aboslutely correct that you don't submit something you have not finished and has not reached the 0.1 version yet - on the other side, the it is only YOU who is responsible for the backup (continuity)...
Admin
I take offense to that. I am a self-taught programmer, and while I wouldn't quite call myself an expert, I am pretty talented. And no, this isn't some moron saying he's talented, I've had others say so as well.
Admin
Not checking in source every night is, "Horrible and stupid"!
Admin
[quote user="A Nonny Mouse" those that are saying he should have checked his script in: no i disagree. if something is not ready then it shouldn't go into source control. my basic assumption is that if something is in then as far as the developer is concerned, it works. i learned this the hard way - someone checked something in, someone else cavalierly released it to UAT, and i was the fire fighter lumped with the messy rollback [/quote]
If your version control system is so broken that you cannot isolate development from production, you should fix that first.
I can't imagine doing development out of a version control system. Of course the code isn't finished and bla bla, but at least each change builds and passes whatever tests it should. For more sweeping changes where you may want to track progress while the build or tests are broken, simply create a sub-branch with its attributes set to not require a build and/or tests...
Heck, in development there are often dead ends and the fact that you hit a dead end doesn't mean that the code should be eradicated. It may help other developers to see what was tried and didn't work. None of that ever has to touch the production code, of course, but it still should be in the VCS. I guess all VCSes let you attach comments to changes, so that you can spell things out for posterity (say: This branch tries frobnicate the foobar -- it turns out it made the code turn into a mess, so this is dead code now.)
Cheers, Kuba
Admin
I agree that the codebase should compile, but development sub-branches, where some sweeping changes are done, may not necessarily need to compile. Usually you'd set the branch integration policy to require building, but individual changes in the branch may be overriden not to require a build.
Source control systems make very good journals, and I don't think it's abuse. Quite to the contrary, it makes it easier for other developers to see incremental, easier to swallow changes if they need to track how something came to be.
If you use a branch as a development journal, the code you're mucking with may well not compile, and spending time on making it so may well be time wasted.
Say I'm refactoring from some C-isms to use standard C++ library, the changes may well be affecting so much of the code that I may check them in piecewise according to some plan of action. The last change (or changes) in such a branch would then be used to fix the build errors and warnings, and the branch itself will be then integrated with whatever it's a child of, and that will have to build correctly. I work in such a process, and it seems to be the best balance of productivity and VCS-kosherness.
Cheers, Kuba
Admin
Since some time (a couple years) every computational homework I submit has a makefile that ultimately generates all the tables and pictures that go into the LyX document, and it really works wonders and had saved me tons of time. I never face the problem of a graph or a table being inconsistent (unless I screwed up the makefile) In fact, for homework where stuff can be sent via e-mail, I simply do make submit and off it goes.
I've had a case of a project that was relatively involved, where I kept all files in an aegis repository. An into-the-future "at" job was there to email the then-current baseline version of the .pdf file to the prof some minutes before the deadline. It kept me pretty relaxed: I knew that iwhatever wasn't integrated into the baseline simply won't get out, so I could experiment while still being able to move things forward. Naturally, the LyX file of the report was part of the repository, and everything up to the final .pdf was generated from a relatively simple makefile.
I'm really scared by the fact that more and more computational software is not being made available on unix (or even commandline windows) platforms anymore - it's relatively hard to automate point-and-click software in a canned build environment. Doable, but not as easy as it could have been. Most software, even if it gives you OLE automation, will still want to show a window etc.. :(
Ansys, as much as it sucks, is still not bad in this department, otherwise I'd be really screwed.
I'm an ME student ;)
Cheers, Kuba
Admin
Recursive Make Considered Harmful
There's no problem with building a makefile from lists of files in individual directories, if you want to go that way. It avoids having a big monolithic makefile in the source control which will get frequent conflicts, but still lets your build tool know about the whole dependency tree. This is the only safe way for make to parallelize the build. If you use say distcc, you can maximally exploit your build farm that way.
This is one of the reasons I despise qmake: they didn't read the cited article :(
Admin
Not every company has a sane policy regarding their version control system. In my last job it would have violated process to check in something unregistered. Nuts, yeah, but they were unwilling to deal with (either emotionally or procedurally) the possibility of an incomplete build sneaking into production.
Admin
Reminds me of a colleague who started his work scoffing at my code as "dirty code". When I reviewed the code to his first big project, it was riddled with non-descriptive variable names like $wt457...