This post originated from an RSS feed registered with Ruby Buzz
by Jeremy Voorhis.
Original Post: Large merge, tiny automation
Feed Title: JVoorhis
Feed URL: http://feeds.feedburner.com/jvoorhis
Feed Description: JVoorhis is a Rubyist in northeast Ohio. He rambles about Ruby on Rails, development practices, other frameworks such as Django, and on other days he is just full of snark.
At Values of n, we branch our codebase to create a safe environment for experiments or non-trivial changes to Stikkit. After spending a week on the east coast for holidays, I had the cough pleasure of merging over a weeks’ changes into my branch to keep current.
In my first approach, I tried merging everything at once. I ended up catching a multitude of conflicts – some of which made no sense since I was missing a weeks’ worth of context in a fast-paced environment. Clearly that was not the way to go.
My second attempt: divide and conquer. Using our revision history to look up changesets, I merged a day’s worth of changes at a time. Because a small number of issues tend to prevail on any given day, this allowed me to deal wih actual conflicts as they came. Actual, meaningful conflicts as opposed to conflicts in binary files or code I haven’t touched.
For reverting and resolving files I had no interest in, I learned the smallest bit of awk.
This handy one-liner finds all conflicted files from the output of svn status, reverts them, and resolves them, allowing me to proceed. Other awk invocations resolved conflicts for a particular set of files by copying them from another directory and resolving. Familiarity with tools like lex and racc made awk a cinch to learn and more useful than I would have guessed.
Open question: what small-time automation do you rely on to support regular development?
Previous Topic
