[Adium-devl] SoC Merging

[Juan Manuel Palacios]

On Aug 24, 2007, at 11:59 AM, Augie Fackler wrote:

> Hey all,
>
> In light of the recent "pencils down" for SoC, I'd like to figure out
> a schedule for when to do merges. I'd like to merge bonjour first, as
> I think it'll have the fewest conflicts and be the easiest to get
> running.


	For the sole reason of being the easiest, I'd say bonjour should be  
last to merge in once the more conflicting branches have been brought  
down to stable land within trunk. But probably doing one over the  
other wont have any sizable effects over other merges if branches are  
really orthogonal enough, it's just my particular approach to do the  
easiest last and get the hardest over with ASAP. My 2 cents.

	Other than that:

>
> After that, I'm not sure who should merge next. If I don't hear any
> other recommendations, I'm thinking the order will be multi-user
> chat, snapping groups, and then applescript. My fear is that the
> other branches might introduce changes that applescript needs to
> handle, so I'd like to deal with that before merging it to trunk.
>
> FYI, here's the procedure to merge a branch back to trunk:
> 1) Merge all changes made on trunk since the last mergepoint to the
> branch
> 2) Resolve any conflicts (can be done interactively if you build svn
> 1.5, a huge time saver)
> 3) Commit, bringing the in-repo branch up to trunk
> 4) Merge from the branch to trunk
> 5) Resolve conflicts
> 6) commit, bringing all of the branch changes onto trunk in the repo
>
> Note that before both commit steps you should make sure the project
> builds and the app runs.


	Commit freezes should be declared on trunk while students test  
merges to their branches and commit them (still on branch, so that  
they don't have to resync them over and over) and also while they  
test merging their branches to trunk (cleaning wc and trial testing  
the resulting adium app) and commit the end result. Conflicts are  
very likely to occur given the huge code delta between trunk and the  
branches, so resolution will likely not be an easy task for anyone...  
I'm sure many things will fly through the air in hatred if a student  
sees some changes being committed to trunk *just* after he finished  
cleaning his wc but *just* before committing it (sounds like I can  
relate...? ;-) Lather, rinse, repeat is not a very pleasing approach  
for such tedious tasks.

	In my opinion, individual merge schedules should be posted,  
discussed, agreed upon and respected for merges to be as clean and  
quick as possible, and commit freezes except for the up-to-the-plate  
student should be imposed for the duration of the current merge.  
These are comments from a dude how's had to handle practically every  
single release branch in the MacPorts project, among other repo admin  
duties.

	Other than that, the plan sounds fine ;-) Regards,...


-jmpp



> If anyone wants my patch for svn that
> launches FileMerge on merge conflicts, let me know. It requires svn
> trunk, and it saves a *ton* of time for doing merges like this.
>
> Any objections to me running a merge of bonjour tomorrow? I have 5
> hours in a computer lab that I can't do much of anything...
>
> Peace,
> Augie
>
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com