Google Summer of Code 2012 project for Bazaar

Hey guys,

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.
Bazaar Explorer would be a nice thing to work on as I think it could use
some improvement.

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?

Best regards,
 Andreas Sommer

I would vote for Netbeans support.

On Sun, Feb 26, 2012 at 9:23 PM, Mark A. Flacy  wrote:
> I would vote for Netbeans support.Netbeans support seems like a good idea to me. The existing project doesn't
seem to be very active.

On 02/27/2012 04:21 AM, Parth Malwankar wrote:
> On Sun, Feb 26, 2012 at 9:23 PM, Mark A. Flacy  wrote:
>> I would vote for Netbeans support.
> Netbeans support seems like a good idea to me. The existing project doesn't
> seem to be very active.
>+1 for Netbeans. It's one of the reasons why my team decided to go with
Mercurial instead of Bazaar.

David

On 26/02/2012, Andreas Sommer  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>> 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.> 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.

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

*From:* Martin Packman 
*Sent:* 26.02.2012 19:16
*To:* Andreas Sommer 
*Cc:* , Daniel Holbach, Jelmer Vernooij 
*Subject:* Re: Google Summer of Code 2012 project for Bazaar

> On 26/02/2012, Andreas Sommer  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>> <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

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:

https://lists.ubuntu.com/archives/bazaar/2011...

Anyway, any help is better than no help at all.
Thank you.Andreas Sommer пишет:
> 
> *From:* Martin Packman 
> *Sent:* 26.02.2012 19:16
> *To:* Andreas Sommer 
> *Cc:* , Daniel Holbach
> , Jelmer Vernooij 
> *Subject:* Re: Google Summer of Code 2012 project for Bazaar
> 
>> On 26/02/2012, Andreas Sommer  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
> 
>

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
 AndreasAndreas Sommer wrote:
>
> *From:* Martin Packman 
> *Sent:* 26.02.2012 19:16
> *To:* Andreas Sommer 
> *Cc:* , Daniel Holbach
> , Jelmer Vernooij 
> *Subject:* Re: Google Summer of Code 2012 project for Bazaar
>
>> On 26/02/2012, Andreas Sommer  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

On 29/04/2012, Andreas Sommer  wrote:
>
> since Canonical didn't participate in GSoC, I couldn't implement the
> idea I described below.Yes, Ubuntu wasn't accepted, which makes not having applies separately
for Bazaar a little frustrating.> 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.Work along these lines seems reasonable to me. Will discuss in our
standup this week, management changes are making planning a little
difficult at the moment. I'd suggest you try diving in now and making
some changes to get a feel for how bzr development is done.> :P ? Any links on Bazaar development (like a source code overview or so)
> will also be helpful.Start in the docs/developers directory, you can also read this online at:

<http://doc.bazaar.canonical.com/developers/>

Good luck!

Martin

Martin Packman wrote:
> On 29/04/2012, Andreas Sommer  wrote:
>> 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.
> 
> Work along these lines seems reasonable to me. Will discuss in our
> standup this week, management changes are making planning a little
> difficult at the moment. I'd suggest you try diving in now and making
> some changes to get a feel for how bzr development is done.
> 
>> :P ? Any links on Bazaar development (like a source code overview or so)
>> will also be helpful.
> 
> Start in the docs/developers directory, you can also read this online at:
> 
> <http://doc.bazaar.canonical.com/developers/>Started coding something already, and I pushed it to my own branch to
get some early feedback:
https://code.launchpad.net/~andidog/bzr/diff-...

And another thing: Do the files need to have "Copyright (c) Canonical Ltd"?> 
> Good luck!
> 
> MartinThanks!

On Tue, May 1, 2012 at 9:34 AM, Andreas Sommer <
 wrote:

> Started coding something already, and I pushed it to my own branch to
> get some early feedback:
> https://code.launchpad.net/~andidog/bzr/diff-...I was going to mention the mergetools module but it looks like you've
already seen it. Something to consider is whether it would be feasible to
refactor the mergetools module and your new difftools module to use a
common module for managing and invoking external tools. It would depend on
how much common code there is.

And another thing: Do the files need to have "Copyright (c) Canonical Ltd"?
>

IANAL, but as far as I know all contributions to bzr have to be made under
a copyright assignment scheme with a signed contributors agreement.

Ciao,
Gordon

