8 ms·

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

by ken 7y ago

emodendroket 7y ago
When I started developing the options people were taking seriously were Mercurial and git. At first I was using mercurial, but since everyone else was using git I switched to that. So those are the only ones I've seriously used.
EdSchouten 7y ago
I don't think there are many people that considered CVS good enough, even back in the days. For example, there was no way for end-users to retain the history of a file when renaming/copying it. When the FreeBSD project still used CVS, committers always had to file tickets against the admins to ask them to do it server-side through a so-called 'repocopy': https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080
jerf 7y ago
Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all. There were several times there were builds that were completely unreproducible because it turned out that they were, technically, r83726, except this directory was r84713, but this other directory was r78372 except for a subdirectory that was r84299, etc. That problem I saw even before I saw a replacement. But once I saw git, having a full copy of the repo was pretty killer. It was also better at merging, partially for having the history local. In fact I recall some SVN people protesting at the time that merging wasn't so hard, but in a nutshell, they were just wrong. It was harder. Source control that can't merge fluidly is pretty limited from the get-go. There's literally entire dimensions of things we do with git that were so impractical with SVN that only the very largest projects could afford to do them, with the whole "workflow" question. Now you don't even hear about the difficulties of merging since all the open source SCMs copied each other and "good merging" is just table stakes now. The problem is is that git doesn't really have fatal flaws, it has annoyances, and that's not the same thing. "The UI is difficult" is an annoyance for its target audience. Most every other criticism I've seen of it is an annoyance, not a fatal flaw. Fossil doesn't solve a problem I have with git. It has some neat ideas and arguably does solve some problems, but it doesn't solve the problems I have with git; you could lift Fossil's solutions to wiki and bugtracking and just put them in Git and I'd probably be happier with that than Fossil itself. The problem isn't that Fossil is an SCM competing with git; the problem is that Fossil is a monolith competing with the rapidly-moving git ecosystem. The former is perhaps beatable, the latter is a juggernaut. All of Fossil's other features sitting in git is something that might get somewhere, but if the base source control isn't git-based, I can't sneak it into a work project to try it out. I've got a corporate mandate that all source belongs somewhere standard, and it's a perfectly sensible requirement for someone paying me to do a job.
- _ZeD_ 7y ago
  >>> [SVN] made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. that is a feature! You don't know how I miss that! (that, and the handling of blobs)
  - shakna 7y ago
    Git still let's you check out particular directories at particular commits. It's just a specialised usecase rather than the default. git --work-tree=/path/to/outputdir checkout HEAD -- subdirname
  - jerf 7y ago
    I would check, double-check, and triple check whatever use case you miss that for. It is a serious misfeature, and I find any workflow that critically depends on it to be very likely a process smell. Handling of blobs I can at least see preferring the differences, though git-lfs mostly acceptably shims that for me. The need to use git-lfs is definitely an annoyance, but it's another place where it's probably not a fatal flaw. Or, to the extent that it arguably is, it would be when you're using git as something that it really, really isn't... it's a source code management tool. It's a good enough source code management tool that it's useful for many other things as well, like the way some people directly drive their personal websites with it. But it isn't a tool for managing lots of large files that can't be textually diffed, not a generic "content" management tool. I wouldn't expect git to necessarily store terabytes of video files, but then, it's not like Fossil is going to do that either from the sounds of it. git-lfs shims content blobs well enough to make it just an annoyance for source code management.
  - dev_north_east 7y ago
    > that is a feature! You don't know how I miss that! Yep, handiest way to perform a first pass on narrowing down an introduced bug between a few commits.
    - jerf 7y ago
      Have you used "git bisect"?
sys_64738 7y ago
These fell by the way side as they never had consensus of being better than SCCS. Now git has the weight of the Linux kernel behind it which pretty much EOL'd all other source control mechanisms.
- rhabarba 7y ago
  That's like saying Windows has pretty much EOL'd every non-Windows desktop. Citation needed.
- vnorilo 7y ago
  There was a certain hub that had a role in git's rise. Kernel pedigree may lend it credibility but I doubt it's the driving factor.
- theamk 7y ago
  I don’t think Linux kernel matters that much - only a tiny fraction of the total number of developers use it. From what I saw, it was git vs hg - which had different philosophies. Hg gave you nice, polished workflow for supported tasks. Git gave you building parts that you can make your own system from. It turned out that enough programmers wanted to build from parts.
