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]
