merge tracking: robustness?

[Jack Repenning <jr...@collab.net>]

What standard has been set for robustness of the merge tracking  
stuff, in the face of user-accessible silliness?

I just got this error:

 > svn ci -m"rename gamma to gamma-1"
Deleting       greek/A/D/gamma
Adding         greek/A/D/gamma-1
subversion/libsvn_client/commit.c:916: (apr_err=160046)
svn: Commit failed (details follow):
subversion/libsvn_fs_util/mergeinfo-sqlite-index.c:202: (apr_err=160046)
svn: Unable to close due to unfinalised statements


... but upon investigation I find that the repo showing the problem  
was made with a rather old 1.5 revision (r26502), though I'm using a  
more modern client (r27305).  When I build a repo from scratch with  
the modern 1.5 (r27305), I can't reproduce it.

So I didn't say anything. Then it occurred to me that, with most of  
the merge-related stuff recorded in properties, this failure come  
come from some sort of botch in svn:mergeinfo ... and any joe user  
can change the merge info, right?  So maybe this case is interesting  
anyway?

Let me know; I'm happy to recreate the repo state and file something  
more concrete, but would like to be sure it's worth the effort.

-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: merge tracking: robustness?

[Jack Repenning <jr...@collab.net>]

On Oct 23, 2007, at 11:32 PM, Daniel Rall wrote:

> Do you have an idea of the reproduction recipe for the problem?

Hmmm, maybe not: it's not reproducing.  Doubtless, I did something or  
other to the repo after the conference, which I no longer remember.   
And since I nuked the repo in that state, I have no non-synaptical  
memory to fall back on.

Sorry.

-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning

Re: merge tracking: robustness?

[Jack Repenning <jr...@collab.net>]

On Oct 23, 2007, at 11:32 PM, Daniel Rall wrote:

> Jack, would you:
>
> 1) Run this under gdb, to determine exactly where in
> mergeinfo-sqlite-index.c this problem is being triggered.
>
> 2) Get the svn:mergeinfo for gamma-1, and tell us if it makes sense
> for your repository.


Sure will, as soon as I get a chance.  I do have an svnadmin dump of  
the repo, just a few revs before this came up, and all the work done  
therein since then is done by following my demo script from Subconf,  
so I'm pretty confident I can reproduce.  As soon as I get the time....

-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning

Re: merge tracking: robustness?

[Daniel Rall <dl...@collab.net>]

On Tue, 23 Oct 2007, Jack Repenning wrote:
...
> > svn ci -m"rename gamma to gamma-1"
> Deleting       greek/A/D/gamma
> Adding         greek/A/D/gamma-1
> subversion/libsvn_client/commit.c:916: (apr_err=160046)
> svn: Commit failed (details follow):
> subversion/libsvn_fs_util/mergeinfo-sqlite-index.c:202: (apr_err=160046)
> svn: Unable to close due to unfinalised statements

Since as you pointed out, users can inject arbitrary mergeinfo,
Subversion needs to be able to cope with this situation, at least by
ignoring nonsensical mergeinfo.

> ... but upon investigation I find that the repo showing the problem  
> was made with a rather old 1.5 revision (r26502), though I'm using a  
> more modern client (r27305).  When I build a repo from scratch with  
> the modern 1.5 (r27305), I can't reproduce it.
...

Do you have an idea of the reproduction recipe for the problem?

The error message "Unable to close due to unfinalised statements" is
coming from sqlite3_close(), which is called from Subversion's
close_db() wrapper, which is in turn called from four places in
mergeinfo-sqlite-index.c.  From the information you provided, I'm
guessing that this particular case is from the "cleanup" jump point in
svn_fs_mergeinfo__update_index(), where an attempt to close the DB
connection is causing SQLite to complain, likely because a transaction
was begun without it being committed (or aborted?).  From
sqlite3_close():

  /* If there are any outstanding VMs, return SQLITE_BUSY. */
  if( db->pVdbe ){
    sqlite3Error(db, SQLITE_BUSY,
        "Unable to close due to unfinalised statements");
    return SQLITE_BUSY;
  } 

The early jump to "cleanup" in svn_fs_mergeinfo__update_index() is
likely caused by index_txn_mergeinfo(), which in turn calls
index_path_mergeinfo(), which is probably choking up a hairball
(returning an svn_error_t *).

Jack, would you:

1) Run this under gdb, to determine exactly where in
mergeinfo-sqlite-index.c this problem is being triggered.

2) Get the svn:mergeinfo for gamma-1, and tell us if it makes sense
for your repository.