Slashdot Mirror
An Illustrated Version Control Timeline
rocket22 writes "Most software developers are supposed to be using the latest in tech and see themselves as living on the edge of software innovation. But, are they aware of how old some of the tools they use on a daily basis are? There are teams out there developing iPad software and checking in code inside arcane CVS repositories. Aren't we in the 21st century, the age of distributed version control? The blog post goes through some of the most important version control systems on the last three decades and while it doesn't try to come up with an extremely detailed thesis, it does a good job creating a catalog of some of the most widely spread or technologically relevant SCMs."
Second, the article doesn't even mention SCCS, developed in 1972 (and still available), so his history lesson is lacking some completeness and perspective.
Third, remarking, "It [CVS] is outdated now, but it worked in the 90s! (If you have it, just walk away and go on to something else!)" -- as well as the other snobbish comments about other (older) systems -- is simply narrow-minded. CVS is completely satisfactory for many, many projects. Contrary to later comments in the article, I've used, and still use, CVS in several commercial products and it works just fine.
Real lesson: Newer is not always better; more features are not always needed.
It must have been something you assimilated. . . .
I hear all the time how terrible Subversion is at branching and merging, but I can't really see any issues with it. Am I missing something, or is this all based on pre-1.5, when it didn't have merge tracking? Granted, it was fairly brain-dead to not track what revision a branch occurred in or what revision it was last merged to a particular other branch (or the head), but as far as I can tell, comparing it to AccuRev which I use at work heavily and is supposed to be fantastic at merging (it's ... ok), there's little difference beyond the terminology.
Can somebody explain what it handles so badly? I feel like I'm not missing something I should be. I like Subversion, probably just because I know it, and use it for my home projects, but if there was an actual benefit (and decent cross-platform tools, TortiseSVN is fantastic, I love working on my linux box but doing graphical diffs on the same working copy over a Samba share) I'd love to switch to something better--I know I said I like Subversion, but it's more like how you like a kevlar vest, it's better than the alternative, which in this simile is bullet holes in my torso.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Geez, he's right, I've been using things like grep and gcc just because I'm familiar with them and they perform the task at hand. Time to upgrade to the hip and new version that does the same damn thing in a slightly different way!
Not that I'm against progress, but it's a matter of weighing the hassle against the gains. Forcing the new kids to learn the old tools can be annoying, but good for them. Likewise, showing grandpa that there's a diff with side-by-side comparisons is probably a good idea.
Don't forget bitrot. Enough other people move to $new_tech, and those of us who were productive with $old_tech suddenly see things break.
tasks(723) drafts(105) languages(484) examples(29106)
Full of troll, and incorrect in some spots. For example, TFS doesn't do branching and merging? It may do a crappy job of branching and merging, but that functionality is prominently there.
I quit using SVN just because I found the Xcode integration to be flakey at best, and remote work was less than seamless. It otherwise seems to work fine, and what it lacks are things that are just poseur points for most shops (quick, list two problems for your shop that only a DCVS can solve).
Git worked for me when I was doing work on the bus to and from my day job, allowing granular commits instead of the big mixed-up commit when I got home. I like it for a lot of other reasons even after doing my own thing full-time. But there's no way I'd get on a religious soapbox about it, starting with the learning curve (first time a merge or a push goes wrong, break out the google).
But hey, use what you want as long as it's not VSS. Because even a tabs vs. spaces flamewar interests me more than source control debates.
Not the GP, but as someone who has used several VCS, I have to say that there is nothing, and I mean NOTHING to like about TFS. Its nearly as bad as VisualSourceSafe, and I'm not joking when I say I think they built a .Net service to wrap a VSS back-end. Besides the god-awful performance (it is sloooooow), you can't work off-line (which is great, because TFS will often stop working), the user interface is random and inconsistent (some places will let you view a file's history, others won't for example). It has an obsessively complex security model that, no doubt, keeps middle management feeling all warm and fuzzy - but often breaks. The integration with Windows File Explorer is bat-shit-crazy and SLOOOOOW. The whole system seems to try and track all local changes, in real time, and fails - editing a file with notepad instead of in VisualStudio/TFS will confuse the hell out of it. Getting latest version doesn't always get the latest version - we've got used to using 'force get latest' and risking over writing local changes. And that's before you consider that the technology, even if it worked well, is a decade or more out of date! Oh, and as an added bonus, your code and history gets locked up in a proprietary format. Avoid at all costs.
I agree. This is why I use CMake, CTest and Git.
Test results are stored in a file inside my Git repo, and are therefore part of the "story".
However, what really matters is the total build, regression, bug reporting, electricity consumption, end user satisfaction, employee payroll, and stock price story -- which encompasses more than just revision control and illustrates that "what matters" is a matter of opinion.
Mercurial's SVN re-education page does a good job of describing the advantages.
I don't know why this one piece of software evokes such illogical responses. Oh well.
Well, unless you're completely insane, you don't change SCMs more then once a decade. Entire processes get built around the current SCM (QA, deployment, development, archival, etc) and that's not something easily changed.
So it's never as simple as swapping one command for another. The thought processes are slightly different, everyone has to update their workflow or custom-written glue tools and you may lose version history.
(Distributed SCMs are almost worth the effort, if I actually needed that feature more then once a year.)
Wolde you bothe eate your cake, and have your cake?
With SVN, this is: svn switch file:///arcane/long/path/to/svn/tags/gold ; work ; svn switch file:///arcane/long/path/to/svn/trunk ; svn ci -m "Why are SVN tags so long?"
The usual approach is to not use svn switch at all, but to check out your tags or branches into a separate directory, which works just fine. Alternatively, you could use (as another poster suggested) an environment variable to specify your repository basem or one of the many GUIs that make using switch easier. Most development environments have such an integration. Even emacs has one, although I've never tried it.
With CVS, if I check in with an outdated tag on the trunk, it'll fail and tell me. With SVN, it will blindly alter the contents of the tag.
The normal approach to solving this problem is to install a pre-commit.sh script on the server that rejects any operations other than copy in the tags directory.
"TFS is based on SVN. Really."
Really? This seems very unlikely as there is no mention in the license and the repository is a SQL Server database. Even if this were true, Subversion is a technology that is in decline. DVCS offers substantial advantages.
"I'm really not sure where all the TFS hate comes from."
It comes from using SourceSafe, Subversion, ClearCase and, more recently, Git. Doesn't stand up to any of them except possibly SourceSafe - though that's hardly a great accolade.
"It's heavily integrated with VS..."
And that's part of the problem. What if I don't/can't use VisualStudio? For example, our database design is done in Erwin. The hoops we have to go through to make sure that TFS doesn't get its knickers in a twist! Maybe its because Erwin generates binary files (TFS sends the whole file not diffs, which makes the whole thing even slower than it is normally). In contrast, Notepad++, WinMerge, File Explorer and even VisualStudio seamlessly integrate with Tortoise/SVN making my workflow seamless and painless. The difference between the two is striking. Another example: We generate SQL scripts from Erwin and then check these scripts into TFS. When TFS sees that these files have changed (even though it is usually just the date stamp that has changed), it will download all the SQL scripts (there are lots of them!). For some reason this process takes 10 times longer than a normal refresh - I can wait 20 minutes for it to complete, instead of about 2 minutes. Why does it even need to download the files that are the same except for the date stamp? 20 minutes x once a week x a four year project... Wow, what a waste of time!
"Check out/check in seems like a tedious process"
Check out/Check in IS a tedious process when you realize its completely redundant. TFS has an option to remove this requirement, however management seems to think this is a good idea as 'it helps avoid merges'. Face/Palm. Case in point: Our developers are split across two sites, and I often fly between them. While working on the Subversion based project, I worked on the plane. My workflow was essentially uninterrupted. Now I'm working on the TFS based project, I am forever having to bring up file explorer to change Read/Write permissions. If I want to add a file to a project... well, its easier to wait until I arrive at my destination. With a DVCS my workflow would be *exactly* the same - and I'd even have a full history of all the files!
"There is no integration with Windows Explorer."
Yes, there is if you install the TFS Power Tools. I don't recommend it though as it seems to screw the performance of Windows.
TFS is not a source control system, its a developer control system designed to allow middle management to fiddle with security, lock files and generally dick about with the development process. If you really want that kind of functionality, I'm sure there are better ways. Avoid at all costs.