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

Re: "transaction has active cursors" / "Invalid change ordering" ???

From: Brian Denny <brian_at_briandenny.net>
Date: 2003-04-25 23:35:11 CEST

On Fri, Apr 25, 2003 at 03:34:52PM -0500, Ben Collins-Sussman wrote:
> Yes, Brian... sorry to be so silent on this issue. My original
> response to you was based on a misunderstanding of my own, so I fear
> that I only made you more confused. :-(

don't sweat it -- i learned a *lot* about subversion trying to figure
this puppy out. :)
> Mike's solution is the correct one: the libsvn_wc code which crawls
> the wc and generates a report should remember every path that is
> "missing" (i.e. the entry exists, but the actual object is gone).
> Then, after the update completes, it should check to see if any of the
> "missing" paths are *still* missing (i.e. they weren't restored by the
> server)... if so, the entries should be permanently removed.

cool. i'd like to make sure i understand what the essential difference
is between this idea and my original idea #2 (in which i was going to
change recursively_tweak_entries to check for missing paths and delete
their entries -- i posted a patch in the other thread.)

is it that recursively_tweak_entries is too general-purpose, and might
get called at times other than at the end of a successful update?

> We do something similar to this in another scenario, but I won't go
> into detail about that here, lest we confuse things more. Let's just
> say there's a good precedent for this solution. :-)

if you really think it would confuse things, i'll trust your judgment on
that; but i am kinda curious. :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 25 23:31:24 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.