I recently did my first experiments with darcs: A friend of mine and I hacked on
the same code, and by giving each other access to one’s darcs repository, we
could easily exchange our new code.

One problem I had was that my friend recorded a patch that I did not want
applied in my repository. Nothing else depended on it, so I could just say no
everytime I use “darcs pull”, but it’s still a hassle. Also, imagine that I’m
somewhere else and I suddently decide that I do want the patch?

A similar problem would be if I created some patches that I temporarily don’t
want applied. I could branch, and then unpull them, but this is a bit too much work.

In both cases a “patch shelve” would be handy. A seperate storage for patches in
my repository that are available, but not applied. I’d imagine that the “darcs
pull” command would then allow me to “pull and put on the shelf”, and not offer
me this patch again. There would also be “put on shelf” and “get from shelf”
commands. So if anyone feels like hacking on darcs, this feature would be
appreciated.

(From http://www.joachim-breitner.de/blog/archives/236-A-shelf-for-darcs.html)

Joachim Breitner wrote:
> A similar problem would be if I created some patches that I temporarily don’t
> want applied. I could branch, and then unpull them, but this is a bit too much work.

That would be the darcs-approach, and it shouldn't feel like to much 
work.  darcs get even has some very nice options to quickly do that 
branch work for you, for instance you could use --to-patch="First Patch 
you don't want yet", or you could use --tag="Last tag" and darcs pull 
any additional patches you want interactively, if you prefer that to unpull.

> In both cases a “patch shelve” would be handy. A seperate storage for patches in
> my repository that are available, but not applied. I’d imagine that the “darcs
> pull” command would then allow me to “pull and put on the shelf”, and not offer
> me this patch again. There would also be “put on shelf” and “get from shelf”
> commands. So if anyone feels like hacking on darcs, this feature would be
> appreciated.

It has been mentioned before that darcs could use a way to ignore/ban 
patches to keep pull push for re-prompting patches that you explicitly 
don't want and there's at least one existing issue for that:
http://bugs.darcs.net/issue139

The shelf idea is an interesting name, but beyond the ignore/ban patches 
part the darcs-approach would be to suggest that you just keep around a 
second "shelf" repository and then its just a simple matter of push/pull 
between your "working" repository and your "shelf" repository.  In darcs 
it's generally quite easy to keep a small web of repositories around for 
just this sort of thing.

This actually just about follows the work-flow of some groups like yours 
where you might want to keep a local repository for each co-developer of 
yours that is just entirely synced with their repository and a 
repository of your own "publishable" patches with one or more working 
repositories pulling from the co-developer repositories and pushing to 
the published repository.

Hi,

Am Dienstag, den 01.05.2007, 15:45 +0000 schrieb Max Battcher:
> Joachim Breitner wrote:
> > A similar problem would be if I created some patches that I temporarily don’t
> > want applied. I could branch, and then unpull them, but this is a bit too much work.
> 
> That would be the darcs-approach, and it shouldn't feel like to much 
> work.  darcs get even has some very nice options to quickly do that 
> branch work for you, for instance you could use --to-patch="First Patch 
> you don't want yet", or you could use --tag="Last tag" and darcs pull 
> any additional patches you want interactively, if you prefer that to unpull.

Maybe it would have the same effect, but an integrated shelf area would
be easier to use and setup. Also, if the shelf is a full repository and
I store a lot of similar patches, or variations of the same patch, the
files there will be full of conflict markers. Of course you suggest that
I ignore the working area of the shelf repository, but it’d be easier if
it were a separate concept from a repository. (Similar to the unpull
command, which is not really unpull, but easier to use and understand
with that name).

Not sure if it’s worth the work to implement it, if it’s already
possible with a branch, but at least there seems to be some interest in
the feature, see
http://www.joachim-breitner.de/blog/archives/236-A-shelf-for-darcs.html#comments

Greetings,
Joachim

Joachim Breitner wrote:
> Maybe it would have the same effect, but an integrated shelf area would
> be easier to use and setup. Also, if the shelf is a full repository and
> I store a lot of similar patches, or variations of the same patch, the
> files there will be full of conflict markers. Of course you suggest that
> I ignore the working area of the shelf repository, but it’d be easier if
> it were a separate concept from a repository. (Similar to the unpull
> command, which is not really unpull, but easier to use and understand
> with that name).

In which case you may be talking about another use case for my recent issue:
http://bugs.darcs.net/issue431

This would be to have a --no-working-directory ability when making a 
repository.  My use cases were for immutable repositories (generally 
read-only or tool-modified) where the pristine cache alone suffices, but 
perhaps a simple "patch storage repository" without a working directory 
and possibly even without a pristine cache might have it's uses as well.

I know other tools like darcs-server have implemented raw patch caches 
by doing things like pretending to be darcs apply, but maybe it wouldn't 
be a bad idea for darcs to support it as a standard "repository type".

This is precisely the scenario that the pull --complement is intended
to address.

Basically, you have repository A and your friend has repository B, and
he has a patch Bn that you don't want in your working repository A.
Simply create another local repository of yours, called C.  When you
identify a patch that you don't want in A (in this case, Bn), pull it
into C instead.  Whenever you pull patches from A to B, just complement
that against C:

$ cd A
$ darcs pull --complement /path/to/B ../C

Any patch that is in B but not in A or C is a candidate for pulling;
since Bn is in C, it is removed from the available set for pulls.

-KQ

On Tue, 01 May 2007 10:21:16 +0000, Joachim Breitner <bugs@darcs.net>
wrote:

>
> New submission from Joachim Breitner <mail@joachim-breitner.de>:
>
> I recently did my first experiments with darcs: A friend of mine and I hacked on
> the same code, and by giving each other access to one’s darcs repository, we
> could easily exchange our new code.
>
> One problem I had was that my friend recorded a patch that I did not want
> applied in my repository. Nothing else depended on it, so I could just say no
> everytime I use “darcs pull”, but it’s still a hassle. Also, imagine that I’m
> somewhere else and I suddently decide that I do want the patch?
>
> A similar problem would be if I created some patches that I temporarily don’t
> want applied. I could branch, and then unpull them, but this is a bit too much work.
>
> In both cases a “patch shelve” would be handy. A seperate storage for patches in
> my repository that are available, but not applied. I’d imagine that the “darcs
> pull” command would then allow me to “pull and put on the shelf”, and not offer
> me this patch again. There would also be “put on shelf” and “get from shelf”
> commands. So if anyone feels like hacking on darcs, this feature would be
> appreciated.
>
> ----------
> messages: 1665
> nosy: EricKow, beschmi, droundy, nomeata, tommy
> priority: wishlist
> status: unread
> title: Patch Shelf feature
>
> ____________________________________
> Darcs issue tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue447>
> ____________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel

I'm marking this one resolved.  Kevin seems to be saying that the pull
--complement essentially provides the same thing as a patch shelf.  Please
re-open if you object.  Thanks!