>>>>> On Fri, 13 Jul 2001 11:53:37 +0100,
	Chris Gilbert <chris@paradox.demon.co.uk> said:

> I would ask why you didn't say so sooner?

Perhaps because he thought the situation would be fixed sooner,
but actually this wasn't fixed for a month? (i.e. tired to wait?)

Anyway, the rule to commit things to repository is:

[1] design
[2] write code
[3] compile the code (of course!)
[4] confirm that the code works.
[5] (if the change is relatively large) get review
[6] commit it.

(i.e. do not commit code which is not tested.)

But this change was done by the following order.

(1) commit code.
  not only this code doesn't work (i.e. doesn't satisfy [4]), this
  code isn't really able to be compiled (i.e. "make build" failed.
  this means it doesn't satisfy [3]).
(2) try to design to solve the brokeness.
  (i.e. doesn't satisfy even [1])

I don't think this was the best way of software development.

But I don't intend to blame anyone (although I hope such change should
be done by proper order next time), I'd like to think about how to
solve current situation.

There are 2 ways to solve this situation.

1. leave things broken, until the problem is fixed.
2. backout the change for now. and re-commit the change, when
 all problems are solved.

If fixing the problems takes only few days, 1. is fine.

But if it takes more than weeks, 2 is better.
(especially if the consensus how to solve problems isn't really made yet...)

The good thing to use revision control system is that
we can back out any changes any time, and revive the backed out
changes any time, too.

Why do you want to preserve broken tree for long term?
If you know how to use cvs (and you must know..), backing out the
changes shouldn't really prevent to solve the problems.
--
soda