[darcs-devel] darcs patch: added postget to prefs (and 2 more)

David Roundy droundy at abridgegame.org
Mon Aug 1 03:51:29 PDT 2005


On Mon, Aug 01, 2005 at 01:03:05AM -0700, Jason Dagit wrote:
> Perhaps 'darcs send' should allow the user to add notes about the  
> patch bundle they are sending?  I find my self wanting to do that...

$ cat /home/droundy/.darcs/defaults 
send --edit-description

...
> Finally, the rationale for this feature is that now I can have a  
> "central" repository with a special test defined (one that sends out  
> email notification for successful patches), and I can use postget to  
> set a different test for the copies of the repository.  So, when  
> someone gets a copy of the repo, the postget command will be run and  
> it will modify test so that it no longer sends out email notification.

I'd rather support this feature with a hook to apply than with a hook to
get.  In spite of the fact that I created it, I don't care for the whole
prefs and setprefs mechanism--it has too many potentially confusing
features (see, for example, my response to your doc fix).

I'd like most hooks (and get here is a special exception, since the
repository in question doesn't exist until after the command is run) to be
implemented as simple command-line flags that would normally be specified
in either _darcs/prefs/defaults or ~/.darcs/defaults.  Thus a post-hook
in apply would quite naturally allow you to do your email notifications in
the central repo.

That said, I can imagine a few other uses of postget.  One would be to fix
permissions (or extended attributes, or anything like that).  Another would
be to to run autoconf or something as an aid to lazy or ignorant users.
One could also use this as a chance to set up customized defaults... for
example to set up the _darcs/prefs/defaults to run a permissions-fixing
hook after each pull.

Unless there's a compelling reason to the contrary, I'd prefer to make this
not a prefs/prefs data object--precisely because setprefs *is* so
confusing.  The only reason to make it a setprefs object is if you need to
make sure that the postget is *always* run, regardless of which repository
is gotten from.  I can see that several of the above scenarios would
satisfy this criterion, but none of them seem like a particularly strong
reason.


--------------

Actually, as far as your reason for postget is concerned, I think we'd be
better of fixing the bug of local gets, that they copy locally modified
prefs.  The reason they do that is because there's no way to tell whether
the pref has been locally modified without parsing all the patches, which
is something we'd really like to avoid (for efficiency reasons).  I think
the solution would be to split the prefs into two files, one for local
(overriding) modifications, and one for the prefs set with setpref itself.
Then we'd only copy the latter on a local darcs get.  I'm envisioning
something like:

# contains the "gettable", "global" versions of prefs --not user-modifiable:
_darcs/setprefs
# where the user sets "local" versions of the prefs:
_darcs/prefs/prefs

We'd have to modify RepoPrefs to check in both locations.  We'd be
backwards-compatible, provided we echo the "global" prefs in
_darcs/prefs/prefs, using the existing mechanism of modifying that file
only if its current setting matches the "old" version in a setpref patch.

I think this is two cleaner solutions to your problem (either a post-hook
on apply, or fixing the local get prefs bug).  The latter is a good idea
anyways, since it makes local gets behave like remote gets.  It also could
allow us to make optimize --checkpoint somewhat more efficient, since we
could trust that _darcs/setprefs (or _darcs/global_prefs?) hasn't been user
modified, so we wouldn't have to search through the entire history looking
for setpref patches.
-- 
David Roundy
http://www.darcs.net




More information about the darcs-devel mailing list