4 ms·

Subversion Vision and Roadmap (spoiler: no DVCS)

33 points by bokchoi 17y ago

dustingetz 17y ago
more detailed spoiler: Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations. A shorter, business-card-sized motto might be: "Enterprise-class centralized version control for the masses".
- njharman 17y ago
  Yeah, and I'm fine with that. I'm so against the notion that every tool has to have all the feature/act like every other tool. DVCS vs CVCS, vim vs IDE, etc. A variety of tools focused on different strengths is a great thing. A bunch of me-also's is not.
- umjames 17y ago
  All I can say is thank goodness I can use Git with Subversion without anyone being the wiser. Local feature branches are one of the godsends of DVCS.
  - vlisivka 17y ago
    Yeah. But it is hard to send local branch to review to other team members when Subversion is used on the project. We use Savana to add proper branches to Subversion. Tool lacks polishing, but it is helpful. It is simple to use: you can create private branch, sync your private branch with parent branch, and promote your private branch to parent branch ( http://savana.codehaus.org/gettingstarted.html http://savana.codehaus.org/gettingstarted.html ). It is not a git replacement, of course.
Kadin 17y ago
So when is it going to start preserving filesystem modification times? That's only been on the TODO list for what, close to ten years? I'd really like to see that (which has existed in branches) before some sort of massive effort to keep up with the DVCS Joneses.
dasil003 17y ago
Subversion has no future as a DVCS tool. Let's just get that out there. It's fortunate that the developers are smart enough not to go down that road. The big problem with svn is that the simplicity of the underlying model does not translate into robust features on the front-end. The idea of directories as subdirectories and branches and tags is the result of muddled thinking that will make it impossible for svn to ever have reliable merge tracking. Partial checkouts are a useful feature, but they are not worth botching the architecture so as to make it unusable for basic version control needs like history tracking, diffing and merging. The idea of an atomic repository with an identifying hash is so powerful, as exemplified by git and other DVCSes, even for mundane development tasks and workflows, that svn is basically a dead-end. They can't fix the situation without breaking backward compatibility, and they can't break backward compatibility without a huge uproar from existing repo administrators.
- arebop 17y ago
  Could you please elaborate on how the use of hashcodes rather than counting numbers for identification on an atomic repository botches history tracking, diffing, or merging?
  - dasil003 17y ago
    Well the hashcode effectively signs the full repository state, so that you know that if a repo has the same hash code it has the same contents, however that's not the main problem with svn. The main problem is that svn has no notion of a project to attach it's merges or comparisons against. A directory in a repo may be a subdir of the project or it may be a branch. This leads to an explosion of edge cases and legal commands that make no logical sense. As long as everyone follows certain practices (such as not committing changes to two branches at the same time) then a heuristic approach sort of works, but that's hardly the way to design a robust (and ostensibly simple!) system. If you can merge subdirectories in a project, and if you can merge branches which are just an ancestor directory of that, and if a given merge only affects certain subdirectories in a repository, how can anyone expect subversion merge tracking to be viable? Even if they somehow munge it to work in 99.9% of real world cases, think of the complexity and mental overhead of maintaining this solution compared to what a DVCS with clear-thinking primitives can achieve. It's time for the successor to svn in centralized version control systems to be built from scratch. svn itself is hopelessly hamstrung.
Brendon 17y ago
They don't need to go the dvcs route, just get merging working.
- wanderr 17y ago
  I agree. They can keep the centralization, distributedness isn't all that useful for in-house development and leads to problems when people forget to push after committing. The real power of git is super cheap, super easy branching and merging. If that existed in svn, we would never have switched.
prog 17y ago
"Enterprise-class centralized version control for the masses" is the right way to go for svn IMO. With fast reliable networks, if svn implements the said roadmap features then existing organization probably won't need to move to DVCSes. Distributed model works really well with open source. So I suppose svn has chosen its niche. I know I would have been happier using svn over ClearCase so many times.
plq 17y ago
in my opinion, subversion fails to properly support many features it claims to support. when people find that some things do not work as advertised by design, people naturally get pissed. for example, subversion claims to do path-based authorization. we found that it only works when not using repository-wide branches/tags. when one wants to assign different rights to different users on different parts of a project, and also wants to tag the whole project, the policy file needs to be adjusted accordingly for the new branch. so the best way to do it is to hold these parts on separate repositories, which breaks subversion's main selling point over cvs. so one defines svn:externals, which in turn needs to be updated for every branch/tag with revision numbers. and this is a just minor annoyance in the whole stinking pile of mess that is branching/merging in subversion.

33 points by bokchoi 17y ago

more detailed spoiler: Subversion exists to be universally recognized and adopted as an open-source, centralized version control system characterized by its reliability as a safe haven for valuable data; the simplicity of its model and usage; and its ability to support the needs of a wide variety of users and projects, from individuals to large-scale enterprise operations. A shorter, business-card-sized motto might be: "Enterprise-class centralized version control for the masses".

njharman 17y ago
Yeah, and I'm fine with that. I'm so against the notion that every tool has to have all the feature/act like every other tool. DVCS vs CVCS, vim vs IDE, etc. A variety of tools focused on different strengths is a great thing. A bunch of me-also's is not.
umjames 17y ago
All I can say is thank goodness I can use Git with Subversion without anyone being the wiser. Local feature branches are one of the godsends of DVCS.
- vlisivka 17y ago
  Yeah. But it is hard to send local branch to review to other team members when Subversion is used on the project. We use Savana to add proper branches to Subversion. Tool lacks polishing, but it is helpful. It is simple to use: you can create private branch, sync your private branch with parent branch, and promote your private branch to parent branch ( http://savana.codehaus.org/gettingstarted.html http://savana.codehaus.org/gettingstarted.html ). It is not a git replacement, of course.

Kadin 17y ago

So when is it going to start preserving filesystem modification times? That's only been on the TODO list for what, close to ten years? I'd really like to see that (which has existed in branches) before some sort of massive effort to keep up with the DVCS Joneses.

dasil003 17y ago

Subversion has no future as a DVCS tool. Let's just get that out there. It's fortunate that the developers are smart enough not to go down that road. The big problem with svn is that the simplicity of the underlying model does not translate into robust features on the front-end. The idea of directories as subdirectories and branches and tags is the result of muddled thinking that will make it impossible for svn to ever have reliable merge tracking. Partial checkouts are a useful feature, but they are not worth botching the architecture so as to make it unusable for basic version control needs like history tracking, diffing and merging. The idea of an atomic repository with an identifying hash is so powerful, as exemplified by git and other DVCSes, even for mundane development tasks and workflows, that svn is basically a dead-end. They can't fix the situation without breaking backward compatibility, and they can't break backward compatibility without a huge uproar from existing repo administrators.

arebop 17y ago
Could you please elaborate on how the use of hashcodes rather than counting numbers for identification on an atomic repository botches history tracking, diffing, or merging?
- dasil003 17y ago
  Well the hashcode effectively signs the full repository state, so that you know that if a repo has the same hash code it has the same contents, however that's not the main problem with svn. The main problem is that svn has no notion of a project to attach it's merges or comparisons against. A directory in a repo may be a subdir of the project or it may be a branch. This leads to an explosion of edge cases and legal commands that make no logical sense. As long as everyone follows certain practices (such as not committing changes to two branches at the same time) then a heuristic approach sort of works, but that's hardly the way to design a robust (and ostensibly simple!) system. If you can merge subdirectories in a project, and if you can merge branches which are just an ancestor directory of that, and if a given merge only affects certain subdirectories in a repository, how can anyone expect subversion merge tracking to be viable? Even if they somehow munge it to work in 99.9% of real world cases, think of the complexity and mental overhead of maintaining this solution compared to what a DVCS with clear-thinking primitives can achieve. It's time for the successor to svn in centralized version control systems to be built from scratch. svn itself is hopelessly hamstrung.

Brendon 17y ago

They don't need to go the dvcs route, just get merging working.

wanderr 17y ago
I agree. They can keep the centralization, distributedness isn't all that useful for in-house development and leads to problems when people forget to push after committing. The real power of git is super cheap, super easy branching and merging. If that existed in svn, we would never have switched.

prog 17y ago

"Enterprise-class centralized version control for the masses" is the right way to go for svn IMO. With fast reliable networks, if svn implements the said roadmap features then existing organization probably won't need to move to DVCSes. Distributed model works really well with open source. So I suppose svn has chosen its niche. I know I would have been happier using svn over ClearCase so many times.

plq 17y ago

in my opinion, subversion fails to properly support many features it claims to support. when people find that some things do not work as advertised by design, people naturally get pissed. for example, subversion claims to do path-based authorization. we found that it only works when not using repository-wide branches/tags. when one wants to assign different rights to different users on different parts of a project, and also wants to tag the whole project, the policy file needs to be adjusted accordingly for the new branch. so the best way to do it is to hold these parts on separate repositories, which breaks subversion's main selling point over cvs. so one defines svn:externals, which in turn needs to be updated for every branch/tag with revision numbers. and this is a just minor annoyance in the whole stinking pile of mess that is branching/merging in subversion.