[Buildbot-devel] mult-changesource patch

[Hans Lellelid]

Sorry about that; I assumed that the diff that darcs was giving me was a 
unified diff and didn't really bother to read it.  (Can you tell me what 
command I should use to diff this w/ darcs?)

I'll look at your thread; I didn't find it in a quick Google search, but 
that obviously has more to do with how this stuff is being archived than 
anything else.  As for my changes they took all of 20 minutes, so I'm 
sure that the feature you're describing was something more far-reaching 
than this.

Hans

Axel Hecht wrote:
> Hans,
>
> sadly, your patch is basically impossible to read. Add more context,
> and use unified diff?
>
> This is somewhat similar to what I discussed a while back on this list
> (nag, why exchange mails in private about features?), adding a tag
> list to Change. That'd allow a bit more flexibility, not sure if it'd
> be needed. The thread was called "Multiple change sources and
> scheduler issues".
>
> I didn't completely drop the plan to work on that, but focused on
> other stuff while all the repo transitioning is transitioning.
>
> Axel
>
> 2008/10/3 Benoît Allard <benoit at aeteurope.nl>:
>   
>> Hans Lellelid wrote:
>>     
>>> Hi folks,
>>>
>>> After exchanging a couple emails with Dustin yesterday, I put together a
>>> basic patch to add multi changesource support to Buildbot (or more
>>> specifically tracking of change source to scheduler).  I wanted to get
>>> some
>>> feedback on this before I wrap it up and add it to a Trac enhancement
>>> ticket.
>>>
>>> What I did was to add a 'name' attribute to the ChangeSource (so far only
>>> to SVNPoller) and then added a 'sourcename' attribute to the Change object
>>> (so the system can keep track of which source a particular Change came
>>> from) and also an optional 'sourcename' attribute to the Scheduler class
>>> which works like the 'branch' attribute to limit the changes that a
>>> scheduler cares about.
>>>
>>> This all sounds very minor (and was only a handful of lines of code), but
>>> it was really important for us to be able to have a single buildmaster
>>> with
>>> many projects and this seemed to be the easiest path to that solution.
>>>
>>> A few notes:
>>>  - This isn't really "multi-project" as much as multi-changesource and
>>> changesource filtering on schedulers (e.g. there's no change to the web
>>> frontend to track different projects)
>>>  - I did add the source name to the logging messages, meaning that if it's
>>> not specifed you may see something like
>>> "SVNPoller(None:http://your.repo/url) initializing"
>>>  - As mentioned I only added the parameter support to the SVNPoller, but
>>> am
>>> happy to add it to the other change source classes if this patch would be
>>> accepted
>>>
>>> The attached diff is against the Darcs trunk repo.
>>>
>>>       
>> Nice idea, I'm using here a patched buildbot with a similar something tuned
>> for Mercurial. I called my property "repository", but the idea is there.
>> I'll try to get an hand on a proper diff monday. I also have a new Scheduler
>> (RepoScheduler) which schedule only for a list of repositories (via a list
>> of regex), and some support for property expansion.
>>
>> (For the records, unified diff (diff -u) are easier to read and apply)
>>
>> Regards,
>> Benoit
>>
>>