Google Summer of Code 2012 project for Bazaar

Alexander Belchenko bialix at
Tue Feb 28 07:58:50 UTC 2012

Sorry for top-posting.

I think predefined merge tools is already implemented in bzr 2.4 by 
Gordon Tyler as bzrlib.mergetools and they used in qbzr/explorer.

I agree though there is big room for improvements, especially re diff tools.

Also, IWATA Hidetaka has just landed better support for external diff 
viewers in qbzr, so that's also partially addressed. But, again, of 
course we can do it much better. Often people asked why bzr-explorer 
does not launch diff in their favorite diff viewer.

I see you have already selected your target and goal. That's fine.

Just to add more ideas to the pot:

* Better IDE intergration is very good in long term

* If somebody wants to work on quite challenging and researching project 
for Bazaar Explorer I'd recommend to think about sketching on idea of 
separate processes behind bzr-explorer and qbzr GUIs. For explanation 
see my last year post:

Anyway, any help is better than no help at all.
Thank you.

Andreas Sommer пишет:
> *From:* Martin Packman <martin.packman at>
> *Sent:* 26.02.2012 19:16
> *To:* Andreas Sommer <andreas.sommer87 at>
> *Cc:* bazaar at, Daniel Holbach
> <daniel.holbach at>, Jelmer Vernooij <jelmer at>
> *Subject:* Re: Google Summer of Code 2012 project for Bazaar
>> On 26/02/2012, Andreas Sommer <andreas.sommer87 at> wrote:
>>> I was wondering if there's interest in offering a GSoC project for
>>> Bazaar this year. From my side, I'd be interested to contribute to my
>>> favorite VCS, but to be honest I don't have a precise topic proposal.
>> This sounds like a great idea. I'm not sure if it makes sense for
>> Bazaar to apply as a mentoring organisation (and the deadline for that
>> is only a bit over a week away), but perhaps you propose a project
>> under the Ubuntu banner? Daniel Holbach is coordinating things there,
>> and there's a wiki page we could add bzr+ubuntu project ideas to:
>> <>
> Daniel, I'm describing my project idea in more detail below. Maybe you
> want to have a look?
>>> Bazaar Explorer would be a nice thing to work on as I think it could use
>>> some improvement.
>> There's certainly a lot in bzr-explorer that needs work and it would
>> be a great thing to tackle, my main worry would be how to define a
>> clear project. There would be real long term benefit in code
>> restructuring and automated testing, but that's not the sexiest thing
>> to work on and is harder to set out clear goals and waypoints than
>> working on a new feature of some kind.
> Exactly, I guess for GSoC it's a good idea to have a well-defined
> target, probably with some small milestones along the way.
>>> One idea would be to work a bit more on
>>>, i.e. improving support for
>>> configuring diff/merge tools (and implementing it in the configuration
>>> dialogs of qbzr). I think it would be nice to be able to define diff
>>> tools in a more precise way, such as by file extension or regex. That
>>> way, one could use special tools like the MS Word diffing scripts from
>>> TortoiseSVN for *.doc files, or other tools for comparing non-text files
>>> without having to use "bzr diff --using" via the command line. What do
>>> you think?
>> I think there's the core of a really good idea here. Having several
>> smaller targets, like making the configuration of custom differs and
>> mergers simple, and writing some specific ones for different formats,
>> would probably help the project. We also have some existing mergers
>> such as for Debian changelogs in bzr-builddeb, and the recent .po
>> merge plugin Vincent implemented, that work as specific examples.
>> Avoiding the messy conflicts when using bzr for ubuntu distributed
>> development has been helpful in those cases, and we could get feedback
>> on what other formats cause developers the most pain.
> I'd like to focus on custom diff/merge tools. That would comprise of
> 1) Defining a configuration format in bazaar.conf. Each tool can be
> defined by its executable, arguments, probably type (diff, 2-way merge,
> 3-way merge?), boolean whether it's a graphical or command line program,
> and a friendly name so that later one can use "bzr diff --tool
> some_tool_name" (there must also be a tool "default"). Other than that,
> there will be a configuration that says which files (by extension/regex)
> should be diffed/merged by which tool(s). Maybe the configuration could
> also be made overridable per branch.
> 2) "bzr diff", "bzr merge" and Bazaar Explorer must make use of that
> configuration.
> 3) Try it out with some popular tools. This is a good point for
> integrating with the work of the extmerge plugin.
> 4) Configuration dialog for Bazaar Explorer (qconfig).
> 5) Pre-define popular tools (with their standard installation
> directory). They should be part of the default configuration instead of
> forcing users to edit the configuration themselves.
> 6) Documentation
> So far for a more precise project outline ;) Please add anything that's
> missing.
> Just for clarification: By the above examples (.po / changelog mergers),
> you mean merge hooks, right? If so, it's not directly related to the GUI
> tools for diffs and merges that I was talking about primarily. As these
> hooks seem to implicitly select files (via PerFileMerger.file_matches as
> I can see from the docs), there won't be need for any configuration for
> the hooks. But maybe it's possible to add this to the project as
> nice-to-have-if-time-remains goal (i.e. to implement some merge hooks,
> selected by popular demand).
>> Jelmer has been a GSoC mentor in the past for Samba, he may also have
>> some suggestions from seeing what's worked in the past and what
>> hasn't.
>> Martin

More information about the bazaar mailing list