[darcs-users] Re: File/Directory Metadata

[Quag]

On Sat, 13 Nov 2004 23:53:35 -0500, Michael Conrad
<conradme at email.uc.edu> wrote:
> *** Minor instant brainstorm
> What if darcs had the ability to run a script on applying a patch (as
> suggested previously) and the meta tags were defined as environment
> variables while running the script for a given file!  This would make it
> trivial to set the permissions for a file:
> 
>   #!/bin/sh
>   chmod $unix_perm $CURRENT_FILE
> 
> And, this would mean that darcs wouldn't need to have any of these features
> decided on or built-in!!  I could add a script that would clobber the '\r'
> as well:
> 
>   #!/bin/sh
>   [ -n "$logical_lines" ] && dos2unix -o $CURRENT_FILE
> 
> I suppose I'd also suggest that you put in a nice hooking-spot in the darcs
> code in case people want to do their 'script' in haskell.
> 
> So, what do people think now?

<daydreaming>

When I first read David's response I had the same "Minor instant
brainstorm". It works fine for the action side of things, like
changing the perms or fixing the lines, but it doesn't handle the
record or commution side of these types of changes.

The new meta data as well as scripts (actions) to "execute" the
patches, would also need a way to detect new meta data changes
(recording). The meta data patches created are likely to need custom
rules for how their patches can interact (commute). In short, it is
likely that for each item of meta data a new patch type would have to
be added to darcs.

Although it may seem like only the new meta data patch type is
required, I think that anytime different action, record and commution
rules are required it would probably be simpler to create a new patch
type.

Darcs operates on a simplified model of a file system and the files
contained within it. The model provides constraints on how all the
entities in the model can interact and how they can be changed.
Patches are only allowed to change the repository state with
accordance with this model.

The question is, how difficult is it to extend or replace the internal
model darcs uses? My uneducated guess, is that it would be difficult
and it would become more difficult as more patch types were added.

Darcs currently describes the simplified file system model through the
rules on commution and the tools used for recording new patches. One
question I am interested in, is could darcs be structured around an
easily replaceable model? I'm day dreaming about some way to create a
darcs-like system where the rules for commution and patch addition
were automatically derived from the model.

Jonathan.

</daydreaming>