RFC: Please add 'type:' to "bzr info"

[James Westby]

On (23/11/06 15:44), Jari Aalto wrote:
> 
> Ok, so the (a) is regular full blown version because it reads
> "branch", but differentiating (b) from (c) can't be read from the
> listing. Perhaps that could be made read:
> 
> a)
>     Location:
> +     type: standalone
>       branch root: file:///tmp/1/
> 
> b)
>     Location:
> +     type: shared
>       shared repository: file:///tmp/2
> 
> c)
>     Location:
> +     type: shared trees
>       shared repository: file:///tmp/3

I think this is reasonable. I'm not sure about your choice of names, but
that's not the point.

I'm not sure if there is any sort of policy about the output of info and
what can go in it.

There was also a request for more terse/readable info output, perhaps
there is a case for a --short flag to provide this, there is only going
to be more added to info over time.

> 
> Btw, please drop the trailing slash from the path names. The backend
> tools that read the information can then just 
> 
>     PATH + FILENAME
> 
> instead of
> 
>     (rip off the last slash from PATH) + FILENAME
> 

I'm not sure of the merit of this, I've yet to find somewhere that

  dir//file and dir/file

meant different things or only the second was accepted. There are also
tools to get the second from the first.

There could be a case for changing this in bzr so that it doesn't have
to be implemented by all people using the output. However I would say
there was a stronger case the other way, the visual indication that it
is a directory for humans reading the output, and for those people
trying to find a file using non / prefixed paths (like is output for bzr
status), for whom you have just reversed the problem.

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256