4 ms·

I can't say I understand your point. With svn, I commit often, as long as the code builds and my own unit tests pass. If I need to make a lot of breaking chang

by tolenka 17y ago

I can't say I understand your point. With svn, I commit often, as long as the code builds and my own unit tests pass. If I need to make a lot of breaking changes, I use 'svn cp' to create a branch and then I can still leverage svn's merge tracking in keeping that branch up-to-date. This seems like the same way I use git/hg, but without worrying about excessively divergent local/remote branches across machines -- I can see your branches, you can see mine, they're all centrally accessible by definition.

gvb 17y ago
If you own the SVN repository, I agree, it works well enough. However, if you don't have write privileges to the repository or if it is a shared repository with a lot of other people, it becomes much more difficult. If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. Creating and maintaining a tracking repository is a hassle, especially compared to a DVCS where that is the normal operation. If there are a lot of people with write access into your SVN repository, creating branches doesn't scale well because all the branches are public. Creating a SVN branch for every experiment rapidly gets out of hand. Again, you can create a separate tracking SVN repository (hassle) or you can use branches, but it is nowhere near as easy as with DCVSes. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well.
- tolenka 17y ago
  If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. This is fairly unique to open source software -- it's not something that occurs in an organization, and should only occur when a user without commit access is doing large-scale modifications to a project. Unfortunately, the functionality often used to maintain divergent forks where individuals fail to push small hacks/changes immediately back to their origin project. Creating a SVN branch for every experiment rapidly gets out of hand. Out of hand how? I've worked in organizations where every single feature received a developer specific branch (eg, branches/tolenka-feature-xyz) and never ran into trouble. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well. Given merge tracking, merging works more or less the same as a DVCS. As far as scaling across developers, I'm not sure what the issue is.

by tolenka 17y ago

gvb 17y ago

If you own the SVN repository, I agree, it works well enough. However, if you don't have write privileges to the repository or if it is a shared repository with a lot of other people, it becomes much more difficult. If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. Creating and maintaining a tracking repository is a hassle, especially compared to a DVCS where that is the normal operation. If there are a lot of people with write access into your SVN repository, creating branches doesn't scale well because all the branches are public. Creating a SVN branch for every experiment rapidly gets out of hand. Again, you can create a separate tracking SVN repository (hassle) or you can use branches, but it is nowhere near as easy as with DCVSes. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well.

tolenka 17y ago
If you don't have write privileges into the SVN repository, you have no ability to revision control your changes without creating a tracking repository of your own. This is fairly unique to open source software -- it's not something that occurs in an organization, and should only occur when a user without commit access is doing large-scale modifications to a project. Unfortunately, the functionality often used to maintain divergent forks where individuals fail to push small hacks/changes immediately back to their origin project. Creating a SVN branch for every experiment rapidly gets out of hand. Out of hand how? I've worked in organizations where every single feature received a developer specific branch (eg, branches/tolenka-feature-xyz) and never ran into trouble. The big difference with DCVSes is that scaling across lots of developers is not a problem, branches are strongly encouraged, and merging works really well. Given merge tracking, merging works more or less the same as a DVCS. As far as scaling across developers, I'm not sure what the issue is.