Many mailing lists have size limits for messages. It would be nice if darcs
could commute irrelevant patches out of the context, to reduce the chances of
the patch landing in the moderation queue. (For instance, cvs-ghc@haskell.org,
the default destination for GHC patches.)

On Sat, Oct 14, 2006 at 22:28:19 +0000, Samuel Bronson wrote:
> Many mailing lists have size limits for messages. It would be nice if darcs
> could commute irrelevant patches out of the context, to reduce the chances of
> the patch landing in the moderation queue. (For instance, cvs-ghc@haskell.org,
> the default destination for GHC patches.)

Hi,

This is something I was supposed to implement, but I have since set it
aside and think somebody else should do it.  The good news is that David
seems to be working on hashed inventory right now,  which is good in
that the hashed inventory feature also needs some kind of minimal
context feature.  You might see this moving forward some day.

More details here:
  http://www.mail-archive.com/darcs-devel@darcs.net/msg02118.html

Also perhaps closer to what you're specifically asking for:
  http://www.abridgegame.org/pipermail/darcs-devel/2004-November/000639.html
  http://www.abridgegame.org/pipermail/darcs-users/2004-July/002519.html

Actually, the hashed inventory as implemented won't need a
minimal-context.  It's the signed patches idea that requires that...

David

I don't care how it works, as long as I can send patches to a mailing list
without having context push them over the size limit regardless of the size of
the changes I made. (Not necessarily all the time, but more often at least.)

I like the "minimal" and "minimal, assuming this tag" options from: 

http://www.abridgegame.org/pipermail/darcs-devel/2004-November/000641.html

Except that I do have a destination repository, I just don't care to list all
the patches that I my repo shares with it. (I'd especially like it if I didn't
have to pick the tag.)

On Tue, Oct 17, 2006 at 07:17:24PM +0000, Samuel Bronson wrote:
> I don't care how it works, as long as I can send patches to a mailing list
> without having context push them over the size limit regardless of the size of
> the changes I made. (Not necessarily all the time, but more often at least.)

You already get this, if you tag your repository.  As long as you tag
regularly, the context sent should remain small.

David

So how do you explain this file? It has a bunch of TAG patches in it, and lots
of others that must surely have been included in the tags. And I'm running 1.0.8
(release). And I just made this patch file with "darcs send -o", so I know I
made it with this version of darcs.

(Should I mention that my working copy is a --partial repository?)

Attachments

• inliner.dpatch

On Tue, Oct 17, 2006 at 08:31:51PM +0000, Samuel Bronson wrote:
> So how do you explain this file? It has a bunch of TAG patches in it, and lots
> of others that must surely have been included in the tags. And I'm running 1.0.8
> (release). And I just made this patch file with "darcs send -o", so I know I
> made it with this version of darcs.
> 
> (Should I mention that my working copy is a --partial repository?)

You may need to run darcs optimize --reorder on either your working
directory or central repository.  More likely the former.

Darcs should be smarter about this, though...
-- 
David Roundy
Dept. of Physics
Oregon State University

Doesn't seem to help. At least, not on mine -- I don't exactly have commit
access to the GHC repo...

On Tue, Oct 17, 2006 at 11:07:33PM +0000, Samuel Bronson wrote:
> Doesn't seem to help. At least, not on mine -- I don't exactly have commit
> access to the GHC repo...

You could test by sending to a local copy of the GHC repo.

David

Developers:

To re-cap this report, it's wish for darcs to generate smaller messages with
less context. Tagging was recommended, but it seems an "optimize --reorder"
didn't help in this case. 

- Should we expect better luck with the Darcs 2 repo format? If so perhaps this
can be considered "resolved"

- Is there any thing else that makes sense to do here besides recommend
"optimize --reorder" ?  If not, considering this "resolved" or "wont-fix" seems
in order.

I think resolved is probably appropriate.  It's possible that we could reduce
the context somewhat by running optimize on the remote repository ourselves. 
But with darcs2, optimize is automatically run, so the repository should remain
in good shape, and the context should be small.

David