Re: What's the status of changing UUIDs of repos in working copies?
On Thu, Jul 14, 2022 at 9:44 AM Daniel Shahaf wrote: > > Ryan Schmidt wrote on Wed, 13 Jul 2022 21:45 +00:00: > > [...] that way all your public users' working copies continue to work > > as before, and you would just need to check out new working copies for > > those hopefully fewer and more technically capable internal users who > > were using the formerly private server with its old UUIDs. > > Or manually change the UUID in those working copies using sqlite3. Or throw in the towel on trying to transform multiple simultaneous upstream Subversion servers, and switch to git. Or switch to using a git-svn setup to keep the upstream servers in sync
Re: [External] : Re: What's the status of changing UUIDs of repos in working copies?
On 7/13/2022 9:25 AM, Daniel Shahaf wrote: Thorsten Schöning wrote on Mon, Jul 11, 2022 at 16:06:11 +0200: Do you have any tips for the easiest possible change of the UUIDs? It'll be a lot easier to set the repository's UUID to the one expected by clients. See «svnadmin setuuid». This is what I do, I have svnsync replicas at another site for disaster recovery, and I change the UUIDs to match so that, in a disaster, I can flip the DNS alias and they can keep working transparently (of course, making the replica read-write is also needed, but that's a different, more complicated, subject). trent...
Re: What's the status of changing UUIDs of repos in working copies?
Ryan Schmidt wrote on Wed, 13 Jul 2022 21:45 +00:00: > [...] that way all your public users' working copies continue to work > as before, and you would just need to check out new working copies for > those hopefully fewer and more technically capable internal users who > were using the formerly private server with its old UUIDs. Or manually change the UUID in those working copies using sqlite3.
Re: What's the status of changing UUIDs of repos in working copies?
On Jul 13, 2022, at 12:04, Thorsten Schöning wrote: > Guten Tag Daniel Shahaf, > am Mittwoch, 13. Juli 2022 um 15:25 schrieben Sie: > >> It'll be a lot easier to set the repository's UUID to the one expected >> by clients. See «svnadmin setuuid». That was going to be my suggestion as well. > Which isn't possible, as the logically same repo is used by working > copies as public or private repo currently. One pair of working copies > will break this way. :-) I guess I don't understand your scenario well enough then to understand why this is not possible. What pair of working copies are you talking about? You said you used to have two servers with two synced sets of repositories with two different UUIDs and now want to move to a single server with a single set of repositories. Since changing the UUIDs of the public working copies directly is not a feature offered by Subversion, and since checking out new working copies for your public users is difficult to coordinate, as you explained, then it should be easier to change the repositories on the formerly private server to have the UUIDs of those on the now decommissioned public server, that way all your public users' working copies continue to work as before, and you would just need to check out new working copies for those hopefully fewer and more technically capable internal users who were using the formerly private server with its old UUIDs.
Re: What's the status of changing UUIDs of repos in working copies?
Guten Tag Daniel Shahaf, am Mittwoch, 13. Juli 2022 um 15:25 schrieben Sie: > It'll be a lot easier to set the repository's UUID to the one expected > by clients. See «svnadmin setuuid». Which isn't possible, as the logically same repo is used by working copies as public or private repo currently. One pair of working copies will break this way. :-) I hoped something like "setuuid" would be available for working copies in the meantime somewhere hidden... Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 (0)515 94 68 - 0 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz
Re: What's the status of changing UUIDs of repos in working copies?
Thorsten Schöning wrote on Mon, Jul 11, 2022 at 16:06:11 +0200: > BUT: Each working copy stores a UUID of it associated repo and those > UUIDs are different between private and public repos. In the past, it > wans't supported to change that, one needed to either replace them in > config files or later in the SQLite database maintained in the working > copy. That's still the case. > Do you have any tips for the easiest possible change of the UUIDs? It'll be a lot easier to set the repository's UUID to the one expected by clients. See «svnadmin setuuid».
What's the status of changing UUIDs of repos in working copies?
Hi everyone, I have hundreds of SVN working copies all over my IT. All of those are used to maintain source code of software, configs of systems, deployments of software for systems etc. The important thing to note is that some of those working copies are really stored on the systems for which they maintain configs or deployed software, which includes customer systems where I can't access at will, but need to coordinate with or let customers or let those do things themself. I have two VMs containing all my repos, while VM1 is the master and for internal purposes only. All of those repos get SVNSYNCed to VM2, which is publicly accessible using mod_dav_svn. Those publicly available repos are used by and for customers and our own servers. Don't want to have VM2 anymore, as it consumes additional storage, needs to be maintained etc. Might have made sense in the past, but have changed my mind now. Putting things back into VM1 isn't that difficult, just need to deal with external access through the firewall, configs for mod_dav_svn and stuff. Did that already, seems to work. BUT: Each working copy stores a UUID of it associated repo and those UUIDs are different between private and public repos. In the past, it wans't supported to change that, one needed to either replace them in config files or later in the SQLite database maintained in the working copy. Is that still the case of am working copies allowed to changer their UUIDs with SVN tools these days? According my research, it's still not, but all threads were some years old already. Do you have any tips for the easiest possible change of the UUIDs? I see only two ways: Some script using SQLITE if available or storing the URL checkout URL of the current working copy, move .svn aside and --force-checkout the same URL again. I have quite some systems which don't have SQLITE clients available and can't install them easily. Any other way, possibly search on the database file? :-) Thanks for suggestions! Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 (0)515 94 68 - 0 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz
