6 ms·
CVS was awful, but it was so much better than RCS, which operated only on single files. There was a time in the late 90s when CVS + Bugzilla + Tinderbox was the
by jdblair 8y ago
CVS was awful, but it was so much better than RCS, which operated only on single files. There was a time in the late 90s when CVS + Bugzilla + Tinderbox was the state of the art of CI if your toolset was all open source. I used this combination at multiple workplaces 1998-2002. It worked and we shipped, but we didn't really understand how bad the tools were.
At Sun all stuff was in Teamware, except when it wasn't, because every group at Sun could do whatever they wanted to (we used SVN in the x86 ILOM team). Teamware was good but suffered by being a wrapper on top of SCCS.
SVN was a revelation after CVS. I resisted switching to git from SVN for a long time because the mental model for SVN is so much simpler: everything is in one central place, every change is marked with a monotonically increasing version number, remember a number and you can always reproduce the state of the project. Eventually I saw the huge benefit of the "git workflow" (local branches, pull requests) for collaboration. Branches in SVN are error prone and always risked painful conflict resolution, so we made them rarely.
Perforce, which is commercial, was like stepping into another dimension (you mean all this stuff just works? Out of the box?). There's another historical timeline where Perforce has an early open-source model (like Redhat) and is the dominant VCS.
I enjoyed that remembrance of 20 years working on free-software based projects, not a bad way to start Sunday. I hope it was worth your time!
- oblio 8y agoI still don’t like the Perforce model of workspaces or whatever they call it (clients?). That mapping between the server folders and your local ones. Extra complexity for no obvious benefit I could see.
- solipsism 8y agoThe complexity is completely optional. Your client map can just map the entire depot to a single directory. And it has always been very easy to enforce this at the organizational level, with a small script in the server.
- vvanders 8y agoFor the right use case workspaces are awesome. We used to do code + art in the same 1TB perforce repo back when I did gamedev. Art folder was ~600GB. Having a workspace to eliminate that as a developer was awesome. Git still fails to even approach the usefulness that P4 brought to those types of shops. Between the auto-cache proxies, dealing with 1TB+ repos and workspaces there's a reason P4 still does pretty well.
- oblio 8y agoI won't reply to all the comments saying mostly the same thing, but Git doesn't have this, true. SVN, another centralized system, does have it. Shallow checkouts plus folder checkouts and you can have any combo you want. Without adding another concept to take care of. Much simpler conceptually, in my opinion.
- pjc50 8y agoIt allows you to check out small bits of a really large repo.
- a-dub 8y agoIt was great for large projects. I worked on a project that was similar to Android. Imagine 10 device trees (device drivers), two OS trees (Linux, vxWorks), and two application trees (the old stuff, the new stuff). You could define a mapping that got you just the trees you needed, which both sped up builds and VC operations (although p4's local indexing made most VC operations lightning fast). Imagine a world where 'svn up' or 'cvs up' takes 20 minutes. Not only did the client mappings limit the scope of the operations, but local indexing brought the time for those operations down to 0-4 seconds.
- cousin_it 8y agoYeah, the mapping was a wart. Piper+CitC is much nicer, it's a file system that pretends you have the whole tree locally, while actually storing only the stuff you changed.
- st26 8y agoRule of thumb, one man's useless version control feature is another man's saving grace. I've never needed to open multiple changelists simultaneously in one work area, but I'm sure someone loves that feature.
- gkya 8y agoI use RCS for version controlling single in a bunch of places. Using Emacs' VC mode makes it mostly invisible to me.
- nradov 8y agoWhy are branches in SVN error prone? We branch constantly and haven't had any serious problems.
- jdblair 8y agoI think my memory of pain is during merging. We settled on a fairly simple, conventional system: mainline new dev, branches for each release, and occasional personal branches for experimentation. This meant we rarely merged other than fixes to sustaining branches.
- MereInterest 8y agoThe branching isn't the problem, but the merging is. My experience is that it depends on how closely the team is working together. If everybody is working on separate files, then SVN can merge together on a file-level. If people are working on the same files, then every such file requires manual merging. Since git works on a line-by-line basis, merging is much easier. It still requires a human to look through the resulting merge for logical consistency, but it gets a lot closer on the first try.
- nradov 8y agoWe have multiple people working on the same files and use Eclipse to do line-by-line merges automatically (except when there are actually conflicts). It works fine. So I still haven't seen any real evidence of error prone merges.
- yitchelle 8y agoIf someone can come up with an error free merging for all situations, it would be the "killer app" for configuration management. I would especially look forward to merging for XML files as well.
- cpeterso 8y agoDo any source control systems have filetype-aware merge algorithms? We can do something smarter when merging XML than textual line diffs.