[darcs-users] sugggestion on command naming
droundy at abridgegame.org
Sat Mar 13 13:35:19 UTC 2004
On Thu, Mar 11, 2004 at 08:09:57PM -0800, Adam Megacz wrote:
> That's fine; I just think push-and-DONT-apply is really confusing. I
> still don't really understand what it does. What is it useful for?
> When I push a patch using email, why would I not want to apply it?
> And what happens to the patch if it doesn't get applied? Does it go
> to patch heaven? ;)
As Aggelos said, that's up to the owner of the repository. While it's true
that most of the times that you push you may be pushing to your own
repository, it's probably not true that most of the repositories you push
to are your own. And it's even less likely that most of the people who
push to your repository are you.
I think that by default the push process should be optimized for people who
push most seldom--possibly even once--who are the outside contributors to a
project. It's not hard in one's own repository to add "push and-apply" to
_darcs/prefs/defaults, but it's very nice to be able to tell potential
contributors that they can contribute bugfixes by just running "darcs push"
(after recording, of course).
I think the confusion here is perhaps caused by the change in mindset in
going from CVS to darcs. CVS breaks the users into two categories: those
who can commit and those who can't. For those who can't, CVS is just a way
of getting the latest version. If they want to contribute to the project,
they have to use a different tool (probably patch/diff). Darcs doesn't
have this clear distinction between those who can commit and those who
can't. With darcs, any contributer can take advantage of darcs to make
changes and share those changes with others--either with a central
repository, or simply with other users who might like to have those
improvements. Since it is easy to apply a darcs patch from an email, and
easy to use darcs to push patches via email, there is less need to give
contributors write access to a centralized repository.
> > True, if your project is a one-developer project, you might like
> > projects in mind, and in such an environment, --and-apply is unlikely
> > to be helpful. True, there could be a central user account to which
> > everyone has ssh access, but that's a unique (and not necesarily
> > common) situation.
> Actually most multi-developer projects have already been forced (largely
> by cvs's lameness) to set up ssh keying. I'm on the gcc staff, and the
> FSF has already put considerable effort into doing this. Likewise with
> every project on sourceforge.net. (actually sourceforge in general).
As below, this only works if you implicitly trust your users enough to give
them full admin permissions on the repository. If you want to allow some
users "commit" priveledges without giving them "delete the repositories
and/or modify the history" privileges, you need something more
sophisticated. So perhaps giving every one ssh access is common, but not
> > that users are encouraged to --apply-as. (Yes, I realize those are
> I'm also not 100% clear on the apply-as... is this to keep all the
> permissions correct? If so, shouldn't you be using 'chmod g+s'?
No, it's in case you trust your users not to try to crack the system, but
don't trust them not to do something stupid. With chmod g+s, your users
can do whatever they want to the repo, modifying it by hand, using darcs
pull rather than apply --test (if perhaps you have a policy requiring that
a test suite be run on every push). With the sudo trick, the user can only
run darcs apply on the repo.
More information about the darcs-users