Re: [boost] is_pod.hpp change and RC_1_29_0

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-02 11:48:56

"John Maddock" <jm_at_[hidden]> writes:

> > On Friday 01 November 2002 12:47, John Maddock wrote:
> > > No, I did, I'll get it fixed (eventually), but is the release branch
> still
> > > in use?
> >
> > In the run-up towards a release I use the release branch, making
> infrequent
> > updates. To get the final version I usally only update the release branch.
> So
> > that's how I discovered the problem.
> >
> > In general I think that the release branch should be usable. I.e.
> reflecting
> > the released version with possible minor tweaks if we choose to use the
> > release branch to provide patched releases (e.g. 1.29.1).
> >
> > >
> > > Actually if your using the release branch can you make the change of all
> > > occurrences of is_POD.hpp to is_pod.hpp?
> >
> > I can make the neccessary changes. I just didn't want to fiddle with the
> > branch while I was not 100% sure what's going on.
> 
> This was one of those unintended consequences - and a lesson for the future.
> Basically cvs won't allow two files in the repository that differ only in
> the case of their name, so I had to get the sourceforge tech guys to make
> the change by editing the repository.  What none of us realised when we
> discussed the name change, was that this means that the files name has
> changed *for all versions of that file across all cvs branches*.  And that's
> what has retrospectively broken the release branch.  Thankfully it's a new
> file so only one release branch is affected, even so I see no alternative
> but to retrospectively patch that branch, as you say someone should be able
> to come along in the future and check out that branch and expect it to work,
> which is my way of telling you to go ahead and add the necessary patches
> (there should only be type_traits.hpp that needs patching plus one or two of
> the boost/type_traits/*.hpp headers).

This is bad. We have a release which is tagged Version_1_29_0. Should
we move the Version_1_29_0 tag on the appropriate files after applying
the neccessary patches, thus making Version_1_29_0 different from the
release archive, or should we leave the tag where it is, thus making
Version_1_29_0 broken in CVS for all time?

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com