Hi all, I added some minor changes to the version lifecycle document today. Included is a note and svn checkout example about checking out the release branch and trunk separately:
http://framework.zend.com/wiki/x/HYo You can click the envelope icon in the upper right-hand part of the page to "watch" the page and receive e-mail when a change is made. Still no comments on the document... who will be the brave first poster? Best regards, Darby Thomas Weidner wrote: > I use also tools which are able to do such things... > UltraCompare is my choice. > > I think we should also write this "best practice" into the document. > Just to mention: Even if the things are clear to me, I asked this > questions because documentation did not make this clear enough ;-) > > Greetings > Thomas > I18N Team Leader > > ----- Original Message ----- From: "Bill Karwin" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, July 18, 2007 12:20 AM > Subject: RE: [fw-general] Re: Lifecycle Handling > > > 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 >> >> > >
