[darcs-users] Leading / stripped from local repository

Eric Y. Kow eric.kow at gmail.com
Sat Aug 30 08:58:34 UTC 2008


> Well, I don't know where this happens, but I noticed some code in
> FileName.lhs ripping paths into parts (separated by "/") and putting
> them together again. If you're doing this stuff, and you're not
> sure you're always dealing with absolute paths (starting with "/"),
> you'll be in trouble because you have to prepend a "/" when
> reassembling the path iff the original path was an absolute one.

I would like to revisit the question of using System.FilePath in darcs.

We'll still need to keep a lot of our idiosyncratic path handling code
(we need to know about remote paths, for example, and we also have
special types to explicitly mark paths as being SubPath in some
directory tree or AbsolutePath, among others), but I think it would be
a very worthwhile investment to see how many internals we can replace by
System.FilePath.

Now, as David points out in http://bugs.darcs.net/issue341, there may be
reasons to be cautious about using System.FilePath:

  I'm not convinced that System.FilePath is a route we'd want to go.  We
  already have code that is almost certainly better tested than
  System.FilePath, and that we understand.

This is true; our path handling code has been battle tested in a real
world darcs setting, whereas System.FilePath not so much.  On the other
hand, System.FilePath has been around for quite some time now -- notice
that this comment was written in 2006 -- and was written by somebody
that certainly understands Windows better than us and who also provided
an extensive battery of QuickChecks.  The QuickChecks do not substitute
for field testing, but they do give us a lot of extra confidence about
this library.

Also, it was also true that we 'understand' our own path handling code
better than System.FilePath (i.e. we know about its flaws), but as we
can see [a] we are doing new work on filepaths that we do not understand
anyway and [b] we are constantly getting new developers who may not have
the same familiarity with our homegrown code as we do.  Switching to
System.FilePath may make our code more transparent for outsiders.

Summing up: our paths code used to be well understood and field tested,
but is starting to fray at the edges.  System.FilePath is now more
mature, has an aggressive automated testing suite which we do not, and
will be easier for new darcs developers to understand.  Furthermore, the
library was written by somebody who understands paths very well and will
hopefully be able to give us advice.

I say we give it a shot!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20080830/ee63b9e7/attachment.pgp 


More information about the darcs-users mailing list