Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

An Illustrated Version Control Timeline

CmdrTaco posted more than 3 years ago | from the remember-when dept.

Programming 244

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."

cancel ×

244 comments

Sorry! There are no comments related to the filter you selected.

VSS All the Way (0)

Anonymous Coward | more than 3 years ago | (#34256982)

If only PHB's had a clue, we're forced to use Visual Source Safe at work. I would claim it a legacy system but they just put it in a couple of monthes ago. I think any version control is better than nothing, but I'm not sure Visual Source Safe beats the file system's snap shots that are automatically created.

My god, it's full of troll. (5, Insightful)

conner_bw (120497) | more than 3 years ago | (#34256990)

iPad developers use CVS because Xcode integrates with it out of the box (and SVN, and Perforce). If it works for them, why do you care?

The illustration is idiotic. The image of cellphones in comparison to SCMs is stupid. Linux was released in 1991, LOL 1991 CELLPHONE!!!1! ... Oh wait, the initial release date is irrelevant as software changes with time.

Finally, i'll go out and say it, the hate-on for SVN is overrated. A part from a few world class developers who, for some reason, have shitty network connections and thousand patches to sort though, it's mostly cool-kids overcomplicating their lives solving "problems" they never had while developing their blogging software, not working in an office, and imagining they are Linus Torvalds?

Bonus reading: Taco Bell programming [teddziuba.com] .

Re:My god, it's full of troll. (1, Informative)

Anonymous Coward | more than 3 years ago | (#34257026)

It's also an advertisement. Sigh.

Re:My god, it's full of troll. (1)

walshy007 (906710) | more than 3 years ago | (#34257146)

Finally, i'll go out and say it, the hate-on for SVN is overrated. A part from a few world class developers who, for some reason, have shitty network connections and thousand patches to sort though, it's mostly cool-kids overcomplicating their lives solving "problems" they never had while developing their blogging software, not working in an office, and imagining they are Linus Torvalds?

While I agree svn isn't bad to work with, having a local repository can be VERY handy once you're accustomed to the workflow.

Enough so that when dealing with svn repositories it's rather nice to be able to import a complete copy of the repo using git-svn, albeit it takes somewhat longer etc.

With svn I could not do version control based things during a long commute such as finding out who wrote a specific line of code so I can make a note to yell at them, with git I can. One of many things.

Re:My god, it's full of troll. (2, Informative)

dannys42 (61725) | more than 3 years ago | (#34258856)

I agree, subversion is not terrible. However, after getting a laptop, I definitely see the advantages of a DVCS. git's not the friendliest of tools, but regardless of the reason, there's a lot of moment out there and supporting tools, so I prefer using git as my DVCS system.

In addition, with git, I also have gotten extremely comfortable with creating a new local branch for any separate task I want to do. This makes my commits much cleaner and virtually eliminates the problem I had with svn where I was working on a feature then got interrupted with a high priority bug.

The git-svn bridge also comes in extremely handy, and is a great way to get the benefits of both worlds.

I have to say though, that I think git not handling directories as real objects is a big step backwards. And Subversion's use of metadatas can also be pretty handy sometimes.

Re:My god, it's full of troll. (1)

e4g4 (533831) | more than 3 years ago | (#34259072)

While I agree svn isn't bad to work with

SVN is barely tolerable. I'm never going back - git is so much better it's not even fair to consider it in the same league as SVN.

Re:My god, it's full of troll. (1)

walshy007 (906710) | more than 3 years ago | (#34259330)

Completely agree that git is leagues ahead, but svn is usable in the sense I could use ed as my ide if I wished, while nowhere near as useful it is still functional, for a certain need.

Re:My god, it's full of troll. (0)

Anonymous Coward | more than 3 years ago | (#34257462)

Yeah, the article seems to conflate old with bad, and advocates using more complicated technology because its "better", without really considering what "better" is. It's folly to think that distributed version control imposes no overhead, it does. Now whether or not the overhead is worth the features you gain really depends on what your needs are. Open source projects have a MUCH different workflow(tending to involve a large # of globally distributed users, no need to secure code against unauthorized reads etc.) than a lot of small shops which have a small # of developers(and maybe no full-time SCM), tend to be located in the same office etc. The extra overhead of getting a distributed SVN vs. the dead simple SVN setup isn't always worth it.

Re:My god, it's full of troll. (2, Insightful)

C3c6e6 (766943) | more than 3 years ago | (#34257584)

I couldn't agree more. In my previous job, I had a colleague who wanted to convert me from SVN to Bazaar (http://bazaar-vcs.org/).

He told me "it was very simple to use, you only have to..." and then started drawing a very complicated diagram on my whiteboard.

Personally, I thought it was complete overkill for the two-man project we were working on.

Re:My god, it's full of troll. (1)

wiredlogic (135348) | more than 3 years ago | (#34259282)

Actually Bazaar and Mercurial do work with the much simpler feel of RCS in that there is no real effort needed to set things up. It can be refreshing to not have to mess around with repository configuration for simple projects.

Re:My god, it's full of troll. (-1)

Anonymous Coward | more than 3 years ago | (#34258014)

This Taco Bell programming article is the biggest pile of shit I've ever read.

Re:My god, it's full of troll. (4, Interesting)

mikestew (1483105) | more than 3 years ago | (#34258630)

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.

Arcane CVS and what not (2, Insightful)

discord5 (798235) | more than 3 years ago | (#34257008)

There are teams out there developing iPad software and checking in code inside arcane CVS repositories

But does it work for them? If so, great! Why switch to something else if you have no real need for all those features?

Re:Arcane CVS and what not (4, Insightful)

glwtta (532858) | more than 3 years ago | (#34258490)

But does it work for them? If so, great! Why switch to something else if you have no real need for all those features?

It's not just about features, CVS is deeply broken (tagging/branching, directories, binary files, metadata, etc). Subversion is a drop-in replacement that fixes (most) of the problems and can be used in exactly the same workflow. The two are equivalent and one is less broken - it's kind of a no-brainer.

I do live on the edge. ;-) (-1, Offtopic)

commodore64_love (1445365) | more than 3 years ago | (#34257034)

supposed to be using the latest in tech and see themselves as living on the edge of software innovation.

I do. I live on the tail edge:

~500 megahertz K6 laptop w/ ~192K RAM
-single core P4 desktop w/ 512K RAM
-750k DSL and 50k dialup
-Word 97
-WinXP
-frequent use of floppies
-no HDTV television w/ old-fashioned antenna
;-)

Re:I do live on the edge. ;-) (1, Funny)

Anonymous Coward | more than 3 years ago | (#34257082)

~500 megahertz K6 laptop w/ ~192K RAM
-single core P4 desktop w/ 512K RAM

I bow before your leet minimalist systems!

Re:I do live on the edge. ;-) (1)

Arancaytar (966377) | more than 3 years ago | (#34257688)

Are you able to use any software written in the last decade? Modern desktop applications seems to soak memory like water.

Re:I do live on the edge. ;-) (1)

rocket22 (1131179) | more than 3 years ago | (#34257874)

You're so right!!

Re:I do live on the edge. ;-) (1)

JackCroww (733340) | more than 3 years ago | (#34257782)

supposed to be using the latest in tech and see themselves as living on the edge of software innovation.

I do. I live on the tail edge:

~500 megahertz K6 laptop w/ ~192K RAM -single core P4 desktop w/ 512K RAM

192K? 512K? Kilobyte? You sure about that? Not Megabyte?

Re:I do live on the edge. ;-) (1)

Compaqt (1758360) | more than 3 years ago | (#34257888)

Brings back memories of (barely) running the first version of Visual C++ on a 386SX.

Re:I do live on the edge. ;-) (1)

commodore64_love (1445365) | more than 3 years ago | (#34258364)

Ooops...
~500 megahertz K6 laptop w/ ~192[M] RAM
-single core P4 desktop w/ 512[M] RAM

You can tell you're old when you remember when 512K was considered a lot of memory. "I got a Commodore Amiga 500. I could do BASIC or C programming for an entire month and still not fill-up all the space! Wow." ----- Now we have computers with 1000 times that amount and they won't run Win7 or OS X out-of-the-box.

Re:I do live on the edge. ;-) (0, Redundant)

rthille (8526) | more than 3 years ago | (#34258922)

Ha, my _server_ is a 250MHz MIPS box (Cobalt RaQ2) with 256MB RAM. Pretty sure your systems have MB of ram, not KB of RAM...

SCCS? (1, Informative)

Anonymous Coward | more than 3 years ago | (#34257050)

SCCS predates RCS. Why isn't it on the list?

Re:SCCS? (1)

doug (926) | more than 3 years ago | (#34259000)

SCCS is a decade older than anything else on this chart. Perhaps it was left off to avoid stretching it out too much.

- doug

Meh. (2, Insightful)

HeckRuler (1369601) | more than 3 years ago | (#34257078)

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.

Re:Meh. (1)

chipschap (1444407) | more than 3 years ago | (#34258034)

I still use RCS because it does what I need, which is merely tracking single-developer projects and single-writer authoring. It works, it's simple, so what more do I need. And syncing an RCS directory from desktop to laptop with an online sync tool is more than good enough. I should set up GIT repositories *why*? No thanks.

Re:Meh. (2, Interesting)

Short Circuit (52384) | more than 3 years ago | (#34258050)

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.

pardon, your ignorance is showing (0, Troll)

rubycodez (864176) | more than 3 years ago | (#34257088)

Distributed version control systems are only useful for certain types of projects, e.g. a Linux kernel, and useless for others e.g. a three-person development team making an rpc-xml insurance claim submitter.

Re:pardon, your ignorance is showing (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34257802)

It's extremely useful even for a single developer.
You can still use DVCS systems as if they were centralized, without any inconvenience.
I'm not even going to bother to list them myself, as wikipedia does a fine job already.
http://en.wikipedia.org/wiki/Distributed_revision_control [wikipedia.org]

Every single project I've worked that didn't use DVCS, I missed it alot. DVCS is how it should be done, and CVCS is inherently flawed.

However, I also think the article sucked.

Re:pardon, your ignorance is showing (1)

Cyberax (705495) | more than 3 years ago | (#34257966)

Nope. Distributed systems are ALWAYS more useful than centralized ones for source code control.

Only sometimes their advantages are not that significant.

Re:pardon, your ignorance is showing (1)

rocket22 (1131179) | more than 3 years ago | (#34258232)

I do agree, and sometimes is not even about being distributed, is because the older systems suck in terms of branching and merging.

Re:pardon, your ignorance is showing (1)

rubycodez (864176) | more than 3 years ago | (#34258604)

even stinky ol' subversion does branch and merge well enough for small project with a few devs.

Re:pardon, your ignorance is showing (1)

rubycodez (864176) | more than 3 years ago | (#34258552)

bullshit, the three developers I gave (real) example always must work inside company on local network. name one advantage of distributed system for them

Re:pardon, your ignorance is showing (2)

icebraining (1313345) | more than 3 years ago | (#34258806)

Central machine with repo is down - nobody works.
They can commit locally many times and merge that to a single commit per feature before ushing to the central system.
Git uses much less space than SVN - Mozilla's repo size: CVS - 3GB, SVN - 12GB, Git - 300MB.

Re:pardon, your ignorance is showing (1)

chthon (580889) | more than 3 years ago | (#34258936)

Feature branches and isolation of production and development code : branch a repository and work on it in isolation, then merge it later back in the mainline. I use it for myself in that way. There are things that sometimes need to be done fast, while in parallel I also need to be able to implement larger changes.

I work with git within a company (1)

Chirs (87576) | more than 3 years ago | (#34259136)

A distributed system is handy because you don't need to be net-connected to do work, so you can take it on your laptop and work on it while on the plane, bus, etc. without worrying about a net connection.

You can pass half-done changes to your coworkers for evaluation without checking them in to the central server.

If doing any work with the linux kernel, git is the most efficient tool to use simply because everyone else is using it.

And of course you can still have a central server to act as the "official" repository. It's just that you can also bypass it when desired.

Re:pardon, your ignorance is showing (3, Insightful)

icebraining (1313345) | more than 3 years ago | (#34258518)

DVCS can use the exact same workflow as non-distributed VCS, and they're faster in many cases - including not having to connect to a central server for each and every commit.
If it costs you to change now, don't, but if you're starting a new project, I see no reason to choose CVS.

Re:pardon, your ignorance is showing (2, Insightful)

mikestew (1483105) | more than 3 years ago | (#34258764)

I'm mostly a single person team, and I find DCVS quite useful (the reasons I won't bore anyone with). For my workflow, centralized (SVN in my case) was limiting me.

a DVCS can be used like a centralized one (1)

Chirs (87576) | more than 3 years ago | (#34259022)

You can always use a DVCS like a centralized one. The opposite is not true.

Welcome to hell (2, Informative)

Transfinite (1684592) | more than 3 years ago | (#34257124)

We use TFS here. Because some suit that shouldn't have been making the decisions he did, who was also probably wined and dined by some MS suit. Was told it was the best thing since sliced bread. Every developer to a man hates it. It sucks. god knows how much this 'privilege' costs us.

Re:Welcome to hell (1)

Simon (S2) (600188) | more than 3 years ago | (#34257656)

Our .NET devs like it. I prefer the more simple trac+svn (I do small Java projects with my team).
Why do you hate TFS?

Re:Welcome to hell (1)

Compaqt (1758360) | more than 3 years ago | (#34257932)

How's trac installation these days?

Re:Welcome to hell (2, Interesting)

ocularsinister (774024) | more than 3 years ago | (#34258672)

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.

Re:Welcome to hell (1)

rocket22 (1131179) | more than 3 years ago | (#34257820)

TFS is a a corporate beast. Good for managers only. You know, give a try to Git, or Mercurial, or Plastic.

Re:Welcome to hell (1)

Tridus (79566) | more than 3 years ago | (#34258240)

TFS is actually tossed in with every MSDN subscription now. So if you're in a shop that pays for MSDN, then going to TFS didn't cost you anything in terms of the software. For small .net shops, its actually pretty convenient since you also get issue tracking, test tracking, and a bunch of other stuff tossed in at the same time.

I had Codice pitch PlasticSCM to me once. It was interesting, but for what we were doing there was nothing in there that particularly mattered and thus the price couldn't be justified. I think that's the problem with a chart like this, you've got things he's bashing that for certain workloads are actually perfectly adequate.

(Amusingly a few months later I had the same guy who had pitched Plastic email me again saying he was now with a new company due to the relative immaturity of Plastic as a product. Ah, salesmen.)

Re:Welcome to hell (1)

mikestew (1483105) | more than 3 years ago | (#34258958)

God's not the only one that knows, I was responsible for pricing it last place I was at. First, it's old-school enterprise pricing as I could barely figure out how much it would be for our shop, let alone yours. Figure about $500US for client license, $3K for the server.

It's actually pretty damned good for bug and project tracking, and keeping it all tied together. If your manager's any good, just forget status reporting as it can all be pulled from TFS.

But in the context of source control, TFS sucks ass. Slow, branching sucks, and the workspaces paradigm is mostly a poor implementation of what branching should have been, IMO.

Throw away old tools. Good idea. (-1)

Anonymous Coward | more than 3 years ago | (#34257128)

Lets start with the wheel. Who needs that anyway.

Joel on software had a great article about throwing away old code and how well that worked out for netscape. It didn't work out, btw.

Online applications (1)

falldeaf (968657) | more than 3 years ago | (#34257142)

Speaking of modern CVS repositories, one thing I haven't seen is version-ing for web based applications and sites. The one I use is a custom job built by our corporate office and it works very well but it's missing a lot of features. Every once in a while I google for any projects like this and haven't had anything turn up. Anyone know of any?

Re:Online applications (1)

19thNervousBreakdown (768619) | more than 3 years ago | (#34257194)

What special needs does a website have for versioning that isn't covered by the usual tools?

Re:Online applications (1)

falldeaf (968657) | more than 3 years ago | (#34257500)

I guess not a whole lot, honestly... but our custom job keeps a development, staging and production version of our code, each that has it's own versioning and is sort of like it's own site, but doesn't have all the nice stuff from a full cvs like diffs and patching. I think that this functionality could probably be done with some bash or perl scripts to move the files around for you. I did see though that sparkfun.com used subversion and is now using git for their sites code base, so maybe your question has answered mine...

Re:Online applications (1)

icebraining (1313345) | more than 3 years ago | (#34258402)

You can just have different branches, and then use git push to update the production branch on the server's repository.

Re:Online applications (1)

falldeaf (968657) | more than 3 years ago | (#34258744)

Interesting, that makes sense, I think I may try setting up a theoretical system like that. Thank you for your advice, good sir.

Re:Online applications (1)

nschubach (922175) | more than 3 years ago | (#34258820)

Ah, I've been dealing with this extensively recently.

Web development is sometimes not done locally as application development. Without a file synchronization utility you practically have to work on the dev server if you want to see your changes immediately (edit file, save, refresh page.) There is a plugin for Eclipse that that will sync files on save, but it's a one way copy and if anything changes on the server (from another team member) your file sync will copy your version of that file up overwriting their changes. Needless to say, this irritates some people.

We are currently "given" Serena PVCS to use because "we have licenses for that already" and the Eclipse plugin stores all change information in the same folders as the source code (on the development server.) Most other versioning solutions I've seen do as well. As you can guess, this tremendously slows down development because Serena goes out and updates the status of all the files on the remote server and with a ~1000 page site it takes literally 30-45 minutes just to start Eclipse using the plugin.

There are no (that I have found) version management solutions that store versioning information locally and synchronize that versioning information transparently among the team. DVCS systems would require that the "main" trunk be on the dev server and literally every file edit would have to be merged from your local VCS to the trunk and that just doesn't work.

We literally use our VM as an "every so often" check in and cannot use the IDE tools because of the "version information in the same location as source" model that VCS programs use.

Re:Online applications (1)

VortexCortex (1117377) | more than 3 years ago | (#34258542)

I'm not sure what you mean by "version-ing for web based applications and sites"

I have SSH access to my web host.
The web app code resides in a remote Git repo on the server.

This is how I update my web based application.

git checkout remote-master
git merge local-changes
git push

Re:Online applications (1)

falldeaf (968657) | more than 3 years ago | (#34258710)

No that makes sense, but for our major site there's three different versions of basically the same code base as a development, staging and production. But icebraining pointed out to me that I could keep three different branches. I've never been at the top level planning stage for large projects so I've never thought out and set up a cvs system for a project. I've only ever been a user. To be clear I don't have say so over the major site that I work on anyway I'd just like to understand the process I guess. I'm working on a web-app project now that I would like to put into a version-ing system. It might just be delusions of grandeur making me think there will be other developers later on, though :)

Hey! (1)

vrmlguy (120854) | more than 3 years ago | (#34257150)

I'm stuck using SCCS [wikipedia.org] , you insensitive clod!

Re:Hey! (2, Funny)

blair1q (305137) | more than 3 years ago | (#34258022)

Stuck? You're probably the least stressed of us all. Using sccs is the code-control equivalent of moving to Napa and buying a vineyard.

CVS May be Old, but... (0, Troll)

Anonymous Coward | more than 3 years ago | (#34257164)

"If it ain't broken, don't fix it."

Re:CVS May be Old, but... (4, Insightful)

JerkBoB (7130) | more than 3 years ago | (#34258388)

"If it ain't broken, don't fix it."

Right. And CVS is horribly broken. So it's been fixed. :P

Re:CVS May be Old, but... (0)

Anonymous Coward | more than 3 years ago | (#34258746)

It is broken. I'd like to rename files and directories, and track those changes. With CVS? Good luck..

TMA's for me (1)

digitaldc (879047) | more than 3 years ago | (#34257184)

Too Many Acronyms

Like Hudson? (1)

Wolvenhaven (1521217) | more than 3 years ago | (#34257208)

If it's anything like Hudson's graphical build timeline, it's a cool feature that made me go "neat" but I have honestly never used it to look stuff up on our CI server.

Source control is so political (4, Insightful)

MobyDisk (75490) | more than 3 years ago | (#34257260)

All of "big" companies I've worked for use ancient out-of-date source control. The first one used VSS (late 90's, so it wasn't so unusual at the time) but then around 2000 moved to PVCS. All the developers assumed that someone got kickbacks because there's no reason to move to an older, more expensive, inferior product. Now I work at a Fortune 500 company that also uses PVCS. Their reason: not a soul in the building has ever used anything else. I explain about the features of modern source control and people look at with with either marvel (it can do that!!??), or disdain (how dare you question my source control system).

I don't know why this one piece of software evokes such illogical responses. Oh well.

Re:Source control is so political (1)

blair1q (305137) | more than 3 years ago | (#34258002)

Because this one piece of software is ingrained in the company's quality process. With most tools, if you use something different, nobody cares, they're just glad you're getting your work done. With CM, you have to use the same tool everyone does. When you start proposing to change that tool, everyone has a stake in it, and an opinion of it, and of your opinions.

And this is mild. Can you imagine if everyone had to use the same editor [wikipedia.org] ?

Re:Source control is so political (0)

Anonymous Coward | more than 3 years ago | (#34258416)

I actually enjoyed PVCS the one place I used it. The idea of not needing branches and the promotion system were a change, but worked well if the process in place made proper use of them.

Also, someone mentioned this already, but saying PVCS is bad because the initial release was decades ago is like saying Linux is bad because it's initial release was 20 years ago. Older, maintained software tends to be better than equivalent new software since they've had decades to get the bugs out of it.

Re:Source control is so political (1)

rocket22 (1131179) | more than 3 years ago | (#34259042)

Is like when you explain merging and then people start saying: "hey, but I can't trust a program merging code for me". God!

Re:Source control is so political (2, Informative)

MobyDisk (75490) | more than 3 years ago | (#34259078)

P.S.
- One company used their own internal source control. That was by far the worst.
- All the small companies and contracts used either perforce or svn.

Just pointing this out since I meant to contrast the relationship between company size and tools.

Advertising disguised as history lesson. (4, Interesting)

fahrbot-bot (874524) | more than 3 years ago | (#34257438)

First, the history/time-line is simply a lead-up to the plasticscm product.

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.

Re:Advertising disguised as history lesson. (1)

rocket22 (1131179) | more than 3 years ago | (#34257514)

Hey, wasn't Linus Torvalds himself who said "you must be brain dead to use CVS"?? Don't shoot the messenger!

Small companies need to be creative, share information, tell stories... I guess that's the goal of the post. If the Plastic SCM guys were Microsoft they would be on slashdot everyday, don't you think?

Re:Advertising disguised as history lesson. (0)

Anonymous Coward | more than 3 years ago | (#34257882)

If the Plastic SCM guys were Microsoft they would be on slashdot everyday, don't you think?

And if cows were angry bulls milking them would be quite hazardous.

Re:Advertising disguised as history lesson. (1)

rocket22 (1131179) | more than 3 years ago | (#34257970)

XD. I can't beat that!!

Re:Advertising disguised as history lesson. (3, Insightful)

fahrbot-bot (874524) | more than 3 years ago | (#34258176)

Hey, wasn't Linus Torvalds himself who said "you must be brain dead to use CVS"?? Don't shoot the messenger!

Linus is not a god and not everything he says should be taken as gospel. He gets a LOT of things wrong. Put down the cool-aid. :-)

Hey, I'm successful and independently wealthy too, and I like CVS. Quote that! :-) Now, I admit that I haven't extensively used most of the tools in the "article", but I haven't needed what they offer above and beyond CVS.

As for the cell-phone analogy in the "article", I still use a Qualcomm QCP-1900 cell-phone from 1998 and, surprise, it still manages to work great as a phone. Paid $200 for it outright (no contract), which works out to $16 a year and still have a $15/month no-contract account. I only need it to make phone calls. Sometimes, it pays to stick with what you have and what works...

Re:Advertising disguised as history lesson. (2, Insightful)

david_thornley (598059) | more than 3 years ago | (#34258354)

Linus Torvalds sometimes shoots his mouth off for no good reason, and he tends to look at everything in terms of how it would work for the Linux kernel.

The fact is that CVS would be bad for the Linux kernel development process, which really does need a distributed VCS. You can kinda sorta make something like that work on CVS, but you'd wind up with a nightmare, and if you wanted to spend the time to write everything you'd need to make it work you might as well write something like Git instead.

CVS is perfectly usable as a centralized system, despite its deficiencies, and it's no more arcane than Subversion.

Re:Advertising disguised as history lesson. (1)

rocket22 (1131179) | more than 3 years ago | (#34258536)

CVS is more arcane than SVN. It locks the whole thing every time you create a branch or a tag (label). It doesn't have merge tracking, no atomic commits, no good branching... well, yes, it's an outdated beast and a nightmare to use unless the team is so lazy they prefer to stay with it.

Re:Advertising disguised as history lesson. (1)

icebraining (1313345) | more than 3 years ago | (#34258466)

But git is faster [contextual...opment.com] , so there are reasons to use it even if you don't need the new features.

Re:Advertising disguised as history lesson. (2, Insightful)

fahrbot-bot (874524) | more than 3 years ago | (#34258738)

But git is faster, ...

Yes, given the example on your link, if I ever need to checkout the *entire* FreeBSD repository, I'll think of GIT. Otherwise, I'm not losing much sleep over the speed difference. :-)

From a practical standpoint, people will use what their employer is already using. Here, we mainly use CVS. There are pockets of SVN and (perhaps) GIT, but no one is interested in converting and, more importantly, retraining the users and rewriting the management/utility scripts.

Another example, I also currently use SCCS to revision system data files on a Solaris project because it comes with the OS out of the box -- cannot install something else -- and it works just fine.

Bottom line: If I ever need to use something else, I'll learn it, but here and casually at home, I already know RCS/CVS and they work just fine.

Re:Advertising disguised as history lesson. (1)

icebraining (1313345) | more than 3 years ago | (#34258906)

You can use a Git client with a CVS or SVN server.

Re:Advertising disguised as history lesson. (1)

EvanED (569694) | more than 3 years ago | (#34258870)

Contrary to later comments in the article, I've used, and still use, CVS in several commercial products and it works just fine.

One of us is probably a basket case then. I whine about most programs I use, but a program is in rare company if I complain about it as much as CVS.

I hate it enough that if I was considering starting to contribute to an open source project and the project I was considering used CVS, that alone would be enough for me to drop that idea.

slightly one sided... (1)

haute_sauce (745863) | more than 3 years ago | (#34257470)

also leaves out SCCS (a precursor to RCS), as well as layered tools/integration of tools ONTO the SCM (like eclipse -> SVN, etc.)

the article was a good intro to the history of SCM, however i am amazed they didnt just do a box, and put their tool in the upper right hand corner...

Re:slightly one sided... (1)

rocket22 (1131179) | more than 3 years ago | (#34257676)

Yes, should have done that: highlight their tool instead telling so many good things about Git, don't you think?

at the office (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34257564)

best office prank ever http://www.youtube.com/watch?v=ATBr_b-6ZKI [youtube.com]

RCS... (-1, Troll)

flyingfsck (986395) | more than 3 years ago | (#34257878)

Bah, I still use RCS for single person projects and for versioning the configuration files in /etc. It is perfect for that.

Subversion branching and merging (4, Interesting)

19thNervousBreakdown (768619) | more than 3 years ago | (#34257904)

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.

Re:Subversion branching and merging (0)

Anonymous Coward | more than 3 years ago | (#34258562)

Merging in git is simply git merge , in SVN it's something complicated requiring you too know the revision when you branched and other stuff, something like 'svn merge -r a:b ../../trunk' from inside the branch.

Re:Subversion branching and merging (2, Interesting)

c++0xFF (1758032) | more than 3 years ago | (#34259340)

Read the post you're replying to! That's all changed since 1.5. Now SVN knows when you branched and what you've already merged together.

Read about it here [red-bean.com] .

For most branching, the command would be a simple 'svn merge http://svn.example.com/repos/calc/trunk [example.com] ' from within the branch. The most complicated part is specifying the location of the branch to merge from (trunk in this case).

1.5 did wonders for SVN.

Re:Subversion branching and merging (1)

MobyDisk (75490) | more than 3 years ago | (#34259182)

Am I missing something, or is this all based on pre-1.5, when it didn't have merge tracking?

AC replies with:

in SVN it's something complicated requiring you too know the revision when you branched and other stuff, something like 'svn merge -r a:b ../../trunk' from inside the branch.

19NervousBreakdown: I think the AC just proved exactly what you were saying. Everyone thinks it is hard because it was hard pre-1.5.

Re:Subversion branching and merging (5, Interesting)

EvanED (569694) | more than 3 years ago | (#34259188)

It's possible I'm missing some shortcut syntax or something, but just the Subversion syntax for creating a branch and merging is just terrible. Compare git checkout -b my-new-branch to either remembering the whole repository URL or running svn info and copying and pasting it, then running svn copy some://really.long/url/to/your/repository/trunk some://really.long/url/to/your/repository/branches/my-new-branch then svn switch some://really.long/url/to/your/repository/branches/my-new-branch. And merging is similar.

You can avoid this syntax by checking out the whole damn repository and using working-copy paths, but this has its own set of severe drawbacks (e.g. now your svn copy takes a long time).

These drawbacks are made smaller by Tortoise (which is awesome) since you can just edit the existing URL in the switch dialog, but it's still pretty darn ugly.

I like Subversion, probably just because I know it, and use it for my home projects, but if there was an actual benefit ... I'd love to switch to something better

I'd really encourage you to give Git a shot. Pick a project and use it for that project. It takes some getting used to, but it's not too bad, and once you are used to it it provides a number of really nice benefits even if you're just a single person working on your own projects. And there is a TortoiseGit that works well. (Just be aware that TortoiseGit attempts to hide what Git calls the index. This makes it act more like TortoiseSvn from your standpoint, but I did run into a problem once that was caused by mixing use of TortoiseGit and the command line git client in one repository.)

(From my own standpoint, I've heavily used all of CVS, Svn, and Git. I hate CVS with a passion, and for a long time thought that the improvements you get from moving from CVS to Svn were enormous in comparison to moving from Svn to Git. I still think this is true, but as I've used Git more and more, I think the Svn to Git change brought about rather more benefits than I initially considered even for single-person and centralized projects.)

Re:Subversion branching and merging (2)

dsuarezv (1189437) | more than 3 years ago | (#34259318)

It becomes really ugly when you start refactoring code. Renamed and moved files are killer to merge. Even in 1.6, I'm afraid...

Wait, this isn't a git tool? (1)

Zigurd (3528) | more than 3 years ago | (#34258312)

I was hoping for a visual timeline of distributed git repos, or something that would make using git easier. Git is likely a better way to do version control, but it is better because it is fundamentally different. Those differences have not worked their way into Eclipse's abstraction of version control far enough, yet.

Show me an actual distributed RCS. (0, Troll)

BitZtream (692029) | more than 3 years ago | (#34258348)

What? You really can't? You mean EVERY SINGLE ONE of what you want to call a Distributed RCS actually depends on something centralized to make it useful to anyone?

Seriously, you guys need to get over the 'dstributed' bullshit and start realizing that anarchy and decentralization is not actually the solution to ever problem on the planet.

There has to be some point for software to go to start looking for 'distributed' copies.

So many people rant about which RCS to use, and 99% of you don't even know how to fully exploit even the most basic of RCS systems to their advantages.

Re:Show me an actual distributed RCS. (1)

CompMD (522020) | more than 3 years ago | (#34258722)

Mod parent up.

Have you ever tried to administer a central hg or git code repository accessed by a couple thousand developers and maintain access controls on it, like you would in a corporate environment? I have, its a complete pain.

The distributed nature of a tool like git is nice in that you don't have locking and its easy to get all the code you need. However, its worthless to a company unless that can be managed, and you realistically need something like Gerrit (git code review, access control system) or github:fi (costs a metric crapload to help Scott Chacon buy a fleet of Ferraris).

Revision control gets far too much attention. (1)

Brannon (221550) | more than 3 years ago | (#34258410)

What matters is the total build and regression story, which encompasses configuration management and revision control--that topic gets far too little attention.

Re:Revision control gets far too much attention. (2, Interesting)

VortexCortex (1117377) | more than 3 years ago | (#34258826)

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.

FIRST (-1, Redundant)

Anonymous Coward | more than 3 years ago | (#34258860)

I won't bore you *BSD but FrreBSD Consider worthwhile fly...3on't fear

They forgot CMVC... (0)

Anonymous Coward | more than 3 years ago | (#34258914)

I'm not sure that I would blame them...

c08 (-1, Redundant)

Anonymous Coward | more than 3 years ago | (#34258978)

tops res4onsibility Have somebody just

Meh, I'm *still* happy with plain RCS. (1)

DdJ (10790) | more than 3 years ago | (#34259056)

For personal projects, I've mostly been happy running RCS on my own server. I use CVS from time to time, and bits of it annoy me, but I can get work done with it.

Maybe for huge open source projects with teams all over the planet who can't communicate very tightly and who don't have a unified SDLC, some of these newer tools are worthwhile. But if you've got a small team and an adequate process, what's the compelling argument for switching to one of them if what you've got in place is working fine?

How could he miss SCCS? (0)

Anonymous Coward | more than 3 years ago | (#34259226)

I cut my source-control eye-teeth writing versioning scripts for sccs based systems.

Horses for Courses (2, Insightful)

dubious_1 (170533) | more than 3 years ago | (#34259254)

The author appears to believe that old version control systems are bad because they are old.
I have used ( and administered ) projects using RCS, CVS, SVN, Perforce, Clearcase, Git and VSS.
RCS - Advantage: no setup necessary. I used RCS to track changes to my 140 page thesis ( latex ) during the year of writing. I can still take that tar archive and extract to any workstation, PC ( windows, mac or linux) and have full access to the revision history. No setup, dirt simple. ( of course since RCS was never designed to handle more than a single person modifying the file at a time, concepts like branching, merging etc, don't exist, but for simple single person projects, this is far better than nothing ( and vastly better than manually archiving copies when you remember to)
CVS - Advantage: Supports multiple users, branching and merging (same server, DCVS variant provides some concept of distributed but should be avoided). Relatively easy to setup, and when restricted to ssh only access can be relatively secure. Disadvantage: no distributed support, very coarse security ( if you have access to the server and repository directory you have access, multiple projects on same server are clumsy to secure).
SVN - better than CVS, but harder to setup ( less obvious ?). Distributed support (sort of), but no concept of locking checkouts, so not suitable for code that is not easily merged ( VHDL and Verilog can get ugly when you try to merge what appear to be trivial changes ).
(CVS and SVN are pretty well supported via integration with many IDEs out of the box).
Clearcase - Great big bag of hurt. Avoid this if at all possible. Advantage: Large companies ( Govm't contractors ) use this tool. Ratio of administrators to users 1:10 typically, so expensive manpower. Provides distrubuted (ish) support using Multi-Site. License costs very high. Security is laughable. Any user with network access to the server ports, and an installed licensed client (access to license server) and the ability to assume root on a unix/linux machine can perform any administrative level operations of the files. The client reported username and group membership are trusted by the server to determine access privilege.
Perforce - Despite the authors grouping, P4 provides very good distributed support for controlled development projects. Using proxy servers remote access to files is pretty fast. The only tool listed so far that supports atomic checkins. If any file in the set you are submitting fails to checkin, the whole checkin fails. This may sound like a bad thing if you have never had to fix a problem where one file didn't get checked in, breaking the build. Security (access to parts of the repository) is controlled within the tool, so a fine level of granularity can be achieved. Account management can be done directly in perforce by the admin ( passwords stored locally ), or can be setup to use ldap/kerberos/Active Directory for added trust.
VSS - Small bag of hurt. Small bag because it worked so poorly that we never used it for large projects. Nothing good to say about this, just say no.
Git - I haven't used this enough to know if I like it or not. Having the repository replicated at each remote leaf (user) is nice for the distributed development, but for projects requiring close control of the source code this can be nightmarish. Since every remote site has a copy of the whole history, fixing the problem when Johnny accidentally checks in code from projectX that contractually cannot be shared with projectY can suck.

I use both svn and git (1)

vrillusions (794844) | more than 3 years ago | (#34259356)

We purely use subversion at work (after years of trying to convince them, prior to this all work was done on live server, by multiple devs at once). I've switched to git for most personal projects. Of all the benefits and downsides of git vs svn, I just feel more comfortable in a distributed VCS workflow. My home directory is still subversion though. Seems to address the problem better for wanting to keep my different home directories in sync. Don't want to login to a server and go "oh crap, I forgot to push my changes from other computer".

I've tried converting work to git but it just isn't going to happen. I just snicker when something happens in subversion that I know git can do easier.

(rant)To revert changes in subversion you do a non-intuitive reverse merge? With git it's... git revert. Anytime someone needs to revert a commit in subversion they ask me and I always have to look up the syntax because it doesn't make sense(/rant)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>