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

Re: Sharing SVN-Repository between Linux/x86 and WinNT

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2003-12-29 23:16:33 CET

Ben Collins-Sussman wrote:

> On Mon, 2003-12-29 at 15:49, Aaron Optimizer Digulla wrote:
>
>
>>Thanks, that's *exactly* what I mean with "quality problem". More precisely:
>>Is pressing Ctrl-C while the programm accesses the DB such an uncommon
>>event? Probably not (or why is that in the FAQ?)!
>
>
> Yes, actually, it is fairly uncommon to use file:/// access at all.
> Most people use a network to access a repository. This means that a
> persistent server process (either apache or svnserve) is accessing the
> repository. If a client is interrupted or disconnects, it's easy for
> the server to just toss the work and cleanly disconnect from the
> database.
>
>
>>Why is there no signal handler which does a rollback?
>
>
> Hm, that's a legitimate question. I wonder why we are/aren't doing
> this. The signal handler ought to be able to guarantee that we close
> the database environment cleanly. Can another developer comment on
> this?

For the 'svn' process we do catch the signal, it's how the cancellation
stuff works. Repeated signals may not be caught (I don't think we reset
the signal handler after it fires, and IIRC some systems require that),
and in those cases (hiting control-c multiple times) you can still kill
the process, but if you hit control-c once it should let you exit
cleanly. If it doesn't that is a bug.

For 'svnadmin' i don't think we have a cancellation system in place, so
if you hit control-c it will most likely mess up the db.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 29 23:17:18 2003

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.