[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-04-25 23:40:32 CEST

Brian Denny <brian@briandenny.net> writes:

> 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?

Hmm, maybe your proposal was exactly the same. Does anything call
recursively_tweak_entries() other than 'svn up' and 'svn switch'?
I don't think so...

> > 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. :)

You asked for it. :-)

If you schedule a file for deletion and then commit, guess what? The
file's entry isn't really gone yet. It's marked as "deleted" --
past-tense. Why? For update reporting. When reporting wc state to
the server, the parent dir claims to be at revision N, but really,
it's a lie, because rev N of the directory includes the deleted file.
(The file was deleted in rev N+1). Thus the reporter has to notice
the 'deleted' entry and report it as missing. The server does a diff,
sees no difference between the txn and rev N+1, and sends no changes.

Now we get into post-update processing. The directory is bumped to
working revision N+1. If the server never mentioned the deleted file,
then heck, it *should* be gone for good, so we remove the 'deleted'
entry permanently.

(On the other hand, the server may have decided to add a *different*
file by the same name. That's fine too -- the 'deleted' entry would
just get overwritten by the new file's entry.)

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:42:09 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.