Adding files from different threads in same Folder or sub folders to SVN fails

Hello,  We are trying to commit new files concurrently from different threads in one existing directory and its existing sub directories. We are getting following error.   svn: E160024: File or directory 'test' is out of date; try updating svn: E160024: version resource newer than txn (restart the commit) svn: E175002: CHECKOUT of '/svn/temp/!svn/ver/6435/test': 409 Conflict (http://XXXXXXXXXX.com:444) All files are new. We are using VisualSVN server 3.5.7 (Subversion 1.9.5, Apache 2.2.31) and SVNKit (1.8.15) as client side library. Should SVN resolve conflict automatically as same file is never added or updated simultaneously in our test. Please guide us how we can achieve this scenario, "Updating or adding files simultaneously in same directory and child directories. Same file is not updated simultaneously that we have taken care of." Thanks and Regards.

Last updated 5 years ago

Are you using a single working copy for those threads? From my understanding of SVN - definitely NOT perfect in this case - a single working copy was never meant to be used to check in multiple changes concurrently via different threads so such a use-case would be breaking core assumptions.  A different thought: have all of the directories been previously added and checked in? If not then some threads could be checking in a state where the directory exists and, given parallelism, a different thread could be checking in a state where the directory did not exist. That would be a true conflict. So at a minimum all directories must be checked in beforehand.  A parallel thought experiment based solely on files would also point to conflicts (file exists in checkin at time T0 and a different file is added (but the 1st file does not exist) in a checkin at T1: conflict).  A huge amount of proper coordination of the threads must happen to make this truly an "additive only" affair. And, sadly, the working copy must declare that knowledge to the repository for each checkin. So there needs to be a checkin; working copy update; checkin; working copy update; ... cycle going on.  In general, I've got to ask: why not just add all of the files and then check them all in at once?

Hi Dough,  Thank you for your detail reply. Please consider following points.  We are using SVNKit's lower level APIs which does not keep local working copy. SVNKit's ISVNEditor works without local working copy and commits file to SVN. We created/checked in all directories before adding files concurrently.  "why not just add all of the files and then check them all in at once?" We are creating content server like component on which multiple users upload files concurrently and we commit those files to SVN to have versions of those files.  One more point, we found following thread which is talking about httpv1 and httpv2 and same kind of exception we are having,  http://subversion.tigris.org/ds/view...sageId=1139464   We are also thinking that when our service gets files from user it will store them on disk first and there would be one job which will be committing one file at a time one by one to SVN.  Please do let us know if you have any comments on the basis of this reply. Once again thank you for your observations, guidance and detailed reply.  Regards, Vishal

Vishal: When you want to create something new based on an existing infrastructure you need to adhere to that infrastructure's architecture. And implementation limitations. Given Subversion is OpenSource, you can also jump in and help fix any implementation details that are getting in your way. The community would love it.  Of course, in this case the SVNKit java implementation is the SVN client, not the SVN repository server which may be where the blocking issue occurs (or, more possibly, the transport).  Given the information in the issue thread you found (note: some of those are SVN committers), it might be wise to move to using the "svnserve" protocol. I don't know SVNKit - does it talk that protocol or only the web_dav_svn protocol? On the other hand, at least issue #3119 referenced was fixed in SVN 1.6.4.  If you can jump into the C code and help fix the underlying error, then I'd discuss things with the SVN Committers (at least see if they have any pointers). If you're a java solution only outfit then you could consider javaHL for calling directly into some of the C code so you can use the "svnserve" protocol. If you are completely boxed in to pure java then you may need to serialize/single thread the updates so that the update is always referencing the latest revision.

Hello Doug,  Unfortunately we are boxed to pure JAVA + HTTP communication to SVN. We will talk to SVNKit support too.  We may end up create one Job for ourselves which will serialize/single thread updates so that the update is always referencing the latest revision.  Thank you for your detailed reply and guidance.  Regards, Vishal