[darcs-users] darcs patch: Make FileName.drop_dotdot work with abso... (and 2 more)

[David Roundy]

On Fri, Sep 26, 2008 at 07:23:16PM +0400, Dmitry Kurochkin wrote:
> On Fri, Sep 26, 2008 at 3:17 PM, Dmitry Kurochkin
> <dmitry.kurochkin at gmail.com> wrote:
> [skip]
> >>
> >> Dmitry's code tells us that if we are calling ioAbsolute on a file, then
> >> we must get its parent directories' ioAbsolute name.  One question: what
> >> happens if the file in question is "/foo"?  Does super_name do what we
> >> expect?
> >
> > Yes. I did not test it. But is should work fine - super_name returns
> > '.' in this case.
> 
> Actually, after thinking on this a bit more, it is broken for "/foo"
> paths. super_name "/foo" returns an empty string, not "." as I
> expected (and even if it returned "." that would be wrong).
> 
> I will send a patch to make super_name work with "/foo" paths after
> latest David's FileName patches hit the repo.
> 
> Do I understand it correctly that after 2.1.0 release we are going to
> get rid of FileName module (that one that is not in Darcs/Patch)? Are
> we going to use System.FilePath or smth else?

To sidestep your question, my plan is to use Darcs.RepoPath.  I don't
greatly care how Darcs.RepoPath is implemented, but I do want it to
export a sane interface (which System.FilePath doesn't attempt), and I
want to use that sane interface.  We should probably also rename it,
as RepoPath doesn't describe either what it does, or how it is used.
I just kept the existing name when reworking it.

Right now (once the FileName patch goes in, which is waiting on yet
another power outage in Oregon, this one supposedly short), by my
count we've got two deprecated filepath handling modules in darcs.
Provide we don't know of more filepath-related bugs, I recommend that
we refactor before rewriting to use System.FilePath or anything else.

David