Jørn A Hansen wrote:
On 2/2/06, Christian Boos <[EMAIL PROTECTED]> wrote:
...
I also wonder if by default, the base revision should not be the oldest
shown,
instead of the previous to last one, because viewing the ''Last Change''
is directly possible using the navigation link of the same name.
Good idea! I constantly fall into selecting the wrong order of the
radiobuttons and therefore have to reverse the order of the diff after
a few seconds of confusion when looking at the diff. As I understand
your suggestion with by default selecting the chronological order I
Ah, no that was not exactly what I had in mind.
Let me take an example. If we are viewing the revision log of
a folder, showing the appropriate subset of range [1:444],
we have something like this:
( ) (o) ... rev 444
(o) ( ) ... rev 333
( ) ( ) ... rev 222
( ) ( ) ... rev 111
i.e. by default the old rev. is 333 and the new rev. is 444
(and that's the correct chronological order btw).
I was making the proposal to change the above to:
( ) (o) ... rev 444
( ) ( ) ... rev 333
( ) ( ) ... rev 222
(o) ( ) ... rev 111
i.e. the new default would be to show the entire set of changes
currently shown in the revision log. The rationale for this is:
1. nice for branches, because in combination with the
default stop-on-copy mode, the ''View Changes...'' will
directly show you everything that has changed on the branches
since its creation (most of the time, that is, except for
long-lived branches where there's more than 100 changesets)
2. clicking on the [base:target] part of the Changeset title
will go back to the very same revision log view (i.e. the
range would be the same)
3. there's already a ''Last Change'' navigation link which
shows the changes between the last two revisions.
think we could get rid of having two buttons for each changeset. As
Getting rid of the two buttons means that the target revision
will always be the most recent revision shown in the revision log, right?
The revision log gives you a summary of all the changes and allows you
to visually pick the revisions for which you are interested in the
detailed changes...
Forcing you to select the target by narrowing the revision log view
so that it starts with the target revision doesn't seem to be more
intuitive to me.
It's also like that for the Wiki history and AFAIK nobody complained.
And... WikiMedia does it that way, too. Additionally, WikiMedia uses
some Javascript to ensure you're viewing the diffs in chronological
order, which is not necessarily a relevant restriction when code
diffs are concerned.
...
Another topic:
Fooling around with the anydiff feature left me wondering why diffs
spanning multiple revs does not display the commit messages... is
there a reason for this?
Well, yes, I think that the Changeset view is primarily designed for
viewing the actual, detailed, set of changes.
If that set of changes is a revision (i.e. what Trac calls a
''changeset''),
then it's of course natural to also focus on the related metadata,
including the commit message.
But as soon as there are more than one revision involved, it's really
the Revision log view which is better designed for this job
(possibility to choose between shortened or fully formatted log message,
tabular view of the dates, author, etc.)
The Changeset view and the Revision log view for the same range of
revisions are dual: the first focusing on the actual changes, the second
focusing on the metadata of the changes (hence point 2. in the above).
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
