[Adium-devl] Version control

[Colin Barrett]

On Oct 8, 2007, at 9:19 AM, Augie Fackler wrote:

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

It was immaturity on my part. I apologize. I'm at the end of my rope  
here on a lot of other stuff, and I took it out on you.

My bad.

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

When a full build takes you 45+ minutes? i.e. when building Firefox?

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

Again, in my usage, cloning is an expensive operation. It bothers me  
that hg's branches die when I merge trunk with them. If I have branch  
a and branch b and default, it's tricky to rebase branch a and b  
against new changes coming in on default.

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

Our current usage pattern involves many cherry picks from trunk to  
branch. I guess to do what we do now we would:

push to adium1.1
merge adium1.1 with adium1.2

What about changes to adium1.1 that aren't applicable to adium1.2  
though? Say we rewrote FooWriter to use red colored text intead of  
green colored text for adium1.2. But there's a critical bug in the 1.1  
version of FooWriter we need to fix. What do we do?

Deal with the conflict by having nothing happen?

-Colin