[Buildbot-devel] Discussion on source steps

[Pradeepkumar Gayam]

On Fri, May 20, 2011 at 6:53 PM, Axel Hecht <l10n.moz at googlemail.com> wrote:

> 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 idea is to classify common build scenarios into categories so that they
don't have to specify commands. Most of the devs want to test their new
commits. For that they can simply  says "Hey, pull my new changes and test
them" or "Clean all the ignored files and test my changes". And these modes
will(should) do exactly same thing whatever the VCS is. But, this way we
practically can't implement all the possible scenarios. For that having a
facility to run their own commands will help.

>
> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including 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/20110521/756b393d/attachment.html>