Ticket Change Details
Not logged in
Overview

Artifact ID: e193d0a85f2ec090d17b46b0a05479eb5c982c13
Ticket: 74cfdb438a246e462a9a860dff858aa0f773a508
`fs info FILENAME` appears to be broken
User & Date: anonymous 2011-02-23 22:52:49
Changes

  1. comment changed to:
    Pretty easy to reproduce this one.
    
    <verbatim>% cd /tmp
    % mkdir bug-test
    % fs new fs-info-test.fossil
    % mkdir co
    % cd co
    % fs open ../fs-info-test.fossil 
    % echo bar > foo.txt
    % fs add foo.txt 
    ADDED  foo.txt
    % fs ci -m "Add a test file" foo.txt 
    New_Version: a152dde43c9bf3410205e98b7fee57555d92378a
    % fs info foo.txt 
    fossil: no such object: foo.txt
    
    Exit 1</verbatim>
    
    Getting in to feature request land that led to uncovering this bug.
    
    I was doing a vendor import of some code and started to apply a local patch to the new branch. I was hoping to be able to snag the contents of the patch from branch=trunk, but wasn't able to do so. While poking around to find an easy way to get the artifact-id from the command line, I stumbled across this bug not working.
    
    Ideally I'd like to be able to do something like:
    
    <verbatim>% fs finfo -p -r master some/path/foo.txt</verbatim>
    
    Without having looked at the code, it appears as though the arg to -r isn't performing a lookup of symbolic names.  Associating artifact-ids with filenames would be ideal.  Something like:
    
    <code>fs artifact some/path/foo.txt</code>
    
    And have it spit out a list of artifacts that match a given file, or "-r tip" and have it only spit out the artifact-ids of what's in tip.
    
  2. foundin changed to: "4f78571eb2"
  3. private_contact changed to: "127204cd1ac207bde45a3475c9bf39db33e7d155"
  4. severity changed to: "Important"
  5. status changed to: "Open"
  6. title changed to: "`fs info FILENAME` appears to be broken"
  7. type changed to: "Code_Defect"