[darcs-users] [patch39] darcs fetch

Eric Kow kowey at darcs.net
Wed Dec 9 16:59:06 UTC 2009


Thanks, Florent,

Sorry for letting this be stuck.

Grumpy Old Men: One difficulty with our Grumpy Old Man process is
finding people to take on the role.  We'll need to work on this one a
bit.  It doesn't have to be anything so formal; the point really is just
that we should be trying our damnedest to avoid feature creep.

 /me looks in the mirror and thinks about SVN integration

THAT said: I find your responses below convincing enough, and Dan Pascu
(having been asked to comment on it) seems to agree
 http://lists.osuosl.org/pipermail/darcs-users/2009-November/022410.html

Since this appears to be sort of stuck, I'm going to step in and
green light this as BD once it's amended and it passes review.
Or maybe there actually is consensus, and that action isn't needed.

Cheers,

Eric

On Tue, Nov 24, 2009 at 16:57:52 +0100, Florent Becker wrote:
> > 1.  What problem does the proposed feature solve?
> 
> Retrieving and keeping together a set of remote patches without having
> to apply them.
> 
> > 2.  What are the user stories?
> 
> Reviewing the set of patches before applying them. Keeping them together 
> in a file to apply them one-by-one, while concurrently recording the merge 
> resolution patches if there needs to be some. Fetching the patches and 
> keeping them in an archive for later application/reference if application 
> does not make sense yet. Anything we do with send, except the initiative 
> belongs to the receiver rather than the sender.
> 
> > 3.  Does this change any pre-existing workflows? Does this introduce any
> > incompatibilities?
> 
> No. All it ever does is to create bundle files where yoeu tell it to.
> 
> > 4.  Does this interfere with the conceptual integrity of Darcs? Is the 
> UI
> > really Darcs-ish?
> 
> I think the consensus is yes.
> 
> > 5.  What are the possible unintended interactions with other pre-
> existing
> > features?
> 
> See question 3, i don't think there are any.
> 
> > 6.  What are the alternative approaches to solving the same problem? Why
> > do we prefer this one?
> 
> Other ways to do the same thing involve either relying on the patch cache, 
> which is not darcsish and has interference with the possibility to clean 
> it, or they use temporary repositories, which are heavyweight (if only 
> because you need one working dir for each).
> 
> > 7.  Who are the stakeholders? Who is going to benefit/be affected by 
> this
> >     feature: end-users, repo farms like patch-tag, darcs developers?
> > 
> End-users would benefit from this.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20091209/b6ffcf9f/attachment.pgp>


More information about the darcs-users mailing list