Gordon Tyler wrote:
> On Tue, May 1, 2012 at 9:34 AM, Andreas Sommer
> 
> > wrote:
> 
>     Started coding something already, and I pushed it to my own branch to
>     get some early feedback:
>     https://code.launchpad.net/~andidog/bzr/diff-...
> 
> 
> I was going to mention the mergetools module but it looks like you've
> already seen it. Something to consider is whether it would be feasible
> to refactor the mergetools module and your new difftools module to use a
> common module for managing and invoking external tools. It would depend
> on how much common code there is.I will see that soon. From what I've seen in in mergetools, it has a
different way of replacing arguments. Something like "executable
/base:filename.BASE" is not possible because {base} must be a single
argument (i.e. "executable /base filename.BASE" would be possible). This
will be improved if I create a common module for tool invocation. If I
remember correctly, this was actually bugging me for a while because I
had to write a workaround in order to use the awesome TortoiseMerge. So
it's a good chance to get that fixed too :)>     And another thing: Do the files need to have "Copyright (c)
>     Canonical Ltd"?
> 
> 
> IANAL, but as far as I know all contributions to bzr have to be made
> under a copyright assignment scheme with a signed contributors agreement.Right, I remember having read something about that. Just signed and
submitted it online.

On Tue, May 1, 2012 at 11:41 AM, Andreas Sommer <
 wrote:

> I will see that soon. From what I've seen in in mergetools, it has a
> different way of replacing arguments. Something like "executable
> /base:filename.BASE" is not possible because {base} must be a single
> argument (i.e. "executable /base filename.BASE" would be possible). This
> will be improved if I create a common module for tool invocation. If I
> remember correctly, this was actually bugging me for a while because I
> had to write a workaround in order to use the awesome TortoiseMerge. So
> it's a good chance to get that fixed too :)
>It certainly sounds like that would be a good improvement and should be
backwards compatible.

Another diff-related feature request that I recall seeing was for proper
handling of multi-file diffs with tools that can handle them. I think it
might have been WinMerge that could display multiple diffs in a single
window, but the way our diff invocation currently works, it would show one
diff, wait for the diff app to close, invoke it again for the next file,
etc.

Ah, here it is: https://bugs.launchpad.net/bzr/+bug/490212

Ciao,
Gordon

From: Gordon Tyler 
Sent: 03.05.2012 01:16To: Andreas Sommer 
Cc: , Martin Pool 
Subject: Re: Major diff/merge changes in bzr and explorer
> On Tue, May 1, 2012 at 11:41 AM, Andreas Sommer
> 
> > wrote:
> 
>     I will see that soon. From what I've seen in in mergetools, it has a
>     different way of replacing arguments. Something like "executable
>     /base:filename.BASE" is not possible because {base} must be a single
>     argument (i.e. "executable /base filename.BASE" would be possible). This
>     will be improved if I create a common module for tool invocation. If I
>     remember correctly, this was actually bugging me for a while because I
>     had to write a workaround in order to use the awesome TortoiseMerge. So
>     it's a good chance to get that fixed too :)
> 
> 
> It certainly sounds like that would be a good improvement and should be
> backwards compatible.
> 
> Another diff-related feature request that I recall seeing was for proper
> handling of multi-file diffs with tools that can handle them. I think it
> might have been WinMerge that could display multiple diffs in a single
> window, but the way our diff invocation currently works, it would show
> one diff, wait for the diff app to close, invoke it again for the next
> file, etc.
> 
> Ah, here it is: https://bugs.launchpad.net/bzr/+bug/490212Good point. There is an important distinction to make:

1) Tools that show multiple 2-way diffs, e.g. in tabs. This is done by
multiple process invocations (e.g. WinMerge) or passing the file pairs
as parameters (e.g. meld) as described in the bug comments.

2) Tools that can handle 3+ way diffs like Diffuse. 'bzr diff' can only
compare two revisions at the moment, so multi-revision diff tools can
not be used yet. But it might be worth considering it in the
implementation of a common tool invocation module. For example, instead
of parameters (old_filename,new_filename) one could use a list
new_filenames (that would contain one filename in case of the
traditional 2-way diff).

On 12-05-03 04:41 AM, Andreas Sommer wrote:
> From: Gordon Tyler 

>> Another diff-related feature request that I recall seeing was for
>> proper handling of multi-file diffs with tools that can handle
>> them.

