What does "Revision X doesn't match existing revision Y" mean?

[Brett Cook <Br...@wdc.com>]

Hello,

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".  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.

I'm not subscribed and would appreciate being cc'd in any responses.

Thanks in advance!
Brett

----------------------------------------------------------
Brett A. Cook
Firmware Technologist

Western Digital(r)
1951 S. Fordham Street
Suite #105
Longmont, CO  80503
Email:  brett.cook@wdc.com
Office:  +1-303-834-3223
www.wdc.com

Re: What does "Revision X doesn't match existing revision Y" mean?

[Daniel Shahaf <d....@daniel.shahaf.name>]

Brett Cook wrote on Fri, 21 Jun 2019 15:45 +00:00:
> 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 sharing the diagnosis.  You should be able to use
svn:externals instead of the manual delete-and-checkout procedure.

Cheers,

Daniel

RE: What does "Revision X doesn't match existing revision Y" mean?

[Brett Cook <Br...@wdc.com>]

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 <d....@daniel.shahaf.name> 
Sent: Friday, June 21, 2019 4:00 AM
To: Brett Cook <Br...@wdc.com>; users@subversion.apache.org
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

Re: What does "Revision X doesn't match existing revision Y" mean?

[Daniel Shahaf <d....@daniel.shahaf.name>]

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