Google Summer of Code 2012 project for Bazaar

[Andreas Sommer]

*From:* Martin Packman <martin.packman at canonical.com>
*Sent:* 26.02.2012 19:16
*To:* Andreas Sommer <andreas.sommer87 at googlemail.com>
*Cc:* bazaar at lists.canonical.com, Daniel Holbach
<daniel.holbach at ubuntu.com>, Jelmer Vernooij <jelmer at samba.org>
*Subject:* Re: Google Summer of Code 2012 project for Bazaar

> On 26/02/2012, Andreas Sommer <andreas.sommer87 at googlemail.com> 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:
>
> <https://wiki.ubuntu.com/GoogleSoC2012>
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
>> https://bugs.launchpad.net/qbzr/+bug/489915, 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