> Good point. There is an important distinction to make:
> 
> 1) Tools that show multiple 2-way diffs, e.g. in tabs. This is done
> by multiple process invocations (e.g. WinMerge) or passing the file
> pairs as parameters (e.g. meld) as described in the bug comments.
> 
> 2) Tools that can handle 3+ way diffs like Diffuse. 'bzr diff' can
> only compare two revisions at the moment, so multi-revision diff
> tools can not be used yet. But it might be worth considering it in
> the implementation of a common tool invocation module. For example,
> instead of parameters (old_filename,new_filename) one could use a
> list new_filenames (that would contain one filename in case of the 
> traditional 2-way diff).I would distinguish between per-file diff tools and per-tree diff
tools.  The diff code I wrote handles per-file diff tools as
extra_factories for DiffTree.  I imagined that per-tree diff tools
would be implemented using the same API as DiffTree, and registered
with bzrlib.diff.format_registry, but I didn't do any work on that.

Aaron

From: Aaron Bentley Sent: 03.05.2012 16:07
To: 
Subject: Re: Major diff/merge changes in bzr and explorer
> On 12-05-03 04:41 AM, Andreas Sommer wrote:
>> From: Gordon Tyler 
> 
>>> Another diff-related feature request that I recall seeing was
>>> for proper handling of multi-file diffs with tools that can
>>> handle them.
> 
>> Good point. There is an important distinction to make:
> 
>> 1) Tools that show multiple 2-way diffs, e.g. in tabs. This is
>> done by multiple process invocations (e.g. WinMerge) or passing
>> the file pairs as parameters (e.g. meld) as described in the bug
>> comments.
> 
>> 2) Tools that can handle 3+ way diffs like Diffuse. 'bzr diff'
>> can only compare two revisions at the moment, so multi-revision
>> diff tools can not be used yet. But it might be worth considering
>> it in the implementation of a common tool invocation module. For
>> example, instead of parameters (old_filename,new_filename) one
>> could use a list new_filenames (that would contain one filename
>> in case of the traditional 2-way diff).
> 
> I would distinguish between per-file diff tools and per-tree diff 
> tools.  The diff code I wrote handles per-file diff tools as 
> extra_factories for DiffTree.  I imagined that per-tree diff tools 
> would be implemented using the same API as DiffTree, and
> registered with bzrlib.diff.format_registry, but I didn't do any
> work on that.
> 
> AaronNot sure what you mean by per-tree diff tools - no tool except for the
bzr textual representation can display all different types of changes
(modified text files or pictures, symlinks, changed directories, renames).

