On Wed, Dec 21, 2005 at 13:09:25 +0100, Juliusz Chroboczek wrote:
> > -                                 putStrLn ("making executable: " ++ f)
> > +                                 putVerbose $ text (" " ++ f)
> 
> There's a bit of the output missing.

Oops! I can fix that and resubmit the whole absolute path thing as one
integrated patch if you want

> > +                    -- convert absolute paths in ex to be relative to 
> > fix_path
> 
> Is this correct?  If I understand what this does (which is not sure),
> you're filtering every single parameter to remove the current
> directory prefix.  I'm not sure this is correct -- I believe that some
> commands take paths relative to the repodir (which might be remote),
> not to cwd.

Uh-oh.  Let me check my understanding of the original darcs code with
you:

1. When you call first call darcs, you start at some directory
   which is presumably a (grand...)daughter of the repodir -
   call this the 'original_wd'

2. Darcs does cd.. until it finds the repodir, and builds a
   'fix_path', which is the original_wd but relative to the
   repodir

3. Now the cwd ('here') *is* the repodir and the fix_path gets
   you to where you first started

And what I added was to translate any parameters starting with slash
to be as if the user had typed them in relative to the original_wd : 

4. We strip the repodir's absolute path: 'here' is the cwd, but it
   corresponds to the repodir, not to 'original_wd' because we 
   had previously 'cd..'d our way back up to repodir.
   
5. We add the same number of '..' as there are segments in the
   'fix_path' 
   
To sum up these steps with an example:
     original_wd         (1) : /tmp/foo/subdir
     repodir             (2) : /tmp/foo 
     fix_path            (2) : subdir
     here (==repodir?)   (3) : /tmp/foo
     original parameter      : /tmp/foo/bar
     stripped parameter  (4) : bar
     corrected parameter (5) : ../bar

Now if I'm understanding correctly, here are some things I am doing 
wrong:

Potentially bad things: 
 A. parameters which are not paths are also affected by this
    filtering -- this could be bad if there are non-path 
    parameters which begin with '/'
 B. assuming the repodir is a (grand)*-parent directory of the 
    original cwd

I could have another look.  How do we deal with repodirs which are
passed in as parameters?

-- 
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon français.

Attachment: pgpAB6WNwdWnx.pgp
Description: PGP signature

_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel

Reply via email to