[Nut-upsdev] Preparing the 2.0.3-pre2 release (regex matcher)

[Charles Lepple]

On 10/9/05, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> Charles Lepple wrote:
> >
> > On 10/1/05, Arnaud Quette <aquette.dev at 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.

OK, I'll try to work on it.

That regex_matcher is a very elegant solution to the matching problem, btw.

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

It can be easier to follow branches in SVN, but it blurs the history
of files a little. As you found out before, SVN doesn't provide the
best support for tracking individual file history through renames
(though it is somewhat better than CVS, if you view the logs
manually).

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

you almost have to go tag-crazy in CVS to get the changeset functionality.

The good news is that you can view some of the older changesets in
Trac. Maybe I'll re-import a new snapshot of CVS into SVN/Trac for
that purpose.

--
- Charles Lepple