I propose the following: Bazaar's textual representation remains the
default, and the differs in extra_factories are tried first. The
"--format" parameter which does the selection in
bzrlib.diff.format_registry, will only be valid for the internal diff
(e.g. one could implement different formats apart from the unified
diff, that's how I understand the word "format").
Now for the external tools: I will add an option like
"bzr.difftool.MyDiffTool.is_default" (true/false). Also an option
".is_console_based" that says whether it can be run without a
graphical environment. "bzr diff" without the "--tool" parameter will
try all "default" differs first before using the textual
representation (if there's no graphical environment like in an SSH
session (how would I check this??), only the ones with
.is_console_based==true). In contrast, "bzr diff --tool=MyCoolTool"
will select the tool with that name and use it for all changes that it
supports, else falls back to other preferred tools, then to built-in
diff. The ".is_default" option thus means that "bzr diff" uses them
automatically without the "--tool" parameter, so that a user can
replace the default diff algorithm completely by another tool.

Does that make sense somehow? Or how did you imagine this, also
regarding the existing DiffPath implementation?

Andreas

Andreas Sommer wrote:
> From: Aaron Bentley  Sent: 03.05.2012
> 16:07 To:  Subject: Re: Major diff/merge
> changes in bzr and explorer
>> On 12-05-03 04:41 AM, Andreas Sommer wrote:
>>> From: Gordon Tyler 
> 
>>>> Another diff-related feature request that I recall seeing
>>>> was for proper handling of multi-file diffs with tools that
>>>> can handle them.
> 
>>> Good point. There is an important distinction to make:
> 
>>> 1) Tools that show multiple 2-way diffs, e.g. in tabs. This is 
>>> done by multiple process invocations (e.g. WinMerge) or
>>> passing the file pairs as parameters (e.g. meld) as described
>>> in the bug comments.
> 
>>> 2) Tools that can handle 3+ way diffs like Diffuse. 'bzr diff' 
>>> can only compare two revisions at the moment, so
>>> multi-revision diff tools can not be used yet. But it might be
>>> worth considering it in the implementation of a common tool
>>> invocation module. For example, instead of parameters
>>> (old_filename,new_filename) one could use a list new_filenames
>>> (that would contain one filename in case of the traditional
>>> 2-way diff).
> 
>> I would distinguish between per-file diff tools and per-tree diff
>>  tools.  The diff code I wrote handles per-file diff tools as 
>> extra_factories for DiffTree.  I imagined that per-tree diff
>> tools would be implemented using the same API as DiffTree, and 
>> registered with bzrlib.diff.format_registry, but I didn't do any 
>> work on that.
> 
>> Aaron
> 
> Not sure what you mean by per-tree diff tools - no tool except for
> the bzr textual representation can display all different types of
> changes (modified text files or pictures, symlinks, changed
> directories, renames).
> 
> I propose the following: Bazaar's textual representation remains
> the default, and the differs in extra_factories are tried first.
> The "--format" parameter which does the selection in 
> bzrlib.diff.format_registry, will only be valid for the internal
> diff (e.g. one could implement different formats apart from the
> unified diff, that's how I understand the word "format"). Now for
> the external tools: I will add an option like 
> "bzr.difftool.MyDiffTool.is_default" (true/false). Also an option 
> ".is_console_based" that says whether it can be run without a 
> graphical environment. "bzr diff" without the "--tool" parameter
> will try all "default" differs first before using the textual 
> representation (if there's no graphical environment like in an SSH 
> session (how would I check this??), only the ones with 
> .is_console_based==true). In contrast, "bzr diff
> --tool=MyCoolTool" will select the tool with that name and use it
> for all changes that it supports, else falls back to other
> preferred tools, then to built-in diff. The ".is_default" option
> thus means that "bzr diff" uses them automatically without the
> "--tool" parameter, so that a user can replace the default diff
> algorithm completely by another tool.
> 
> Does that make sense somehow? Or how did you imagine this, also 
> regarding the existing DiffPath implementation?
> 
> AndreasSo now I implemented it as described above, with some small changes:
- - Added the following options for each diff tool (default value in
parentheses): is_default (false), is_gui (false), filename_regex
(None), file_types (text,binary)
  - filename_regex defines which filenames are supported, e.g.
\.docx?$ for a tool that can diff Word documents
  - file_types defines whether text, binary or both can be handled
  - is_default defines whether "bzr diff" may choose this tool
automatically
  - is_gui is for default (is_default=true) tools that should only be
chosen if the new "--ui" parameter is given

Conclusion: "bzr diff" stays as is because no default tools are
defined for the command line (yet?!). The user can define own
preferred tools. "bzr diff --ui" will start a GUI-based tool if available.

Since I'm using Windows/Tortoise{Git,SVN} quite often, I already added
TortoiseMerge (also works as diff tool despite its name) for text
files and the TortoiseSVN MS Word diff script for .doc and .docx files.

See branch at
https://code.launchpad.net/~andidog/bzr/diff-... feedback
welcome!! Thanks,
 Andreas

On 29/04/12 09:43, Andreas Sommer wrote:
> 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
>Dear Andreas,
A plea if you are looking at how bzr handles diff tools:
When an interactive diff tool like meld is used and you run a diff on a 
branch where files have been added or removed then bzr just dumps the 
content of the added or removed file to the terminal instead of also 
showing the contents via the diff tool with an empty counterpart. This 
is very annoying as one has to switch between the terminal and the 
interactive diff tool to see the changes and the 'dumped' contents may 
be larger than the scroll buffer.

If bzr knowns about diff/merge tool definitions then it can also be told 
that a tool is interactive and in that case all changes should be shown 
through that tool.

So if it fits in your work I'd be very pleased if you could look at this 
issue too :-)
thanks,
David.

