Bzr datasource doesn't use different uri for different events on the same branch

IMO subject of a bzr event is the branch, and a branch is identified by the uri, exact revision is just metadata of the event, not really a subject property. Perhaps gaj should take a look also on the text and not cluster events with different subject text?

+1 for me. I've suggested the same thing in a previous bug.
If nobody else has a better idea i could assign this bug to me.

Agreed. If the URI is carefully constructed GAJ (and others) could
even pull out the commit message to show in a tooltip etc... Maybe use
a bzr: URN scheme like

  bzr:file:///home/mikkel/myproject/trunk#27

  bzr:bzr+ssh://bazaar.launchpad.net/~kamstrup/dee/foobar#68

Or don't use the bzr: URN, but just the raw URLs for the affected
repo, and then rely on some subject interpretation != FILE_DATA_OBJECT
(although I think we are missing that in the ontologies)...:

  file:///home/mikkel/myproject/trunk#27

  bzr+ssh://bazaar.launchpad.net/~kamstrup/dee/foobar#68

Lot's of options here... :-)

The bzr: URN sounds good to me, because doing that we have different uris and we don't have to compare text.
Anyway the URL thing doesn't work: a COMMIT on a branch it's not a PUSH. So if the user only commits we don't have an URL suitable for the URI...but i could be wrong.

In conclusion: +1 bzr: URN.

> bzr:file:///home/mikkel/myproject/trunk#27

I disagree, not even bzr itself would understand this notation, which means special-casing it in each and every zg client.

> file:///home/mikkel/myproject/trunk#27

This is a perfectly valid file (directory) name, with one little problem that it doesn't exist.

-1 from me.

Yes, it's a special casing and GAJ and other clients must handle it...anyway also comparing the text is a plus operation that GAJ should do.
Concluding, in every case the client should handle bzr event in a different way; we only have to decide what's the "less invasive".

On 5 January 2011 12:38, Michal Hruby <email address hidden> wrote:
>>  file:///home/mikkel/myproject/trunk#27
>
> This is a perfectly valid file (directory) name, with one little problem
> that it doesn't exist.

This is *not* a file name. It is a URI. Let's keep the terminology
correct here. It has path member being /home/mikkel/myproject/trunk
and has a URI fragment of 27. Please see
http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components.

Fragments should be definition point to some resource inside the
resource specified by the path element. If we consider the path
element as a bzr repo, and not just a file, then I think that a revno
fragment is perfectly reasonable.

On 5 January 2011 15:43, Mikkel Kamstrup Erlandsen
<email address hidden> wrote:
> On 5 January 2011 12:38, Michal Hruby <email address hidden> wrote:
>>>  file:///home/mikkel/myproject/trunk#27
>>
>> This is a perfectly valid file (directory) name, with one little problem
>> that it doesn't exist.
>
> This is *not* a file name. It is a URI. Let's keep the terminology
> correct here. It has path member being /home/mikkel/myproject/trunk
> and has a URI fragment of 27. Please see
> http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components.
>
> Fragments should be definition point to some resource inside the
> resource specified by the path element. If we consider the path
> element as a bzr repo, and not just a file, then I think that a revno
> fragment is perfectly reasonable.

BTW - and if an app instructed to open file:///foo.txt#27 fails with
"Can not open /foo.txt#27. No such file or directory." Then that's a
bug in the app. Because the fragment should not be taken into account
when resolving the path.

Mikkel: I agree 100% on this :).

Well, now that have that info, i think we should have to choose the idea of
Mikkel.
Michal is it ok for you?

2011/1/5 Mikkel Kamstrup Erlandsen <email address hidden>

> On 5 January 2011 15:43, Mikkel Kamstrup Erlandsen
> <email address hidden> wrote:
> > On 5 January 2011 12:38, Michal Hruby <email address hidden> wrote:
> >>> file:///home/mikkel/myproject/trunk#27
> >>
> >> This is a perfectly valid file (directory) name, with one little problem
> >> that it doesn't exist.
> >
> > This is *not* a file name. It is a URI. Let's keep the terminology
> > correct here. It has path member being /home/mikkel/myproject/trunk
> > and has a URI fragment of 27. Please see
> > http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components.
> >
> > Fragments should be definition point to some resource inside the
> > resource specified by the path element. If we consider the path
> > element as a bzr repo, and not just a file, then I think that a revno
> > fragment is perfectly reasonable.
>
> BTW - and if an app instructed to open file:///foo.txt#27 fails with
> "Can not open /foo.txt#27. No such file or directory." Then that's a
> bug in the app. Because the fragment should not be taken into account
> when resolving the path.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/695003
>
> Title:
> Bzr datasource doesn't use different uri for different events on the same
> branch
>
> Status in Zeitgeist Data-Sources:
> New
>
> Bug description:
> Step to reproduce:
> -commit or pull in a bzr branch ---->the event show up in GAJ
> -commit or pull another time-------> the event doens't show up because GAJ
> discard it (these two events have the same uri: the branch's path one)
>
> RainCT opinion: IMHO the Bazaar plugin should be fixed to give each
> revision a different URI, possibly including the revision ID.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/zeitgeist-dataproviders/+bug/695003/+subscribe
>

>This is *not* a file name. It is a URI. Let's keep the terminology
> correct here. It has path member being /home/mikkel/myproject/trunk
> and has a URI fragment of 27. Please see
> http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components.

I learn something new every day too, in this case I'm perfectly fine with this.

After talking with everyone, probably we are better off not fixing this as changing the URI will mess up with subject popularity as per mhr3