41–50 of 76 posts
Earlier quoted context omitted.
Misses also GOOG's dearly Perforce.
Google 's Perforce?
I think that the GP used the phrase correctly, but not being a native English speaker myself, I'm not entirely sure.
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…
Misses also GOOG's dearly Perforce.
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…
Misses the absolutely massive Clearcase. In 1999, (and earlier, but I ran into in 1999 at Loudcloud) - if you wanted to support multiple branches and allow merging code into them, it was the only tool that made it easy. Had great (windows) client side environment that gave everyone a "view" into the source, But _man_ was the backend ugly.
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.
Earlier quoted context omitted.
Misses also GOOG's dearly Perforce.
There is nothing particularly astonishing about perforce. What makes you think it should have been included?
People often complain about the idea of using version control for large binary files, as if it is unreasonable to want such a thing, and that as a point of principle version control systems should contain only text files, and the fact that many version control systems support this poorly is proof that you don't want it anyway. But there are actually people who create, with their own hands, large binary files, often of the completely-unmergeable variety, and they deserve version control just as much as the programmers do.
(And then once you have a system that works well for them, you can then use it to solve all manner of problems that might previously have involved storing files in public folders, mailing them round, or maybe just waiting for them to compile again. No need for any of that crap any more - just check the files in, they're there forever, and you can get them back quickly.)
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.
Exactly! Try versioning data with ChronicDB:
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.
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.