4 ms·

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, b

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.
  - rumanator 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. It was not a naming issue. It was a bona fide lack of support for a basic feature. The manual itself states quite clearly that in SVN land you create a branch by copying around the entire working directory within your repository. SVN's manual is quite clear on how SVN actually tracks the state of a file system, and not the state of a source code tree. By copying the working directory around the repository you're creating new revisions of your file system. That' it. Just because you can diff two directories it does not mean copying a directory around in a file system is a branch. And nor is it a tag.
xorcist 7y ago
Considering CVS had branches, Subversion probably had them from the start or at least some early development version. Very different under the hood though, as you say.

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.
- rumanator 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. It was not a naming issue. It was a bona fide lack of support for a basic feature. The manual itself states quite clearly that in SVN land you create a branch by copying around the entire working directory within your repository. SVN's manual is quite clear on how SVN actually tracks the state of a file system, and not the state of a source code tree. By copying the working directory around the repository you're creating new revisions of your file system. That' it. Just because you can diff two directories it does not mean copying a directory around in a file system is a branch. And nor is it a tag.

xorcist 7y ago

Considering CVS had branches, Subversion probably had them from the start or at least some early development version. Very different under the hood though, as you say.