More on this ...
The "file@rev" (PEG revision) formulation seems to work for these files. e.g.,
galaxy 0 ~% svn ls -r 127892
https://mls:8043/mls3/lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_align.c
svn: REPORT request failed on
'/mls3/!svn/bc/129661/lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_align.c'
svn: File not found: revision 127478, path
'/lf/futures/next/wip/thineng/Striker/apps/colorcal_app_align.c'
fails, while:
galaxy 1 ~% svn ls
https://mls:8043/mls3/lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_align.c@127892
colorcal_app_align.c
succeeds.
Howeverr, this file exists in all revisions from when it was created
(r127892) up to and including HEAD. So, the "file@rev" (PEG) formulation
shouldn't be needed, right?
Even if file@rev formulation is needed, the behaviour is inconsistent
between the files that were added at the same time (r127892). .buildname
and colorcal_app_align.h are fine with either form, while
colorcal_app_align.c, colorcal_app_rto.h and colorcal_app_rto.c only work
with the file@rev formulation, yet all files were created in the repo at the
same time.
Sill Scratching My Head,
T.
On 2/14/07, Tim Noell <tnoell@gmail.com> wrote:
>
> Hi svn list:
>
> I have a repo with a wierd problem that I need help on.
>
> Namely, there are 3 files that were added in the same commit that show up
> in the svn ls output of the directory parent but when you svn ls them with a
> full path to the individual file, svn reports an error.
>
> Here is an example on a file called colorcal_app_align.c in a directory
> named apps:
>
> zeppo 0 tnoell% svn ls -r 127892
> file:///svn/mls3/lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps| grep colorcal_app_align.c
> colorcal_app_align.c
> zeppo 0 tnoell% svn ls -r 127892 file:///svn/mls3/lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_align.c
>
> svn: File not found: revision 127478, path
> '/lf/futures/next/wip/thineng/Striker/apps/colorcal_app_align.c'
>
> The files were created in r127892. The rev it is complaining about is
> before that.
>
> Interestingly, there are two other files that were added in the same
> transaction that do not have this problem. This transaction also has a
> number of modified files and a replaced file.
>
> The behavior anomaly is there on svn diff, as well. Namely, a diff on the
> file gets the above error, but a diff on the parent directory node shows the
> correct diff of the affected (and unaffected) files.
>
> The good news - the contents of the files appear to be fine. When we svn
> co the dir, the files are AOK.
>
> So, this looks like a metadata problem with the file node itself, not the
> contents.
>
> I'm running an svnadmin verify right now, but I don't have results yet -
> This repo is 3+ years old with 125k+ revisions.
>
> Other data about my environment:
> subverison version 1.3.2
> Host is FreeBSD 5.4
> back end is fsfs
> problem is independent of RA layer used (see file:// urls, above)
>
> Here is log from commit where files were created:
> zeppo 0 tnoell% svn log -v -r 127892 file:///svn/mls3
> /bonus/scratch/tnoell
> ------------------------------------------------------------------------
> r127892 | shuman | 2007-02-05 15:52:17 +0000 (Mon, 05 Feb 2007) | 2 lines
> Changed paths:
> A /lf/futures/next/branches/StrikerEng/archives/eea (from
> /lf/futures/next/wip:127051)
> A /lf/futures/next/branches/StrikerEng/archives/eea/.buildname
> R /lf/futures/next/branches/StrikerEng/archives/eea/thineng (from
> /lf/futures/next/wip/thineng:127478)
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/Imakefile
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app.c
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app.h
> A
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_align.c
> A
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_align.h
> A
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_rto.c
> A
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_app_rto.h
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_calcmach.c
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/colorcal_calcmach.h
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/data_colorcal_common.h
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/engmgrcomm.h
> R
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/apps/flex.c
> (from /lf/futures/next/wip/thineng/Striker/apps/flex.c:127579)
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/driver/data_colorcal_drv.c
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/driver/data_colorcal_drv.h
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/driver/tpsdrv.c
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/sharc/colorcaltypes.h
> M
> /lf/futures/next/branches/StrikerEng/archives/eea/thineng/Striker/sharc/data_colorcal.c
>
> Creating special spin eea
> external=n
> ------------------------------------------------------------------------
>
> I'll be glad to post fsfs rev files, or other data, if someone can tell me
> what to post.
>
> Thanks In Advance,
> Tim Noell
> tnoell@gmail.com
>
> --
> // "Only dead fish go with the flow"
--
// "Only dead fish go with the flow"
Received on Thu Feb 15 19:53:46 2007