Major diff/merge changes in bzr and explorer

[Andreas Sommer]

Hi all,

since Canonical didn't participate in GSoC, I couldn't implement the
idea I described below. Also I was not accepted for GSoC because I'm
writing my master's thesis, and organizations expect full-time
commitments (applied for Debian and Monkey). So much about that... Still
I'd like to do some work on diff/merge tool definitions because for me
this is a feature that I am totally missing, so I would like to have
your opinion and feedback about the idea I already presented some weeks
ago - it is outlined below. Are you okay with the changes I'm proposing,
do you see problems, do you think I shouldn't mess around with your code
:P ? Any links on Bazaar development (like a source code overview or so)
will also be helpful.

Best regards
 Andreas


Andreas Sommer wrote:
>
> *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