104313 - UI for blame of previous versions should be more visible

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Bonsai, defect, P1)

Description

[Gervase Markham [:gerv]]

Currently, it is very hard to get Bonsai to show you a file as it was in a
previous version. One way of doing this is by asking for the blame for that
version, but links to this ability are not exposed in the UI. This is a serious
deficiency, easily remedied.

Gerv

Comment 1

[Dave Miller [:justdave]]

I'll second that.  Had a use for it the other day and ended up settling for cvs
annotate on the command line. :)

Comment 2

[Bradley Baetz (:bbaetz)]

See bug 80386 for whitespace-ignoring bonsai cvsblame.

Comment 3

[timeless]

My goal is to avoid making any menu grow too fast, and having a single 
optionlist for all revisions and all tags/branches would be a disaster for 
mozilla/configure. So my suggestion is 2 selects, one for branches and one for 
revisions and two listboxes to show the other symbolic names for the selected 
branch/revision.

Problems to address: how should we select the symbolic name for the <select>s 
oldest, newest, alphabetical...
At first I leaned towards newest, as did tara, then I wavered to oldest, but 
I'm still fence sitting.

mozilla/configure
Branch   [ FastLoadXUL_20020410_BASE (1.949)    |^]
Revision [ NETSCAPE_7_0_PR1_RELEASE (1.949.2.4) |^]
   Symbolic names for 1.949      Symbolic names for 1.949.2.4
/---------------------------v-\ /--------------------------v-\
| FastLoadXUL_20020410_BASE |^| | MOZILLA_1_0_RC2_RELEASE  |^|
| MOZILLA_1_0_0_BASE        | | | NETSCAPE_7_0_PR1_BASE    | |
|                           |v| | NETSCAPE_7_0_PR1_RELEASE |v|
\---------------------------^-/ \--------------------------^-/

Problems not addressed by this design: Deep branching. The easiest way to do it 
in keeping with this architecture is to add extra pairs of select/listbox for 
each extra branch so         AUTOCONF_NSPR_WIN32_XCOMPILE_19990621_BRANCH: 
1.237.2.1.0.2
would trigger three <select>s and three <listbox>es. Anyone could of course 
enter a rev manually into the url field or use some other tool to browse them.

a submit button will probably be used, and the originmost <select> will win in 
the event the user changes more than one. (So if you switch to
N3 (1.100) and MOZILLA_1_0_0_2002052821 (1.949.2.6) you will end up at N3.

The example above is actually missing an optionlist/select pair

the select would have:
        NETSCAPE_7_0_PR1_BASE: 1.949.2.4
        NETSCAPE_7_0_PR1_BRANCH: 1.949.2.4.0.2
and the listbox would either have the same content as the second listbox or 
would be disable/replaced by content indicating it's the same tag as the 
earlier one.

Comment 4

[Tara Hernandez]

I think that's a bit overkill for the short-term, though certainly meriting a
long-term discussion.

In the mean time, I'm identifying areas to make this somewhat better, starting
with making the default "blame" link on cvsview2 point to the revision getting
diffed, rather than the tip.

Next, evaluating other flow paths to cvsblame.cgi

Comment 5

[Adam Muntner [:adamm] (use NEEDINFO)]

Bonsai was decommissioned, closing all remaining bugs "wontfix"