Re: ideas for auto-processing patches

On Fri, Jan 05, 2007 at 11:02:32PM -0600, Andrew Dunstan wrote:
> Tom Lane wrote:
> > "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
> >> Jim Nasby wrote:
> >>> More important, I see no reason to tie applying patches to pulling
> >>> from CVS. In fact, I think it's a bad idea: you want to build just
> >>> what's in CVS first, to make sure that it's working, before you start
> >>> testing any patches against it.
> >
> >> Actually, I think a patch would need to be designated against a
> >> particular
> >> branch and timestamp, and the buildfarm member would need to "update" to
> >> that on its temp copy before applying the patch.
> >
> > I think I like Jim's idea better: you want to find out if some other
> > applied patch has broken the patch-under-test, so I cannot see a reason
> > for testing against anything except branch tip.
> >
> > There certainly is value in being able to test against a non-HEAD branch
> > tip, but I don't see the point in testing against a back timestamp.
> >
>
> OK, if the aim is to catch patch bitrot, then you're right, of course.

Actually, I see point in both... I'd think you'd want to know if a patch
worked against the CVS checkout it was written against. But of course
each member would only need to test that once. You'd also want to set
something up to capture the exact timestamp that a repo was checked out
at so that you could submit that info along with your patch (btw, a plus
to subversion is that you'd be able to refer to the exact checkout with
a single version number).

But since setting that up would require non-trivial additional work, I'd
just save it for latter and get testing against the latest HEAD up and
running.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)