How to rename a shelf?
Say I shelve some changes: svn x-shelve fix-some-bug …then later I create an issue in my project's issue-tracker, and I want to add the issue number to the shelf name — for example, 12345-fix-some-bug — to help me find it later on. My current process is to x-shelve whatever other stuff I'm currently working on, then x-unshelve fix-some-bug, then x-shelve those changes as 12345-fix-some-bug, then x-unshelve my other changes… but that only works if my other changes are shelvable. Is there a simpler way? -KR
Re: SVN 1.11 authentication freeze 30-45 seconds
> On Jan 10, 2019, at 1:43 PM, Cotrut, Michael > wrote: > > Hi Mark, > > We are migrating from SVN 1.9.2 to 1.11 (Apache 2.2 to Apache 2.4) > > We’ve been using SVN for 7-8 years and we have hundreds of repositories and a > client base of 300-400 users. > > We’ve been noticing during testing of 1.11 a period of about 30-45 seconds > delay when the SVN seems frozen upon an initial log in to a repository or > after the user is not using SVN for a while. After the initial delay > everything seems to be working as it should. We don’t have this delay on SVN > 1.9.2 and we are using similar configuration. I think this is a known issue with Apache 2.4 on Windows when using LDAP authentication. Try adding the LDAPTimeout directive with a low value like 5. Mark
SVN 1.11 authentication freeze 30-45 seconds
Hi Mark, We are migrating from SVN 1.9.2 to 1.11 (Apache 2.2 to Apache 2.4) We’ve been using SVN for 7-8 years and we have hundreds of repositories and a client base of 300-400 users. We’ve been noticing during testing of 1.11 a period of about 30-45 seconds delay when the SVN seems frozen upon an initial log in to a repository or after the user is not using SVN for a while. After the initial delay everything seems to be working as it should. We don’t have this delay on SVN 1.9.2 and we are using similar configuration. During the freeze time I see lots and lots (thousands) of these messages logged: [Wed Jan 02 11:58:33.427566 2019] [authz_core:debug] [pid 2616:tid 896] mod_authz_core.c(817): [client X.XX.XXX..XXX:64085] AH01626: authorization result of Require valid-user : denied (no authenticated user yet) [Wed Jan 02 11:58:33.427566 2019] [authz_core:debug] [pid 2616:tid 896] mod_authz_core.c(817): [client 7.28.145.212:64085] AH01626: authorization result of : denied (no authenticated user yet) [Wed Jan 02 11:58:33.427566 2019] [authnz_ldap:debug] [pid 2616:tid 896] mod_authnz_ldap.c(522): [client 7.28.145.212:64085] AH01691: auth_ldap authenticate: using URL ldap://OmegaLDAP1.OMEGA.DCE-EIR.NET:XXX/OU=XX,OU=,DC=,DC=XXX.XX=NET?sAMAccountName?sub?(objectClass=user) Basic conf LDAPSharedCacheSize 50 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 CacheEnable disk DAV svn SVNParentPath d:/data/RepoDU SVNListParentPath on SVNAutoversioning On # Repository Display Name Also display this in IE's title bar SVNReposName "CBSA Subversion repository" # Authorization control policy AuthzSVNAccessFile "D:\apps\Subversion\Apache2\conf\svnaccessfile.conf" AuthzForceUsernameCase Lower # Authentication (WHO is allowed to access the repository) #Satisfy any AuthBasicProvider omega file AuthType Basic AuthName "Location apps" LDAPReferrals Off Require valid-user # What to display on the login dialog AuthName "Please enter your OMEGA username and password" # Make LDAP the authentication mechanism but offer file (non-ldap) as well AuthBasicProvider omega file # FILE if not in ldap use thi user\password file AuthUserFile "D:\apps\Subversion\Apache2\conf\svnuserfile.conf" #Example of typical authentication used [/] @dcadmins = rw * = rw [dcscripts:/] # dcadmins group has read/write access. All other users have read access only. @dcadmins = rw * = r Michael Cotrut Consultant, DevCentre Canada Border Services Agency Place Vanier, 333 North River road, 17th floor, Tower A, 17th Floor 17077 Ottawa, Ontario 343-291-6097 Office From: Mark Phippard [mailto:markp...@gmail.com] Sent: December 17, 2018 1:00 PM To: Cotrut, Michael Cc: users@subversion.apache.org Subject: Re: ra-serf missing from SVN Client for windows 1.11 On Mon, Dec 17, 2018 at 12:54 PM Cotrut, Michael mailto:michael.cot...@cbsa-asfc.gc.ca>> wrote: Hi, It looks like ra-serf is missing from svn 1.11 client for windows Svn –version svn, version 1.11.0 (r1845130) compiled Nov 1 2018, 12:47:00 on x86/x86_64-microsoft-windows10.0.17134 Copyright (C) 2018 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme For 1.10 svn --version svn, version 1.10.2 (r1835932) compiled Aug 30 2018, 11:56:10 on x86/x86_64-microsoft-windows10.0.17134 Copyright (C) 2018 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.9 (compiled with 1.3.9) - handles 'http' scheme - handles 'https' scheme The Subversion project does not provide binaries, so you should report this to whomever or wherever you obtained them. You are right that it looks like they were not built properly and/or did not include all of the libraries needed for http support. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Problems with using a symbolic link for .svn folder on TSVN
On Thu, Jan 10, 2019 at 10:48 AM Oscar Lee wrote: > The external drive is actually a company samba server that I connect over > VPN. As such, it's super slow to read and even worse to write (maxes at > 3MB/s). I don't care if the cleanup process or updating of the pristine > files is slow, but I can't run the game off such a slow hard drive. > In that case, my suggestion is to invest <$200 in a USB3 5TB external hard drive and work off of that. > *The answer to Life, The Universe and Everything is 42* > How many roads must one take? :-p
Re: Problems with using a symbolic link for .svn folder on TSVN
On Thu, Jan 10, 2019 at 7:39 AM wrote: > I cannot do a sparse checkout as I require every part of the information > to get the software running (a game) > At risk of saying the obvious, may I make a suggestion: Work on the (larger) external hard drive. In other words, have your entire working copy, .svn directory and all, on the external drive.
Re: Problems with using a symbolic link for .svn folder on TSVN
On 10.01.2019 13:40, minxing...@gmail.com wrote: > I see. Is it possible to change the implementation slightly as outlined by > Boost SVN? (https://svn.boost.org/trac10/ticket/6809). I believe this is the > same issue. It is the same issue and no it is not possible to change the implementation "slightly" because the integrity of the working copy relies on atomic renames. That is why Subversion doesn't use the system- (or user-) specific temporary directory (defined by %TMP% and %TEMP% on Windows) for such files but creates them in .svn/, to make it as likely as possible that they'll be on the same volume as the rest of the working copy. The only thing we could do would be to not create temporary files in .svn/ but in the same directory as the target file, but then we'd have problems with potential name collisions and with such temporary files cluttering the working copy tree after aborted operations. It's possible, but it's not a "slight" change like adding another flag to MoveFileEx. -- Brane > -Original Message- > From: Daniel Shahaf > Sent: Thursday, 10 January 2019 1:36 PM > To: Oscar Lee ; users@subversion.apache.org > Subject: Re: Problems with using a symbolic link for .svn folder on TSVN > > Oscar Lee wrote on Wed, 09 Jan 2019 19:10 +0100: >> My company uses TortoiseSVN internally to keep our files updated. The >> .svn folder for the project I have is massive (250GB) and as such I >> had to move it off to an external HDD. I created a symbolic link to >> the new location so that TortoiseSVN 'should' still continue to work. > How large are the working copy files not under the .svn/ directory? > > If they're substantially smaller than 250GB, you might be running into this: > https://subversion.apache.org/docs/release-notes/1.7#wc-pristines > >> I managed to run a clean-up, but when I tried to revert a file, it >> gave me an error 'Failed to run the WC DB work queue associated with >> (file)" and "Can't move (tmp file) to ... (original file): The system >> cannot move the file to a different disk drive". >> >> I found that this error is caused by Windows not letting a file be >> renamed while it is being moved ( >> https://docs.microsoft.com/en-us/previous-versions/ms837428(v=msdn.10)). >> Does anyone know a solution to this? >> Why is this an issue that only occurs with a symbolic link setup? > Subversion assumes that it is possible to atomically move a file from the > .svn directory to the working copy's checked out files. That would not > possible when the .svn directory is on a different drive / filesystem. >
RE: Problems with using a symbolic link for .svn folder on TSVN
I see. Is it possible to change the implementation slightly as outlined by Boost SVN? (https://svn.boost.org/trac10/ticket/6809). I believe this is the same issue. -Original Message- From: Daniel Shahaf Sent: Thursday, 10 January 2019 1:36 PM To: Oscar Lee ; users@subversion.apache.org Subject: Re: Problems with using a symbolic link for .svn folder on TSVN Oscar Lee wrote on Wed, 09 Jan 2019 19:10 +0100: > My company uses TortoiseSVN internally to keep our files updated. The > .svn folder for the project I have is massive (250GB) and as such I > had to move it off to an external HDD. I created a symbolic link to > the new location so that TortoiseSVN 'should' still continue to work. How large are the working copy files not under the .svn/ directory? If they're substantially smaller than 250GB, you might be running into this: https://subversion.apache.org/docs/release-notes/1.7#wc-pristines > I managed to run a clean-up, but when I tried to revert a file, it > gave me an error 'Failed to run the WC DB work queue associated with > (file)" and "Can't move (tmp file) to ... (original file): The system > cannot move the file to a different disk drive". > > I found that this error is caused by Windows not letting a file be > renamed while it is being moved ( > https://docs.microsoft.com/en-us/previous-versions/ms837428(v=msdn.10)). > Does anyone know a solution to this? > Why is this an issue that only occurs with a symbolic link setup? Subversion assumes that it is possible to atomically move a file from the .svn directory to the working copy's checked out files. That would not possible when the .svn directory is on a different drive / filesystem.
RE: Problems with using a symbolic link for .svn folder on TSVN
I cannot do a sparse checkout as I require every part of the information to get the software running (a game). From: Paul Hammant Sent: Thursday, 10 January 2019 1:36 PM To: Oscar Lee Cc: Subversion Subject: Re: Problems with using a symbolic link for .svn folder on TSVN Alternative solution: do a Sparse Checkout - excising things in that tree that you don't really need. Google's monorepo is north of 100TB of history with over nine million source files at HEAD revision. Individual Googler's day to day checkout tens of megabytes only: https://trunkbaseddevelopment.com/expanding-contracting-monorepos/ Though they made tooling for that expanding/contracting stuff, most normal companies could do the same to share within the team with a single bat/sh script for checkout. After that, 'svn up', 'svn commit' work as they always have. Indeed, if that bat file using the command line svn exe did it stuff, TortoiseSvn afte that will work as you expect for update/commit. The sym-link for something that Subversion needs to refer to a lot is a bad idea. - Paul
RE: Problems with using a symbolic link for .svn folder on TSVN
(Sorry forgot to reply all) Yes, it’s on my computer when I do a checkout if that’s what you mean. If I do a fresh checkout, the .svn is the same size (over 250GB). From: Paul Hammant Sent: Thursday, 10 January 2019 1:27 PM To: Oscar Lee Cc: Subversion Subject: Re: Problems with using a symbolic link for .svn folder on TSVN The .svn folder on the client side? If you do a fresh checkout, how big is it then?
Re: Problems with using a symbolic link for .svn folder on TSVN
On 09.01.2019 19:10, Oscar Lee wrote: > Hi, > > I was told to post my issue here from a TSVN dev. > > My company uses TortoiseSVN internally to keep our files updated. The .svn > folder for the project I have is massive (250GB) and as such I had to move > it off to an external HDD. I created a symbolic link to the new location so > that TortoiseSVN 'should' still continue to work. Well, it "should" not, see below. But if your .svn/ directory is much bigger than the rest of your working copy, then 'svn cleanup --vacuum-pristines' will probably reduce its size. In TSVN you'll have to select the checkbox "Vacuum pristine copies". > I managed to run a clean-up, but when I tried to revert a file, it gave me > an error 'Failed to run the WC DB work queue associated with (file)" and > "Can't move (tmp file) to ... (original file): The system cannot move the > file to a different disk drive". > > I found that this error is caused by Windows not letting a file be renamed > while it is being moved ( > https://docs.microsoft.com/en-us/previous-versions/ms837428(v=msdn.10)). > Does anyone know a solution to this? Why is this an issue that only occurs > with a symbolic link setup? This has nothing to do with symbolic links but with the fact that Subversion, during normal operations, has to atomically rename (and move) a file from somewhere in the .svn/ directory to its expected location in the working copy. Windows can't do that if the source and target of the rename are on different volumes, that's what the error message is telling you. The explanation your link points to is misleading, to put it mildly ... it's the move to a different volume that fails, not the renaming of the file. -- Brane
Re: Problems with using a symbolic link for .svn folder on TSVN
Alternative solution: do a Sparse Checkout - excising things in that tree that you don't really need. Google's monorepo is north of 100TB of history with over nine million source files at HEAD revision. Individual Googler's day to day checkout tens of megabytes only: https://trunkbaseddevelopment.com/expanding-contracting-monorepos/ Though they made tooling for that expanding/contracting stuff, most normal companies could do the same to share within the team with a single bat/sh script for checkout. After that, 'svn up', 'svn commit' work as they always have. Indeed, if that bat file using the command line svn exe did it stuff, TortoiseSvn afte that will work as you expect for update/commit. The sym-link for something that Subversion needs to refer to a lot is a bad idea. - Paul
Re: Problems with using a symbolic link for .svn folder on TSVN
Oscar Lee wrote on Wed, 09 Jan 2019 19:10 +0100: > My company uses TortoiseSVN internally to keep our files updated. The .svn > folder for the project I have is massive (250GB) and as such I had to move > it off to an external HDD. I created a symbolic link to the new location so > that TortoiseSVN 'should' still continue to work. How large are the working copy files not under the .svn/ directory? If they're substantially smaller than 250GB, you might be running into this: https://subversion.apache.org/docs/release-notes/1.7#wc-pristines > I managed to run a clean-up, but when I tried to revert a file, it gave me > an error 'Failed to run the WC DB work queue associated with (file)" and > "Can't move (tmp file) to ... (original file): The system cannot move the > file to a different disk drive". > > I found that this error is caused by Windows not letting a file be renamed > while it is being moved ( > https://docs.microsoft.com/en-us/previous-versions/ms837428(v=msdn.10)). > Does anyone know a solution to this? > Why is this an issue that only occurs with a symbolic link setup? Subversion assumes that it is possible to atomically move a file from the .svn directory to the working copy's checked out files. That would not possible when the .svn directory is on a different drive / filesystem.
Re: Problems with using a symbolic link for .svn folder on TSVN
The .svn folder on the client side? If you do a fresh checkout, how big is it then?
Problems with using a symbolic link for .svn folder on TSVN
Hi, I was told to post my issue here from a TSVN dev. My company uses TortoiseSVN internally to keep our files updated. The .svn folder for the project I have is massive (250GB) and as such I had to move it off to an external HDD. I created a symbolic link to the new location so that TortoiseSVN 'should' still continue to work. I managed to run a clean-up, but when I tried to revert a file, it gave me an error 'Failed to run the WC DB work queue associated with (file)" and "Can't move (tmp file) to ... (original file): The system cannot move the file to a different disk drive". I found that this error is caused by Windows not letting a file be renamed while it is being moved ( https://docs.microsoft.com/en-us/previous-versions/ms837428(v=msdn.10)). Does anyone know a solution to this? Why is this an issue that only occurs with a symbolic link setup? Regards, Oscar
