On Saturday, December 28, 2002, at 04:49 PM, jonatan wrote:
> Thanks for all of the responses. I will respond to just one to spare
> some bandwidth.
>
>>> 1) "svn delete". This seems to delete the file permanently. Suppose I
>>> have files a and b in revision 1, but in revision 2 I do away with
>>> file b. Since the file is deleted permanently, there is no way to
>>> revert to revision 1, since b is deleted. Am I missing something, or
>>> is there some other way of deleting a file from future revisions
>>> without deleting it from past revisions?
>>
>> You're thinking of CVS. Subversion doesn't delete it in past
>> revisions, only in future ones. If you 'svn update -rOLDREV', the
>> file will reappear. If you 'svn checkout -rOLDREV URL', the checked
>> out tree will have b in it.
>
> I see. Good to know the file can be reinstated. The reason I assumed
> it was lost forever was that "svn cat -r1 b" and svn log b" return
> error messages. Is that intended? I was expecting "svn cat -r1 b" to
> return revision 1 of b, and "svn log b" to return all log messages
> associated with b.
>
> svn cat -r1 b
> subversion/clients/cmdline/cat-cmd.c:69: (apr_err=150004)
> svn: Entry has no url
> svn: 'b' has no URL
>
> svn log b
> subversion/libsvn_ra_dav/util.c:358: (apr_err=160013)
> svn: Filesystem has no item
> svn: REPORT request failed on /path/to/repos
> subversion/libsvn_ra_dav/util.c:152: (apr_err=160013)
> svn:
> file not found: revision `18', path `b'
for both of these, the problem (i think) is that svn is trying to look
in your working copy for the file, and it's been deleted, so it can't
find it. if you give a url as the target instead of a path, it should
work. (i.e. svn log -r 1 file:///path/to/repos/b). the log command
really should be easier to use with deleted files, since you basically
have to know the reivsions it existed in to get any useful log info
about it. this is annoying when you're trying to figure out when
something was deleted for example...
> svn: Berkeley DB error
> svn: Berkeley DB error while checkpointing after Berkeley DB
> transaction for filesystem /home/arksvn/db:
> DB_RUNRECOVERY: Fatal error, run database recovery
out of curiosity, what file system are you running this on? we've had
weird berkeley db errors in the past that turned out to be file system
bugs.
> From Garrett Rooney:
>> well, your repository is getting screwed up somehow. are you
>> accessing it via ra_local (file:// url's) and hitting control-c to
>> kill the process or something? or did svn crash for some reason? if
>> svn exits unexpectedly while talking directly to the repository it
>> can leave the berkeley db database in an inconsistent state.
>
> I do access the repos with ra_local, but am not killing the process
> (that I know of). How do I see if svn crashes?
well, either your apache logs would have something about a crash, or
you'd see your client crash (if you were accessing it via ra_local).
> I should mention that I'm modifying the group owner and privileges of
> the files in the db/ subdirectory of the repository to get them
> readable and writable by a group called "svn". Perhaps this is causing
> problems.
that shouldn't cause that kind of problem (as far as i know).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 28 22:59:21 2002