Re: [avr-libc-dev] Fixed various minor bugs

[Theodore A. Roth]

On Mon, 16 Feb 2004, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > If you do a 'cvs diff -u > foo.diff' just before doing the commit,
> > you don't have to jump through hoops to pull out the diffs. It also
> > gives you a chance to review the patch yourself before the commit.
>
> I usually do, but don't store these files anywhere.  Most of the time,
> I rather only browse through the diff in "less" since I know I could
> review it again later on.
>
> Sigh, I'm currently quite disappointed about the slowness of working
> directly against subversions.gnu.org, compared to what I'm used to
> from the FreeBSD development environment.  It would have been a matter
> of 5 minutes to produce the desired diff for you, even without the
> more modern cvs(1) command that can take a -jrev:date argument: since
> all the commit logs are automatically recorded (as opposed to the
> cumbersome manually maintained ChangeLog), /together/ with their CVS
> ids of the change, I would have found out about all the affected file
> revisions quickly.
>
> In effect, producing the diff for you took me almost an hour. :-(
> (It's been quite late to realize that there were no other changes
> since 1.0.2, so I realized I could simply cvs diff against the tag for
> 1.0.2.)
>
> I wish they'd at least allow CVS mirroring again.  Remote CVS to
> subversions is currently dog slow.

Try it with an 28.8K dialup connection. ;-) That's what I'm stuck with
at home.

>
> > From there, it's also a trivial step to wrap the cvs diff command to
> > automate generating a patch with a ChangeLog entry stub ready to be
> > filled in. I've posted my wrapper script a few times already.
>
> Yeah, still I'd prefer the fully automated way where I only enter my
> cvs command once, and everything else is done by scripts. ;-)

Sure, but it's not an option right now. In the end, I'm still not
convinced that having that automated would save me more the 15-30
seconds over how I do it now. Plus, with how I do it, I can revert the
patch if it's not ready to commit, set it aside and when I come back to
it later, it's already got the ChangeLog entry in the patch so I know
what it's purpose was.

>
> > > symbolic names:
> > >         avr-lib-1_0_2-release: 1.293.2.32
> > >         avr-libc-1_0_1-release: 1.293.2.20
>
> > > Do we want to correct this?  (Should not be too difficult.)
>
> > Oops. I screwed that one up. It should be fixed, but I don't know a
> > trivial way to fix it. Do you know an easy way to do it?
>
> The simplest way is to check the tree out somewhere by the (wrong)
> symbolic name, apply the new tag, and then remove the old tag.  Then
> completely discard the checked-out tree again:
>
> % cvs update -Pd -ravr-lib-1_0_2-release
> % cvs tag avr-libc-1_0_2-release
> % cvs tag -d avr-lib-1_0_2-release
>
> [output snipped]
>
> I've verified the resulting tree against your official 1.0.2
> distribution tarball.  The only differences are related to the auto*
> generated files (my auto* version had a different patchlevel than
> yours).
>
>

It looks like you already fixed it. Thanks.

Ted Roth