[Python-Dev] Re: [Python-checkins] CVS: python/nondist/sandbox/Lib README,NONE,1.1 davlib.py,NONE,1.1 httpx.py,NONE,1.1

[Guido van Rossum]

> As mostly a bystander in the python development process, i have a question
> about an alternative approach.  I believe we (zope dev) use branches for
> this kind of thing, and wonder whether you've considered using that? I
> gather that this is for things that have not yet gotten approval for
> inclusion in the distribution, but that doesn't disqualify the branch
> approach - branches need not ever be merged.
> 
> The two drawbacks i see with using branches this way:
> 
>  - More risk that configuration mistakes can lead to disruption, eg if
>    someone thinks they've established their checkout in the branch.
> 
>    That said, mistakes using the version control system are generally
>    painful, so care is needed in any event.
> 
>  - Pollution of the branch namespace.
> 
>    This can be mitigated by a good system for choosing names.
> 
> The advantage is that the subject files are developed where they're used,
> instead of some arbitrary other place.  This is easier on developers, and
> means that the initial development history is included in the version
> control history, rather than being in some separate (nondist/sandbox/...)
> place.
> 
> Is it worth considering using branches for this kind of thing?

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.

--Guido van Rossum (home page: http://www.python.org/~guido/)