avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Fixed various minor bugs
Date: Mon, 16 Feb 2004 14:11:38 +0100
User-agent: Mutt/1.2.5i

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.

> 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. ;-)

> > 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).

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]