Implications of duplicate UUIDs on a server
Hi,for a long time, a company I am working with now has set up new repositories using a “template” repository, which is a folder on the server with a “configured but empty” repository, that was just copied over and over to the SVN server's directory with a new folder name every time a new repository was created. This resulted in lots of repositories having the same UUID as the template.I intend to quick fix that by calling "svnadmin setuuid" after copying the template, for future repositories.But what to do about the existing ones? What are the implications of duplicate UUIDs on a server?For context, we’re talking about some thousand repositories used by some thousand different users. Since on the WC side there is no option to tell “svn relocate” to accept a new UUID, after changing the UUID of a repo, all WCs would break and users would need to check out thousands of repos again. So that’s a big “con” on the list of pros and cons to do anything about the UUIDs. Furthermore, it has been like this for years, and apparently there were no obvious issues so far that they related to the duplicate UUIDs. So the perceived urgency to do something about it is quite low.But I do not assume the UUID is completely irrelevant within the server, is it? So I’d like to understand what the UUID is used for (besides making sure repository and WC belong together), so we can better understand the “pro” side making them all unique would have. E.g. does it improve performance, does it reduce load because of less hash collisions in a cache file, does it prevent obscure errors we might have seen but not realized it was related to the UUID duplicates, etc.?Thank you very much,Christoph
Re: Implications of duplicate UUIDs on a server
On 2025-04-28 18:11, Andreas Stieger wrote:> However, I am not aware of anything breaking for the server itself, access to the on-disk repository date is purely path based unless I am mistaken.We noticed the issue that all had the same UUID while we were trying to figure out a problem we encountered with our set up.We automate a lot of edits and have created our own SVN client program that communicates with the servers. One functionality is that upon creation of a new repository through a REST service (which internally then copies the template repository as described) the client also SVN imports a file to a related repository (e.g. create 'AB-123' and 'AB' gets updated to reflect that '123' exists).We tested that newly developed client feature with the same repository names multiple times, deleting the test repositories and recreating them to test the feature again. And what happened was that according to the TortoiseSVN repo browser, no file was imported, according to the SVN log, it was imported but into the wrong directory, you could not open the SVN log inside the repo browser because it would throw errors, etc. Opening the TortoiseSVN repo browser from the server's file system however, it showed correct commits and contents.Therefore we suspect it was some kind of caching issue in the SVN server (WANdisco) due to same path same UUID same commit number; after restarting the SVN server, the issue went away. But I don't know if WANdisco is a "typical server implementation", or if the issue was something deeper, or if the issues are related at all or pure coincidence, etc.Thanks a lot for the responses so far, Daniel and Andreas. We will evaluate whether we want to do something for the existing repositories.Christoph
