On Tue, 11 Sep 2001, Guido van Rossum wrote: > I believe the sandbox is for an earlier stage in development. My > experiences so far with branches is that they present many surprises > and sources of confusion. How many times in Zope have you run into a > bug that was already fixed on a branch -- or on a trunk? Just > recently I reported a ZEO bug to Jeremy and he said "Oh yeah, that's > fixed on branch so-and-so; I haven't looked at the trunk for ages". :-( > > I like using short-lived branches for things like releases, but doing > the types/class unification on a branch probably caused more grief > than light. Merge problems certainly increase the longer the developing code is isolated from the trunk - whether or not you're using a branch for the developing code. (When the project is big enough, that code skew is inevitable - at least when using a branch you have the option to occasionally merge form the trunk into the in-process branch. I didn't follow the types/class unification very carefully, but have the impression that you and tim did some of that - perhaps later in the process than you would have, in retrospect, preferred.) I'm not the CVS practices maven here - brian lloyd has that pleasure;-) and in any case realize the cost/benefits balance is complicated. CVS branching does offer some real advantages, but the complication of realizing them can be an added burden, and CVS' foibles can muddy cost/benefit balance a good bit, as well - so i don't mean to suggest there's a clear-cut win here, one way or the other... Ken klm@zope.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4