[darcs-users] Re: questions on development process

[David Roundy]

On Thu, Aug 12, 2004 at 08:55:24AM -0400, Eric S. Johansson wrote:
> In my head, the way I would work is that patches reflect individual
> changes one makes to a repository.  It seems neither should be a second
> level of grouping which is a "submission".  This is a set of patches with
> what ever context is necessary that the authoritative repository manager
> would take and apply to the authoritative repository.
> 
> I believe you've been handling the submission concept via the amount of
> information sent in a single send or push but I'm not sure what keeps
> that set of patches together as an entity and how one identifies it or
> operates on it.

What you're calling a "submission" I usually call (which isn't a much
better name) a "patch bundle".  A "patch bundle" is almost equivalent in
information content to a "partial" repository, that is a repository
downloaded with darcs get --partial (which my not help if you're unfamiliar
with that option).

This means it has full history information in terms of patch IDs, but
doesn't have most of the old patches themselves.  You apply a patch bundle
via "apply", which has an --interactive option that gives you all the power
you'd have with "pull" to pick and select which patches you want and which
you don't.

> this also raises the issue of patch organization.  If I have a bunch of
> people sending me patches, how do I keep track of them?  should there not
> be some sort of a queuing mechanism so I can keep track of when, what
> order and which patches/submissions?  yes, in theory your e-mail client
> can do that but it's not the ideal tool for a variety of reasons.  Not
> the least of which being that my e-mail client is not on the same machine
> as I do my development and it's really obnoxious to try and transfer
> files between machines. (hint, it's all hand driven and it hurts really
> bad)

There are a number of ways one could deal with patches send via email.  I
prefer to just browse them and apply them (or not) from my email client.
However, you could set up procmail to apply them automatically to a scratch
copy of your repository if you wanted, and then you'd just have to browse
the directory tree to see what was changed, and pull at will.

> >What do you do, for example, when pushing via ssh to a repository that
> >has an associated email address? It may be that you can't push via ssh
> >directly because you might not have write access in the target
> >repository.  So do you try pushing via ssh first, and if that fails try
> >sending via email? Do you try creating a file in the target repository
> >just to find out if you have write access? Or do you send the patch via
> >email without checking if you might have been able to write to the
> >repository? It was in trying to create a set of reasonable defaults and
> >then to document that behavior that I decided that the people were right
> >who were trying to convince me to split push into send and push.
> 
> it seems to me that each repository would have a preferred method of how
> to communicate with it.  For example, yours may have the profile of
> e-mail, somebody else may have ssh and I would be notified by instant
> messenger driven patch manager.

No, each repository can't have a preferred method for communication, since
it will depend on who is doing the sending.  *I* may have the right to
push patches to abridgegame.org, but I'm certainly not going to give that
right to just anyone who wants to send me a patch.

I'm still not really clear how your IM driven patch manager would
work... perhaps partly because I haven't used an IM for quite some time.
Do they now have offline deliver capability? If not, does this mean that
everyone's computers will have to be always on? And in particular, from
what you said before (unless I'm mixing things up), you wanted the initial
IM "send" to just indicate the patch was available, not to actually include
the patch.  Does that mean everyone sending you a patch would have to leave
their computer on until you've pulled it? If so, it seems they may as well
just run an http server (except I guess that would be hard behind a
firewall or NAT).

> But I think you're seeing my bias that there should not even be a push
> capability.  In theory I know there is some advantage to moving patches
> by e-mail but 1) I live in the world of e-mail and I know it's not
> reliable.  2) e-mail is not efficient for multiple site distributions
> except with very small messages (that looks just like Spam). 3) e-mail
> has problems with order.

I think you mean there shouldn't be a send capability? Order isn't a
problem for darcs, at least as long as there is a common reference
available, and email for most people is how they'd announce they have a
change anyways.  You certainly don't have to use it, but for many people an
email server is the only server they have access to, so it's the only way
they can reliably receive a message.

> a solution that is popping up in my head there should be a submission 
> queue manager.  In that notifications of patch sets/submissions should 
> be collected in submission sequence and listed in same.  The repository 
> owner would then pick and choose submissions or if that shows, actual 
> patches within submissions (hierarchical view perhaps).

This can (and should) be written outside of darcs itself.  For email,
something like this could relatively easily be set up using procmail and
some appropriate scripting.
-- 
David Roundy
http://www.abridgegame.org