Hi, Den mån 28 apr. 2025 kl 17:18 skrev LWChris <lwch...@gmx.de>:
> 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. > We do something very similar, although we used something like: [[[ svnadmin create newrepository svnadmin dump -rHEAD template | svnadmin load --ignore-uuid newrepository ]]] ...to copy the template repository. The advantage is that we can "version control" the template repository without having all the history of the template repo included in the new repository - a dump with -rHEAD will just contain the template at the current state so the new repository has the template as r1. Initially we forgot to add the --ignore-uuid option, effectively causing all repos having the same UUID, just like your case. Your solution sounds fine - as long as you are happy it. 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.? > Subversion checks for UUID in a few cases. Of the top of my head: * As you already discovered, svn relocate is checking the UUID of the new repository, refusing to relocate if you try to relocate to a different repository. This is for good reasons - you will break the WC. * When checking if merges are same-repository or foreign-repository merges. I'm probably missing some cases. As far as I know the repositories are primarily identified by the PATH/URL on the server side, so there are no issues server-side having duplicate UUIDs, at least not in the standard server implementation. So the win would primarily be to protect your users from making mistakes - however that very protection will make migration very difficult. We have - so far - decided against changing the UUIDs for the very reasons you mention. We almost never relocate (having a dedicated svn.example.com domain name which will not change, and no reasons to rename the repositories) and we never do foreign repository merges. Cheers, Daniel