From: David Ingamells Sent: 03.05.2012 07:50
To: 
Subject: Re: Major diff/merge changes in bzr and explorer
> On 29/04/12 09:43, Andreas Sommer wrote:
>> 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
>>
> Dear Andreas,
> A plea if you are looking at how bzr handles diff tools:
> When an interactive diff tool like meld is used and you run a diff on a
> branch where files have been added or removed then bzr just dumps the
> content of the added or removed file to the terminal instead of also
> showing the contents via the diff tool with an empty counterpart. This
> is very annoying as one has to switch between the terminal and the
> interactive diff tool to see the changes and the 'dumped' contents may
> be larger than the scroll buffer.
> 
> If bzr knowns about diff/merge tool definitions then it can also be told
> that a tool is interactive and in that case all changes should be shown
> through that tool.
> 
> So if it fits in your work I'd be very pleased if you could look at this
> issue too :-)
> thanks,
> David.Hi David,

I addressed this already in my first commit. My plan is to define for
each tool which kinds of changes it can display, e.g. modified file,
missing file, added file, etc. This is handled with the parameters
old_kind/new_kind as I saw, so I added a new setting that allows to
define which changes a tool supports, e.g.
"bzr.difftool.TortoiseDiff.supports_kinds_from_to = none-file,file-file"
for a tool that handles added and modified files. The default is that it
can only show modified files because I guess that most diff tools need
two files as parameters, not just one?!

Best regards

Hello,On 26.02.2012 19:16, Martin Packman wrote:
> 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>I'm not really coordinating things at the Ubuntu side. This cycle and
next are likely going to be too busy for me to be able to commit to
doing it. I just felt it necessary to remind everyone of the GSoC2012 dates.

All the best with your project.

Have a great day,
 Daniel

*From:* Daniel Holbach 
*Sent:* 27.02.2012 11:51
*To:* Martin Packman 
*Cc:* Andreas Sommer ,, Jelmer Vernooij 
*Subject:* Re: Google Summer of Code 2012 project for Bazaar

> Hello,
>
> On 26.02.2012 19:16, Martin Packman wrote:
>> 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>
> I'm not really coordinating things at the Ubuntu side. This cycle and
> next are likely going to be too busy for me to be able to commit to
> doing it. I just felt it necessary to remind everyone of the GSoC2012 dates.
>
> All the best with your project.
>
> Have a great day,
>  Daniel
>I'm seeing a lot of project ideas coming, but as the deadline for
organisation application will be quite soon, it would be good idea to
know if Canonical will offer GSoC projects in the first place and who
will be the supervisor(s).

See also the thread
https://lists.ubuntu.com/archives/ubuntu-deve...

In the meantime, I will edit the wiki page to include my detailed
project idea that I wrote to the list.

I personally would love to see better integration with JetBrains' IntelliJ
IDEA. There is a bzr plugin for it already, but it's not maintained and
currently crashes on most VCS operations in IDEA 11.

The community edition of IDEA is open source:
http://www.jetbrains.org/display/IJOS/Home

On Tue, Feb 28, 2012 at 6:17 AM, Gordon Tyler  wrote:

> I personally would love to see better integration with JetBrains' IntelliJ
> IDEA. There is a bzr plugin for it already, but it's not maintained and
> currently crashes on most VCS operations in IDEA 11.
>
> The community edition of IDEA is open source:
> http://www.jetbrains.org/display/IJOS/Home
>Without trying to be offensive, that seems a little too specialized to make
a good GSOC project, "fix up a plugin for one specific IDE", useful though
the end result might be to a few people; IDEA is certainly well down the
list of most popular IDEs...  And probably a mentor could be found for the
bzr side, but it seems it would need one on the IDEA side as well?

I figured it couldn't hurt to suggest it since somebody else suggested
NetBeans support. But I see your point about it not being one of the more
popular IDEs, although IMO that's a crying shame since I think it's one of
the better ones.On Mon, Mar 5, 2012 at 10:27 AM, Wichmann, Mats D 
> wrote:

>
>
> On Tue, Feb 28, 2012 at 6:17 AM, Gordon Tyler  wrote:
>
>> I personally would love to see better integration with JetBrains'
>> IntelliJ IDEA. There is a bzr plugin for it already, but it's not
>> maintained and currently crashes on most VCS operations in IDEA 11.
>>
>> The community edition of IDEA is open source:
>> http://www.jetbrains.org/display/IJOS/Home
>>
>
> Without trying to be offensive, that seems a little too specialized to
> make a good GSOC project, "fix up a plugin for one specific IDE", useful
> though the end result might be to a few people; IDEA is certainly well down
> the list of most popular IDEs...  And probably a mentor could be found for
> the bzr side, but it seems it would need one on the IDEA side as well?
>
>
>
>

