On 10/26/07, Karl Fogel <kfogel@red-bean.com> wrote:
> "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.
Haven't had time to rewrite the *.prej code that uses
svn_wc__loggy_append, but in r27639 I "deprecated" the command, and
opened Issue #3015 for removing it. Bite-sized; should be pretty easy
for somebody looking to understand how the loggy code works.
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 7 01:33:20 2007