From: G. James Berigan (usefor@war-of-the-worlds.org)
Date: Tue Nov 09 1999 - 11:35:57 CST
chl@clw.cs.man.ac.uk (Charles Lindsey) wrote:
>"Clive D.W. Feather" <clive@demon.net> writes:
>> If we want to allow for it in the future, why not make the syntaxes:
>>
>> mvgroup old.group new.group ; group
>> mvgroup old.group.* new.group.* ; hierarchy
>> mvgroup old.group.* new.group ; merge
> Agreed - much clearer.
And I believe back how it was originally proposed.
And the syntax:
mvgroup old.group new.group.*
could have details in the body about what the new groups are, with the
old.group being renamed/merged into new.group.misc.
I agree merging is a difficult concept. The implementation I always
envisioned is the existing articles in the original group staying numbered
as they are and the moved articles treated as a group as new articles in
the new group starting with the first new article number in the new group.
This preserves the original read history for clients for existing articles
in the destination group, but does give a huge block of suddenly-unread
articles which, though temporary, is much more of an annoyance than would
be not translating Xref headers.
But then, with rmgroup letting the existing articles expire before actual
removal of the group (without accepting new articles or redirecting them
automatically to the appropriate group), perhaps merging isn't necessary.
The "merge" syntax above at least gives a clear indication what is being
performed without necessarily requiring the server to perform a merge. I'd
say it is still a useful syntax for that alone. Behavior would be similar
to rmgroup in situations where merging is not done, with the addition of a
possible aliasing of the old.groups to the new.group.