51–60 of 76 posts
I would say it's missing 7.5, 1996 public anonymous cvs. Before that, you were either one of the developers with a login or you waited until a source tarball was released. Which makes it really hard for outsiders to contribute because they're aiming for a moving target they can't see.
That was one of the major hallmarks, I seem to recall, of OpenBSD - though we all remember it for security right now.
Earlier quoted context omitted.
There is nothing particularly astonishing about perforce. What makes you think it should have been included?
If you ignore all the distributed "stuff", and the workflow enhancements it permits, and assume everybody is always connected to the server and attached via a LAN, you can just concentrate on doing a reasonably good job of handling very large quantities of data, including very large binary files. (Apologies for not trying to reproduce the breathless style of headline.) As is common, the article presupposes that decen…
Ugh, SourceSafe. I worked for a company that used it. They had terrible intermittent file corruption issues. Long story short, we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick, which caused network errors over SMB which led to file corruption. Ugh.
Earlier quoted context omitted.
There is nothing particularly astonishing about perforce. What makes you think it should have been included?
If you ignore all the distributed "stuff", and the workflow enhancements it permits, and assume everybody is always connected to the server and attached via a LAN, you can just concentrate on doing a reasonably good job of handling very large quantities of data, including very large binary files. (Apologies for not trying to reproduce the breathless style of headline.) As is common, the article presupposes that decen…
It is, in the sense that a decentralized VCS is, essentially, a superset of a centralized one.
…
Blobs are certainly still an issue, though orthogonal to distribution (I don't think you intended to imply it was related, but it could be read as if you did).
Earlier quoted context omitted.
If you ignore all the distributed "stuff", and the workflow enhancements it permits, and assume everybody is always connected to the server and attached via a LAN, you can just concentrate on doing a reasonably good job of handling very large quantities of data, including very large binary files. (Apologies for not trying to reproduce the breathless style of headline.) As is common, the article presupposes that decen…
I never had a problem using cvs for what I considered large binaries. Certainly we kept using cvs long after mostly switching to bk because cvs worked better for binaries. Perforce never seemed like a big deal, just cvs with a little more.
As everything, to begin with there was no software.
“At my first job, we had a Source Control department. When you had your code ready to go, you took your floppy disks to the nice ladies in Source Control, they would take your disks, duly update the library, and build the customer-ready product from the officially reposed source.” (Miles Duke)
It makes me wonder, what is next? What new astonishing thing will happen in version control? I think what's needed is an intelligent (as in AI) merge mechanism. Right now, if two people are adding two different features to a set of files, then merging those changes is error-prone and requires a lot of manual work. If this ever gets perfected and automated, it will be a huge milestone.
This should be much simpler once we stop using those silly text files and start storing everything as a proper representation of AST. Then again, at that point we can get rid of the silly text-diff-based systems and just store everything as versioned trees.
It's easy to forget that we are living in a golden age of version control systems. The market is rife with many fairly decent commercial systems and some of the best, state-of-the-art systems are completely free.
cd dir should propose to update it.
save file should commit it and push it in tmp branch.
It is interesting to me that Subversion barely gets a mention. There should be a 7.5 which is along the lines of: cvs was great and all, but we couldn't version our directories, branching and merging was a mess, the wire protocol was hard to use, it had a ton of security holes and the storage format took up too much space. So, Subversion was created as a way to do a better cvs, without thinking about the larger intri…
Earlier quoted context omitted.
It gives very short shrift to commercial source control systems generally. Two (VSS, and SCCS --- the latter part of the original AT&T Unix distributions, on the same closed-source terms) get mentioned in passing, but neither gets treated as a milestone. That would include BitKeeper --- copies were available for a few years at no cost to Linux kernel developers, but only on increasingly restrictive terms, which McVoy…
In terms of historical interest, it's also worth noting why McVoy restricted and eventually withdrew the BitKeeper license: Andrew Tridgell (of Samba and rsync) had begun reverse-engineering the protocol with the eventual intent of implementing a free client. The resulting debacle was fairly ridiculous; Linux chastising Andrew Tridgell, continued flamewars about using a closed-source product. What I find interesting…