[Adium-devl] Version control

[Augie Fackler]

On Oct 8, 2007, at 11:17 PM, Colin Barrett wrote:

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

Fair enough, but our builds are really honestly short.

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

If you're using DVCS, you don't want to rebase:
http://changelog.complete.org/posts/586-Rebase-Considered-Harmful.html
Executive summary: you change the history, which *really* hurts  
people pulling from your repository.

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

Cherrypicking to a release branch is acceptable - cherrypicking to a  
feature branch is unacceptable (example: summer of code branches are  
feature branches, 1.1 branch is a release branch. Release branches,  
by nature, will never merge back to trunk). Because of this, I don't  
see that being a huge problem. Then again, SVN 1.5 fixes this, so I'm  
going to push again we wait until we try 1.5 for merging to see what  
is really broken about our use. If offline commits is all we need,  
then I think investigating git-svn and fixing that up makes more  
sense. As far as external contributions, I'll look at getting  
reviewboard working. It's still on my list, but right now I've got  
another project that is blocking on me.

Augie

>
> -Colin