[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Newbie svn update error: "File not found: revision 'n', path '/path/to/file'

From: Kris Deugau <kdeugau_at_vianet.ca>
Date: 2004-10-22 21:54:44 CEST

I get this error on one file or another (which one depends on where in
the WC tree I am) while trying to update.

I've *probably* managed to Do Things Wrong, as this is the first project
I've put under any kind of revision control (short of occasional "tar -c
workdir/ |gzip>work-mmddyy.tar.gz"). I may be running into the problem
noted in the book that svn does not quite understand file moves or
copies. I may also have made incorrect use of the "svn switch" command
to redirect my working copies to the correct repository locations. :/

I found something similar in the list archives... from August 2003.
The suggested solution didn't help.

My problem, as it stands now:

---
Subversion 1.09 on Debian (from backports.org)
New repository in the last few weeks.  Initial import was at the
"bottom" of the tree, based on (very) old code.  Current revision is 21.
~ 6 months of development imported as revisions up to ~9- assorted
intermediate copies and not-really-part-of-the-project files, many of
which I've since svn rm'ed.  (And manually extracted and left outside of
version control as references for various things.)  I *did* have a few
intermediate versions of the code in amongst the mess.
A few bugfixes committed.
The realization that I need something like the /trunk + /branches +
/tags structure recommened in the book resulted in ~ 3 revisions going
into moving the core code into /trunk from /;  and the addition of
/branches and /tags.  Another few revisions added /tags/1.0 for the
original code, and tags/2.0 for what might be considered the first
"real" release of my new code, based on a specific revision.
/branches/stable was created as a copy from /tags/2.0.
A few bugfixes were ported across copies (/branches/stable -> /trunk
IIRC).  Those were committed, then a few more bugfixes went the other
way and were committed.  I used "svn switch --relocate" to update the
repository path information, as nothing else I tried seemed to work.
A file I had lost a few months ago got found in a ticket-tracking
system, so I added it to /tags/1.0 (as that's the code it was compatible
with), then hacked it to work with newer code, and added it to
/tags/2.0;  then tweaked it a bit further for inclusion in
/branches/stable and /trunk.
Somewhere along the line, something in at least two of my working copies
of various branches has gotten scrambled, and svn update no longer
works- it dies with the error in the subject.
The particular files mentioned do, in fact, exist; and are under
revision control;  and in at least one case it's up to date.
The revision mentioned in the error does NOT contain the file at that
repository path, but the file was there in an older revision.
---
So.  My best guess says that I've probably shot myself in the foot, but
I'm hoping I can do something quick and easy to fix what's broke.
Dump-and-rebuild-repository (with a new series of commits with correct
repo paths) might be an option;  it would end up with mangling the
commit times but I don't consider that critical. 
Dump-and-mangle-the-dump-for-reloading-with-correct-paths would be more
elegant, but much more time-consuming.
Some kind of client-side "Ignore the error and update already!" option
would be best.
Suggestions?
-kgd
-- 
Get your mouse off of there!  You don't know where that email has been!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 22 21:55:31 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.