[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".
>

+1 for custom VC commands.

>
> 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/b29f22db/attachment.html>