Nut upsdev - Oct 2005 - Preparing the 2.0.3-pre2 release (regex matcher)

On 10/1/05, Arnaud Quette <aquette.dev@gmail.com>
wrote:
>  I've decided, as an exception (the second with the ones for 2.0.2,
>  but hey, nut has a lot of late to resorb) to merge the USB
>  improvements from the CVS Development branch.
I took a look at backporting tripplite_usb to Testing. I don't see the
regex matcher, though. Do we want to merge that, too? Or should I use
the old version of tripplite_usb that simply matches the first Tripp
Lite unit that it finds?

--
- Charles Lepple

Charles Lepple wrote:
> 
> On 10/1/05, Arnaud Quette <aquette.dev@gmail.com> wrote:
> >  I've decided, as an exception (the second with the ones for
2.0.2,
> >  but hey, nut has a lot of late to resorb) to merge the USB
> >  improvements from the CVS Development branch.
> 
> I took a look at backporting tripplite_usb to Testing. I don't see the
> regex matcher, though. Do we want to merge that, too? Or should I use
> the old version of tripplite_usb that simply matches the first Tripp
> Lite unit that it finds?
My understanding was that Arnaud wanted to backport the recent
newhidups changes to the Testing branch, so I have done that just now.
The changes are in the Testing branch between the tags before_PSE_11
and after_PSE_11. With this, backporting tripplite_usb should be a
breeze.

I have also backported the corresponding changes to manpages, CHANGES,
and Makefiles, as far as they related to newhidups. I have also
backported the gendb change as well.

This backport covers all the stuff up to tag after_PSE_10 on the
Development branch.

P.S. I find the structure of the CVS tree confusing. Normally,
Development should be the main trunk, and the various releases,
snapshots, etc, should branch off from it. But it is the other way
around: Development is a branch of Testing. So if Development one day
becomes the new Testing branch, then the new Development branch will
have even longer revision numbers, and so forth. 

I think that after the move to SVN, the structure of the repository
will be a lot more transparent.

When doing backports today, I could clearly see the potential
advantage of SVN: in CVS, I had to go file by file, finding all the
changes that I wanted to backport. Whereas in SVN, I would have gone
changeset by changeset. This would make it much easier e.g. to
keep the entries in CHANGES in sync with the backported stuff.

-- Peter