[darcs-users] Symbolic Links and File Permissions

David Roundy droundy at abridgegame.org
Fri Apr 23 10:02:06 UTC 2004


On Thu, Apr 22, 2004 at 02:35:12PM -0400, Pat Regan wrote:
> I have only been using darcs for a few weeks now, and I want to say it is
> an excellent piece of software.  I've been wanting to replace CVS for my
> personal project for quite a while now, and darcs was the only thing that
> covered all my major requirements.  I needed something that would let me
> keep repositories in multiple locations in sync (my desktop, laptop, and
> keychain).  I also needed something that would track moves and renames.
> 
> I was very close to trying Arch, but I really wanted to have a win32
> client available.
> 
> Anywho, here's my question.  I do a lot of sysadmin type work, and I would
> love to use darcs to version control /etc directories (among other
> things).  It would be very convenient because darcs can store everything
> locally in the _darcs directory.
> 
> It would be nice if it could track permissions.  I have small cheater
> script I use to keep the permission right on my ~/bin directory that I
> have checked into darcs, but long term it would be nice to have tracked
> permissions.
> 
> I can live without permissions, but symbolic links are a bit harder.  I
> didn't even think about symlinks and tried to throw my /etc on my desktop
> into darcs and it crashed after a few minutes, I realized it was walking
> the tree in an infinite circle :).
> 
> Anywho, both would be nice to have features.  I have quite a bit of free
> time these days, so I would definately be willing to attempt working on
> it.  I just thought I should check here first, and see if there was
> already any thought into it.

There's been some thought and a bit of talk, but nothing done.  If you
wanted to work on this that would be great.

As far as permissions goes, I think we only want to control the execute
bit, since there are good reasons why the other permissions should
sometimes be different on different copies of the same repository.
Implementing control of the execute permission would involve modifying the
Slurpy to store the execute permission, and the read and write routines to
deal with it as well.  This shouldn't be too hard.  I'd stick the execute
bit in with the file modification time and file length.  Then you'd need to
create a new patch type for modifying the execute permission.  This would
be a bit trickier, mostly just because Patch.lhs is scary.  This permission
would be a FilePatch that commutes with anything but other changes to the
execute permission and add and removes of the file itself.

Symlinks would be a bit more work.  The first trouble is that the standard
libaries don't handle symlinks, so you'd have to get into the win32 side of
the code to make symlinks work without Posix.  You might do this by
modifying the win32/Posix.hs.  Then you'd need to add a third constructor
for the Slurpy, which would be a SlurpSymlink (or some such name), which
would mean you'd have to touch almost every function in
SlurpDirectory.lhs.  On top of all this, you'd have to add a set of patches
for creating and possibly modifying symlinks.  I'd sort of lean towards
treating a change in a symlink as a simple deletion of the old one and
creation of a new one.  That wouldn't give you "symlink history", but I'm
not sure that symlink history is a useful concept.  I think that the
symlink patches could be FilePatches (i.e. FP SymlinkCreate or something),
which would at least save you the trouble of dealing with symlink renames
(as opposed to symlink content changes).

So I guess that's a summary of how you'd go about adding symlink or
permissions support to darcs.  On the downside, darcs is in a sort of loose
feature-freeze leading to darcs 1.0, so unless they could be done quite
cleanly (more cleanly than I suspect is possible), both of these changes
probably wouldn't be accepted into mainline darcs until after 1.0 is
released and a 1.1 "unstable" branch is started.  The main issue is that I
placed a moratorium on new patch types in order to avoid introducing new
bugs.  On the plus side, recently I've been increasingly deciding to put
off new features until after 1.0 is released, so maybe this is a good sign
and I'll finally get 1.0 out the door.  Basically I'd like to have a couple
of 0.9.x releases that don't introduce new bugs before releasing darcs 1.0.
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list