apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: httpd-2.0/apr/apr-util Code Freeze
Date Fri, 09 Mar 2001 15:11:51 GMT
On Fri, Mar 09, 2001 at 06:54:29AM -0800, rbb@covalent.net wrote:
> On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote:
> > On Fri, 9 Mar 2001, Greg Stein wrote:
> >
> > > I don't think it has anything to do with mechanics, nor will throwing more
> > > process at the problem fix it. (more process will simply bog down what we
> > > can accomplish)
> >
> > ...?  if nothing else:

[ scheme described at Advogato ]

>...
> > > No... the problem is about perception. The rate of change recently has just
> > > been quite high. It just isn't very conceivable to make a release in that
> > > environment.
> >
> > ...
> >
> > ah, that's different.
> >
> > _however_ :)

Saw that coming :-)

> > once you _get_ to the point where cvs main is
> > always-releasable, then using this multi-tag process could help make cvs
> > main _remain_ always-releasable.

We only need it releasable when we want to release :-)

Seriously, the general policy is "do your best to keep it compiling and
working, but we understand that sometimes things simply break." We have
about a half dozen active committers, and things tend to work out fine (no
stepping on toes). We haven't really need any long term branching, but I do
know a couple cases where it would have been nice.

> > for, as you described - some significant modifications to mod_include
> > could be done in a dev_mod_include_rewrite tag, and only when completed
> > are they cvs merged into cvs main.
> >
> > surely that's not too much process to cause more pain than the benefits
> > are worth, neh?

It actually has some pretty big pain because of the merge problem. CVS has
horrible merging issues :-). Let's say that you had to grab some stuff from
HEAD and pull it into dev_mod_include_rewrite. Say, because some of the code
*around* you has changed, so you need the compensating changes from HEAD
into your branch.

Later on, you go to merge a reasonable stable form of the branch back into
HEAD, but all those bits you pulled over get reapplied back to HEAD,
generating a bunch of conflicts. You bitch, fix them, then check in the new
HEAD.

You continue some more work on the branch. You're finally done, so you go to
merge it back onto HEAD. Now you're really screwed. Pretty much the entire
set of changes causes conflicts because CVS doesn't record that you already
merged a good portion of the branch onto the HEAD.

It is a pain in the ass.

> There is a lot of resistance to using tags and branches the way you
> suggest Luke.  I believe it has already received a -1 on this list at some
> point, but I would have to look.  There are a lot of people who would
> agree with you that branching is a good thing, we just need to figure out
> how to address the concerns that other people have.

I don't know if a -1 occurred, but I'd certainly consider a negative vote
quite strongly (veto? dunno). The merge problem is just a pain in the ass.

Personally, I'd just state that we don't worry about the problem. Subversion
has *very* easy branching. And it records information about merges, so you
won't see the problems above. I'm presuming we'll want to switch to SVN for
any number of excellent reasons, and that would bring along a much better
branch/merge capability.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message