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'
> (Have you read the online Subversion book or other documentation yet?)
I've skimmed through the book, enough to get by with using it. I
started off with your CVS book, but realized that Subversion was the
way to go :-)
>> 2) Stacked commits. I am sometimes offline for periods of time. It
>> would be great if I could somehow stack up commits to be performed
>> when I get online again. Otherwise I'll have to make one huge commit
>> with all changes, which would make the changes less easily
>> distinguishable. I realize there may be problems (conflicts) when
>> multiple users are committing changes, but since I am the only user
>> accessing the repository, I don't see why this wouldn't be
>> possible. Any thoughts?
>
> Subversion doesn't support this yet, and probably won't anytime soon
> (at least not before 1.0).
I see. Good to know that it is planned.
>> 3) I get intermittent crashes from the BDB when running "svn
>> export". It has happened about three times, and I'm only at revision
>> 11.
>>
>> svn: Couldn't open a repository.
>> svn: Unable to open an ra_local session to URL
>> svn: Unable to open repository file:///home/arksvn/trunk
>> svn: Berkeley DB error
>> svn: Berkeley DB error while opening environment for filesystem
>> /home/arksvn/db:
>> DB_RUNRECOVERY: Fatal error, run database recovery
>>
>> Running "svnadmin recover" fixes it though. Is this normal? (My server
>> is running SVN r3987 and BDB 4.0.14).
>
> This isn't normal, although we've seen it on at least one other
> machine (an old Sparc20 running Debian GNU/Linux).
For the record, I'm getting this on a i686 running Linux.
> Does it still happen if you upgrade your server?
I will try. (I've been putting it off since initial installation was
pretty hairy...)
> Soon Subversion will use BDB 4.1.24, and then we'll see if this
> problem persists. Sorry for the inconvenience.
No problem. I don't expect it to be perfect, yet.
From Branko Čibej:
> This shouldn't happen through normal use. Can you reproduce this
> consistently? If yes, can you tell us exactly how?
No, but it's not consistently reproducible, but it happens "often".
I've had it happen five times so far, out of perhaps 30-40 tries. It
just happened again, this time with a slightly different message:
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
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?
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.
>> 4) How do I find out which revision of Subversion I'm running, when I
>> am running a dev build? "svn --version" just shows "svn, version
>> 0.16.0 (dev build)".
>
> This is something we need to fix, it's been discussed quite a bit
> here. Most Subversions are built from a single revision tree, so we
> could put that revision number where "(dev build)" is, thus making
> everyone's lives easier.
>
> We don't seem to have an issue for it, though; possibly because we
> (uh, I) got temporarily caught up in the complexities of how to handle
> the edge case of a mixed-revision build.
>
> Want to file an issue for this? Put it in milestone 'parallel' for
> now, please, since it doesn't really block anything.
I did (issue number 1053) but for some reason it wasn't possible to set
the milestone.
>> Thanks for all the work. Subversion will be (is) great!
>
> Hope so! :-)
>
> -Karl
>
---------------------------------------------------------------------
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:49:58 2002