Workflows, validate, and rebase
marlowsd at gmail.com
Fri Aug 26 11:41:24 CEST 2011
On 25/08/2011 20:19, David Terei wrote:
> So the rebase work flow advises the following steps:
> 1. fetch patches from ghc-working into ghc-validate: ./sync-all fetch working
> 2. merge from working: ./sync-all merge working
> 3. rebase onto master: ./sync-all pull --rebase
> 4. validate, push
> If I try this I get an error on the second step where ./sync-all
> complains it doesn't know the 'merge' command. Also, what are we
> gaining by doing both step 1 and step 2 when you could just do
> './sync-all pull working'? pull is equivalent to fetch + merge
> Otherwise I like it. Its basically how I work but showed me a few
> ./sync-all tips I didn't know and is a nice easy read. I wonder if I'm
> the only one who still uses separate build trees though these days.
> Not sure if they are buying me much so might drop them myself.
Simon and I use separate build trees all the time, mainly because we
want to keep our source trees on the backed-up NFS drive and build trees
on fast local disk. Also I can use the same source tree to make builds
on different machines (I often have both a 32-bit and a 64-bit build of
my working tree).
I know I could easily have separate source trees and make sure my local
changes were backed up and shared using git (or just rsync), but it's
just one less thing to worry about this way.
More information about the Cvs-ghc