> 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.
Ext2 on a SCSI. Trustix 1.5 Linux 2.2.20 on a i686.
>> 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 just ran "svn co file:///path/to/repos" and got:
A repos/trunk
...
Checked out revision 18.
Abort
The "Abort" seems to mean that the client crashed, right? After this I
get the same error message as before when trying to access the repos.
>> 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 23:21:13 2002