-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Actually, this note really applies to just restarting mailman a Mailman 2.1.9 installation, with or without upgrading to Mailman 2.1.10. But in installations that just 'run' without intervention, this restart may not occur until an upgrade.
There is an error in Mailman 2.1.9. In the introduction of the backup and recovery of queue entries, we neglected to remove the backup queue entry for an unparseable message. Thus, if you sometimes receive unparseable messages which are ignored, you may have an accumulation of .bak files in qfiles/in from these messages. When you restart Mailman, these will all be reprocessed, resulting in a flood of error log entries.
There is no real harm done, but it would be a good idea when upgrading to stop Mailman and remove any qfiles/in/*.bak files.
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIDgCwVVuXXpU7hpMRAlOyAJ4/VpFnCL9JHoEBSl4PmZIBowTbigCgjjRr Bh8FoeuGZDAXonphAnvqwMA= =qt1K -----END PGP SIGNATURE-----
On Tue, 22 Apr 2008, Mark Sapiro wrote:
Actually, this note really applies to just restarting mailman a Mailman 2.1.9 installation, with or without upgrading to Mailman 2.1.10. But in installations that just 'run' without intervention, this restart may not occur until an upgrade.
There is an error in Mailman 2.1.9. In the introduction of the backup and recovery of queue entries, we neglected to remove the backup queue entry for an unparseable message. Thus, if you sometimes receive unparseable messages which are ignored, you may have an accumulation of .bak files in qfiles/in from these messages. When you restart Mailman, these will all be reprocessed, resulting in a flood of error log entries.
There is no real harm done, but it would be a good idea when upgrading to stop Mailman and remove any qfiles/in/*.bak files.
Just a thought, Mark, for consideration...
If this is deemed "Important" (for anyone upgrading over the next year or more), and if this cleaning process is well-defined and capable of mechanisation, then might it be worth superseding 2.1.10 with a "2.1.10a" (or 2.1.11 or whatever nomeclature is appropriate) that automatically does this cleaning?
(I realise that 2.1.x was intended to be frozen at 2.1.10, but wasn't there allowance for significant security fixes and bug fixes?)
(Only sending this to -developers list.)
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
+1 on the auto-delete. I have a lot of boxes running Mailman that I periodically have to go into to clean out stuff, and having more junk pile up, while helpful for debugging, isn't great for production.
Bob
David Lee wrote:
On Tue, 22 Apr 2008, Mark Sapiro wrote:
Actually, this note really applies to just restarting mailman a Mailman 2.1.9 installation, with or without upgrading to Mailman 2.1.10. But in installations that just 'run' without intervention, this restart may not occur until an upgrade.
There is an error in Mailman 2.1.9. In the introduction of the backup and recovery of queue entries, we neglected to remove the backup queue entry for an unparseable message. Thus, if you sometimes receive unparseable messages which are ignored, you may have an accumulation of .bak files in qfiles/in from these messages. When you restart Mailman, these will all be reprocessed, resulting in a flood of error log entries.
There is no real harm done, but it would be a good idea when upgrading to stop Mailman and remove any qfiles/in/*.bak files.
Just a thought, Mark, for consideration...
If this is deemed "Important" (for anyone upgrading over the next year or more), and if this cleaning process is well-defined and capable of mechanisation, then might it be worth superseding 2.1.10 with a "2.1.10a" (or 2.1.11 or whatever nomeclature is appropriate) that automatically does this cleaning?
(I realise that 2.1.x was intended to be frozen at 2.1.10, but wasn't there allowance for significant security fixes and bug fixes?)
(Only sending this to -developers list.)
Bob Puff@NLE wrote:
+1 on the auto-delete. I have a lot of boxes running Mailman that I periodically have to go into to clean out stuff, and having more junk pile up, while helpful for debugging, isn't great for production.
David Lee wrote:
If this is deemed "Important" (for anyone upgrading over the next year or more), and if this cleaning process is well-defined and capable of mechanisation, then might it be worth superseding 2.1.10 with a "2.1.10a" (or 2.1.11 or whatever nomeclature is appropriate) that automatically does this cleaning?
I think this is a good idea. If I had remembered about the unparseable .bak files, and thought it through, I could have added code to bin/update to remove them, and I still can for a fix-up release.
Also, In another thread, Barry asked for feedback on "some kind of shunt queue culler cron script". I think this is a good idea, either for a separate cron, or incorporated into one of the existing crons.
How about something like a couple of Default config settings like
BAD_SHUNT_ARCHIVE_DIRECTORY = None BAD_SHUNT_STALE_AFTER = days(7)
With the idea being anything in the 'bad' or 'shunt' queues older than BAD_SHUNT_STALE_AFTER would be discarded or moved to BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
Do people like this idea?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
How about something like a couple of Default config settings like
BAD_SHUNT_ARCHIVE_DIRECTORY = None BAD_SHUNT_STALE_AFTER = days(7)
With the idea being anything in the 'bad' or 'shunt' queues older than BAD_SHUNT_STALE_AFTER would be discarded or moved to BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
Do people like this idea?
Seems like a good plan.
-- Eino Tuominen
Sounds good to me!
Bob
Mark Sapiro wrote:
How about something like a couple of Default config settings like
BAD_SHUNT_ARCHIVE_DIRECTORY = None BAD_SHUNT_STALE_AFTER = days(7)
With the idea being anything in the 'bad' or 'shunt' queues older than BAD_SHUNT_STALE_AFTER would be discarded or moved to BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
Do people like this idea?
On Tue, Apr 22, 2008 at 11:44:05AM -0700, Mark Sapiro wrote:
How about something like a couple of Default config settings like
BAD_SHUNT_ARCHIVE_DIRECTORY = None BAD_SHUNT_STALE_AFTER = days(7)
With the idea being anything in the 'bad' or 'shunt' queues older than BAD_SHUNT_STALE_AFTER would be discarded or moved to BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
Do people like this idea?
+1
-- Cristóbal Palmer ibiblio.org systems administrator
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 22, 2008, at 2:44 PM, Mark Sapiro wrote:
Bob Puff@NLE wrote:
+1 on the auto-delete. I have a lot of boxes running Mailman that
I periodically have to go into to clean out stuff, and having more junk pile up, while helpful for
debugging, isn't great for production.David Lee wrote:
If this is deemed "Important" (for anyone upgrading over the next
year or more), and if this cleaning process is well-defined and capable of mechanisation, then might it be worth superseding 2.1.10 with a
"2.1.10a" (or 2.1.11 or whatever nomeclature is appropriate) that
automatically does this cleaning?I think this is a good idea. If I had remembered about the unparseable .bak files, and thought it through, I could have added code to bin/update to remove them, and I still can for a fix-up release.
Also, In another thread, Barry asked for feedback on "some kind of shunt queue culler cron script". I think this is a good idea, either for a separate cron, or incorporated into one of the existing crons.
How about something like a couple of Default config settings like
BAD_SHUNT_ARCHIVE_DIRECTORY = None BAD_SHUNT_STALE_AFTER = days(7)
With the idea being anything in the 'bad' or 'shunt' queues older than BAD_SHUNT_STALE_AFTER would be discarded or moved to BAD_SHUNT_ARCHIVE_DIRECTORY if it existed.
Do people like this idea?
+1, but I think it should be a separate cron script. Keep 'em small
and simple!
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)
iQCVAwUBSA+cznEjvBPtnXfVAQIzwAQAqGE8xQ+fFoZb7Y1kEEQv/y+BpVRdmTYm qQeCrMR6V4/nO9xFhavaDE38VWywh7u8U0zMvdAQA6nUVv5z2QVTHEMfIvEzIevV AUBDSWuckoWh4T1dGENPn8O32ni65JiuIeUFZHwekZtqSXu5qJlQGul0HeGhezpr RaNfE77wO88= =QpNE -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote: | On Apr 22, 2008, at 2:44 PM, Mark Sapiro wrote: | |> Bob Puff@NLE wrote: | |>> +1 on the auto-delete. [...] | |>> David Lee wrote: |>>> |>>> If this is deemed "Important" (for anyone upgrading over the next |>>> year or |>>> more), and if this cleaning process is well-defined and capable of |>>> mechanisation, then might it be worth superseding 2.1.10 with a |>>> "2.1.10a" |>>> (or 2.1.11 or whatever nomeclature is appropriate) that |>>> automatically does |>>> this cleaning? | | |> I think this is a good idea. If I had remembered about the unparseable |> .bak files, and thought it through, I could have added code to |> bin/update to remove them, and I still can for a fix-up release. | |> Also, In another thread, Barry asked for feedback on "some kind of |> shunt queue culler cron script". I think this is a good idea, either |> for a separate cron, or incorporated into one of the existing crons. | |> How about something like a couple of Default config settings like | |> BAD_SHUNT_ARCHIVE_DIRECTORY = None |> BAD_SHUNT_STALE_AFTER = days(7) | |> With the idea being anything in the 'bad' or 'shunt' queues older than |> BAD_SHUNT_STALE_AFTER would be discarded or moved to |> BAD_SHUNT_ARCHIVE_DIRECTORY if it existed. | |> Do people like this idea? | | +1, but I think it should be a separate cron script. Keep 'em small and | simple!
I have implemented a cull_bad_shunt cron and a small change to bin/update to remove any .bak files from qfiles/ on an upgrade.
These changes are revisions 1074 and 1075 in the branch at <https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt>.
Revision 1071 is the 2.1.10 release. Revisions 1072 and 1073 have been committed to the 2.1 branch and a patch for these changes is on the sourceforge and GNU download sites.
I would appreciate feedback on the 1074 and 1075 revisions from those interested.
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIFMoqVVuXXpU7hpMRAkP8AJ44h0xk1sBBNLTrrIpcMsta0FR5sACfcVln A9tSvvHb1ZwuU397YEY0wfY= =Bh2q -----END PGP SIGNATURE-----
On Apr 27, 2008, at 2:47 PM, Mark Sapiro wrote:
I would appreciate feedback on the 1074 and 1075 revisions from those interested.
Mark, these changes look pretty good. I have some minor comments
about the formatting but that's it.
-Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote: | On Apr 27, 2008, at 2:47 PM, Mark Sapiro wrote: |> |> I would appreciate feedback on the 1074 and 1075 revisions from those |> interested. | | Mark, these changes look pretty good. I have some minor comments about | the formatting but that's it. | | -Barry | | | ------------------------------------------------------------------------ [...] |> > + preserve=True | | There should be spaces around the = sign.
Agreed. I must have been thinking ahead (or not thinking) to it's ultimate use as an argument in
~ self._switchboard.finish(filebase, preserve=preserve)
[...] |> > + preserve=False | | Same here.
Yep.
[...] | + if (mlist._internal_name <> 'en' and mlist._internal_name not in | + os.listdir(mm_cfg.MESSAGES_DIR)): | | I would format this code like this: | | if (mlist._internal_name <> 'en' and | mlist._internal_name not in os.listdir(mm_cfg.MESSAGES_DIR)): | # It's okay to move the template.
Yes, that's clearly better. It always helps to have someone else review stuff. Thanks.
BTW, the above stuff all comes from changes I made on the 2.1 branch at revs 1072 and 1074. Did anyone look at the cull_bad_shunt cron and bin/update change at revs 1074 and 1075 of <https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt>?
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIHI+mVVuXXpU7hpMRAt3tAJ0TIj6tBaoK2n5IXqxDWC5COT0tQwCggy2h ITXy+VKlxj/Gd8HxKwuqYnc= =DVJz -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 3, 2008, at 12:15 PM, Mark Sapiro wrote:
BTW, the above stuff all comes from changes I made on the 2.1 branch
at revs 1072 and 1074. Did anyone look at the cull_bad_shunt cron and bin/update change at revs 1074 and 1075 of <https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt>?
Mark,
There looks to be something very strange going on with this branch.
How did you create it?
- -Barry
% bzr info Repository tree (format: pack-0.92) Location: shared repository: /Users/barry/projects/mailman repository branch: .
Related branches: parent branch: http://bazaar.launchpad.net/%7Emsapiro/mailman/cull_bad_shunt/
% bzr version-info revision-id: mark@msapiro.net-20080427175235-ld4mi9cf2aunq27b date: 2008-04-27 10:52:35 -0700 build-date: 2008-05-18 18:29:34 -0400 revno: 2 branch-nick: cull_bad_shunt
% bzr log | head -n 20
revno: 1075 committer: Mark Sapiro <mark@msapiro.net> branch nick: cull_bad_shunt timestamp: Sun 2008-04-27 10:52:35 -0700 message: Changed bin/update to remove .bak qfiles.
revno: 1074 committer: Mark Sapiro <mark@msapiro.net> branch nick: cull_bad_shunt timestamp: Sun 2008-04-27 10:37:39 -0700 message: Added new cron/cull_bad_shunt and supporting Defaults.py.in settings.
revno: 1073 committer: Mark Sapiro <mark@msapiro.net> branch nick: 2.1 timestamp: Sat 2008-04-26 17:59:18 -0700 message:
% bzr log -r 1074..1075
bzr: ERROR: Requested revision: u'1074' does not exist in branch:
BzrBranch6('file:///Users/barry/projects/mailman/cull_bad_shunt/')
% bzr diff -r 1073..1075
bzr: ERROR: Requested revision: u'1073' does not exist in branch:
BzrBranch6('file:///Users/barry/projects/mailman/cull_bad_shunt/')
% bzr diff -r 1..-1 bzr: ERROR: exceptions.AssertionError: revno/history mismatch
Traceback (most recent call last): [...] AssertionError: revno/history mismatch
bzr 1.4 on python 2.5.2 (darwin)
arguments: ['/opt/local/bin/bzr', 'diff', '-r', '1..-1']
encoding: 'US-ASCII', fsenc: 'utf-8', lang: None
plugins:
bzrtools /opt/local/lib/python2.5/site-packages/bzrlib/
plugins/bzrtools [1.4.0]
fastimport /Users/barry/.bazaar/plugins/fastimport
[unknown]
hgimport /Users/barry/.bazaar/plugins/hgimport [unknown]
launchpad /opt/local/lib/python2.5/site-packages/bzrlib/
plugins/launchpad [unknown]
loom /Users/barry/.bazaar/plugins/loom [1.4.0dev0]
touch /Users/barry/.bazaar/plugins/touch.py [unknown]
*** Bazaar has encountered an internal error.
Please report a bug at https://bugs.launchpad.net/bzr/+filebug
including this traceback, and a description of what you
were doing when the error occurred.
(Note that this last exception seems to be fixed in bzr 1.5rc1 on
Ubuntu.)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkgwsv8ACgkQ2YZpQepbvXE2MwCeMjJ7cvbgPkVnT2ZRcac8XQw8 tLkAn3OkvfFZZ8WKTfyTuuxZ9qIKH/fh =2aRC -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote: | On May 3, 2008, at 12:15 PM, Mark Sapiro wrote: | |> BTW, the above stuff all comes from changes I made on the 2.1 branch at |> revs 1072 and 1074. Did anyone look at the cull_bad_shunt cron and |> bin/update change at revs 1074 and 1075 of |> <https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt>? | | Mark, | | There looks to be something very strange going on with this branch. How | did you create it?
I have a directory, MM_bzr, on my local workstation that has been 'bzr init'd and has subdirectories 2.1, 2.2, 3.0 and admin which initially were populated via 'bzr co' from launchpad. Everything has subsequently been upgraded with 'bzr upgrade --pack-0.92'. Local bzr is 1.2.0.
I created MM_bzr/cull_bad_shunt locally with bzr branch from MM_bzr/2.1 at rev 1074. I then committed revs 1074 and 1075. I created the cull_bad_shunt branch on launchpad and then 'bzr push'd my local branch.
| % bzr info | Repository tree (format: pack-0.92) | Location: | shared repository: /Users/barry/projects/mailman | repository branch: . | | Related branches: | parent branch: | http://bazaar.launchpad.net/%7Emsapiro/mailman/cull_bad_shunt/
$ bzr info Standalone tree (format: pack-0.92) Location: ~ branch root: .
Related branches: ~ push branch: bzr+ssh://msapiro@bazaar.launchpad.net/%7Emsapiro/mailman/cull_bad_shunt/ ~ submit branch: /cygdrive/c/MM_bzr/2.1
| % bzr version-info | revision-id: mark@msapiro.net-20080427175235-ld4mi9cf2aunq27b | date: 2008-04-27 10:52:35 -0700 | build-date: 2008-05-18 18:29:34 -0400 | revno: 2 | branch-nick: cull_bad_shunt
$ bzr version-info revision-id: mark@msapiro.net-20080427175235-ld4mi9cf2aunq27b date: 2008-04-27 10:52:35 -0700 build-date: 2008-05-18 17:21:11 -0700 revno: 1075 branch-nick: cull_bad_shunt
| % bzr log | head -n 20 | ------------------------------------------------------------ | revno: 1075 | committer: Mark Sapiro <mark@msapiro.net> | branch nick: cull_bad_shunt | timestamp: Sun 2008-04-27 10:52:35 -0700 | message: | Changed bin/update to remove .bak qfiles. | ------------------------------------------------------------ | revno: 1074 | committer: Mark Sapiro <mark@msapiro.net> | branch nick: cull_bad_shunt | timestamp: Sun 2008-04-27 10:37:39 -0700 | message: | Added new cron/cull_bad_shunt and supporting Defaults.py.in settings. | ------------------------------------------------------------ | revno: 1073 | committer: Mark Sapiro <mark@msapiro.net> | branch nick: 2.1 | timestamp: Sat 2008-04-26 17:59:18 -0700 | message:
$ bzr log | head -n 20
revno: 1075 committer: Mark Sapiro <mark@msapiro.net> branch nick: cull_bad_shunt timestamp: Sun 2008-04-27 10:52:35 -0700 message: ~ Changed bin/update to remove .bak qfiles.
revno: 1074 committer: Mark Sapiro <mark@msapiro.net> branch nick: cull_bad_shunt timestamp: Sun 2008-04-27 10:37:39 -0700 message: ~ Added new cron/cull_bad_shunt and supporting Defaults.py.in settings.
revno: 1073 committer: Mark Sapiro <mark@msapiro.net> branch nick: 2.1 timestamp: Sat 2008-04-26 17:59:18 -0700 message:
| % bzr log -r 1074..1075 | bzr: ERROR: Requested revision: u'1074' does not exist in branch: | BzrBranch6('file:///Users/barry/projects/mailman/cull_bad_shunt/')
$ bzr log -r 1074..1075
revno: 1075 committer: Mark Sapiro <mark@msapiro.net> branch nick: cull_bad_shunt timestamp: Sun 2008-04-27 10:52:35 -0700 message: ~ Changed bin/update to remove .bak qfiles.
revno: 1074 committer: Mark Sapiro <mark@msapiro.net> branch nick: cull_bad_shunt timestamp: Sun 2008-04-27 10:37:39 -0700 message: ~ Added new cron/cull_bad_shunt and supporting Defaults.py.in settings.
| % bzr diff -r 1073..1075 | bzr: ERROR: Requested revision: u'1073' does not exist in branch: | BzrBranch6('file:///Users/barry/projects/mailman/cull_bad_shunt/') | | | % bzr diff -r 1..-1 | bzr: ERROR: exceptions.AssertionError: revno/history mismatch
Both of the above bzr diff commands work in my local branch.
Also, browsing the branch and changes at <https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt> seems to produce expected results.
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIMMpyVVuXXpU7hpMRAspEAKD76xlQh7OyOHBBby3aWgRd4B5j/wCgoaJG 9ph9yf/lka0Yqx1ylTH1ygk= =3/rS -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 18, 2008, at 8:31 PM, Mark Sapiro wrote:
I have a directory, MM_bzr, on my local workstation that has been 'bzr init'd and has subdirectories 2.1, 2.2, 3.0 and admin which initially were populated via 'bzr co' from launchpad. Everything has
subsequently been upgraded with 'bzr upgrade --pack-0.92'. Local bzr is 1.2.0.I created MM_bzr/cull_bad_shunt locally with bzr branch from MM_bzr/ 2.1 at rev 1074. I then committed revs 1074 and 1075. I created the cull_bad_shunt branch on launchpad and then 'bzr push'd my local
branch.
What happens if you
bzr branch http://bazaar.launchpad.net/~msapiro/mailman/cull_bad_shunt
?
When I do this, either in my shared repository or in a fresh
directory. I get only 2 revisions.
Both of the above bzr diff commands work in my local branch.
What about in a pristine branch?
Also, browsing the branch and changes at <https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt> seems to produce expected results.
Does it? It looks weird to me. For example, why all the renamed
files in rev 1074?
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkgw1iMACgkQ2YZpQepbvXE3lwCdF3CqO9iOFP06kKEdSkiq6yDF Qn8An1VDhluLghnacPv19twbl8nIErjj =SZ28 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote: | | What happens if you | | bzr branch http://bazaar.launchpad.net/~msapiro/mailman/cull_bad_shunt | | ? | | When I do this, either in my shared repository or in a fresh directory. | I get only 2 revisions.
I'm doing this now in a new directory. I'll post the result after it completes.
|> Both of the above bzr diff commands work in my local branch. | | What about in a pristine branch? | |> Also, browsing the branch and changes at |> <https://code.launchpad.net/~msapiro/mailman/cull_bad_shunt> seems to |> produce expected results. | | Does it? It looks weird to me. For example, why all the renamed files | in rev 1074?
Yes, that is strange, but that is in my local rev 1074 too. I didn't understand it, but it seemed harmless at the time.
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIMNeuVVuXXpU7hpMRAhM6AKCEywK0Fkb31W4/zSA/iFLzMBZI4gCeN+ax QqVcKMxm5yVwvhTpmtk0Qpg= =n6b0 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Sapiro wrote: | Barry Warsaw wrote: | | | | What happens if you | | | | bzr branch http://bazaar.launchpad.net/~msapiro/mailman/cull_bad_shunt | | | | ? | | | | When I do this, either in my shared repository or in a fresh directory. | | I get only 2 revisions. | | | I'm doing this now in a new directory. I'll post the result after it | completes.
It says it branched 2 revisions, but 'bzr diff -r 1073..1075' and 'bzr diff -r 1..-1' produce what seems to be the expected output - at least the 1073..1075 diff is correct and the 1..-1 diff produces the same 540077 lines as the one in the original MM_bzr/cull_bad_shunt directory.
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIMNxvVVuXXpU7hpMRAnrTAJ0cPJTv0lI3gp8pZ3gvBmQZmbs6agCcCJnX ltyYyNUFozY2o/sQWjJ+4Ag= =UvGk -----END PGP SIGNATURE-----
participants (7)
-
Barry Warsaw -
Barry Warsaw -
Bob Puff＠NLE -
Cristóbal Palmer -
David Lee -
Eino Tuominen -
Mark Sapiro