t.e.o and empty changesets

[Tim Hatch]

I noticed that the recent use of svnmerge is showing up as empty
changesets and the properties aren't listed on the respective
locations, although they do exist when queried from the svn console
binary.

For example:
- http://trac.edgewall.org/changeset/4255
- http://trac.edgewall.org/changeset/4256

Is this a bug in 0.10-stable, or a case of properties being explicitly
ignored via customization? I tried and can't reproduce on trunk.

Tim

[Christian Boos]

The svnmerge-blocked and svnmerge-integrated properties were added to
the list of hidden properties.
I don't think this was necessary, as recent versions of Trac (including
the one running on t.e.o) would support scrolling on those long
properties. As time permits, I'll work on a more intelligent display of
those properties. Ideally, it should also be possible to display the set
of changesets still available for merge.

-- Christian

[Tim Hatch]

> As time permits, I'll work on a more intelligent display of
> those properties. Ideally, it should also be possible to display the set
> of changesets still available for merge.

That sounds good. I hope it doesn't slow things down much.

At the risk of becoming svn-centric, properties are currently not
versioned, correct? So it would be difficult to produce a link to the
relevant log: section from the changesets which block and record the
merge, without relying on the message format to stay the same.

This brings up the question, do any of the other backends have the
ability to report on merges?

Tim

[Christian Boos]

Tim Hatch wrote:
>> As time permits, I'll work on a more intelligent display of
>> those properties. Ideally, it should also be possible to display the set
>> of changesets still available for merge.
>>
>
> That sounds good. I hope it doesn't slow things down much.
>

It'll probably depend on how fast the Ranges class will handle the
(Ranges("1-head") - ranges_blocked - ranges_integrated) operation :-)
So, no this shouldn't slow things down.

> At the risk of becoming svn-centric, properties are currently not
> versioned, correct?

No, svn properties *are* versioned, though that's currently not mirrored
in the cache.

> So it would be difficult to produce a link to the
> relevant log: section from the changesets which block and record the
> merge, without relying on the message format to stay the same.
>

No, we don't need the message here, as the properties are versioned.
That would even work when viewing differences between two changesets.

To be more specific about what I'd like to have: it would be a plugin
(necessarily svn specific, e.g. TracSvnMergePlugin) which would register
for the yet-to-be-defined IRepositoryPathPropertyRenderer interface.
That interface would have the following methods:

- render_property_diff(name, old_value, new_value) -> return markup or wiki

This gets called in the TracChangeset view, and can be used to show the
property differences in a meaningful way.
Here, for either svnmerge-integrated or svnmerge-blocked, we could show
the range differences (with the ranges turned into a log link).

- render_property(name, properties) -> return (name, markup or wiki)

This one gets called in the TracBrowser view, and would be used to show
the actual content of a property in a rich way.
Here, instead of displaying the (big) list of svnmerge-blocked and
svnmerge-integrated properties, we should be able to display only a
pseudo-property svnmerge-avail, with the (small) list of changesets
still available for merge (i.e. remaining to be either integrated or
blocked).

The idea behind the proposed signature of `render_property` is that
property renderer plugins will often need to "skip" the raw rendering of
some properties, while producing pseudo-properties which "merge" the
input from different real properties.

Here, for example, we could do:
- name == 'svnmerge-blocked' -> return None (i.e. hide)
- name == 'svnmerge-integrated' -> compute the set of available
changesets, from properties['svnmerge-blocked'] and
['svnmerge-integrated'] -> return ('svnmerge-avail', "Changesets
available for merge: [...]")
- else -> return False (leave up to another IRepositoryPropertyRenderer
implementation)

See also http://trac.edgewall.org/ticket/1601 and
http://trac.edgewall.org/ticket/1947.

> This brings up the question, do any of the other backends have the
> ability to report on merges?
>

Well, most other backends have an explicit notion of merge, though
that's not yet apparent in Trac.
See the discussion in http://trac.edgewall.org/ticket/3236, and
http://trac.edgewall.org/ticket/813.
In Mercurial for example (probably Monotone, bzr and git as well), a
merge operation corresponds to creating a new changeset by "joining" two
branches together. Such a changeset will have two parent changesets, and
can then be unambiguously distinguished from a "normal" changeset.
Perforce records explicitly the merge as the operation happening on a
file in a changeset (similar to "Edit"), see #3236 for details.

-- Christian