Re: [viewvc-dev] [PATCH] Show property diffs in ViewVC
"C. Michael Pilato" <[email protected]> Fri, 30 Sep 2011 15:29:05 -0400
| Newsgroups | gmane.comp.version-control.cvs.viewcvs.devel |
|---|---|
| Organization | CollabNet, Inc. |
| Message-ID | <[email protected]> |
On 09/30/2011 03:08 PM, Alexey Neyman wrote: >>> 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. > > One argument against it that I thought about is that such aggregation would > have to share the same format. E.g., if one wanted to see 'full context diff' > for props, he would be stuck with a 10000 lines of full context diff of the > file contents as well. Is it okay? Hrm, you make a good point. I suppose we could start with a shared diff format selection, and add a distinct pdiff_format CGI variable in the future if we don't like how the original plan plays out. I'd eventually like to see the diff view be less "Pick from the pre-chosen display options" and more "Here's some knobs for you to play with: number of context lines, whitespace consideration, etc.". (See http://viewvc.tigris.org/issues/show_bug.cgi?id=301) Maybe now is the time to start considering what that might all look like. BUT! Don't let any of this future-thinkin' get in the way of integrating your work into ViewVC. No sense in letting the perfect be the enemy of the good. >> 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). > > Actually, that should be pretty straightforward now that the diff_display.ezt > template can be iterated over. The only thing I think is needed for that is to > make the left/right items a part of the 'diff' hash as well, so that href's > can be set (or not set) for each "diffable" object separately. Cool. >> 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. > > With EZT modification off the table, the template arguments to diff.ezt would > have to be changed. As far as I understand, that's allowed for major releases, > right? Yeah, that's no sweat. I'm thinking that its about time to start looking at some of these bigger items for a 2.0 release anyway. >> 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? > > I am okay with that. I think it would be easier to review the changes once > they are split in smaller, "one change at a time" blocks. Cool. You'll first need to create a Tigris.org account. After that, request the Developer role at: http://viewvc.tigris.org/servlets/ProjectMembershipRequest Once the role is approved, one of us can create a branch for you to play in. -- C. Michael Pilato <[email protected]> CollabNet <> www.collab.net <> Distributed Development On Demand ------------------------------------------------------ http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=2848343 To unsubscribe from this discussion, e-mail: [[email protected]].
signature.asc
(application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk6GGIEACgkQokEGqRcG/W68TQCeOXqo5VQ7ebdbjgXRFf+cNaf9 nAYAoMxH4vBMIAgTs5Wwep1V7/dKGwTd =QK+A -----END PGP SIGNATURE-----