- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- 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
After reading this I need to be Committed. Or, at least, Checked-Out.
Addendum (2011-09-06 07:35):
That's why I am a huge proponent of 'git'.Perhaps I need to be Committed. Or, at least, Checked-Out.
Admin
Admin
I've actually had the conversation about the difference between document management and source control before with co-workers. But I admit to not knowing what to use instead. Any suggestions?
Admin
is it just me or is any one else feel that they must be in the twilight zone because this was posted before 8:30?
Admin
Why the hell would you want to keep documentation out of the source control system?
What makes a latex/org/... file different from a c/py/.. file? In both cases you want to track and merge changes and see who did what when, and branch as ideas are tried or different "stable" versions are needed...
Admin
Dimension one look like bits to me. Surely they should be broken up into 8 bit blocks to become bytes?
Chris.
Admin
The companies I've worked for so far, as well as the companies I will work for in the future, will always have to store vast amounts of binary data next to the code. And due to requirements it will always have to be in the same system.
But that's game industry for you, assets of one version might not be compatible with assets of a different version, as such the assets are linked to the code, and using multiple systems for that would make life a living nightmare!
Admin
A few years back I was tasked with merging version 12 into the by now completely different product which was forked off from version 9 (specifically, version 9.4) four years previously. Of course, the QA procedures had since been rewritten, and QA itself had been offshored, so relying on the same test schedule that had been used for version 9.4, 10, 11 and 12 (all versions) would have been inadequate, so 300 pages of QA instructions had to be regenerated from scratch.
There was so much to do and the deadlines were so tight it resulted in me working on the average of 70 hour weeks (all overtime unpaid) and being denied any decent leave for 18 months. Surprise was expressed at my exit interview that one of the reasons I was leaving was that I was tired.
The moral of the story: if you're going to make stupid management decisions, make sure that the engineer who said at the time that it was a stupid idea isn't going to be assigned the task of fixing it, or you may lose him.
Admin
In the codebase I work with, there is a document written in MS Word HTML (don't ask me why; not my decision). While a simple change to a cell in a table looks easy when editing with Word, the underlying HTML seemed to change very drastically with that simple change. Making a patch in SVN with a change of that file ended up just being ridiculous because nobody wanted to go through the crapload of changes. We ended up moving to more of a Wiki system but that, I think, is a good reason why some docs should be left out of a source control system.
Admin
Documentation is usually written in Word (or using a similarly ill-maintainable program) so in a source-control system usually need to be stored in binary form. In such a form it may not be as easy to establish what the differences are between versions.
If you're maintaining your documentation in e.g. TeX, then it may well be more appropriate to use a source-control system for the docs.
Another option is to use a wiki for the documentation.
Admin
Admin
mm...is it SourceSafe (who uses source safe??)
or is it writing an educational article about source control in a website dedicated to bad practices?
i think we're long overdue an article about WTF practices. taken from select implementations on this website through the years and put together into one incoherent collection of WTF practices.
also - how about a WTF rating: you often here people say "i worked on a really crappy system" or "you wouldn't believe how bad the code here is"
but these claims are often not backed up due to "copyright" or "theft of source code" or something. well - i have a solution: WTF rating - a comparable scale of WTFP (WTF points). the ratio tries to capture the level of WTFness (bugs, crashes, user complaints, complexity and incomprehensibility) introduced by each WTF. Points accumulate, reflecting the fact that the larger the system the more WTFs you will find, and the worse off it is.
i.e. 1000 WTFP - Writing your own version of a bool (with that long missing 3rd option) 10 WTFP - giving a variable a meaningless name 20 WTFP - giving a variable an opposite name 50 WTFP - giving a variable an incomprehensible name (NotNonInvisible)
you can also give points to WTFP (WTF Practices) i.e. 300 - Hiring experts that take months to write their own name in code 500 - Hiring cheap outsourceres that build you a crappy system and then paying 3 times the price to have it fixed 6000 - using ACCESS as a database ..
Finally we can award WTFP (WTF Prizes) to the system with the highest WTFP and WTFP.
Admin
Admin
VB and PHP are certainly RWTFs, but there's no way that they're worse than using Access.
Admin
A PHP application calling an Access database would result in 13000 WTFP (and a developer who's been committed to a mental hospital)
Admin
Wait, what? The other universe's Alex is the Bizarro one??
Admin
10^4 WTFP for storing passwords and other sensitive info in plaintext in a database and only thinking you've encoded them
2 x 10^4 WTFP for consistently releasing untested code changes to Production so as to save time assuaging the rage of the customer who's fallen foul of the last swathe of untested code changes that were released to Production
10^5 WTFP for balancing the mission-critical servers on the cistern in the women's bathroom of the office next door and/or frying your breakfast on the chassis of a similarly-deployed servers in the office kitchen
10^6 WTFP for dismissing your most capable staff for daring to suggest that your arse-brained scheme may need some further refinement, nay, even a redesign, before rushing ahead with implementation
10^7 WTFP for turning up at an interview for your perfect job wearing brown shoes
Admin
... and of course 10^9 WTFP for confusion of "its" and "it's" in a comment in a program module
Admin
Maybe Graham's number WTFP for using SourceSafe for anything other than to demonstrate to management that you're using it.
Admin
500 WTFP for having the only developer on the project write the tests after development, then having him run the tests and calling that QA (not to mention being surprised there're still bugs in the thing, as it's been tested!)
Admin
Over 9000 WTFP for using MySQL in a project where a database is really required.
And .. I strongly disagree with putting php (5+) on the same level as ASP . I believe we can safely assume WTFP(ASP/vb)=10*WTFP(php).
But if we're into the language bashing (which imo is not serious WTF .. except asp/vb/foxpro/cobol/...) why not go for a good old religion war and state the following:
if($language.creator=='microsoft'){$language.wtfp=nanotime();}
Admin
First: The revised "Distributed" diagram is not the only way to set up a DVCS. It's by far the easiest, but certainly not the only way. It's also worth mentioning that for a typical project, a local Git repository is actually going to require less space than a Subversion checkout, so storage isn't relevant.
But there's more to it than that. Adding individual shelves to Subversion was the best and worst thing our team did. Best, because it meant that people were no longer afraid to check in for days at a time, not wanting to break the build with their experimental stuff, which only prolonged that experimental stuff due to them not being able to use version control the whole time.
Before this, we were all working off trunk, which has the additional issue that anytime a developer checks something in, they potentially create a merge conflict with someone else's working copy when they do an 'svn up'.
Worst, because Subversion completely fell over when we tried to use it that way. Especially when we added the merge tracking feature, which does make merges less likely to require manual intervention, but also made them take roughly half an hour. At that point, we were afraid to branch more than we had to, because merging would be painful -- but then, it's usually a given that merging is painful.
Git changed all that. After migrating the project to Git, those half-hour merges took seconds. Plus, we get backup for free, and we can work offline easily.
This is a valid concern:
"With the ease of forking, the simplicity of merging, and allure of pulling, it only seems logical to branch by shelf and end up picking up Jenga pieces."
But the real win isn't that each developer has a shelf, it's that even a feature which will take me only a few hours to develop can get its own branch. I can start work on a new feature without worrying that it'll interfere with anything else -- an urgent bug request could come in, and I'll just switch back to my 'master' or 'shelf' (or even 'trunk') branch and work from that, or create a new branch from the latest release if it's urgent enough to rush out a patch.
There's nothing inherently 'distributed' about any of the above. If non-distributed systems made it easy for a developer to create a new branch on the server, work on it for an hour, and then merge it in seconds, that'd be great. But making merging efficient and easy is a problem every DVCS has had to solve, much more so than a traditional SCM with a central server.
But the distributed pieces matter, too. As mentioned before, developer checkouts are now a sort of backup of your version history. I think it also helps that I'm in the habit of committing as soon as I have anything, which makes it a lot easier to keep commits small and to the point. The nice thing about a DVCS here is that I can easily roll back and re-commit that last change before I push it to anywhere publicly visible -- git's "--amend" option, for example -- so if I catch a typo or something minor before I push, I avoid a lot of "fixed typo" commits. This is even more useful with open source -- I can completely edit my commit history, rearranging things until it looks much more logical than it was, before I submit them for review.
For what it's worth, I also don't agree that every merge needs to be manually reviewed. If you've got a decent test suite, run that. Manual code reviews are useful, but they should be done independently of merges.
I can't really say I'm surprised. What would be surprising is if Alex ever admitted that a hot, new, over-hyped technology actually improved anything. But I have to say, there really are better and worse source control systems, and the new breed of DVCS is a huge improvement over systems like SVN.
Admin
Stores metadata (document number, creator, revision, etc.) in MS Office document property fields.
Automatically creates corporate-standard header/footer sections on all documents, making the metadata visible.
Includes facilities for document approval, so managers can sign-off on released versions of a document, distinguishing it from works-in-progress.
Automatic generation of PDFs from all supported document types (so people viewing files don't need to have the original app installed.)
These are things that are really useful (possibly even critical) for document storage, but would be mostly pointless when applied to source code.
Admin
Any advance on Grahams's Number! Who's first up for suggesting a particular WTF is worth Aleph-Null WTFP?
Admin
100110010010110001101111111100001111100111011110 110011010001001010111000010111011111011110001101 100001011101111101111000110110011001001011000110 100110010010110001101111111100001111100111011110 110011010001001010111000010111011111011110001101 100001011101111101111000110110011001001011000110 100110010010110001101111111100001111100111011110 110011010001001010111000010111011111011110001101 100001011101111101111000110110011001001011000110 100110010010110001101111111100001111100111011110 110011010001001010111000010111011111011110001101 100001011101111101111000110110011001001011000110
10011001 00101100 01101111 11110000 11111001 11011110 11001101 00010010 10111000 01011101 11110111 10001101 10000101 11011111 01111000 11011001 10010010 11000110 10011001 00101100 01101111 11110000 11111001 11011110 11001101 00010010 10111000 01011101 11110111 10001101 10000101 11011111 01111000 11011001 10010010 11000110 10011001 00101100 01101111 11110000 11111001 11011110 11001101 00010010 10111000 01011101 11110111 10001101 10000101 11011111 01111000 11011001 10010010 11000110 10011001 00101100 01101111 11110000 11111001 11011110 11001101 00010010 10111000 01011101 11110111 10001101 10000101 11011111 01111000 11011001 10010010 11000110
153 44 111 240 249 222 205 18 184 93 247 141 133 223 120 217 146 198 153 44 111 240 249 222 205 18 184 93 247 141 133 223 120 217 146 198 153 44 111 240 249 222 205 18 184 93 247 141 133 223 120 217 146 198 153 44 111 240 249 222 205 18 184 93 247 141 133 223 120 217 146 198
™ , o ð ù Þ Í ¸ ] ÷ … ß x Ù ’ Æ ™ , o ð ù Þ Í ¸ ] ÷ … ß x Ù ’ Æ ™ , o ð ù Þ Í ¸ ] ÷ … ß x Ù ’ Æ ™ , o ð ù Þ Í ¸ ] ÷ … ß x Ù ’ Æ
I'm so very dissapointed.
~Nick~
Admin
The most important thing, IMO, about any VCS is its ability to make merges as painless as possible.
Many offer very little. They may generate diffs and point out conflicts, but they make you resolve even the most trivial of conflicts. When you've created a private branch/shelf and need to merge in others' changes without damaging your own edits, a good merge system is critical.
Unfortunately, most systems are very bad at this, and every free system I've used is included.
Without (hopefully) sounding like an advertisement, I've found that the commercial product, Perforce, is the only one that gets this right. The server tracks a file's entire revision history, through all of its permutations of branches (and there may be hundreds, for some key files belonging to large projects.) When you need to do a merge (which they call "integrate"), the system uses the version history to find the common ancestor between your file and the one you're merging in (even if this common ancestor is separated by dozens of intermediate branches.) It then does a 3-way diff on the files (yours, the one you're merging in, and the common ancestor), presenting all conflicts as all three versions of the conflicting lines. Sections where only one source (yours or the merged-in version) differ from the ancestor are automatically merged without any user intervention. (You can, of course, still review the merged changes and fix any mistakes, which still happen occasionally.)
With this system, you can actually merge any branch into any other branch, not just into direct parent/child branches. The server will track the operations and make the right thing happen, even if the branch/merge history starts looking like a tangled ball of rubber bands.
It's not a perfect system. You still sometimes have to manually merge files, but they manage to automate all of the easy situations, so you only have to manually merge the really nasty changes that no system is likely to be able to handle automatically.
(No, I don't work for Perforce, but my employer has used their product for many years and I'm very happy with it.)
Admin
Admin
So, have you tried git?
Admin
Admin
Admin
I tend to like distributed system more...
Local copy of repo is most useful when either the main server is down or you don't have network. You can't commit or switch / create / merge (working) branches or even see the logs, then what good is a source control system if you can't use it.
Also I've always thought "commit" and "push" as "commit" and "inflict". One just stores data, the other inflicts other people with it. This extra step means usually I think twice before sending stuff to main server.
Admin
You had a choice, a choice to quit immediately when faced with 30 hours overtime each week. But you didn't and then you complain afterwards. Perhaps now you have learned to stick up for yourself.
Admin
Thanks, Alex, for this back to basics SCM tutorial. It's concise and very informative.
-Larry
Admin
Good call. You're dead right, I should have jumped ship way before I did. But (a) I hadn't realised at the time how heavy it was going to be, (b) it took some time to find somewhere to jump to.
Bear in mind that when you have responsibilities and dependents that are absolutely your job to look after, you can not just walk up and leave a job without preparing the ground first. When you're a bit older maybe you'll learn this.
Admin
I think most languages are not inherently WTFP worthy.
except for perl.
it may be the only "real" language who's 99 bottles code is somewhat similar looking to brainf*ck
oh and why is my comment spam?? what did i do wrong?
Admin
Bear in mind that doing a lot of work for free (e.g. 30 hours of overtime per week for 18 months > 2000 hours), your employers may already not think very highly of you. Sure, they'll think you're a hard working fellow and might recommend your new prospective employer makes references calls. However, they'll most likely laugh their asses off because you gave them so much work for free and soon forget that you ever existed. They most likely know very well that they're asking you to do 2 people's jobs for 1 salary. If you jump ship and drop all those "responsibilities and dependants" once you realize the task is totally unreasonable, it probably won't change what they think of you.
There's one thing I learned early on in my career, by looking at the people around me. Those who put in all that (unpaid) overtime for someone else leave a huge part of their life between four walls and get nothing but a nice reference call, if your new employer actually does call for references.
Admin
There is some documentation written in word, but it's hardly the industry standard. XML markup of various sorts (ie, docbook) is much more reasonable, since it can generate web and PDF and other forms. I believe all of the popular authoring systems are saved as flavors of XML.
Admin
APL is arguably WTF-worthy.
Admin
"The third – and the least used – special type of Fork operation is called Shelf."
From the point of view of the master repository of a large project, aren't most developer repositories and branches in a distributed system?
My branch of a project on GitHub will never be used to make a build of the official library for instance, so aside from my PoV (and perhaps others working with me) my repo/branch is a shelf.
Well, it'll never be used directly to make an official build at least - if I submit a patch from my code that is accepted or the people with access to the master repo/branch otherwise chose to pull in some of my changes then my branch has an indirect effect on the "real" build. but as that indirect effect is gated by the mast repo's owners I'd say they are still in control of that and my copy is still a shelf from their PoV (and the PoV of the public at large if they use the library) by the definition in this article.
That would make the shelf a very common type of fork, rather than the least used one.
Admin
Admin
Admin
I don't think you understood what QJo meant be 'responsibilities and dependents'. Not the JOB responsiblities. Spouse and kids more likely.
Admin
Admin
trwtf is writing documentation in the first place
am i right?
Admin
It's the fools who keep doing it over and over that cause management to continue this practice of abusing and then discarding employees.
Admin
I am not to be using sorce control for porpuses of incriminations.
Admin
QFT.
Admin
I rather suspect that Alex doesn't understand distributed source control systems like Git and Mercurial.
Once you figure out how it actually works and stop thinking in terms of svn and SourceSafe then you start to realise why it really is the best way to work.
That's not surprising because it really doesn't actually behave the same way as traditional source control.
Joel Spolsky said a while ago “To me, the fact that they make branching and merging easier just means that your coworkers are more likely to branch and merge, and you’re more likely to be confused.”
He later realised that he was totally wrong - http://www.joelonsoftware.com/items/2010/03/17.html
Alex seems to be making a similar mistake here.
One of the really key things I've found with Git is that you never have to 'check-out' a file and two people working on the same file is rarely an issue.
For example:
I'm told "Fix bug A", my colleague is told "Fix bug B".
We both need to work on the same file to fix these bugs for whatever reason. (Maybe it's WTF code, maybe not)
With git, we can both go ahead and do our bugfixes on our local repos, then push the changes to each other once we're each happy that our stuff is good.
If I'm slower than her, when I sync with her to merge in her changes (or a central server) I magically get her fixes - unless we both edit the same method, it Just Works.
With VSS, if she gets to the repository before me then I can't do anything. In other ones, it's extremely easy for either of us to accidentally wipe out the other's work. (Sync A, Sync B, Commit A, Commit B - A's commit just vanished!)
That's really annoying.
Distributed source control means that every single developer automatically has their own 'shelf' to work with, and that merging the shelves to make 'trunk' is usually quite easy.
As mentioned earlier, this also means devs are more likely to keep 'commits' down to very small, focused changes - which are much easier to deal with later on.
-Plus you can all keep working - including rollbacks, 'forks' and 'labelling' - when the network (or server) is down and know that it's not going to be painful to put it all together when the sysadmins get it fixed.
Admin
You're doing it wrong!
C:\VersionControl MyProg.201109060900.c MyProg.201109060904.c MyProg.201109060915.c
It's so easy.
Admin