Re: [ANN] SubGit 1.0.0 is released

  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