localtransport.abspath

Robert Collins robertc at robertcollins.net
Tue May 23 23:13:56 BST 2006


On Tue, 2006-05-23 at 08:20 -0500, John A Meinel wrote:
> Martin Pool wrote:
> > On 23 May 2006, Robert Collins <robertc at robertcollins.net> wrote:
> > 
> >> Can anyone think of a reason that LocalTransport.abspath should call
> >> normpath ?
> >>
> >> If we call normpath at __init__ time, then just use pathjoin, that
> >> should be much faster. (In fact, in LocalTransport we can even just use
> >> straight concatentation, as we know relative paths in transports should
> >> always be to the right of the transport - not parents or siblings.
> >>
> >> about 10 seconds of commit on a 10K file repo are spend in
> >> LocalTransport.abspath.
> > 
> > I can't think of any.
> > 
> > It's possible this will reveal some bugs in how we handle symlinks
> > within a tree -- things like 'bzr log symlinkeddir/file'  -- but they
> > need to be fixed in a better way, by checking for symlinks or
> > normalizing the path when it's first brought in.
> > 
> 
> I think it was just a safety/correctness thing.
> 
> If you assert that 'relpath' is always a relative path, then you don't
> need pathjoin or normpath.
> pathjoin is used, because it handles both of these cases:
> 
> foo/ + bar => foo/bar not foo//bar
> /foo + /bar => /bar
> 
> normpath is used to handle stuff like
> foo/bar/ + .. => foo/
> 
> But certainly, if we call normpath(abspath()) on the base string, and
> then we assert 'not isabs(relpath)'
> we could chunk up relpath ourselves, and return the correct location.
> 
> We have to support '..' because that is currently used when we clone()
> to a new directory.

Right. What I ended up doing is splitting localtransports use of abspath
into two:

- file canonicalisation for use by get/put/readv/stat etc.
- file normalisation when a client asks for abspath, or clone() is
called.

This worked well, saving an obscene number of normpath calls.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060524/a3477ab2/attachment.pgp 


More information about the bazaar mailing list