Re: Please publish unsubscribe information in the patch update mailings.
Hi, "CCD Systems Help Desk" wrote: > Subject: Please publish unsubscribe information in the patch update mailings. > > We no longer require updates for SubVersion, please remove us from the > mailing list. Please read: http://subversion.apache.org/mailing-lists.html Andreas
Questions on migrating SVN (and Trac) to a Google Compute Engine instance
Greetings. My employer has put me on a project of moving our SVN and Trac servers from the old Windows Server 2003 box on which they're currently running over to a Google Compute Engine instance. To that end, I've set up the instance using Bitnami's canned Trac image, which includes SVN 1.9.5 (r1770682) and Trac 1.0.15 (our old SVN server is 1.5.0, r31699, and our old Trac server is 1.0). I've got a test repository set up, and I've arranged access via both https: and svn+ssh: protocols, which I then spent a few hours testing from Eclipse. But I'm not the one who set up the original SVN and Trac environments in the first place, and so what little I know about administration on these products is what I've picked up over the past few weeks. Now, Trac's wiki page on the process of a dual migration, https://trac.edgewall.org/wiki/TracMigrate seems to be pretty straightforward on the subject of migrating Trac, but the section on migrating SVN is not so. They recommend setting up a "pre-revprop-change" script with nothing in it but the initial "shebang", for each target repository, and then using "svnsync" to migrate the repositories. It also assumes the existence of an "svnsync" user-ID on the target system, which (at least assuming it's an operating system user-ID) we don't currently have. Everything else I've read, especially The SVN Book, says to use "svnsync" only for mirroring, and instead migrate using some combination of "svnadmin dump," "svnadmin load," "svnrdump," and "svnrload." I'm not seeing a lot about copying configuration files or hook scripts. Is that just a matter of sending them over? And I don't quite understand how this whole business impacts the authors of commits. Does SVN care whether the author of a commit is a user known to SVN or to the operating system? I've already copied an "authz" file from one of the existing repositories into the test repository, and given the current users Apache user-IDs and passwords, but that's all, so far. -- James H. H. Lampert Touchtone Corporation
svn_client_status5 veeeeeeery slow [SEC=UNCLASSIFIED]
UNCLASSIFIED Hi, svn-win32-1.88 I am not subscribed to the mailing list and would appreciate being cc:ed in any response. I have a service that uses svn_client_status5 to determine the current state of a subversion working copy. Even though I have several thousand files in the working copy, this normally takes a few seconds. However, on one particular PC, this takes several minutes. This particular PC doesn't have access to the repository - the working copy is transferred via CD. However, my laptop doesn't have access to the repository when it's not connected to the network and it doesn't exhibit this problem. Furthermore according to WireShark, the software is not trying to access the repository. Using sysinternals procmon, it appears that every single file in the working copy is accessed on the problem PC, but only modified files are accessed normally. In both cases, the directory tree is scanned (apparently in search of .svn directories) and many accesses are made in the .svn directory (especially ws.db). Consequently procmon reports 416,177 file system events on the problem PC vs 30,068 on another normal PC. My call is: svn_error_t *err = svn_client_status5(NULL, context, path, &rev, svn_depth_infinity, true, false, false, true, false, NULL, statuslist_walk_cb, this, pool); Any idea why svn_client_status5 is behaving so strangely? Cheers Russell IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.
Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance
On Jul 27, 2017, at 14:23, James H. H. Lampert wrote: > > They recommend setting up a "pre-revprop-change" script with nothing in it > but the initial "shebang", for each target repository, and then using > "svnsync" to migrate the repositories. Sounds plausible. An empty pre-revprop-change hook script would allow any revprop change, which you may not want. It's probably possible to write a more-specific script that would allow only the changes svnsync needs and disallow others. > It also assumes the existence of an "svnsync" user-ID on the target system, > which (at least assuming it's an operating system user-ID) we don't currently > have. svnsync doesn't care what system user account you use. You would probably want to pick the username that the server process will use. If you're serving with Apache, that'll be a username like nobody or httpd or apache. > Everything else I've read, especially The SVN Book, says to use "svnsync" > only for mirroring, and instead migrate using some combination of "svnadmin > dump," "svnadmin load," "svnrdump," and "svnrload." svnsync is probably best, since it allows you to easily incrementally mirror a live read/write repository to another server. It can be slow but once it's done it makes it very quick to switch from the old server to the new one with minimal downtime. Some of the other methods require you to make the source repository read-only or take it offline for the duration of the migration, which could take hours or days depending on how large your repository is. > I'm not seeing a lot about copying configuration files or hook scripts. Is > that just a matter of sending them over? Pretty much. You may need to edit the files if the setup of the new server differs from the old one. New versions of Subversion may also offer more features than old versions, which may affect your scripts or configuration. > And I don't quite understand how this whole business impacts the authors of > commits. Does SVN care whether the author of a commit is a user known to SVN > or to the operating system? I've already copied an "authz" file from one of > the existing repositories into the test repository, and given the current > users Apache user-IDs and passwords, but that's all, so far. If you're using Apache to serve the Subversion repository, on both the old and new systems, then you're right, Subversion users don't care about server system user accounts; they only care about user accounts as defined in whatever authentication you've set up for the repository in Apache.
Re: Questions on migrating SVN (and Trac) to a Google Compute Engine instance
They recommend setting up a "pre-revprop-change" script with nothing in it but the initial "shebang", for each target repository, and then using "svnsync" to migrate the repositories. It also assumes the existence of an "svnsync" user-ID on the target system, which (at least assuming it's an operating system user-ID) we don't currently have. This doesn't refer to a unix user id, just the username and password used to authenticate to the source repository. It can be any username (not necessarily 'svnsync'). Just make sure that it has read access to the entire repository that you are svnsync'ing Everything else I've read, especially The SVN Book, says to use "svnsync" only for mirroring, and instead migrate using some combination of "svnadmin dump," "svnadmin load," "svnrdump," and "svnrload." While svnadmin dump/load is the recommended path for migrating repos to a newer version, svnsync does pretty much the same thing. You just need to use the newer versions of the svnadmin and svnsync binaries (which are installed in your target system). I'm not seeing a lot about copying configuration files or hook scripts. Is that just a matter of sending them over? Neither svnsync nor svnadmin dump/load will take care of things like hook scripts/configuration files. You will have to copy these over manually and place them in their appropriate paths. And I don't quite understand how this whole business impacts the authors of commits. Does SVN care whether the author of a commit is a user known to SVN or to the operating system? While svnsync'ing you don't need to worry about authz at all, because I see that the document you posted suggests init over file:// . This will not involve authz. You will however need to set up and configure authentication and authorization just like it is in the old system when you want to start using the new system. Regards, Arwin
