[Adium-devl] Version control

[Augie Fackler]

On Oct 8, 2007, at 11:27 AM, Colin Barrett wrote:

> 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.

This isn't immaturity here - this is an absolute inability to use the  
tool. This summer I spent *a whole day* trying to get mtn working -  
Andy finally told me to not bother, that he could get me anything I  
need. I've never managed to get Monotone to work. I think you vastly  
underestimate the number of nightly testers we'll lose by moving to  
Monotone.

>
>> 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.

Branching is and always has been trivial in Subversion. Bad-practice  
merges are doing bidirectional cherrypicking (in 1.4) when you will  
have to eventually merge the branches together.

>
>> 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.

I'm not convinced of this.

>
>> 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.

That's not it - I don't like git because of their design decisions  
(it was an alphabet soup of languages and tools). As they mature, I'm  
considering reevaluating that position.

>
>> 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.

I fail to see how that's a problem - why would you ever *want* to  
share the build directory?

> 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.

To each his own - I found their system very workable for short-term  
feature branches, and I just use a clone for a long-term feature  
branches, which isn't a bad thing anyway because then I don't  
accidentally cross-contaminate my work.

> 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.

Cherry picking from a feature branch is a bad practice (just merge  
the feature back when you're done). Cherry picking from trunk is bad  
as well - just merge all of trunk out to the branch.

Thing is, with Mercurial (or git) I think we'd be able to (in the  
reasonably near future) be able to use either tool, and that'd be a  
real win to my mind.

Of course, I think that subversion is preferable anyway. It's simple,  
comes as part of Leopard (according to all the reliable rumormills,  
anyway), and tons of people actually use it.


> 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

I think usability by contributors is important to consider here - if  
it's hard to use, a lot of people will shrug and walk away instead of  
offering a contribution, and that sucks.

>
>
> -Colin

Augie