You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tim Noell <tn...@gmail.com> on 2007/02/15 18:53:01 UTC
More Info on Re: svn operations on a dir node show files in it, but operations explicitly on files fail
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 <tn...@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"
Re: More Info on Re: svn operations on a dir node show files in it, but operations explicitly on files fail
Posted by Tim Noell <tn...@gmail.com>.
Hi Ryan:
Thx for the suggestion.
However, the file exists in all revisions from HEAD back to when it was
added. Shouldn't that be good enough for the -r 127892 formulation of the
command to work? svn doesn't need a hint to find this incarnation of the
file in that place with that name ...
Anyway, I searched the logs with -v, and this file has never existed and
been deleted in any previous revisions, so the PEG formulation shouldn't be
requried (but it is).
Also, I completed an svnadmin verify of this repo and it did not report any
errors.
Any more ideas out there?
T.
On 2/15/07, Ryan Schmidt <su...@ryandesign.com> wrote:
>
> On Feb 15, 2007, at 12:53, Tim Noell wrote:
>
> > 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.
>
> Sounds like Subversion doesn't think those files' histories are
> continuous. Have those files been deleted and re-added at some point?
> You may want to check the complete log of those files, with the -v
> option, to see what's been happening with them.
>
>
> --
>
> To reply to the mailing list, please use your mailer's Reply To All
> function
>
>
>
--
// "Only dead fish go with the flow"
Re: More Info on Re: svn operations on a dir node show files in it, but operations explicitly on files fail
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 15, 2007, at 12:53, Tim Noell wrote:
> 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.
Sounds like Subversion doesn't think those files' histories are
continuous. Have those files been deleted and re-added at some point?
You may want to check the complete log of those files, with the -v
option, to see what's been happening with them.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org