[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r9362 - in trunk: . notes

From: <kfogel_at_collab.net>
Date: 2004-04-16 15:58:34 CEST

Ben Reser <ben@reser.org> writes:
> Probably not, I noticed the same problem. I just was trying to get the
> releases document in a state that matches

Ah, understood.

> > > +2. Bump the version numbers in svn_version.h on trunk.
> > Well, not for a 1.0.2 release when trunk is already on 1.1.x, right?
>
> That's why you skip to step 3 as it says in step 1. :)

Sorry :-).

> That's fine. We should split the documents... The first half or so of
> the releases.txt file aren't really necessary to know just to make the
> tarball.

+1

> > IMHO, no need for us to talk about the merging guidelines much in
> > releases.txt. We have a self-sustaining voting system, the release
> > manager needs to know how it works and be able to evaluate the STATUS
> > file, but the merges themselves are not part of the release process
> > per se.
>
> Thus the pointer to HACKING. :)

Yup, saw the pointer to HACKING -- was just saying that therefore even
less of that material needs to be included in releases.txt.

> Correct. dist.sh changes the svn_version.h from a development version
> (this commit fixed a bug in the sed that wasn't entirely doing it
> properly). The commit later that changes the svn_version.h actually
> happens on the tag. The branch *NEVER* shows as a release build.
>
> Which reminds me, the comments in svn_version.h are wrong. They have
> instructions that don't match what we've actually been doing. Forgot to
> commit that fix.

Oooh. Urk. Thanks.

> > Ah! Interesting solution. And perfectly fine, IMHO. The point of a
> > tag is not that it can never have any commits at all, but that there
> > is a moment after which one can say "There should be no *more* commits".
>
> *nod* I'd rather the only commit that ever happens on the tag is the one
> that creates it. But it's too much effort to make that happen and I
> think it's more important to ensure that the branch never has something
> that looks like a release on it. Because a follow up commit could make
> the branch different than the release without fixing the svn_version.h

Cool.

/me bows in gratitude toward He Who Cleaneth The Augean Stables.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 16 17:13:34 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.