3 ms·

This article is idiotic and is clearly written by someone who doesn't understand Subversion. You work on feature branches, then merge them into trunk. Only at

by csmuk 13y ago

This article is idiotic and is clearly written by someone who doesn't understand Subversion. You work on feature branches, then merge them into trunk. Only at the point of that merge are you sharing changes with everyone. But at any time, everyone can see your private branch, centrally. Committing infrequently is a problem with not using branches properly. I commit to an SVN repository up to 50 times a day without forcing my code on anyone. Merges aren't any scarier than they are in Hg/Git either despite common belief. All VCS problems are usually external to the VCS i.e. human or process issues. Edit: I just noticed the author is pushing a Git client. need we say any more.

shawabawa3 13y ago
I haven't used SVN in about 2 years, but when I was using it I remember branching taking about 10minutes. It had to redownload the entire working directory again I believe, which made it essentially pointless - I only branched when I was going to be doing a huge amount of work. Have they fixed that?
- mikeash 13y ago
  I think you must have been doing it wrong, because I don't think this has ever been the case. In any event, it's plenty fast now: the branch is a "copy" operation on the server (which takes no time since Subversion does everything as copy-on-write) followed by re-pointing your local copy. Since there are no changes, it fetches no new data.
- csmuk 13y ago
  Creating a branch is instant (well < 5 seconds). Switching branches depends on how much change there is between the previous branch and the one you are switching to. It basically sends all the files that have changed. On our solution which is about 120,000 files, it takes about 10-25 seconds on HTTPS/WebDAV protocol. It's fast enough. I switch probably 2-3 times a day. You can check each branch out separately if you want but this isn't necessary and probably is the cause of the pain you had.
voidr 13y ago
> This article is idiotic and is clearly written by someone who doesn't understand Subversion. Or maybe you don't understand what the article is about. > You work on feature branches, then merge them into trunk. Only at the point of that merge are you sharing changes with everyone. > Merges aren't any scarier than they are in Hg/Git either despite common belief. This is the theory, but in practice I haven't seen SVN people doing it, I once worked for a company that had SVN and told the people that we should do feature branches, and the lead developer instantly rejected it, because it is too hard to merge. So either 99% of the people don't know how SVN works or branching is simply too damn hard in SVN. > Merges aren't any scarier than they are in Hg/Git either despite common belief. > All VCS problems are usually external to the VCS i.e. human or process issues. A lot of major projects switched to git from SVN, so either the are all "idiots" or they had a real issue with it. Even if all VCSes are equal as you say, the fact that people lack the mental capacity to comprehend the greatness of Subversion makes it inferior to Git.

by csmuk 13y ago

shawabawa3 13y ago

I haven't used SVN in about 2 years, but when I was using it I remember branching taking about 10minutes. It had to redownload the entire working directory again I believe, which made it essentially pointless - I only branched when I was going to be doing a huge amount of work. Have they fixed that?

mikeash 13y ago
I think you must have been doing it wrong, because I don't think this has ever been the case. In any event, it's plenty fast now: the branch is a "copy" operation on the server (which takes no time since Subversion does everything as copy-on-write) followed by re-pointing your local copy. Since there are no changes, it fetches no new data.
csmuk 13y ago
Creating a branch is instant (well < 5 seconds). Switching branches depends on how much change there is between the previous branch and the one you are switching to. It basically sends all the files that have changed. On our solution which is about 120,000 files, it takes about 10-25 seconds on HTTPS/WebDAV protocol. It's fast enough. I switch probably 2-3 times a day. You can check each branch out separately if you want but this isn't necessary and probably is the cause of the pain you had.

voidr 13y ago

> This article is idiotic and is clearly written by someone who doesn't understand Subversion. Or maybe you don't understand what the article is about. > You work on feature branches, then merge them into trunk. Only at the point of that merge are you sharing changes with everyone. > Merges aren't any scarier than they are in Hg/Git either despite common belief. This is the theory, but in practice I haven't seen SVN people doing it, I once worked for a company that had SVN and told the people that we should do feature branches, and the lead developer instantly rejected it, because it is too hard to merge. So either 99% of the people don't know how SVN works or branching is simply too damn hard in SVN. > Merges aren't any scarier than they are in Hg/Git either despite common belief. > All VCS problems are usually external to the VCS i.e. human or process issues. A lot of major projects switched to git from SVN, so either the are all "idiots" or they had a real issue with it. Even if all VCSes are equal as you say, the fact that people lack the mental capacity to comprehend the greatness of Subversion makes it inferior to Git.