[Buildbot-devel] Discussion on source steps

[Axel Hecht]

I like the idea to split the options into file-system-based ones and
VC-specific ones.

If people migrate from one VC to the other, they're doing that to change the
process, and I think it's beneficial for people implementing build process
to be able to use the terminology of their VC, instead of using some other
jargon that the docs then need to map to "oh, and this is what git does, and
this is what hg does". Having VC-specific options allows folks to say "do
this", and buildbot would say, "yeah, sure".

The shared code between VCs would still be useful to do things like "verify
that the local repo is talking about the same upstream", and "you're
switching branches, you know how to do that, right"? I can see a benefit in
having common talking points between the master and the slave steps on that
front.

Axel

2011/5/16 Dustin J. Mitchell <dustin at v.igoro.us>

> So I think this gets to the crux of the matter.  There *are* two
> choices to make, although if I may I'd like to adjust their
> presentation slightly.
>
> The first choice, I think should be binary and should be the same for
> every VC.  The second choice should specify behaviors, and thus be
> somewhat VC-specific.
>
> On Mon, May 16, 2011 at 4:30 AM, A.T.Hofkamp <a.t.hofkamp at tue.nl> wrote:
> > Maybe it is my lack of understanding your other modes, but in my view
> there are 2 choices to make.
> > The main one is:
> >
> > 1. Throw away everything each time, or
> > 2. Keep existing directory.
>
> How about
>  1. Build from a pristine directory with no leftovers from previous builds
>  2. Build from an already-used directory with some/all files left intact
>
> Let's refer to 1 as "clean" and 2 as "incremental" (although every
> project seems to have its own names - Mozilla uses "clobber" and
> "objdir")
>
> > In 2, you then have a second choice, namely
> >
> > 2a. Keep all files
> > 2c. Throw away *all* files not in the current revision of the VCS, and
> revert any changed source.
> > (yep, 2b is missing, but it is on purpose, see below.)
>
> Actually, in both cases you have a number of choices in how to
> implement this behavior; those choices differ from VCS to VCS.  For
> example:
>
> 1a. Delete the directory and re-checkout (or re-clone, or whatever)
> 1b. Keep a pristine 'source' directory, delete the build directory,
> copy from source to build, and update
> 1c. Use '$vcs clean' with appropriately harsh (delete it all!) options
>
> These may differ in efficiency in terms of filesystem access speed,
> disk space, and network bandwidth, and as such should be
> user-selectable, but that selection is basically an optimization and
> not part of the high-level clean vs. incremental choice.  Note that by
> this analysis, your 2a falls under "clean", not "incremental"
>
> For incremental, I'm sure there are subtle per-vc behaviors that may
> need to be adjusted.  For example,
>
> 2b. Remove non-ignored files (as Amber suggested is sometimes desirable)
> 2d. if the branch has changed, do $some_other_behavior (e.g., for
> broken svn switches)
>  others?
>
> Dustin
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20110520/c750403d/attachment.html>