Daniel Stenberg <daniel@haxx.se> writes:
> > > + /* we didn't manage to write the complete file, we can't fulfill
> > > + what we're set out to do, get out */
> > > + return SVN_ERR_BAD_URL; /* FIX! add a correct error code */
> > > + }
> >
> > Aack. This causes a build warning. SVN_ERR_BAD_URL is but a numeric code.
> > You need to use svn_error_create to build an svn_error_t * structure to
> > return.
>
> I know, but leaving it creating a compiler warning like this will (make
> people) remind me about this and won't let me sleep well until I've cleaned
> up the client error code situation. Then I'll be able to add good error codes
> and messages to return.
Eh, but the rest of us don't want to see that warning. It might be
better just to return any old existing error and leave a big fat
/* ### todo: */ comment in there. Pretty please?
> > I suppose I can live with the spirit of this patch. I've been pushing for
> > the $EDITOR functionality, but I would prefer to simply pop up an empty
> > editor, not one full of a bunch of files that I should know already.
>
> Personally, I want the info in there even though I already knew it. I think
> it makes writing the commit message easier. However, I wouldn't mind using
> the verbose option or something to make that happen.
No, that's fine. If the community wants this functionality, the
community should have it. I've grown accustomed to simply deleting
everything in my CVS editor pop-ups before adding my log message, and
generally I keep a running log message as I code anyway (thanks to
some great elisp Karl composed).
> > - The code to open an editor populated with text and deal with the
> > return from its usage should be modularized.
>
> I'll make something up.
>
> > - Every commit that falls back to this editor code is going to now
> > have a `status' run on it on top of the regular commit stuff. That
> > means we're running text_modified_p checks on every target twice
> > now.
>
> Yes, but to get the status output in the editor, I didn't know what else to
> do.
Oh, I'm sure you did what you had to do to get the functionality up.
I'm not saying anything other than that. I just want us to remember
in the future that we have outstanding places for optimization in this
segment of code. Of course, there are probably outstanding places for
optimization about every 60 lines in Subversion, so ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:59 2006