Cleanest way of merging back changes to syslogd(8)?

[Ed Schouten]

Hi there,

Some time ago, Dave (cc) asked me whether I'd be interested in merging
back the RFC 5424 / ISO 8601 message format changes I made to
syslogd(8) to stable/11. Now that stable/11 is open again, I thought
I'd go and take a look at doing this.

It turns out that merging these changes back is quite challenging. The
copy of syslogd(8) in HEAD has diverged very strongly over the last
couple of years. There have also been some direct commits to
stable/11, so it seems to be (practically) impossible to come up with
an invocation of 'svn merge' that does what I expect it would.

Because of this, I am considering syncing syslogd(8) between stable/11
and HEAD entirely. More concrete, I want to do this:

stable-11 $ cp ../head/usr.sbin/syslogd/* usr.sbin/syslogd/
stable-11 $ svn revert usr.sbin/syslogd/Makefile.depend
stable-11 $ svn commit

My question is, what's the right way of doing this with SVN (e.g.,
w.r.t. mergeinfo)?

Thanks,
--
Ed Schouten <e...@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Dimitry Andric]

On 6 Jun 2018, at 10:48, Ed Schouten <e...@nuxi.nl> wrote:
>
> Some time ago, Dave (cc) asked me whether I'd be interested in merging
> back the RFC 5424 / ISO 8601 message format changes I made to
> syslogd(8) to stable/11. Now that stable/11 is open again, I thought
> I'd go and take a look at doing this.
>
> It turns out that merging these changes back is quite challenging. The
> copy of syslogd(8) in HEAD has diverged very strongly over the last
> couple of years. There have also been some direct commits to
> stable/11, so it seems to be (practically) impossible to come up with
> an invocation of 'svn merge' that does what I expect it would.
>
> Because of this, I am considering syncing syslogd(8) between stable/11
> and HEAD entirely. More concrete, I want to do this:
>
> stable-11 $ cp ../head/usr.sbin/syslogd/* usr.sbin/syslogd/
> stable-11 $ svn revert usr.sbin/syslogd/Makefile.depend
> stable-11 $ svn commit
>
> My question is, what's the right way of doing this with SVN (e.g.,
> w.r.t. mergeinfo)?

Try:

svn merge --accept=theirs-full ^/head/usr.sbin/syslogd usr.sbin/syslogd

which will "overwrite-merge" everything from head's version of syslogd
into stable/11's version of it.

After that, I am left with the following diff:

--- head/usr.sbin/syslogd/syslogd.c 2018-05-13 15:36:09.124043000 +0000
+++ stable-11/usr.sbin/syslogd/syslogd.c 2018-06-06 09:15:14.398673000 +0000
@@ -744,7 +744,7 @@ main(int argc, char *argv[])
fdsrmax = sl->sl_socket;
}
fdsr = (fd_set *)calloc(howmany(fdsrmax+1, NFDBITS),
- sizeof(*fdsr));
+ sizeof(fd_mask));
if (fdsr == NULL)
errx(1, "calloc fd_set");

@@ -763,7 +763,7 @@ main(int argc, char *argv[])
}

bzero(fdsr, howmany(fdsrmax+1, NFDBITS) *
- sizeof(*fdsr));
+ sizeof(fd_mask));

STAILQ_FOREACH(sl, &shead, next) {
if (sl->sl_socket != -1 && sl->sl_recv != NULL)

For some reason, the MFC of r332877 (in r333356) gets overwritten. I
guess there is nothing to do but manually correct that again.

Oh, and if you want to commit this, you'll have to attempt to defeat
the rather silly pre-commit scripts that want to limit subversion
merge information.

The svn:mergeinfo property on the usr.sbin/syslogd directory will have
to be moved to the root of the stable/11 tree, I'm not sure off the top
of my head how that should be done.

-Dimitry

[Ed Schouten]

Hi Dimitry,

2018-06-06 11:21 GMT+02:00 Dimitry Andric <d...@freebsd.org>:
> The svn:mergeinfo property on the usr.sbin/syslogd directory will have
> to be moved to the root of the stable/11 tree, I'm not sure off the top
> of my head how that should be done.

I did some searching around and it turns out that "svn mergeinfo
--show-revs eligible" can be used to get a list of commits that "svn
merge" would in fact try to merge back. By then running "svn merge" at
the root of the repository with that list of commits, I was able to
merge this back in such a way that the mergeinfo remains at the top of
the tree.

I've completed the merge in r335059. Thanks for your input Dimitry!

Best regards,