On 9/20/2012 8:27 AM, Stefan Sperling wrote:
There are different projects that fulfill different needs, and we
should strive to keep them alive for as long as they serve a useful
purpose to their users. Users should freely be able choose between
tools and benefit from improvements made to each tool.

In the grand scheme of things, the development of git is entirely
orthogonal to the development of Subversion. They're different tools
made for different requirements.

I would like to get a specific list of cases where this is true. It is true that if you have a large, old, mixed revision repository that is on Subversion now, you will want to keep your Subversion. What are the other cases where you will prefer Subversion? Can we brainstorm that? I'd like to have a list of these use cases so that I can make good recommendations.

I frequently see people choosing between git and subversion, and/or migrating, usually to git. By this measure, the use cases are not orthogonal. I argue that people choose subversion for good reasons. It's simpler (and so works for more contributors, including designers) and it handles big files and big repositories - much bigger than git. However, code files are surprisingly small, so for developers working with code, who want to use modern workflows that require merging into integration and production versions, the problems with svn merge are often a deciding factor.

I am struggling to see the specific use case for Subgit, where developers use the git view and the svn view at the same time. You are going to get better results from your development workflow if all of your developers use one recommended repository format. There is a argument for "cloning" subversion subdirectories (bits of a bigger repository) as git repositories for individuals. Can we do that with Subgit? My friends at Accurev and Perforce have both added git clone of subdirectories to their products. The argument is that developers like to use git locally and offline, but repository owners like to have their assets in one repository that is too big for git. This approach fits the mixed-revision-subtree case that is supported in Subversion, since it clones and revises subtrees.

At Assembla, we are interested in workflows to support continuous delivery, like this: http://blog.assembla.com/assemblablog/tabid/12618/bid/87901/Continuous-Delivery-and-Scalable-Agile-Find-Out-the-Secret.aspx . Most people (as we did) adopt git when they move to continuous delivery. This places limits on their contributor set (because git is complicated) and repository size, and it does mean that they have to migrate from their subversion repositories.

So, we've been building a code review and merge system that will work with Subversion 1.8 . There is some question about whether we have made enough progress in Subversion merge to make it competitive for development teams that are considering workflows that require merging. One solution is to limit the cases where we apply merge, so that we increase the success rate. For example, in the Assembla system, we will only branch and merge at the top level. We have been making temporary branches for each task, merging them, and removing them. This short-lived approach avoids some problems. Maybe with symmetric merge, we will be able to succeed with a longer branch lifetime that is closer to the way that most people use svn branches now.

Julian's work is a BIG improvement in usability. However, it doesn't make many adjustments to the underlying algorithms. I know that Stefan is working on fixing problems that happen when we move files. However, I was warned that this will be a slow process.

I started some proposals for more fundamental changes, but these proposals were rejected. To review: 1) Eliminate mixed revision subtrees. This was rejected because, apparently, there are a lot of big repositories out there with mixed revision directories, and this is a core use case. Maybe it is THE core use case. That makes things complicated. 2) Track actual merge history, rather than the integer "mergeinfo". It seems silly not to have a full history, as people working on merge would find it very useful. However, this would probably require change (1), so that each branch has one merge history. 3) Fix the problems that occur after moves. Git uses a heuristic to find moved files by pattern matching. The Subversion team has committed to fixing move problems, realizing that a large percentage of merge and update complaints come from moves. However, they have decided to take a more precise and difficult path than the simple pattern match. It's worth noting that Linus solved most git merge problems in about six months, with approximate heuristics, where the Subversion team has worked on the same problems for 6 years with less progress. Is precision worth the effort?

I agree that it would be useful to have a kickstarter project and some substantial bounty money available for the next set of fixes to either merge or move. I'm in.

I would like to be able to make a workflow recommendation that makes subversion relevant for a fast growing class of development projects.

--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton

Reply via email to