>
> In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
>
> >> The first versions of CTM used diff -e and ed(1) to transmit changes,
> >> and that choked up on binary files. We didn't have patch in the
> >> tree back then.
>
> >patch has always b
In message , Andrew Gallatin
writes:
>On 3/14/19 11:36 PM, Rodney W. Grimes wrote:
>> [ Charset UTF-8 unsupported, converting... ]
>>> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
>>> wrote:
4. There is no easy way to show
"changed byte at offset 0x432 from 0xef to 0
On 3/14/19 11:36 PM, Rodney W. Grimes wrote:
[ Charset UTF-8 unsupported, converting... ]
On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
wrote:
4. There is no easy way to show
"changed byte at offset 0x432 from 0xef to 0xfe"
How do we represent Copyright and License in such objects?
Thi
On Fri, 15 Mar 2019, Poul-Henning Kamp wrote:
In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. Grimes"
writes:
The first versions of CTM used diff -e and ed(1) to transmit changes,
and that choked up on binary files. We didn't have patch in the
tree back then.
In message <201903150152.x2f1q34w027...@gndrsh.dnsmgr.net>, "Rodney W. Grimes"
writes:
>> The first versions of CTM used diff -e and ed(1) to transmit changes,
>> and that choked up on binary files. We didn't have patch in the
>> tree back then.
>patch has always been in the tree.
>htt
Before all of the uuencoded files get decoded in the tree.. are we sure that
non-uuencoded binary files will be proper identified if the mime type is
nonexistent in svn? What about other VCSes like hg?
I’m asking, because not all downstream vendors have the newest versions of svn,
once upon a t
> On Mar 14, 2019, at 20:26, Warner Losh wrote:
>
>
>
>> On Thu, Mar 14, 2019 at 9:14 PM Ed Maste wrote:
>> On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote:
>> >
>> > Libarchive tests and a few bzip2 files are all that is left in contrib.
>> > All can be converted without hassle from what
On Thu, Mar 14, 2019 at 9:36 PM Rodney W. Grimes
wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
> > wrote:
> > >
> > > 4. There is no easy way to show
> > >"changed byte at offset 0x432 from 0xef to 0xfe"
>
> How do we represent Copyr
On Thu, Mar 14, 2019 at 9:31 PM Ed Maste wrote:
> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
> wrote:
> >
> > 4. There is no easy way to show
> >"changed byte at offset 0x432 from 0xef to 0xfe"
>
> But this is not that easy with uuencoded files, either - I'd just end
> up uudecoding both
[ Charset UTF-8 unsupported, converting... ]
> On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
> wrote:
> >
> > 4. There is no easy way to show
> >"changed byte at offset 0x432 from 0xef to 0xfe"
How do we represent Copyright and License in such objects?
This is an issue that is totally left o
On Thu, 14 Mar 2019 at 22:39, Rodney W. Grimes
wrote:
>
> 4. There is no easy way to show
>"changed byte at offset 0x432 from 0xef to 0xfe"
But this is not that easy with uuencoded files, either - I'd just end
up uudecoding both files before running cmp -x. And for the case under
discussion h
On Thu, Mar 14, 2019 at 9:14 PM Ed Maste wrote:
> On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote:
> >
> > Libarchive tests and a few bzip2 files are all that is left in contrib.
> All can be converted without hassle from what I can see.
>
> But these (libarchive at least) are uuencoded in the u
On Thu, 14 Mar 2019 at 22:46, Warner Losh wrote:
>
> Libarchive tests and a few bzip2 files are all that is left in contrib. All
> can be converted without hassle from what I can see.
But these (libarchive at least) are uuencoded in the upstream repo,
and we won't make a local change to undo tha
On Thu, 14 Mar 2019 at 22:34, Rodney W. Grimes
wrote:
>
> > We definitely don't want to change files in contrib/ - that's up to
> > the upstreams.
>
> I think you miss understood, I belive in the paste, and possibly even
> still, that prep work was done to vendor code before import. We use
> to h
On Thu, Mar 14, 2019, 8:35 PM Rodney W. Grimes
wrote:
> > On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
> > wrote:
> > >
> > > Covered this in my reply to Warners reply. I think we also need to
> > > look at how this might affect vendor imported stuff, is there some if
> > > it that was .uu'ed
> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
> wrote:
> >
> > > The reason not to do it is uuencoding adds about a 40% space penalty,
> > > adds to the build time (to uudecode), and makes changes harder to
> > > review. In my mind dropping the unnecessary uuencoding is similar to
> > > droppin
On Thu, 14 Mar 2019 at 22:05, Rodney W. Grimes
wrote:
>
> How do the tools today deal with taking a binary off the vendor branch?
> Isn't this still a for-ever night mare merge thing to deal with?
There isn't really the concept of taking a file off the vendor branch
in the same way as with CVS, a
> On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
> wrote:
> >
> > Covered this in my reply to Warners reply. I think we also need to
> > look at how this might affect vendor imported stuff, is there some if
> > it that was .uu'ed before import?
>
> We definitely don't want to change files in con
On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
wrote:
>
> > The reason not to do it is uuencoding adds about a 40% space penalty,
> > adds to the build time (to uudecode), and makes changes harder to
> > review. In my mind dropping the unnecessary uuencoding is similar to
> > dropping build-time p
On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
wrote:
>
> Covered this in my reply to Warners reply. I think we also need to
> look at how this might affect vendor imported stuff, is there some if
> it that was .uu'ed before import?
We definitely don't want to change files in contrib/ - that's u
@freebsd.org>
> > Date: 2019-03-14, Thursday at 12:21
> > To: "Rodney W. Grimes"
> > Cc: src-committers , <
> svn-src-all@freebsd.org>,
> > Subject: Re: svn commit: r345138 - head/share/man/man9
> >
> > On Thu, 14 Mar 2019 at 14:55, Rodney
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> wrote:
> >
> > We should of documented what the decision process and criteria was
> > that lead to the decission to uuencode the files.
>
> Doing some archaeology, the first instance of a uuencoded file I can
> find is r1796, "Got rid of a couple
> On Thu, Mar 14, 2019 at 3:43 PM Ed Maste wrote:
>
> > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> > wrote:
> > >
> > > We should of documented what the decision process and criteria was
> > > that lead to the decission to uuencode the files.
> >
> > Doing some archaeology, the first insta
>
> In message
>
> , Ed Maste writes:
> >On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>
> >Doing some archaeology, the first instance of a uuencoded file I can
> >find is r1796, "Got rid of a couple of binary files by uuencoding. 49
> >more to go." There's no explanation of why the c
t; Date: 2019-03-14, Thursday at 12:21
> To: "Rodney W. Grimes"
> Cc: src-committers , ,
>
> Subject: Re: svn commit: r345138 - head/share/man/man9
>
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> wrote:
> >
> > [ Charset UTF-8 unsupported, converting.
On Thu, Mar 14, 2019 at 3:43 PM Ed Maste wrote:
> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> wrote:
> >
> > We should of documented what the decision process and criteria was
> > that lead to the decission to uuencode the files.
>
> Doing some archaeology, the first instance of a uuencoded
In message
, Ed Maste writes:
>On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
>Doing some archaeology, the first instance of a uuencoded file I can
>find is r1796, "Got rid of a couple of binary files by uuencoding. 49
>more to go." There's no explanation of why the change was made.
I
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
wrote:
>
> We should of documented what the decision process and criteria was
> that lead to the decission to uuencode the files.
Doing some archaeology, the first instance of a uuencoded file I can
find is r1796, "Got rid of a couple of binary files
it was
> dead long before I got my bit.
>
> -Ravi (rpokala@)
>
> -Original Message-
> From: on behalf of Ed Maste <
> ema...@freebsd.org>
> Date: 2019-03-14, Thursday at 12:21
> To: "Rodney W. Grimes"
> Cc: src-committers , ,
>
> Sub
lf of Ed Maste
Date: 2019-03-14, Thursday at 12:21
To: "Rodney W. Grimes"
Cc: src-committers , ,
Subject: Re: svn commit: r345138 - head/share/man/man9
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
wrote:
>
> [ Charset UTF-8 unsupported, converting... ]
> > Author: ema
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
wrote:
>
> [ Charset UTF-8 unsupported, converting... ]
> > Author: emaste
> > Date: Thu Mar 14 17:09:07 2019
> > New Revision: 345138
> > URL: https://svnweb.freebsd.org/changeset/base/345138
> >
> > Log:
> > firmware(9): remove uuencoded example
>
[ Charset UTF-8 unsupported, converting... ]
> Author: emaste
> Date: Thu Mar 14 17:09:07 2019
> New Revision: 345138
> URL: https://svnweb.freebsd.org/changeset/base/345138
>
> Log:
> firmware(9): remove uuencoded example
>
> We can (should) just commit the binary files to the source tree.
Author: emaste
Date: Thu Mar 14 17:09:07 2019
New Revision: 345138
URL: https://svnweb.freebsd.org/changeset/base/345138
Log:
firmware(9): remove uuencoded example
We can (should) just commit the binary files to the source tree.
Reviewed by: bz, imp, 0mp
Differential Revision:
33 matches
Mail list logo
