On Fri, Mar 09, 2001 at 06:54:29AM -0800, [EMAIL PROTECTED] 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/
