Paul L Lussier <pll@lanminds.com> writes:
> >It's not a big problem, but I think the branch point is the wrong
> >revision to have in the CHANGES file, particularly if non-trivial
> >changes are then made to the branch.
>
> Hmmm. I see your point. Though, I would expect in general though,
> that a release manager should probably not be making non-trivial
> changes in a release branch. *I* certainly am not qualified to be
> doing so :)
Oh, it's not that the release manager will be deciding what changes to
include, but generally he will be including changes of arbitrary
complexity on the advice of others.
I think the best solution might be for the CHANGES file to use a
similar syntax to whatever 'svnversion' prints out for a mixed
revision working copy.
> >> Philip> r6284 was the last change on the branch before it was tagged
> >> Philip> (which means mprice had to guess the revision number in
> >> Philip> advance!).
> >>
> >> I'm not sure how to respond to this. Are you saying I should have
> >> done it's mprice's way, or that he was taking a change by guessing?
> >> I'm unclear as to what your concerns are. Can you explain a little
> >> more please?
> >
> >I don't really know what the correct procedure is--I've never made a
> >release!
>
> Wanna learn? I can show you ;)
I'm pretty sure that Michael Price guessed at the revision number, yes.
> >Guessing the revision is a bit of a hack, although it does produce a
> >neat result if it works (and it will usually work as the repository is
> >not that busy, on the odd occasion when it doesn't you can always try
> >again). If you don't want to guess then you could use a placeholder,
> >xxxx say, when committing the CHANGES file. Then do a final commit on
> >the branch that only changes the placeholder. That way it would only
> >be "trivially" out of date.
>
> Hmmm. okay. I'll try to keep that in mind for next time.
Yeah, I think doing a placeholder until the moment of release is
probably clearest.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 10 22:47:39 2003