On 10/26/07, Karl Fogel <kfogel red-bean.com> wrote:
> "David Glasser" <glasserdavidglasser.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 | glasserdavidglasser.net | http://www.davidglasser.
net/
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org
|