Oleg, I think we have some problem with the COOKIE2 branch. The code in the branch seems to be pretty old (not the one Ortwin reviewed). It was a mistake on my part while updating the patch in the sourceforge respository. I should always remove the patch file and add a new one, since cvs will take the diff of patch files and then update the repository patch.
Anyways, now I will try to create a patch of my existing code and the one in this branch and add a new patch file in sourceforge. I am making some changes to the code right now, so it will be done by evening today. -Samit. On 8/27/05, Michael Becke <[EMAIL PROTECTED]> wrote: > I would go with Oleg's suggestion. No point in muddying up the trunk > until after 3.0 final. Merging in the cookie2 changes shouldn't be > difficult as they are quite isolated and trunk is not likely to change > much more until after 3.0. > > Mike > > On 8/27/05, Ortwin Glück <[EMAIL PROTECTED]> wrote: > > Hey Oleg, > > > > No problem really. I am thinking of how to merge the two when the work > > is done. In my experience I learnt not to use CVS merge. I have no > > experience with SVN merging. So I would do it completely manually i.e. > > using "svn diff" and "patch". If (and only if) all changes are > > completely orthogonal (e.g. patches to TRUNK never interfere with any > > code that was touched on the branch) you can: > > * svn diff the branch's head against the branch start > > * apply this diff to trunk > > This should work smoothly. If the changes are not orthogonal however you > > will have a pain i.t.a. merging the two. > > > > But it is of course safer to keep the branch in sync by backporting and > > applying every patch we make for the trunk. The work is minimal as: > > * there won't (hopefully) not be many more patches until final 3.0 > > * we expect orthogonal changes, so no real backport work but just > > apply the same patch > > When the work on the branch is finished the branch code would then just > > completely replace everything that is on the trunk. Very easy merge indeed. > > > > How do the others feel about it? > > > > Odi > > > > PS. The term "backporting" is maybe a bit misleading. Read it as > > "integrating". > > > > > > Oleg Kalnichevski wrote: > > > Odi, > > > > > > I would not even bother keeping the COOKIE_2_BRANCH in sync with the > > > TRUNK. The Cookie2 changes are meant to be completely orthogonal to the > > > standard HTTP functions. The only critical bit are the changes to the > > > HttpMethodBase class that are luckily confined to just one or two > > > method. My Evil Plan (tm) is to let COOKIE_2_BRANCH evolve completely on > > > its own until the final 3.0 release. Immediately after the release we > > > may want branch off the 3.0 release tag the HTTPCLIENT_3_0_BRANCH, go > > > through the pain of merging COOKIE_2_BRANCH to the trunk only once and > > > live happily ever after > > > > > > What do you think about it? > > > > > > Oleg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