rumanator 7y ago
> But did you think that RCS, CVS, or SVN were also good enough? SVN required a centralized server and didn't even supported branching, so no.
- rileymat2 7y ago
  I actually prefer SVN and HG style branches where you keep the branch history as a known formal branch, then have one merge back to Trunk. It is unclear to me how far back you are saying SVN did not have branching.
  - adrianmsmith 7y ago
    I don't remember a time when Subversion didn't support branches. I'm sure Subversion 1.0 supported branches (although I can't find evidence of that right now, but I also can't find any release notes for Subversion 1.n containing "now we support branches!") One can argue about what a branch is, for sure. Subversion branches, Mercurial branches and Git branches all have very different implementations. But the main workflow of creating a feature branch, developing a feature, then merging it back into the trunk/master, has, as far as I know, always been supported in Subversion.
    - rumanator 7y ago
      > I don't remember a time when Subversion didn't support branches. SVN's official response to branching and tagging was to copy directories around in the repository. Arguably that means it does not support branching, at least according to the concept that has been in place for the last decade.
      - adrianmsmith 7y ago
        That's true that there was no command "svn branch", there was only the command "svn copy". It's true that command could have been better named, like many Git commands could have been better named. However, don't let that confuse you. The "svn copy" command creates a new place where you can do independent development, and where afterwards merging back can occur. So it's the same as a branch by that definition. An "svn copy" is a lightweight copy, with a reference back to the place the copy was made from. - "svn merge" does its merge by looking at what commits have been made at the original location (since the copy), and the commits to the copy. - "git merge" does its merge by looking at what commits have been made on the original branch (since the new branch was created) and the commits on the new branch. So "svn merge" and "git merge" act in the same manner. (Of course there are differences in the algorithm, but I wish to refute the point that Subversion "does not support branching [at all]".) And if you never use "svn merge" or "git merge", then a branch is just a copy, in either system.
int_19h 7y ago
One big thing that DVCS brought to the table were local serverless repos. Now you could version all the things, with very little effort, and promote it to a "proper" repo later. The other big thing was free cloud hosting for the repos. Neither of these are unique to Git, obviously, or even introduced by it. It just happened to be the right combination of features and speed at the right time to become the winner of the popularity contest. Kinda like C. And, just as C is still around, for all its numerous horrible quirks, Git will likely be around for a long time as well.

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

by ken 7y ago

But did you think that RCS, CVS, or SVN were also good enough? Or is this new?

When I started developing the options people were taking seriously were Mercurial and git. At first I was using mercurial, but since everyone else was using git I switched to that. So those are the only ones I've seriously used.

EdSchouten 7y ago

I don't think there are many people that considered CVS good enough, even back in the days. For example, there was no way for end-users to retain the history of a file when renaming/copying it. When the FreeBSD project still used CVS, committers always had to file tickets against the admins to ask them to do it server-side through a so-called 'repocopy': https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=106080

jerf 7y ago

Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all. There were several times there were builds that were completely unreproducible because it turned out that they were, technically, r83726, except this directory was r84713, but this other directory was r78372 except for a subdirectory that was r84299, etc. That problem I saw even before I saw a replacement. But once I saw git, having a full copy of the repo was pretty killer. It was also better at merging, partially for having the history local. In fact I recall some SVN people protesting at the time that merging wasn't so hard, but in a nutshell, they were just wrong. It was harder. Source control that can't merge fluidly is pretty limited from the get-go. There's literally entire dimensions of things we do with git that were so impractical with SVN that only the very largest projects could afford to do them, with the whole "workflow" question. Now you don't even hear about the difficulties of merging since all the open source SCMs copied each other and "good merging" is just table stakes now. The problem is is that git doesn't really have fatal flaws, it has annoyances, and that's not the same thing. "The UI is difficult" is an annoyance for its target audience. Most every other criticism I've seen of it is an annoyance, not a fatal flaw. Fossil doesn't solve a problem I have with git. It has some neat ideas and arguably does solve some problems, but it doesn't solve the problems I have with git; you could lift Fossil's solutions to wiki and bugtracking and just put them in Git and I'd probably be happier with that than Fossil itself. The problem isn't that Fossil is an SCM competing with git; the problem is that Fossil is a monolith competing with the rapidly-moving git ecosystem. The former is perhaps beatable, the latter is a juggernaut. All of Fossil's other features sitting in git is something that might get somewhere, but if the base source control isn't git-based, I can't sneak it into a work project to try it out. I've got a corporate mandate that all source belongs somewhere standard, and it's a perfectly sensible requirement for someone paying me to do a job.

