Am 26.11.2015 um 16:13 schrieb Massimo Manghi: > > > On 11/26/2015 09:29 AM, Harald Oehlmann wrote: >> Am 25.11.2015 um 22:08 schrieb Massimo Manghi: >>> I have a proposal for adopting this release numbers scheme >>> >>> * I propose to prepare a 2.2.4 release simply removing the calls to >>> Tcl_DeleteInterp from src/apache-2/mod_rivet.c in order to fix the >>> occasional crashes during the child process termination >>> >>> * code in branches/2.2 should become branches/2.3, as I did quite a few >>> additions and also I changed the module initialization stage (it was >>> once declared that this would have marked a minor version number bump). >>> This new code deserves closer scrutiny and a longer testing time before >>> releasing >>> >>> * Code in trunk should become Rivet 3.0.0, as the core module was >>> radically changed >>> >>> Moreover, while branches/2.2 could be safely copied as branches/2.3 I >>> would like to bring it back to the status it had on Sep 9th when the >>> commit removing Tcl_DeleteInterp was carried out. Any other solution in >>> order to attain this set up is welcome >> >> Sounds good, thank you for the work! >> >> Harald >> > > I'm thinking of the best way to have a new 2.2 branch the way I want it > to be. > > I created a diff file with the patches between tags/2.2.3 (r1680965) and > r1702115 committed on Sep 9th. We could copy that tagged revision as > branches/2.2 (after the current branch is renamed as branches/2.3) and > apply the patch but the whole history after Sep 9th would disappear from > branches/2.2 (it will survive in branches/2.3). I found also this > command suggested by a svn wizard > > svn merge $(REPO)@$(GOODREV) $(WC) > > that would preserve the whole history > > what do you think Harald?
Couldn't you branch where all was still together and than better make foreward commits ? I use svn each day but with the great TourtoiseSVN user interface, so don't know about command line interface. Harald --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
