Yes, the best working practice is to maintain two svn working copies. One for trunk, and one for the branch (remember to "svn update" in both trees regularly!)
Here's a recommendation: I use a tool for comparing two directory trees, called zsCompare. It allows me to compare full directories, and see which files are different. Then I can open an individual file in both trees to compare side by side. Then I can merge lines of code from one tree to the other on a case-by-case basis. http://www.zizasoft.com/products/zsCompare/index.shtml The Lite version costs only US$35 for a single license. I think it's perfect for cases like this where you are comparing and merging bits between two similar trees of files. I started using zsCompare when I was programming in Java, because the tool can compare collections of files even inside .zip or .jar archives! It saved me a lot of time. Of course other tools exist that can be used in a similar way, but zsCompare works well for me. Regards, Bill Karwin > -----Original Message----- > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 17, 2007 3:00 PM > To: Bill Karwin; [email protected] > Subject: Re: [fw-general] Re: Lifecycle Handling > > Hy, > > which means that core-contributors have to have two released > on their workstations. > The trunk for new features and the branch for maintenance releases. > > That's what I asked for and noone was able to definitly say yes or no. > I expect most people would not be very amused if I fix bugs > only for 1.1 > (trunk) instead of 1.0.x (branch) ;-) > > Greetings > Thomas > I18N Team Leader > > ----- Original Message ----- > From: "Bill Karwin" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, July 17, 2007 11:15 PM > Subject: RE: [fw-general] Re: Lifecycle Handling > > > > > -----Original Message----- > > From: Thomas Weidner [mailto:[EMAIL PROTECTED] > > > > For example Zend_Date.... > > I've integrated new features (array access). > > But when there is a new bug I have to integrate it in trunk > > (where the new feature resists) and in maintenance. > > Otherwise the maintenance branch would also have the new > > feature integrated which is not allowed. > > This means there are a few choices: > > (a) Implement the same bug fix in a different way, to work > with the code > in the branch. But depending on the nature of the bug, this > may be too > much work. > > (b) Implement the bug fix in both trunk and branch, > implemented in a way > that doesn't rely on the new features. Sometimes this is > possible, but > sometimes it's not possible or it's too much work. > > (c) Fix the bug in the trunk but don't fix it in the branch. > Users must > wait until 1.1.0 to get some bug fixes. > > I think all cases will fit into the three choices above. :-) > > Regards, > Bill Karwin > >