_ZeD_ 7y ago
>>> [SVN] made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. that is a feature! You don't know how I miss that! (that, and the handling of blobs)
- shakna 7y ago
  Git still let's you check out particular directories at particular commits. It's just a specialised usecase rather than the default. git --work-tree=/path/to/outputdir checkout HEAD -- subdirname
- jerf 7y ago
  I would check, double-check, and triple check whatever use case you miss that for. It is a serious misfeature, and I find any workflow that critically depends on it to be very likely a process smell. Handling of blobs I can at least see preferring the differences, though git-lfs mostly acceptably shims that for me. The need to use git-lfs is definitely an annoyance, but it's another place where it's probably not a fatal flaw. Or, to the extent that it arguably is, it would be when you're using git as something that it really, really isn't... it's a source code management tool. It's a good enough source code management tool that it's useful for many other things as well, like the way some people directly drive their personal websites with it. But it isn't a tool for managing lots of large files that can't be textually diffed, not a generic "content" management tool. I wouldn't expect git to necessarily store terabytes of video files, but then, it's not like Fossil is going to do that either from the sounds of it. git-lfs shims content blobs well enough to make it just an annoyance for source code management.
- dev_north_east 7y ago
  > that is a feature! You don't know how I miss that! Yep, handiest way to perform a first pass on narrowing down an introduced bug between a few commits.
  - jerf 7y ago
    Have you used "git bisect"?

sys_64738 7y ago

These fell by the way side as they never had consensus of being better than SCCS. Now git has the weight of the Linux kernel behind it which pretty much EOL'd all other source control mechanisms.

rhabarba 7y ago
That's like saying Windows has pretty much EOL'd every non-Windows desktop. Citation needed.
vnorilo 7y ago
There was a certain hub that had a role in git's rise. Kernel pedigree may lend it credibility but I doubt it's the driving factor.
theamk 7y ago
I don’t think Linux kernel matters that much - only a tiny fraction of the total number of developers use it. From what I saw, it was git vs hg - which had different philosophies. Hg gave you nice, polished workflow for supported tasks. Git gave you building parts that you can make your own system from. It turned out that enough programmers wanted to build from parts.

rumanator 7y ago

> But did you think that RCS, CVS, or SVN were also good enough? SVN required a centralized server and didn't even supported branching, so no.

rileymat2 7y ago
I actually prefer SVN and HG style branches where you keep the branch history as a known formal branch, then have one merge back to Trunk. It is unclear to me how far back you are saying SVN did not have branching.
- adrianmsmith 7y ago
  I don't remember a time when Subversion didn't support branches. I'm sure Subversion 1.0 supported branches (although I can't find evidence of that right now, but I also can't find any release notes for Subversion 1.n containing "now we support branches!") One can argue about what a branch is, for sure. Subversion branches, Mercurial branches and Git branches all have very different implementations. But the main workflow of creating a feature branch, developing a feature, then merging it back into the trunk/master, has, as far as I know, always been supported in Subversion.
  - rumanator 7y ago
    > I don't remember a time when Subversion didn't support branches. SVN's official response to branching and tagging was to copy directories around in the repository. Arguably that means it does not support branching, at least according to the concept that has been in place for the last decade.
    - adrianmsmith 7y ago
      That's true that there was no command "svn branch", there was only the command "svn copy". It's true that command could have been better named, like many Git commands could have been better named. However, don't let that confuse you. The "svn copy" command creates a new place where you can do independent development, and where afterwards merging back can occur. So it's the same as a branch by that definition. An "svn copy" is a lightweight copy, with a reference back to the place the copy was made from. - "svn merge" does its merge by looking at what commits have been made at the original location (since the copy), and the commits to the copy. - "git merge" does its merge by looking at what commits have been made on the original branch (since the new branch was created) and the commits on the new branch. So "svn merge" and "git merge" act in the same manner. (Of course there are differences in the algorithm, but I wish to refute the point that Subversion "does not support branching [at all]".) And if you never use "svn merge" or "git merge", then a branch is just a copy, in either system.

int_19h 7y ago

One big thing that DVCS brought to the table were local serverless repos. Now you could version all the things, with very little effort, and promote it to a "proper" repo later. The other big thing was free cloud hosting for the repos. Neither of these are unique to Git, obviously, or even introduced by it. It just happened to be the right combination of features and speed at the right time to become the winner of the popularity contest. Kinda like C. And, just as C is still around, for all its numerous horrible quirks, Git will likely be around for a long time as well.