You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2022/07/11 14:06:11 UTC
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&replace 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.Schoening@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: TSchoening@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?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Jul 14, 2022 at 9:44 AM Daniel Shahaf <d....@daniel.shahaf.name> 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: What's the status of changing UUIDs of repos in working copies?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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?
Posted by Ryan Schmidt <su...@ryandesign.com>.
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?
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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: TSchoening@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: [External] : Re: What's the status of changing UUIDs of repos in working copies?
Posted by Trent Fisher <tr...@oracle.com>.
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?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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».