Menu
▾
▴
fetchmail-devel
|
From: Graham W. <gr...@mk...> - 2004-10-20 07:33:26
|
On Tue, Oct 19, 2004 at 05:51:19PM -0500, sv...@de... wrote: > Added: > trunk/rfc2047e.c > Modified: > trunk/Makefile.am > trunk/fetchmail.h > Log: > Add RFC-2047 encoder for internationalized mail warnings. Shouldn't we be adding this stuff on a branch? Or have we decided that the next release will definitely support correctly encoded warning messages? Even then, shouldn't the code be on a branch until we're sure it's good? -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-10-20 12:58:30
|
Graham Wilson <gr...@mk...> writes: > On Tue, Oct 19, 2004 at 05:51:19PM -0500, sv...@de... wrote: >> Added: >> trunk/rfc2047e.c >> Modified: >> trunk/Makefile.am >> trunk/fetchmail.h >> Log: >> Add RFC-2047 encoder for internationalized mail warnings. > > Shouldn't we be adding this stuff on a branch? Or have we decided that > the next release will definitely support correctly encoded warning > messages? Even then, shouldn't the code be on a branch until we're sure > it's good? The issue at hand is that fetchmail warnings, if translated, are usually in violation of RFC-2822, by stuffing national characters (8-bit data) into headers and bodies unencoded and without markup. I've chosen the trivial approach of just listing the charset of the body and specifying it's 8-bit data (which may fail on ancient MTAs, but I don't care). Practical consequence: if you're using strict mail server settings, SpamAssassin or similar, all fetchmail warnings are either rejected or filtered out as spam, with the user not seeing the warning. Whoops. I hadn't heard contradictions last time I posted my progress indicator WRT the warning message fixes I deemed critical, so I'm a bit surprised by your comments now. I may need to change the integration though, we should interpolate variables before encoding and not just assume the interpolated stuff is US-ASCII, as we're still doing. -- Matthias Andree |
|
From: Graham W. <gr...@mk...> - 2004-10-23 23:09:02
|
On Wed, Oct 20, 2004 at 12:58:27PM +0200, Matthias Andree wrote: > Practical consequence: if you're using strict mail server settings, > SpamAssassin or similar, all fetchmail warnings are either rejected or > filtered out as spam, with the user not seeing the warning. Whoops. Yes, I realize the importance of fetchmail correctly encoding the message if it is in a non-ASCII character set: there is actually a Debian bug (#277324) asking for support for this. I also appreciate you working on it. > I hadn't heard contradictions last time I posted my progress indicator > WRT the warning message fixes I deemed critical, so I'm a bit surprised > by your comments now. Sorry for that. Your right, I should have posted something sooner. I just think that for larger changes like this, we should be working on branches that we can then re-integrate into the trunk. -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-10-24 13:38:37
|
Graham Wilson <gr...@mk...> writes: >> I hadn't heard contradictions last time I posted my progress indicator >> WRT the warning message fixes I deemed critical, so I'm a bit surprised >> by your comments now. > > Sorry for that. Your right, I should have posted something sooner. I > just think that for larger changes like this, we should be working on > branches that we can then re-integrate into the trunk. OK, I will figure how to branch and merge in Subversion and to that next time for "sweeping" changes that aren't self-contained in a single patch-set. It's only that I am not particularly fond of branches as most of my development efforts are still CVS-based, and CVS's branch handling is known to be inferior to SVN. -- Matthias Andree |
|
From: Graham W. <gr...@mk...> - 2004-11-12 19:12:48
|
On Sun, Oct 24, 2004 at 01:38:34PM +0200, Matthias Andree wrote: > OK, I will figure how to branch and merge in Subversion and to that next > time for "sweeping" changes that aren't self-contained in a single > patch-set. It's only that I am not particularly fond of branches as most > of my development efforts are still CVS-based, and CVS's branch handling > is known to be inferior to SVN. Branching and tagging is done by the same operation in Subversion. For example, if I wanted to create Debian branch for fetchmail, I could do the following (this doesn't modify your working copy): $ scp https://decoy.wox.org/svn/fetchmail/trunk \ https://decoy.wox.org/svn/fetchmail/branches/debian \ -m "Create a Debian branch of fetchmail." You can then switch your working copy of fetchmail to the Debian branch by doing the following: $ cd /path/to/my/wc $ svn switch https://decoy.wox.org/svn/fetchmail/branches/debian Switching back to the trunk is just as easy: $ cd /path/to/my/wc $ svn switch https://decoy.wox.org/svn/fetchmail/branches/debian To see what branch your working on current, use the info subcommand in the toplevel of your of your working copy: $ pwd /path/to/my/wc $ svn info Path: . URL: https://decoy.wox.org/svn/fetchmail/trunk Repository UUID: 6bd12b38-53dc-0310-98db-d94f1ca4f90c Revision: 4001 Node Kind: directory Schedule: normal Last Changed Author: m-a Last Changed Rev: 4001 Last Changed Date: 2004-11-10 16:57:00 -0600 (Wed, 10 Nov 2004) Properties Last Updated: 2004-08-08 03:22:17 -0500 (Sun, 08 Aug 2004) You can make checkins on a branch the same way you would on the trunk, as long as the info subcommand shows the branch, not the trunk. Tagging is done the same way as branching, except you copy to the tags directory, not the branhes directory, and you never checkin anything on a tag. The other important operation besides branching is merging. To merge the changes from the branch (make sure you are on the trunk, and not a branch): $ cd /path/to/my/wc $ svn merge https://decoy.wox.org/svn/fetchmail/trunk \ https://decoy.wox.org/svn/fetchmail/branches/debian (Note that this wouldn't make sense for the Debian branch, but this is just an example.) Check the output for any lines that start with C, which means that there was a conflict in the merge. Open the file, and search for the conflict markers, and resolve the conflict. Then do: $ svn resolved conflict.c Then you have to checkin the merged changes the same way you would normally checkin changes. To see what would be merged before doing the merge operation: $ svn diff https://decoy.wox.org/svn/fetchmail/trunk \ https://decoy.wox.org/svn/fetchmail/branches/debian The diff and merge subcommands are pretty similar, except the diff subcommand outputs the differences, while the merge subcommands applies them to your working copy. I'd be happy to answer any questions anyone has (assuming I can, of course :). -- gram |
|
From: Brian C. <B.C...@po...> - 2004-11-12 20:41:04
|
On Fri, Nov 12, 2004 at 12:12:37PM -0600, Graham Wilson wrote: > $ scp https://decoy.wox.org/svn/fetchmail/trunk \ > https://decoy.wox.org/svn/fetchmail/branches/debian \ > -m "Create a Debian branch of fetchmail." OT, but does Subversion really have a command 'scp'? That would conflict with the ubiquitous scp from ssh. > Tagging is done the same way as branching, except you copy to the tags > directory, not the branhes directory, and you never checkin anything on > a tag. Can you slide a tag if you need to? Regards, Brian. |
|
From: Graham W. <gr...@mk...> - 2004-11-12 20:56:08
|
On Fri, Nov 12, 2004 at 07:40:53PM +0000, Brian Candler wrote: > On Fri, Nov 12, 2004 at 12:12:37PM -0600, Graham Wilson wrote: > > $ scp https://decoy.wox.org/svn/fetchmail/trunk \ > > https://decoy.wox.org/svn/fetchmail/branches/debian \ > > -m "Create a Debian branch of fetchmail." > > OT, but does Subversion really have a command 'scp'? That would conflict > with the ubiquitous scp from ssh. No. I just mistype `svn cp' as `scp' pretty often. > > Tagging is done the same way as branching, except you copy to the tags > > directory, not the branhes directory, and you never checkin anything on > > a tag. > > Can you slide a tag if you need to? What do you mean? -- gram |
|
From: Brian C. <B.C...@po...> - 2004-11-12 21:27:42
|
On Fri, Nov 12, 2004 at 01:56:01PM -0600, Graham Wilson wrote: > > Can you slide a tag if you need to? > > What do you mean? I mean you tag a particular version of a file ready for a release, and then at the last minute change your mind, squeeze in a change, and move the release tag to the modified file. FreeBSD do it occasionally just before they make a release :-) |
|
From: Matthias A. <ma...@dt...> - 2004-11-12 21:46:23
|
Brian Candler <B.C...@po...> writes: > I mean you tag a particular version of a file ready for a release, and then > at the last minute change your mind, squeeze in a change, and move the > release tag to the modified file. > > FreeBSD do it occasionally just before they make a release :-) Haven't tried it, but I'd probably try killing (with svn remove) the tag directory, and then tag new (with svn tags). -- Matthias Andree |
|
From: Graham W. <gr...@mk...> - 2004-11-12 23:54:30
|
On Fri, Nov 12, 2004 at 09:46:21PM +0100, Matthias Andree wrote: > Brian Candler <B.C...@po...> writes: > > > I mean you tag a particular version of a file ready for a release, and then > > at the last minute change your mind, squeeze in a change, and move the > > release tag to the modified file. > > > > FreeBSD do it occasionally just before they make a release :-) > > Haven't tried it, but I'd probably try killing (with svn remove) the tag > directory, and then tag new (with svn tags). That is what I usually do. I don't know if there is a better way to do that or not though. -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-11-12 21:45:02
|
Graham Wilson <gr...@mk...> writes: > You can then switch your working copy of fetchmail to the Debian branch > by doing the following: > > $ cd /path/to/my/wc > $ svn switch https://decoy.wox.org/svn/fetchmail/branches/debian > > Switching back to the trunk is just as easy: > > $ cd /path/to/my/wc > $ svn switch https://decoy.wox.org/svn/fetchmail/branches/debian I presume that is ...fetchmail/trunk > Tagging is done the same way as branching, except you copy to the tags > directory, not the branhes directory, and you never checkin anything on > a tag. Are these "check in only on branches" enforced or is that just a convention? For this reminds me of what the svnbook recommended on the handling of vendor branches - and I see nothing but different names. > To see what would be merged before doing the merge operation: > > $ svn diff https://decoy.wox.org/svn/fetchmail/trunk \ > https://decoy.wox.org/svn/fetchmail/branches/debian Helluvalottotype :) > I'd be happy to answer any questions anyone has (assuming I can, of > course :). Thank you. -- Matthias Andree |
|
From: Graham W. <gr...@mk...> - 2004-11-12 23:56:20
|
On Fri, Nov 12, 2004 at 09:44:59PM +0100, Matthias Andree wrote: > Graham Wilson <gr...@mk...> writes: > > $ cd /path/to/my/wc > > $ svn switch https://decoy.wox.org/svn/fetchmail/branches/debian > > I presume that is ...fetchmail/trunk Yes. > > Tagging is done the same way as branching, except you copy to the tags > > directory, not the branhes directory, and you never checkin anything on > > a tag. > > Are these "check in only on branches" enforced or is that just a > convention? For this reminds me of what the svnbook recommended on the > handling of vendor branches - and I see nothing but different names. No, it is only by convention. > > To see what would be merged before doing the merge operation: > > > > $ svn diff https://decoy.wox.org/svn/fetchmail/trunk \ > > https://decoy.wox.org/svn/fetchmail/branches/debian > > Helluvalottotype :) Since I access all of my projects on my server, I set the SVN environment variable and do the following: $ echo $SVN https://decoy.wox.org/svn $ svn diff $SVN/fetchmail/trunk $SVN/fetchmail/branches/debian -- gram |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X