[Adium-devl] Version control

[Colin Barrett]

On Oct 8, 2007, at 7:12 AM, Augie Fackler wrote:

> Ok, so I read through this thread, and this is a quick-and-dirty meta-
> reply.
>
> 1) Subversion is *really* mature at this point.
> 2) We like having contributors - I know for a fact a lot of newbies
> will be scared off by monotone. Heck, if we go that route I'll
> probably give up on working on Adium because I can't figure the
> stupid thing out. It hasn't ever done anything but segfault for me.

Affine transforms are scary if you know the math behind them.  But you  
use them all the time in graphics programming. I don't think anyone  
who is a nightly tester is going to be scared away by mtn. As long as  
you teach them how to cargo cult getting an updated source, they'll be  
fine.

"I'll just stop working on it if you switch." Seriously, man. Grow up.

> 3) Merging in Subversion will Not Suck in 1.5 - there's finally merge
> tracking, and we'll be able to do whatever bad-practice merges we
> want without screwing ourselves. Ideally, when 1.5 hits we should
> just upgrade right away.

It's not just about merging, as I said. It's about easy branching too.  
"bad-practice merges"? You also make it sound like we'll have to  
manually do three way merges? That sounds like Suck.

> 4) Initial checkout size: when you pull down a working copy for svn,
> you need to get O(number of current files) data. When you pull a DVCS
> repo for the first time, you pull down O(number of changes) amount of
> data - when I created a mercurial import of *just* trunk, it was a
> few hundred megs.

I really wish one of them had support for doing a shallow checkout,  
but this seems to be just one of the prices you pay. I think the  
benefit is worth it.

> 5) git-svn: Most of you probably know how much I detest git and its
> design, but if you really want DVCS features against a Subversion
> server, you can do it with git-svn. I'd really like to see this
> investigated before we decide to jump ship to a DVCS tool that will
> be more confusing.

I think you don't like Git because Linus is a jerk. Don't take it  
personally.

> If we were to go DVCS, I'd prefer Mercurial - it seems to be the most
> sane of the ones I've tried. My second choice would be git, because
> there will soon be ways to use git and Mercurial with each other (now
> that libgit is around from SoC).

Mercurial is annoying for a number of reasons:

1) It encourages you to create many fresh, on-disk clones. This is  
annoying, because your build directory does not move along with you.  
There is an extensions that solves this, but it is extremely new, and  
I'm not sure I trust it quite yet.
2)  It encourages you to create clones by having shitty branches. A  
branch is just a property on a revision. When you merge two branches,  
one dies, and you have to revive it with -f (force). It's well suited  
for two divergent branches that don't have repeated merges, or that  
you just do cherry picks from.
3) Cherry picking sucks. hg transplant does not inform the diff  
algorithm that it should look for a copied revision and create a  
pseudo ancestor revision and start from there. It goes back to the  
last explicit merge and generates false conflicts.

that said, there is mq (which is like stgit) that a lot of people seem  
to like. I used quilt (ancestor of both stgit and mq) once before and  
loved it. However, I don't see the point of using a DVCS and that.  
Just use quilt if you want that model...


Someone, maybe me, should to test imports of our repository into each  
competing VCS and measure:

a) imports without problems
b) speed of import
c) size of resultant checkout


-Colin