You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Sozonoff <se...@globalbeach.com> on 2003/01/04 12:02:36 UTC
Re: [Proposal] Upgrade to JavaMail 1.3
All,
I propose that we upgrade to JavaMail 1.3 in order to benefit from the many
bug fixes this release has.
We can do this for the 2.1 branch first.
Sergei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Upgrade to JavaMail 1.3
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Serge Sozonoff" <se...@globalbeach.com>
> I propose that we upgrade to JavaMail 1.3 in order to benefit from the
many
> bug fixes this release has.
+1
I have done some simple testing(replace jar, send msgs) with Java Mail 1.3
and it seems to stand up.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I propose that we upgrade to JavaMail 1.3 in order to benefit from the
many
> bug fixes this release has.
On the list of things to do. Since I, personally, haven't tested it I was
going to wait until next week when I am in the office to test first. But
there is no reason why Danny, who has tested it, can't apply it to the CVS
right away.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Updating both branches
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > What is the appropriate method for updating both branches?
> Commit to one, commit to the other...
Well, OK. I was thinking that I would need to commit to one, and then merge
that commit into the other.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating both branches
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> +1 (yes, I'd apply [DnsJava update] to both branches)
>
>
> What is the appropriate method for updating both branches? I see that
> JavaMail was updated only in HEAD, and we want that in both branches, too.
> Plus, I also need to update KEYS and add README.html and HEADER.html to the
> CVS.
>
> --- Noel
Commit to one, commit to the other...
CVS's basic features lead to simple workflow. :)
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating both branches
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I think change the HEAD and merge into the branch.
> or add to HEAD and then branch the new file with the same branch name.
> But thats just an informed guess, someone else may have a firmer grasp..
>
> d.
For binary files and most of the changes we're making now, we don't
really need to merge. As long as we can continue to do this, the
better. If we really get into this, I would suggest we push for a
release of HEAD as 2.2 or an early non-contentious 3.x release and
branch again for another stabilization.
But if you need to merge, here are two excerpts from a CVS guide:
--------------------------------------------------------------------------
Merging an entire branch
You can merge changes made on a branch into your working copy by giving
the -j branch flag to the update command. With one -j branch option it
merges the changes made between the point where the branch forked and
newest revision on that branch (into your working copy).
The -j stands for "join".
Consider this revision tree:
+-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+
!
!
! +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
The branch 1.2.2 has been given the tag (symbolic name) R1fix. The
following example assumes that the module mod contains only one file, m.c.
$ cvs checkout mod # Retrieve the latest revision, 1.4
$ cvs update -j R1fix m.c # Merge all changes made on the branch,
# i.e. the changes between revision 1.2
# and 1.2.2.2, into your working copy
# of the file.
$ cvs commit -m "Included R1fix" # Create revision 1.5.
A conflict can result from a merge operation. If that happens, you
should resolve it before committing the new revision. See Conflicts
example.
The checkout command also supports the -j branch flag. The same effect
as above could be achieved with this:
$ cvs checkout -j R1fix mod
$ cvs commit -m "Included R1fix"
--------------------------------------------------------------------------
Merging from a branch several times
Continuing our example, the revision tree now looks like this:
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
where the starred line represents the merge from the R1fix branch to the
main trunk, as just discussed.
Now suppose that development continues on the R1fix branch:
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
+---------+ +---------+ +---------+
and then you want to merge those new changes onto the main trunk. If
you just use the cvs update -j R1fix m.c command again, CVS will attempt
to merge again the changes which you have already merged, which can have
undesirable side effects.
So instead you need to specify that you only want to merge the changes
on the branch which have not yet been merged into the trunk. To do that
you specify two -j options, and CVS merges the changes from the first
revision to the second revision. For example, in this case the simplest
way would be
cvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the
# head of the R1fix branch
The problem with this is that you need to specify the 1.2.2.2 revision
manually. A slightly better approach might be to use the date the last
merge was done:
cvs update -j R1fix:yesterday -j R1fix m.c
Better yet, tag the R1fix branch after every merge into the trunk, and
then use that tag for subsequent merges:
cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Updating both branches
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
OK. I can work it out, but if you have some sample CVS commands I'd prefer
not to experiment on our live CVS. :-)
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Tuesday, January 07, 2003 17:45
To: James Developers List
Subject: RE: Updating both branches
I think change the HEAD and merge into the branch.
or add to HEAD and then branch the new file with the same branch name.
But thats just an informed guess, someone else may have a firmer grasp..
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 07 January 2003 21:48
> To: James Developers List
> Subject: Updating both branches
>
>
> > +1 (yes, I'd apply [DnsJava update] to both branches)
>
> What is the appropriate method for updating both branches? I see that
> JavaMail was updated only in HEAD, and we want that in both branches, too.
> Plus, I also need to update KEYS and add README.html and
> HEADER.html to the
> CVS.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Updating both branches
Posted by Danny Angus <da...@apache.org>.
I think change the HEAD and merge into the branch.
or add to HEAD and then branch the new file with the same branch name.
But thats just an informed guess, someone else may have a firmer grasp..
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 07 January 2003 21:48
> To: James Developers List
> Subject: Updating both branches
>
>
> > +1 (yes, I'd apply [DnsJava update] to both branches)
>
> What is the appropriate method for updating both branches? I see that
> JavaMail was updated only in HEAD, and we want that in both branches, too.
> Plus, I also need to update KEYS and add README.html and
> HEADER.html to the
> CVS.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Updating both branches
Posted by "Noel J. Bergman" <no...@devtech.com>.
> +1 (yes, I'd apply [DnsJava update] to both branches)
What is the appropriate method for updating both branches? I see that
JavaMail was updated only in HEAD, and we want that in both branches, too.
Plus, I also need to update KEYS and add README.html and HEADER.html to the
CVS.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Upgrade to JavaMail 1.3
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Jason Webb" <jw...@inovem.com>
> We already use JavaMail 1.3 with James. JM 1.2 had way too many MIME bugs
in
> it.
> I've tested James (and our MLM code) with over 100K messages and found no
> serious problems with it. The test messages were taken from mbox archives
> off other mailing lists so have a variety of mail clients (and their
> encodings).
+1 (yes, I'd apply to both branches)
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by "Noel J. Bergman" <no...@devtech.com>.
None at all. I would expect them to be in both. Until we start working on
things that are specific to v3 (e.g., the Mailet API changes), there really
isn't much to branch. What is the best approach to get them into both?
Apply to v2.1 branch and merge into HEAD?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by Danny Angus <da...@apache.org>.
I have used it too, and no probs.
I can see no reason why these (javamail and dns) changes need be limited to
only the 2.1 branch and not applied to the HEAD too.
Can anyone?
d.
> We already use JavaMail 1.3 with James. JM 1.2 had way too many
> MIME bugs in
> it.
Yes hasn't it!
> I've tested James (and our MLM code) with over 100K messages and found no
> serious problems with it. The test messages were taken from mbox archives
> off other mailing lists so have a variety of mail clients (and their
> encodings).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Upgrade to JavaMail 1.3
Posted by Jason Webb <jw...@inovem.com>.
We already use JavaMail 1.3 with James. JM 1.2 had way too many MIME bugs in
it.
I've tested James (and our MLM code) with over 100K messages and found no
serious problems with it. The test messages were taken from mbox archives
off other mailing lists so have a variety of mail clients (and their
encodings).
No worries :)
-- Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>