Martin v. Löwis wrote: > Jim Fulton wrote: ... >> > which is tedious to do. >> >> It is *much* less so with subversion. We should switch. :) > > > Both Barry and you make this claim, which makes me curious. > How precisely is it more easy to apply the same change to two > branches in subversion? Being a long time subversion user, > I'ld normally just use the same procedure I use in CVS, i.e. > just apply the patch twice, and commit it twice. With CVS either: - When creating the branch, I have to be very carreful about tags, so that I can tell CVS to apply differences made between the 2 tags, or - I have to apply changes to each individual file affected. With subversion, every revision is is effectively a tag. Merging is usually just a matter of merging differences between 2 repository revision numbers. This makes a huge difference when multiple files are involved. >> I think that branching would tend to enforce the feature freeze. > > > Hmm. I'm both uncertain whether that would indeed be the case, I find that having a separate branch makes it absolutely unambiguous that only bug fixes should be created there. <shrug> > and > whether it would be a good thing. You seem the be saying that there > would be less changes on the branch. That might be the case. I'm saying that there would be fewer feature changes made. This definately seems like a good thing if features are supposed to be frozen. Python hasn't always done a good job of avoiding feature changes during beta cycles or on maintenence branches. If avoiding changes in such situations is desireable, as I think it is, then extra process to discourage such changes would be good. Jim -- Jim Fulton mailto:jim at zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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