On Thu, Sep 20, 2012 at 09:58:33AM -0400, Andy Singleton wrote:
> 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.
Yes, because git is currently geared towards these requirements
in a much better way than Subversion is. So please, use git for
this and consider using Subversion for other projects which it is
more suitable for. If you really must refactor your project once
a week and move things around, Subversion currently won't automate
much of this process for you.
However, for software projects where the project's directory
structure remains mostly static, Subversion's merge functionality
is perfectly fine. There are many examples of big projects like
this that use Subversion (Subversion itself, FreeBSD, most projects
at the ASF, ...).
> Julian's work is a BIG improvement in usability. However, it
Agreed!
> 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.
It is slow because we're trying to retrofit requirements into the system
which it hasn't been designed for, while keeping everything else working.
> 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.
That's a misleading statement.
The problem has been known for ages, and the project has been working
towards fixing it for a long time now. But we haven't been working on
this single problem for 6 years. It's not like all we ever did for
6 years during Subversion development is trying to fix problem
with moves. There are many other areas of development.
You also have to keep the design issues in mind. Linus was working
with a design that made the problem easy to deal with. We're working
with a design that makes this problem hard to deal with. But we're
stuck with this design, and the design solves a whole host of other
problems that git doesn't solve (some of which you've already pointed
out yourself).
> Is precision worth the effort?
I don't think it's a question of precision, in the sense that that
using heuristics would magically buy us some development time.
It looks like we'll simply be asking the user what to do about
cases where git applies it's non-100% heuristics. That gives us
100% precision if users provide the correct input :)
> 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.
More development resources would definitely be welcome.
> I would like to be able to make a workflow recommendation that makes
> subversion relevant for a fast growing class of development
> projects.
If this recommendation doesn't lead to the desired level of
productivity then it is the wrong recommendation to make.
Subversion will eventually be able to handle this better, but it
will take time to get here. Luckily, there are other tools that
fill these gaps in the meantime.
Received on 2012-09-20 16:33:17 CEST