[darcs-users] Supporting centralized development

dagit at eecs.oregonstate.edu dagit at eecs.oregonstate.edu
Fri Jul 22 20:03:50 UTC 2005


Hello,

I'm trying to introduce my coworkers to darcs.  We have a small
project starting up and I would like to use darcs as our version
control.  But there are a few constrainsts imposed by the group and by
our workflow.  Let me try to enumerate those:

Group Contraints:

1) Requires no configuration of their computers outside of darcs
   installing.  So for example, setting up postfix in Mac OS X so that
   darcs send can actually deliver the mail is out of the question.

2) Hopefully doesn't require them to use darcs in a non-standard way.

3) Doesn't require them to become darcs experts, just to be able to
   use a few simple commands.

4) No direct control over the server.  No cron jobs, no long running
   processes.  If we need something installed it must either be
   installed in $HOME or approved by our support staff.  We are
   students, so we can't always get things approved.

5) Each group memmber uses their own account to check in code.

Workflow requirements:

6) Automatic email notification when someone shares their changes with
   the rest of the group. (eg, darcs push should send out an email
   when the push is successful)

7) We need a central place to get the official version.


This is what I have setup so far: I don't want to bother the support
staff yet, so I compiled darcs and placed the binary in my home
directory.  I then created a 'test' repository and gave the necessary
premissions to the other group members.  My umask is set very
restrictive so that by default group and other have no access to files
(not read, write or execute). This could come back to bite me, I'm not
sure.

Next, I used darcs setpref test, to create a "test" of the following
form:
echo "Repo Updated" | mail -s "[Repository] Update" joecool at school.edu foo at bar.com

I consider that repository to be the official or central repository.
So now I use 'get' to grab a working copy.  I notice that the new copy
has the same auto email test.  It would appear that I have to use the
command "darcs setpref test ''" on this local copy now, which is
undesirable.  I think this violates constraint (2).

Which made me think, wouldn't it be nice if there was a script that
could be run automatically after 'get' creates a new copy of the repo?
But, of course, there is the problem of security for a script like
that.  OTOH, having an arbitrary script run when 'record' is used has
the same trappings.  How do people feel about having a hook for a
'get' script?  I'm imagining in my case that the get script would set
the test to nothing when people do a "get" on the repo so that the
central repository can stay "special".  Of course we would also then
need a way to disable this script, so maybe add "darcs get
--do-not-run-scripts"

I'm also wondering how my group will deal with permissions, but this
can perhaps be managed from the test script.  Although, I think darcs
could benefit from having the ability to run pre and post test
scripts.  Also, it would be nice if the names and/or descriptions of
the patches could be sent (on the command line or via stdin) to these
these scripts.

Accepting patches via email only and using procmail is not a bad idea,
but I don't want to require email as the way to send patches, at least
not yet.  I may consider it later though.

What do people think?

Thanks,
Jason





More information about the darcs-users mailing list