[ANN][RFC] plugin package: ezbzr

[Nathaniel McCallum]

On Fri, 2006-01-20 at 19:36 +1100, Martin Pool wrote:
> On 20 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> > On Thu, Jan 19, 2006 at 08:19:27 -0500, Nathaniel McCallum wrote:
> > > Its not scary, its just basically a shortcut for:
> > > $ TEMP=`mktemp`
> > > $ cd $TEMP
> > > $ branch --basis=mybranch sftp://foo//bar
> > > $ cd bar
> > > $ bzr merge mybranch
> > > $ bzr commit "Merged into mainline"
> > 
> > This *IS* damn *MUCH* scary.
> > 
> > > $ bzr push
> > > $ cd $orig_dir
> > > $ rm -rf $TEMP
> > > 
> > > If conflicts occur, the temp directory is left alone and instructions on
> > > how to proceed are printed on the screen.
> > 
> > Semantic conflicts may occur without syntactic ones ever appearing.
> > Especially since the push is likely to be to a public place, it is
> > absolutely necessary to run syntax check, unit test (if available) and
> > that human actually *reads* the diff before it is commited.
> > 
> > Yes, I have already seen such merge that did not declare a conflict, but
> > the result did not compile at all.
> 
> Yes, testing and reviewing the diff after merging is pretty important.
> But I think the basic idea is nice; it's basically what I do when
> merging new work into bzr.dev.
> 
> So if we can make bzr somehow get that test/review phase it'd be good.
> 
> Running a configurable 'make check' after merging would be a good start.
> (Indeed relying on the selftest might encourage people to make it
> solid.)
> 
> I'd also like something that previews a merge - basically jsut the same
> recipe but running bzr diff at the end instead of commit/push.

Shouldn't the 'make check' be run as a pre-commit hook though? (ie. it
doesn't belong in the 'release' code).

Nathaniel