Re: Re: [cvsgui] Re: Can the DATE FORMAT in the WinCVS browser be changed ??

Am 27.01.2004 um 23:38 schrieb Jerzy Kaczorowski:

>> The current Timestamp column can contain more than just dates. 
>> Especially,
>> it could contain additional textual information supplied by CVS (e.g. 
>> about
>> conflicts or file additions). It's origin is the ./CVS/Entries file. 
>> WinCvs
> only
>> parses it in order to produce more meaningful sorting results. Local
>> modification time is an altogether different matter and is only 
>> loosely
>> related.
>
> While doing the new State and Encoding columns with it's empty-looses
> sorting I was seriously considering to hide the Timestamp contents if 
> it
> contains the modification time and only show it if it doen't parse 
> into date
> correctly to expose the additional information rather than the actual
> timestamp.
>
> Timestamp as it is seems to confuse people a lot as they want it be in 
> local
> time, then formatted according to their regional settings just to 
> discover
> that it doesn't realy mean anything usefull - not even the repository
> checkin time. It doesn't even make sense to sort by it's value as it 
> gets
> modified with update and other operations.
>
> Even thought one can see the Timestamp there is no column to compare it
> with. We could provide new file modification date column but then we 
> have to
> make it UTC and formatted like Timestamp. However it is not very
> user-friendly format so we would have to really format it according to 
> the
> regional settings. Then it would look good and one could compare the 
> two
> columns. Great, but all that effort isn't neccessary because whatever 
> you
> could read from comaring two columns is already displayed in the form 
> of
> icon and State/Status column for easy consumption.

IMHO, a file modification date column (i.e. the 'real' file 
modification date on disk) is _very_ useful for e.g. sorting for your 
latest changes, etc.
Whether the date is formatted as UTC or local time should be a user 
preference. I can see useful situations for both, although in general I 
think local time is what makes most sense.
I agree we should forget about the timestamp from cvs - doesn't really 
make sense at all to display this.

>
> The new problem is that in such case the column name doesn't fit the
> function any more. No time information in the Timestamp shown any 
> more, only
> things like "Initial ...." or "Result of merge....". Suggestions 
> anyone?

Shouldn't this info go into the state column, too? Looks like state 
information to me...

>
> Additionally, we ought to get rid of "Conflict" column which is also
> displaying the time of the conflict in the same format as timestamp. 
> There
> seems to be no reason to show it any more after we've got the State 
> column
> comming with filter to follow to expose resolved and un-resolved 
> conflicts.
>
>> I haven't yet looked at the local CVS timestamp from
>> ./CVS/Entries.Extra, so I couldn't really comment on that yet. If it 
>> also
>> contains the textual information which ./CVS/Entries supplies it might
>> indeed make sense to optionally show only one of the two.
>
> Actually it seems like Tony has put a "usefull" timestamp that can 
> give the
> information about the repository checkin time of the current revision. 
> That
> could prompt to introduce new column such as "Baseline".

Sounds good, but please keep in mind that not everybody is using cvsnt 
[yet] ;-)
For the "Baseline" column, there definitely needs to be a preference 
setting whether to display in UTC or local time.

</jum>


 

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/cvsgui-dev/

To unsubscribe from this group, send an email to:
 [email protected]

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/