Re: [viewvc-dev] [PATCH] Show property diffs in ViewVC

On 09/30/2011 01:39 PM, Alexey Neyman wrote:
> Hi all,
> 
> Attached is a patch that allows ViewVC to show property changes in 
> files/directories. I have not formally described it in template authoring 
> guide yet, pending approval of the approach taken.

Holy drive-by feature donations, Batman!

SIDEBAR:
{{{

> - In viewvc-install, a minor bug is fixed which resulted in traceback if 
> [Enter] was pressed in response to "overwrite/do not overwrite" question.

This is logically unrelated to the other work, thus should be submitted as a
separate patch.
}}}

> In a hindsight, I think the pdiff view may have been made a part of the 
> regular diff view (with "props changed" link pointing to an anchor in the diff 
> view). Please advise if you think it would be a better way.

Given that we're probably not talking about tons of property changes needing
to be displayed on the page, I do think adding these to the bottom of the
regular diff view -- recycling the machinery used to choose the diff format,
avoiding another view and the configuration mechanics around it, etc. --
would be useful.

I'm loving some of the abstractions you've mentioned though, and am
wondering how many of them could be further used to provide the
oft-requested "revision diff" feature for Subversion (see
http://viewvc.tigris.org/issues/show_bug.cgi?id=217).

> The changes in diff.ezt template arguments could have been avoided if it were 
> possible to alias "variables" in the templates. For example, this fails:
> 
> [define changes][diff.changes][end]
> 
> as the diff.changes is an array and ezt.py throws a traceback, failing to 
> convert it to a printable form. I thought about something like:
> 
> [alias changes diff.chages]
> 
> which would make "diff.changes" be used wherever "changes" variable is 
> encountered. Again, please advise if such new template command would be 
> useful.

EZT is at this point a somewhat divergent reflection of an upstream module.
 I'd really like to someday re-sync with the upstream module, but I also
know that the primary author and maintainer of that module strongly desires
to avoid feature creep in EZT.  (He wasn't pleased with the addition of the
immensely useful [define] directive, even.)  So, I'd like to see how far we
can go without modifying EZT itself.

Thanks so much for this contribution.  I have not reviewed the code changes,
but given the size of the patch, I suspect it would be mutually beneficial
for you to simply do this work in a branch of the project's repository.
What do you think?

-- 
C. Michael Pilato <[email protected]>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=2848333

To unsubscribe from this discussion, e-mail: [[email protected]].

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk6GC60ACgkQokEGqRcG/W6trgCdEsGp89Z8TpRC0CJ9jEwiRgUg
iVUAnj5lffLYAaekudl4UZL8w7S2evfd
=qS/4
-----END PGP SIGNATURE-----