[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 7857 - in trunk/subversion: libsvn_client libsvn_ra_svn libsvn_subr mod_dav_svn svnserve

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-11-27 03:12:26 CET

kfogel@collab.net wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>>>Modified:
>>>> trunk/subversion/libsvn_client/commit.c
>>>> trunk/subversion/libsvn_client/copy.c
>>>> trunk/subversion/libsvn_ra_svn/editorp.c
>>>> trunk/subversion/libsvn_subr/subst.c
>>>> trunk/subversion/mod_dav_svn/update.c
>>>> trunk/subversion/svnserve/serve.c
>>>>Log:
>>>>Clear svn_error_t errors rather than just ignoring them, else there is
>>>>a memory leak.
>>>
>>>Please follow our log message format conventions.
>>
>>Yeah, I was going to ask about that. I got too carried away with
>>the "same change in lots of places" optimisation that is documented
>>in HACKING. In this case I guess the list of changed files isn't
>>specific enough; I need to specify the functions as well. Will do.
>
> Actually, I thought Julian's log was fine.
>
> Anyone can figure out this change from reading its log and running
> 'svn diff'; and conversely, one can more or less tell what the change
> looks like just by reading the log.
>
> When both those conditions are met, it seems IMHO a good candidate for
> a "same change in lots of places" log message. It won't be more
> useful to list the functions individually (especially now that we have
> 'svn blame').
>
> Just my $0.02,
> -K

Oh, well, I don't mind either way. I've already changed it to how I think Branko likes it, and I think I may as well continue to do them in full when there are only half a dozen or so functions changed. It does mean that a reader can easily see whether he might be interested in the change.

By the way, mail gets through to me with varied and often large delays. I received your message just now, nearly an hour after it says you sent it, and that's not unusual these days.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 27 03:09:37 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.