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
Received on Tue Oct 23 19:20:39 2007