Am 27/02/12 11:51, schrieb Daniel Holbach:
> On 26.02.2012 19:16, Martin Packman wrote:
>> 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>
> I'm not really coordinating things at the Ubuntu side. This cycle and
> next are likely going to be too busy for me to be able to commit to
> doing it. I just felt it necessary to remind everyone of the GSoC2012 dates.
>
> All the best with your project.
>Do you know if anybody else is coordinating this from the Ubuntu side of 
things? The deadline for signing up is Friday IIRC.

If not, perhaps I can look into it.

Cheers,

Jelmer

Hello Jelmer,

thanks for your interest in this!On 06.03.2012 16:49, Jelmer Vernooij wrote:
> Do you know if anybody else is coordinating this from the Ubuntu side of 
> things? The deadline for signing up is Friday IIRC.
> 
> If not, perhaps I can look into it.Luke Faraone (~lfaraone) indicated interested and Benjamin Kerensa
(~bkerensa) too to some degree. In the "Google Summer of Code 2012
announced" thread on  I tried to answer all
the questions everyone had, but I don't know how much planning is going
on in the background now.

Have a great day,
 Daniel

On 02/26/2012 01:00 PM, Andreas Sommer 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.
> Bazaar Explorer would be a nice thing to work on as I think it could use
> some improvement.
>
> 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?It would be interesting to see if we could participate in the Summer of 
Code again this year. I've put up an ideas page, based on the one from 
earlier years.

http://wiki.bazaar.canonical.com/SummerOfCode...

If you have more ideas, please let us know.

Cheers,

Jelmer

Jelmer Vernooij пишет:
>   On 02/26/2012 01:00 PM, Andreas Sommer 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.
>> Bazaar Explorer would be a nice thing to work on as I think it could use
>> some improvement.
>>
>> 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?
> It would be interesting to see if we could participate in the Summer of 
> Code again this year. I've put up an ideas page, based on the one from 
> earlier years.
> 
> http://wiki.bazaar.canonical.com/SummerOfCode...
> 
> If you have more ideas, please let us know.I'm sure the very last line should be changed. I'm not sure who will be 
contact person this year though.

"If you have any questions, please contact  
(igc on #bzr)."

On Sun, Feb 26, 2012 at 8:22 PM, Jelmer Vernooij  wrote:

>  On 02/26/2012 01:00 PM, Andreas Sommer 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.
> Bazaar Explorer would be a nice thing to work on as I think it could use
> some improvement.
>
>

>  It would be interesting to see if we could participate in the Summer of
> Code again this year. I've put up an ideas page, based on the one from
> earlier years.
>
> http://wiki.bazaar.canonical.com/SummerOfCode...
>
> If you have more ideas, please let us know.
>What about integrating tools/support to ease *automatic* synchronization
between bazaar repositories/branches across multiple machines?
I'm thinking about using inotify/fsevent along with bzr pull, maybe with
zeroconf/bonjour.

Maybe I'm the only one having this particular itch, but working with
multiple machines, not always online, and with no clear master, I find it
difficult to adapt existing workflows.

Cheers,
Marco

On 26 February 2012 23:00, Andreas Sommer
 wrote:
> Hey guys,
>
> 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.
> Bazaar Explorer would be a nice thing to work on as I think it could use
> some improvement.Hi Andreas,

I think that would be great to do a GSoC for you, and anyone else interested.

I have been sceptical in the past about how much it is worthwhile to
sponsor random students who just want to do some GSoC project.  I
think it is better to concentrate developer time on helping people,
students or not, who want to improve Bazaar in particular.   If we get
both, of course that's awesome.

On 26 February 2012 23:00, Andreas Sommer
 wrote:
> Hey guys,
>
> 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.
> Bazaar Explorer would be a nice thing to work on as I think it could use
> some improvement.
>
> 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?"Ubuntu was not accepted into GSoC this year, due to procedural issues
with the application."
<https://lists.ubuntu.com/archives/ubuntu-deve...>
 (I don't know what that means.)

However, if you would like to do a summer project on this, we would be
happy to look at taking you, and other students, on as an intern at
Canonical, with mentoring and a similar honorarium.