Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Jun 2020 20:41:18 -0700
From:      Ravi Pokala <rpokala@freebsd.org>
To:        <rgrimes@freebsd.org>
Cc:        Ian Lepore <ian@freebsd.org>, Dimitry Andric <dim@freebsd.org>, <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/libs...
Message-ID:  <AFC1FF59-FEC9-48B4-A89B-6BAEA9823F0A@panasas.com>
In-Reply-To: <202006020247.0522lkCD015032@gndrsh.dnsmgr.net>
References:  <A5B0F887-091B-4C4D-B005-CF9839B1BB6F@panasas.com> <202006020247.0522lkCD015032@gndrsh.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> > I generally feel the opposite -- I do a destressing amount of work on a=
n 80x24 serial console :-/ -- but I agree that "> 3 lines" is a reasonable c=
ompromise.
>=20
> I think we have had a communications breakdown?  To me it sounds as we bo=
th agree that needlessly making Makefiles vertically long is not wanted, but=
 acceptable when folding these very long lists onto wide lines creates a dif=
ferent problem.

That's exactly what I said: 'but I agree that "> 3 lines" is a reasonable c=
ompromise.'

:-)

-Ravi (rpokala@)

=EF=BB=BF-----Original Message-----
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Reply-To: <rgrimes@freebsd.org>
Date: 2020-06-01, Monday at 19:47
To: Ravi Pokala <rpokala@freebsd.org>
Cc: <rgrimes@freebsd.org>, Ian Lepore <ian@freebsd.org>, Dimitry Andric <di=
m@freebsd.org>, <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <sv=
n-src-head@freebsd.org>
Subject: Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/libapr li=
b/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsvn_diff=
 lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/libs...

    > -----Original Message-----
    > From: <owner-src-committers@freebsd.org> on behalf of "Rodney W. Grim=
es" <freebsd@gndrsh.dnsmgr.net>
    > Reply-To: <rgrimes@freebsd.org>
    > Date: 2020-06-01, Monday at 09:40
    > To: Ian Lepore <ian@freebsd.org>
    > Cc: Dimitry Andric <dim@freebsd.org>, <src-committers@freebsd.org>, <=
svn-src-all@freebsd.org>, <svn-src-head@freebsd.org>
    > Subject: Re: svn commit: r361677 - in head/usr.bin/svn: . lib lib/lib=
apr lib/libapr_util lib/libserf lib/libsvn_client lib/libsvn_delta lib/libsv=
n_diff lib/libsvn_fs lib/libsvn_fs_fs lib/libsvn_fs_util lib/libs...
    >=20
    >     > On Sun, 2020-05-31 at 22:04 +0000, Dimitry Andric wrote:
    >     > > Author: dim
    >     > > Date: Sun May 31 22:04:51 2020
    >     > > New Revision: 361677
    >     > > URL: https://svnweb.freebsd.org/changeset/base/361677
    >     > >=20
    >     > > Log:
    >     > >   Change Makefiles under usr.bin/svn to make them easier to
    >     > > incrementally
    >     > >   update. No functional change intended.
    >     > >  =20
    >     > >   MFC after:	2 weeks
    >     > >=20
    >     >=20
    >     > I wish we could get style.Makefile(9) updated to mandate this 1=
-per-
    >     > line style when listing sources, dirs, etc, when the number of =
items is
    >     > greater than N, where N is something like 3-6 filenames.  Other=
wise the
    >     > requirement to sort the names alphabetically pretty much mandat=
es that
    >     > many lines of the file will change just to insert one or two ne=
w files,
    >     > and that makes it all but impossible to figure out from a diff =
what
    >     > actually changed.
    >=20
    >     I like this idea, though rather than 3-6 filenames I propose
    >     it to be anything longer than 3 lines, which is kinda about when
    >     the pain point should start.  See the immediate SUBDIR below, it
    >     is 11 items on 2ish/3 lines, and any change would worst case be a
    >     3 line diff.  This probably covers a large portion of the tree.
    >=20
    > FWIW, I'm partial to the 'FOO+=3Dbar' syntax, rather than continuation =
lines. It's too easy to forget to add the continuation when appending or ins=
erting.

    That is indeed a better technique.

    >=20
    >     I particularly do not like massive amounts of vertical white
    >     space which this would create, but lacking an automated tool
    >     this is probably a reasonable compromise.
    >    =20
    >     If we did it everywhere it would mean lots of scrolling when
    >     working on rather simple makefiles.
    >=20
    > I generally feel the opposite -- I do a destressing amount of work on=
 an 80x24 serial console :-/ -- but I agree that "> 3 lines" is a reasonable=
 compromise.

    I think we have had a communications breakdown?  To me it sounds as we
    both agree that needlessly making Makefiles vertically long is
    not wanted, but acceptable when folding these very long lists
    onto wide lines creates a different problem.

    > -Ravi (rpokala@)
    >=20
    >     > -- Ian
    >     >=20
    >     > >=20
    >     > [...]=20
    >     > > -SUBDIR=3D	lib .WAIT \
    >     > > -	svn svnadmin svnbench svndumpfilter svnfsfs svnlook svnserv=
e \
    >     > > -	svnsync svnversion svnmucc svnrdump
    >     > > +SUBDIR=3D	lib \
    >     > > +	.WAIT \
    >     > > +	svn \
    >     > > +	svnadmin \
    >     > > +	svnbench \
    >     > > +	svndumpfilter \
    >     > > +	svnfsfs \
    >     > > +	svnlook \
    >     > > +	svnserve \
    >     > > +	svnsync \
    >     > > +	svnversion \
    >     > > +	svnmucc \
    >     > > +	svnrdump
    >     > >  SUBDIR_PARALLEL=3D
    >     > > =20
    >     >=20
    >     >=20
    >=20
    >     --=20
    >     Rod Grimes                                                 rgrime=
s@freebsd.org
    >=20
    >=20
    >=20

    --=20
    Rod Grimes                                                 rgrimes@free=
bsd.org





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFC1FF59-FEC9-48B4-A89B-6BAEA9823F0A>