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

Re: (proposal) Subverion 1.0 date: 23 Feb 2004

From: Greg Stein <gstein_at_lyra.org>
Date: 2004-01-09 00:39:27 CET

On Thu, Jan 08, 2004 at 04:17:24PM -0600, kfogel@collab.net wrote:
> Looking over the STATUS file, and the current state of two
> vetoed-but-in-discussion issues, I think we can finally schedule the
> 1.0 release. Ben Collins-Sussman, Greg Stein and I chatted about
> this, and thought that four weeks of soak time for a candidate tarball
> (before we call it 1.0) is about right. Hope y'all agree.

Obviously, I do. :-)

>...
> Oh, regarding merging: I think it'll be easier if one person does it.
> I'd like to be that person. My plan is to apply committed changes
> roughly in order (to avoid spurious conflicts), then take changes from
> issues, and commit the whole shebang in one commit. This is okay
> because we already *have* the changesets in all cases -- either as
> revisions, or as patches. That way I can do my 'make check's once.

Not the patches. Those are not available as changesets within _source_
_control_. I don't want to say "oh, but that change is over in IZ."

IMO, each IZ patch that is being held for "only apply to trunk if also
applied to 1.0" should be applied to one of the branches first, then
merged over. IMO again, that should be trunk first, then port over to the
stabilization branch (as part of your big mother merge).

Each changeset should be in source control, then ported over. As you said:
if you need to make an adjustment, then that "should" be a separate commit
so the tweaked changeset is available.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 9 00:44:58 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.