"David Glasser" <glasser@davidglasser.net> writes:
> The good news is it's only used for the relatively unimportant task of
> writing a human-legible *.prej file. Should we try to remove it and
> use something else there? Or mark it with a big "do not use for
> anything where you care about data consistency" comment? Removing it
> would be pretty simple; instead of doing:
>
> * loggily append reject_tmp to reject_real
>
> we would just do
>
> * copy reject_real to a new reject_current_tmp file
> * append reject_tmp to reject_current_tmp
> * loggily rename reject_current_tmp to reject_real
>
> (Also, the cp_and_translate implementation also runs a
> maybe_set_read_only and a maybe_set_executable at the end, but if you
> cancel after the copy but before these maybes, they'll be skipped on
> rerun. Perhaps they should be removed and any caller should be
> writing separate loggys for these "maybe" commands? There's even
> already loggy functions for them.)
I think it's pretty important that the loggy commands always observe
the principle of idempotent-or-discernable. Things will not be
maintainable in the long run if some commands are exceptional.
So yes, removing these commands and replacing them with groups of
commands that do obey that principle is the only way to go, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 26 22:34:45 2007