On Mon, 2003-12-29 at 10:31, Aaron Optimizer Digulla wrote:
> - I dumped the linux repos
> - I loaded the dump on Windows.
> - I made some changes on linux
> - I make an incremental dump (using the example in the docs; the example
> has a bug, btw: The parameters for svnadmin dump have changed but the
> example wasn't updated).
> - I copied the dump to windows
> - I tried to load it -> svnadmin just hangs during rev 10 after the successful
> import of rev 9 (8 was the latest on the win side).
>
> I had to abort the load with Ctrl-C. Now, svn up didn't work anymore,
Of course not. A process was directly accessing the repository, and you
interrupted it. That almost always guarantees that the database will be
left in an inconsistent state, usually with a lockfile left behind.
It's a basic FAQ.
> recover did work but I still couldn't load the dump.
Can you show us the dumpfile? Help us reproduce? There's no reason for
a dumpfile to "hang" in the middle of loading. It could be something as
simple as a database permissions problem. I doubt it's a bug in the
actual dumping/loading code. A "hang" is almost always a BDB problem.
Lots of people are ready to help, you're willing to give us details and
help us reproduce your problem.
>
> So again, subversion doesn't deliver :-( Let me emphasise that: I've
> used subversion for a while. It does work under these conditions:
>
> 1. Local repository
> 2. You use only the commands create, update, status and commit.
>
> Anything else seems to break now and then (checkout on Windows destroyed
> the DB when I pressed Ctrl-C because I was in the wrong directory,
> recover sometimes works, sometimes fails, in 0.33.1, load doesn't always
> work).
Welcome to the world of databases. On the one hand, you get
transactions, rollbacks, and hot backups. On the other hand, you need
to be a lot more careful when accessing the database directly. It's a
tradeoff. You can't treat a Subversion repository like CVS repository;
they're fundamentally different beasts.
If you access a Subversion repository directly and interrupt the
process, you'll need to recover the database. That's how it works. If
that's too fragile for you, then stop using 'file:///' access directly.
Run an svnserve daemon instead, and access everything via
'svn://localhost'.
>
> >From my point of view as a user, subversion is not yet usable in a productive
> environment. I understand the arguments why it is supposed to be better than
> CVS but unless you succeed in creating a stable and reliable DB backend
> which doesn't get corrupted all the time, SVN is useless.
This is not a useful criticism. It's not worth my time to argue with
you whether BerkeleyDB is "stable" and "reliable". But I point out that
a corporation sells it for lots of money, mainly to other corporations
that embed it into their own commercial software. I doubt anything
unstable and unreliable could be quite so successful.
The only problem that I see here, perhaps, is that we haven't explained
(well enough) the dangers of using 'file:///' or 'svnadmin' access to
ordinary users.
>
> To stress this: You currently have a major quality problem.
Show us the quality problems, don't make vague statements. If you're
frustrated, ask for help, or give concrete feedback. Please don't
insult the developer community like this.
> A couple of
> my friends also tried Subversion and their conclusion: Good ideas, design.
> Maybe usable in a year.
Really? I know dozens and dozens of people have tried Subversion, and
are using it in real production environments, and think it works great.
Does that counter your statement? ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 29 20:42:54 2003