Hi again! =)

On 5/30/06, Steve McIntyre <[EMAIL PROTECTED]> wrote:
Just a heads-up; things are not as simple as I'd hoped. I've spent
several hours today trying to get old behaviour back, and so far it's
not working...

Indeed =(  I've been held back by today's power blackout (I just got
back on now,) but I was looking into this last night, and grepping the
./src/ChangeLog following the clues as included in your links reveals
this (its coincidence to my birthday is purely coincidental ;):

2005-09-22  Derek Price  <[EMAIL PROTECTED]>

        * classify.c (Classify_File): If a file had a conflict and the
        timestamp hasn't changed, it still has a conflict.  Add comment about
        how T_MODIFIED could later turn out to have conflict markers and why
        it should not be checked in this function.
        * client.c (send_fileproc): Don't send contents for files known to have
        conflicts unless this is for `cvs diff'.
        * commit.c (check_fileproc): T_CONFLICT should be handled like
        T_MODIFIED, since force could be requested.  Simplify logic since
        T_CONFLICT can now be trusted.
        * rcs.c (RCS_Checkout): Comment noexec behavior in header block.
        * server.c (serve_unchanged, serve_is_modified): Handle conflicts.
        * status.c (status_fileproc): Trust T_CONFLICT to simplify.
        * subr.c (file_has_conflict): Removed.
        * subr.h (file_has_conflict): Remove proto.
        * update.c (update_fileproc): Trust T_CONFLICT.
        (RegisterMerge): New function factored from...
        (merge_file, join_file): ...these two functions.
        * vers_ts.c (time_stamp_server): Handle = conflict timestamps in server
        entdata.
        * sanity.sh (files-12): Account for slight behavior improvement.
        (status, conflicts, mwrap): Account for corrected behavior.
        (join-readonly-conflict-10): Correct comment.
        (binfiles-con1b): New test for correct behavior.

        * classify.c (Classify_File): Consolidate redundant conditionals.

Thoughts?  Also, would convincing upstream to undo this be feasible?
It seems that we're not the only ones complaining...

Cheers,

Zakame

--
Zak B. Elep  ||  http://zakame.spunge.org
[EMAIL PROTECTED]  ||  [EMAIL PROTECTED]
1486 7957 454D E529 E4F1  F75E 5787 B1FD FA53 851D


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to