Thanks for the information. I also received a separate private response that pointed out that SVN versions 1.7 and above have a single .svn folder in the root, whereas 1.6 and before had separate .svn folders for every sub-directory. This was the key to understanding what the problem is.
The evolution of our codebase has resulted in a directory structure in the repository of: root_dir/sub_dir1 Which worked fine until we discovered that the contents of sub_dir1 needed to be shared with other repositories, and thus should no longer be a sub-directory under root_dir. The "correct" fix should have been to more sub_dir1 to another repository location, but instead, the build process was changed such that root_dir was checked out (along with sub_dir1), then sub_dir1 deleted in the working copy (WC), and finally, sub_dir1 is repopulated from the common repository. This is what creates the error I was seeing, since sub_dir1 is part of the root_dir checkout (and thus reflected in the .svn folder in root_dir). When we try to repopulate sub_dir1 from the common repository, SVN now complains basically that it's already revision controlled via the information in root_dir. Now that I understand the issue, I don't believe there is any workaround for the issue that will allow the builds to work with SVN 1.7 (or above) the way they did with SVN version 1.6. As such, I will work with my team to try and make the changes necessary to work with later SVN versions. Thanks for the fast response! Brett -----Original Message----- From: Daniel Shahaf <[email protected]> Sent: Friday, June 21, 2019 4:00 AM To: Brett Cook <[email protected]>; [email protected] Subject: Re: What does "Revision X doesn't match existing revision Y" mean? Brett Cook wrote on Fri, 21 Jun 2019 04:57 +00:00: > I’m doing a checkout using ‘svn co URL DEST’ and get an error that > says “Revision X doesn't match existing revision Y in DEST”. For future searchers' benefit, the error code should have been E155000. (more below) > I’ve tried figuring out what causes this and why an old version of SVN > (svn, version 1.6.17 (r1128011) compiled Jun 2 2011, 23:35:08) works > and a newer version (svn, version 1.11.1 (r1850623) compiled Jan 9 > 2019, 19:28:50 on x86-microsoft-windows) does not, but have not been > successful. > > When searching for the answer, I get a lot of information about this > happening during a merge, but have yet to find anything related to > checkout. > > > I’m trying to find an explanation of a) what causes this and b) if > there are ways to have SVN not worry about it. It's a client-side error. I think it means working-copy recorded data doesn't match data newly received over the wire, but I haven't had time to confirm this. The relevant client-side library was rewritten between 1.6 and 1.7, which would explain why 1.6 and 1.11 behave differently. Note that 1.11.x is no longer supported; only 1.9.x/1.10.x/1.12.x are currently supported. In 1.12.x (and probably 1.11.x too) the error should only be raised if DEST existed and was a working copy before the 'svn co', so try specifying a new or empty directory as DEST instead. Cheers, Daniel
