Re: GUI interface to Subversion via web browser?
On Wed, 22 May 2024 12:05:25 +0200, Bo Berglund wrote: >Subversion 1.14.0+ > $ svn --version > svn, version 1.13.0 (r1867053) > Oops! My Ubuntu 20.04 LTS has only svn 1.13.0 !! > >How can I fix that svn problem? > >$ apt policy svn >svn: > Installed: (none) > Candidate: (none) > >Seems like svn was *not* installed via apt at all... >I have used it on this machine for many years and it should not be at 1.13 >unless "something" updated it. > >$ which svn >/usr/bin/svn > >What/who put it there? >Apache? SORRY! I made an error here, I'm so used to typing binary's name svn that I forgot to use the true package name with apt: $ apt policy subversion subversion: Installed: 1.13.0-3ubuntu0.2 Candidate: 1.13.0-3ubuntu0.2 So it seems like subversion has been stuck at this revision on Ubuntu 20.04 LTS! If I test on another device running Ubuntu 22.04 LTS (this is a desktop system): $ apt policy subversion subversion: Installed: 1.14.1-3ubuntu0.22.04.1 Candidate: 1.14.1-3ubuntu0.22.04.1 Question: Is it possible to upgrade subversion from the apt installed version which is locked to the distribution level to a more recent version available on 22.04 or even 24.04? -- Bo Berglund Developer in Sweden
Re: GUI interface to Subversion via web browser?
On Wed, 22 May 2024 10:14:36 +0200, Daniel Sahlberg wrote: >> Many years ago (like 20+ years) when I worked at a company using CVS there >> was a >> web interface which had very useful functions in this regard. It was all >> running >> on Windows Server. >> >> It was named ViewCVS (Python based) and was accessed using a web browser >> towards >> the CVS server. > > >ViewCVS evolved to ViewVC > >https://viewvc.org > >A prominent user is the Apache Software Foundation, see > >http://svn.apache.org/viewvc > Thanks for that! I think I will test this first. I located its sources on GitHub!!! https://github.com/viewvc/viewvc/ Seems to be modified last on 2023-01-04 (rev 1.2.3) Latest release as of now: https://viewvc.org/downloads/viewvc-1.2.3.tar.gz or here https://github.com/viewvc/viewvc/releases/tag/1.2.3 So I will download it and see if I can get it running on my local svn server (Ubuntu) requirements seem to be: Python 3.6+ $ python3 --version Python 3.8.10 Subversion 1.14.0+ $ svn --version svn, version 1.13.0 (r1867053) Oops! My Ubuntu 20.04 LTS has only svn 1.13.0 !! How can I fix that svn problem? $ apt policy svn svn: Installed: (none) Candidate: (none) Seems like svn was *not* installed via apt at all... I have used it on this machine for many years and it should not be at 1.13 unless "something" updated it. $ which svn /usr/bin/svn What/who put it there? Apache? -- Bo Berglund Developer in Sweden
GUI interface to Subversion via web browser?
... I hope this is not totally OT ... I am running an SVN server on an Ubuntu 20.04 LTS system and I have the Apache connection so I can access it via its web interface. This works but is *very limited* in functionality, so I am looking for some kind of GUI interface that can be added to my Ubuntu SVN installation and gives me functionality to view file revisions, logs etc and also diff revisions using the web view. Many years ago (like 20+ years) when I worked at a company using CVS there was a web interface which had very useful functions in this regard. It was all running on Windows Server. It was named ViewCVS (Python based) and was accessed using a web browser towards the CVS server. I have tried to search for something similar for SVN and found WebSVN on Github: https://github.com/websvnphp/websvn and: https://websvnphp.github.io/ However, I have yet to find any examples on how its displays look or work and it also seems to be a rather old project... I have also recently used VisualSVN, which has some improvements over Apache Subversion but it is a Windows only system AFAICT and I do not like to use that platform... And it is not being updated with the operating system so it gets older over time. So is there something available apart from WebSVN and are there some howto sites showing actual screenshots from its use? -- Bo Berglund Developer in Sweden
Re: Subversion 1.14.2 on Linux how to enable plaintext password store?
On Fri, 01 Dec 2023 11:21:32 +0100, Bo Berglund wrote: >OK, I will have to test it again. > >But I have so many RPi units and some have this problem whereas others don't so >I have to somehow figure out how to test it on all to look for commonality/diff >between those that pop the GUI dialog and those that don't. > >On one where the svn commands work without popping up anything I have this: > >Inside ~/.subversion/auth are these dir/files: > >svn.simple/03994a04eb338a432667e51f0e0720bf >svn.ssl.server/52e60f46d8c02303aea5256b18eb7aac > >The other dirs are empty. >So maybe these two together is the store for text based access logins? UPDATE: --- Now I have tried to check out a package from our SVN server into a freshly built Raspberry Pi4B running 32 bit PiOS (bookworm). Before I did this I had compared the config between an older installation using a several years old operating system and this new one and I saw that the old had this setting enabled: [auth] password-stores = gnome-keyring So I added this to the svn installation config on the new RPi4B Then on the SSH login I tried to check out the package I wanted and this happened: It asked for the password for "bosse" But I had not told it what user to use on svn so it seems like it forces one to use the local system username rather than the subversion server username! In this case they happened to be the same since the new RPi systems no longer uses pi as the user but some username configured on installing the operating system. But after I typed in my password it just hung as before... So then I opened a VNC session to the GUI and sure enough there was a dialog box popped up on that window!!! Here it asked me the following: --- Choose password for new keyring An application wants to create a new keyring called "Default". Choose the password you want to usefor it. Password: * Confirm: * [Cancel] [Continue] --- So I entered the password twice and hit Continue. Now in the SSH window the checkout proceeded as it should have in the first place... Finally: After this was done I now created a new SSH session and inside that I went to a different target directory and issued the same svn command for a checkout and this time I was not asked for a password and the GUI screen did not pop up a dialog. So it seems like svn can be used on the command line provided one first does this: - Install subversion via apt - Run a bare svn command to create ~/.subversion/config - Edit the config file and enable this: [auth] password-stores = gnome-keyring - Go somewhere like ~/projects - Issue a svn co command for a package on the server - Enter the requested password - Access the GUI screen where the dialog shown above is now displayed - Enter the requested password twice Now the svn checkout proceeds and apparently any following checkout will not trigger the GUI dialog. But I have not tested a svn ci command yet Or another package of our svn server.. -- Bo Berglund Developer in Sweden
Re: Subversion 1.14.2 on Linux how to enable plaintext password store?
On Fri, 1 Dec 2023 09:25:55 +0100, Daniel Sahlberg wrote: >Den fre 1 dec. 2023 kl 08:35 skrev Bo Berglund : > >> As it has been for some time now when I enter a command window svn command >> that >> requires authentication it pops up a dialog on the GUI window which is >> invisible >> to me at that point. >> It took a while before I understood what was going on, at first I thought >> svn >> had crashed or similar. It just hung there on the command window. :( >> > >What does echo $DISPLAY return? I think it is awfully strange that an SSH >session on the PiOS would start a graphical program, but if DISPLAY is set, >maybe you can unset it and at least the GUI part would be solved? echo $DISPLAY returns nothing at all > >> So on this new system I want to avoid this from happening and was >> encouraged by >> the output shown when I checked the svn version. >> >> I have no idea if any of the allowed stores mentioned (gnome-keyring, >> kwallet, >> gpg-agent) will work inside an SSH command line section... >> > >I don't think any of those stores works on the command line. No idea what >Subversion will do but I assume it will fall back to inputting the password >on the command line. OK, I will have to test it again. But I have so many RPi units and some have this problem whereas others don't so I have to somehow figure out how to test it on all to look for commonality/diff between those that pop the GUI dialog and those that don't. On one where the svn commands work without popping up anything I have this: Inside ~/.subversion/auth are these dir/files: svn.simple/03994a04eb338a432667e51f0e0720bf svn.ssl.server/52e60f46d8c02303aea5256b18eb7aac The other dirs are empty. And the svn.simple/03994a04eb338a432667e51f0e0720bf file contains a reference to gnome-keyring, could that be a non-GUI way of saving the login on a command line operation? Here it is: cat auth/svn.simple/03994a04eb338a432667e51f0e0720bf K 8 passtype V 13 gnome-keyring K 15 svn:realmstring V 45 <https://svnserverpc:443> VisualSVN Server K 8 username V 5 bosse END The auth/svn.ssl.server/52e60f46d8c02303aea5256b18eb7aac file contains a block of data looking like a cert of some kind (encrypted password maybe). It also references the server connection, but not the username. So maybe these two together is the store for text based access logins? -- Bo Berglund Developer in Sweden
Re: Subversion 1.14.2 on Linux how to enable plaintext password store?
On Fri, 1 Dec 2023 00:55:30 -0500, Nathan Hartman wrote: >On Thu, Nov 30, 2023 at 6:43?PM Bo Berglund wrote: >> >> When I installed subversion on a Raspberry Pi4B and checked the installed >> version afterwards it printed this: >> >> $ svn --version >> svn, version 1.14.2 (r1899510) >>compiled Nov 12 2022, 20:30:30 on arm-unknown-linux-gnueabihf >> >> Copyright (C) 2022 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/ >> >> < cut > >> >> The following authentication credential caches are available: >> >> * Plaintext cache in /home/bosse/.subversion >> * Gnome Keyring >> * GPG-Agent >> * KWallet (KDE) >> >> I have had a lot of problems with password caching for a number of years >> since I >> am working on these devices mainly on the command line via ssh and when I >> issue >> a svn command against a server on our LAN what happens is that svn pops up a >> password entry dialog on the (invisible) **GUI screen**! >> And the operation started on the command line fails... >> >> It was not always so but some svn update changed the way svn operates >> >> Now I see the banner above where it looks like it is again available: >> >> * Plaintext cache in /home/bosse/.subversion >> >> The problem is that in the config file there is no example of the syntax for >> enabling this >> >> So my question here is: >> How do I enable the plaintext cache in svn client version 1.14.2 on a >> Raspberry >> Pi4B running Pi-OS? >> >> >> -- >> Bo Berglund >> Developer in Sweden > > >In the user's home directory, there should be a subdirectory called >.subversion which contains a file called config. In that file, there >is a section called [auth] which contains a setting called >"password-stores". It might be commented, or it might say something >like "password-stores = gpg-agent,gnome-keyring,kwallet". This setting >determines the order in which the different password stores >(credential caches) are used. You could set this to "password-stores = >plaintext". Make sure you don't have "store-passwords = no" or >"store-plaintext-passwords = no". I think this will solve the issue -- >though note that if the password has not been saved to the plaintext >cache yet, the SVN client should prompt for it once, and then prompt >whether you accept the risk to save it in the plaintext cache. This >should take place on the command line, so I think you won't have the >issue with the inaccessible GUI dialog box on the remote machine. Once >saved, it shouldn't prompt for it anymore. > >Note: In addition to the user's ~/.subversion/config file I mentioned >above, there is also a systemwide /etc/subversion/config. If changes >in the user-level file don't appear to work, check the systemwide one >as well. > >Hope this helps, >Nathan This is the auth content of the user's config file (which is what I referred to in my post): ### Section for authentication and authorization customizations. [auth] ### Set password stores used by Subversion. They should be ### delimited by spaces or commas. The order of values determines ### the order in which password stores are used. ### Valid password stores: ### gnome-keyring(Unix-like systems) ### kwallet (Unix-like systems) ### gpg-agent(Unix-like systems) ### keychain (Mac OS X) ### windows-cryptoapi(Windows) # password-stores = gpg-agent,gnome-keyring,kwallet ### To disable all password stores, use an empty list: # password-stores = ### ... info stuff about Kwallet,PID, ssl ... ### The rest of the [auth] section in this file has been deprecated. ### Both 'store-passwords' and 'store-auth-creds' can now be ### specified in the 'servers' file in your config directory ### and are documented there. Anything specified in this section ### is overridden by settings specified in the 'servers' file. # store-passwords = no # store-auth-creds = no So this is what I meant by missing plaintext... And the system wide /etc/subversion/config is exactly the same as the user's config file, diff returns nothing. So the question remains if adding a setting like this will work: password-stores =plaintext given the text in the config file... I have also looked in the servers file and am none the wiser... What I really want is NOT to have my svn password stored in *unencrypted plaintext*, just that it is stored on disk in a way that can be used by subversion on the next connec
Subversion 1.14.2 on Linux how to enable plaintext password store?
When I installed subversion on a Raspberry Pi4B and checked the installed version afterwards it printed this: $ svn --version svn, version 1.14.2 (r1899510) compiled Nov 12 2022, 20:30:30 on arm-unknown-linux-gnueabihf Copyright (C) 2022 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/ < cut > The following authentication credential caches are available: * Plaintext cache in /home/bosse/.subversion * Gnome Keyring * GPG-Agent * KWallet (KDE) I have had a lot of problems with password caching for a number of years since I am working on these devices mainly on the command line via ssh and when I issue a svn command against a server on our LAN what happens is that svn pops up a password entry dialog on the (invisible) **GUI screen**! And the operation started on the command line fails... It was not always so but some svn update changed the way svn operates Now I see the banner above where it looks like it is again available: * Plaintext cache in /home/bosse/.subversion The problem is that in the config file there is no example of the syntax for enabling this So my question here is: How do I enable the plaintext cache in svn client version 1.14.2 on a Raspberry Pi4B running Pi-OS? -- Bo Berglund Developer in Sweden
Re: Command to list all revisions (with date?) when a particular was modified?
On Tue, 7 Nov 2023 19:34:34 +0100, Daniel Sahlberg wrote: > >svn blame accepts an -r N:M so if you know the revisions that occurred in >the time period of interest (maybe also works with the date range arguments >already suggested by Nathan) you should be able to limit the revision >numbers. Didn't try that... >But since you use TortoiseSVN I might suggest that you look at Tortoises >graphical Blame. It looks much like the command line client in that you get >the revision number each line was changed but you can right click a >revision number and blame previous revision which will give the previous >time that line was changed. I find this helps a lot to figure out past >refactorings. > Well I have actually been using the command line for this "research" and with log I could list all 106 checkins to the file over the years. But I failed to find the place where the code I am looking for was checked in, instead I discovered an old working copy (from CVS) on my disk where the file I was looking at actually *had* the changes I was trying to find... But looking in SVN both sides of the timestamp of the file failed to get any commit with the changed code. So the conclusion is that that particular code section which should have fixed the bug back in 2015 was actually not checked in to CVS and hence did not reach SVN a couple of years later. So the binary in that working copy worked as it should whereas all following compiles (that were part of the transfer to Delphi XE5 vis SVN) did not since they were based on fresh checkouts Looks like an oversight at the time... -- Bo Berglund Developer in Sweden
Re: Command to list all revisions (with date?) when a particular was modified?
On Mon, 6 Nov 2023 15:39:40 -0500, Nathan Hartman wrote: >Hope this helps, >Nathan Yes, thank you! -- Bo Berglund Developer in Sweden
Re: Command to list all revisions (with date?) when a particular was modified?
On Mon, 06 Nov 2023 11:53:30 -0800, Kenneth Porter wrote: >--On Monday, November 06, 2023 7:32 PM +0100 Bo Berglund > wrote: > >> I am hunting for when a particular change was made in a file under version >> control. It happened years ago. > >svn blame path > path.blame > >That gives you the file annotated with each line showing which revision it >last changed on. > Thanks, but: I tried blame: svn blame https://svnserver/svn/pc/AgiSSAdmin/trunk/Source/class_SuperSting.pas > blame.txt It produced a text file containing the content of the source file as it looks today with each line annotated when that line was committed the *last* time. But that is not what I want, instead I want to know *all* revisions in which the file was modified so I can look at these revisions and see what changed between them concerning the function I want to inspect. If I could get the rev numbers at the beginning of each result line in numerical order and nothing else I would be done with the list. with this command: svn log -q https://svnserver/svn/pc/AgiSSAdmin/trunk/Source/class_SuperSting.pas > log.txt I got a file containing a reverse ordered list of revisions looking like this: r200 | bosse | 2001-06-24 17:29:47 +0200 (Sun, 24 Jun 2001) r197 | bosse | 2001-06-23 12:12:37 +0200 (Sat, 23 Jun 2001) with 106 revisions present. So log is the better solution. Now I need to figure out how to best attack this analysis with so many commits... -- Bo Berglund Developer in Sweden
Command to list all revisions (with date?) when a particular was modified?
I am hunting for when a particular change was made in a file under version control. It happened years ago. The versioning system was migrated from CVSNT to Subversion back in 2017 and the old CVS repository was imported into SVN with all branches and tags etc available. The change I am looking for should have happened back in 2004 when the property behind what I am hunting for was changed but I cannot find any message about this in my archives... So now I am looking for *when* a particular section of a source file was changed so I would like to list all revisions when this file had a commit to it at all. Then I will extract the revisions in a binary fashion to find when exactly the change that should have been done in 2004 was actually done. Can this be done somehow using the command line interface to svn? If so what would be the correct command to issue? I need to get a list of the revisions where the file was changed. I tried reading the redbean documentation on line but I am not sure I understand the way the export works for different revisions of the same file. The way I understand svn the revision when you export/checkout a file at a specific rev number is the file as it existed at the time that revision was committed. So even if the file did not change during that revision there will be an exported file if I use the -r argument, right? So I need to start by some command to give me the revision numbers when the specific file *actually changed*. So I can focus on the commits when this file changed instead of getting lots of the same file because the revisions were done because something else changed.. Can that be done? -- Bo Berglund Developer in Sweden
Re: Subversion actively refused connection
On Thu, 26 Oct 2023 12:51:31 -0500, David Gerler wrote: >Good Afternoon, >I had to change the subnet for our subversion server from 192.168.2.0/24 >to 192.168.3.0/24. Now when we try to connect to the subversion server with >TortoiseSVN it actively refuses connection. This message in windows is really misleading! It has been there for ages and at the start when I saw it the first time many years ago I thought like a human that the other end had ACTIVELY analyzed the situation and decided to refuse... Not so! This error in Windows pops up when you try to connect to somewhere where there is no response, nothing else! So the target app is not running or you have a firewall that does not allow connections or the address you use is wrong etc. Normally it has NOTHING to do with the target application refusing something after analyzing the incoming call as one would think by the message words It simply could not be reached. -- Bo Berglund Developer in Sweden
How to check if a file is *really* modified against the repository?
I have some files in my Windows PC that are under subversion versioning. One exe file has been committed and not recompiled or anything, yet TortoiseSvn marks it as modified... Is there a way with svn to check files against the repository so that a difference may be displayed or else just flagged? I think that something like Windows marking the file as used may have affected it because I have not recompiled it... -- Bo Berglund Developer in Sweden
Re: passwd file stores plain text passwords - how to protect it
On Tue, 22 Aug 2023 17:38:12 +0200, Bo Berglund wrote: >On Tue, 22 Aug 2023 13:14:25 +0200, Daniel Sahlberg > wrote: > >>Please note that for Subversion 1.12 until 1.14 the default was to disable >>the plaintext password cache. In Subversion 1.15 the plaintext password >>cache will again be enabled by default. > >I am using svn a lot on raspberry pi devices and I have now checked the current >version on one of them: > >$ svn --version >svn, version 1.14.1 (r1886195) > compiled Apr 5 2022, 23:23:59 on arm-unknown-linux-gnueabihf > >So in order to get back the file cache again I need a version update, right? > >Does anyone know when Debian will move ahead to 1.15? >PiOS is based on Debian, so I guess it will be guided by that... > >Or is it possible to force a version update via apt? Forgot to say that PiOS ia version bullseye at the moment... -- Bo Berglund Developer in Sweden
Re: passwd file stores plain text passwords - how to protect it
On Tue, 22 Aug 2023 13:14:25 +0200, Daniel Sahlberg wrote: >Please note that for Subversion 1.12 until 1.14 the default was to disable >the plaintext password cache. In Subversion 1.15 the plaintext password >cache will again be enabled by default. I am using svn a lot on raspberry pi devices and I have now checked the current version on one of them: $ svn --version svn, version 1.14.1 (r1886195) compiled Apr 5 2022, 23:23:59 on arm-unknown-linux-gnueabihf So in order to get back the file cache again I need a version update, right? Does anyone know when Debian will move ahead to 1.15? PiOS is based on Debian, so I guess it will be guided by that... Or is it possible to force a version update via apt? -- Bo Berglund Developer in Sweden
Re: How to move the svn server data to new partition?
On Tue, 9 May 2023 07:36:12 -0400, "Bo Berglund" wrote: >I am running a backup subversion server on an Ubuntu 20.04.6 LTS SERVER. >The subversion version is: 1.13.0 (r1867053) > >The subversion data are located in /var/lib/svn and it has caused the root >file system to be all used up such that much don't work anymore like apt... > >The root partition is 30 GB and the svn data is about 18 GB of that > >$ du -c -h -s /var/lib/svn/ >18G /var/lib/svn/ >18G total > >I need to fix this urgently and therefore I want to know how to go about it. > >Currently there is a spare partition on the disk which is currently mounted in >the /home tree: >$ df -h >... >/dev/nvme0n1p7 79G 56M 75G 1% /home/bosse/data >... > >In /etc/fstab it is mounted like this: > >#So far unused data partition on main drive (will not be visible across NFS >share...): >UUID=fb4a08b7-378e-42eb-9b7a-2c7b4f85cd06 /home/bosse/data ext4 nodev,nosuid >0 2 > > >Can I use this data drive by this sequence of commands: >1) Stop the subversion service (how?) > >2) Move /var/lib/svn to the root of the so far unused data drive > sudo mv /var/lib/svn /home/bosse/data > thus freeing up the 18GB of data used by svn > >3) Edit the /etc/fstab entry such that it will mount the copied dir into >/var/lib as svn > > UUID=fb4a08b7-378e-42eb-9b7a-2c7b4f85cd06 /var/lib/svn ext4 nodev,nosuid 0 > 2 > (Do I need to create the /var/lib/svn dir manually or will the mount make > it work?) > >4) Restart the subversion service > I fixed it by using the steps above: 1) sudo systemctl stop apache2 2) sudo mv /var/lib/svn/* /home/user/data 3) Fstab: UUID=fb4a08b7-378e-42eb-9b7a-2c7b4f85cd06 /var/lib/svn ext4 nodev,nosuid 0 2 4) sudo systemctl start apache2 Now the svn dir and below are on the other partition and the system behaves normally with an 18GB margin for / being full. -- Bo Berglund Developer in Sweden
How to move the svn server data to new partition?
I am running a backup subversion server on an Ubuntu 20.04.6 LTS SERVER. The subversion version is: 1.13.0 (r1867053) The subversion data are located in /var/lib/svn and it has caused the root file system to be all used up such that much don't work anymore like apt... The root partition is 30 GB and the svn data is about 18 GB of that… $ du -c -h -s /var/lib/svn/ 18G /var/lib/svn/ 18G total I need to fix this urgently and therefore I want to know how to go about it. Currently there is a spare partition on the disk which is currently mounted in the /home tree: $ df -h ... /dev/nvme0n1p7 79G 56M 75G 1% /home/bosse/data ... In /etc/fstab it is mounted like this: #So far unused data partition on main drive (will not be visible across NFS share...): UUID=fb4a08b7-378e-42eb-9b7a-2c7b4f85cd06 /home/bosse/data ext4 nodev,nosuid 0 2 Can I use this data drive by this sequence of commands: 1) Stop the subversion service (how?) 2) Move /var/lib/svn to the root of the so far unused data drive sudo mv /var/lib/svn /home/bosse/data thus freeing up the 18GB of data used by svn 3) Edit the /etc/fstab entry such that it will mount the copied dir into /var/lib as svn UUID=fb4a08b7-378e-42eb-9b7a-2c7b4f85cd06 /var/lib/svn ext4 nodev,nosuid 0 2 (Do I need to create the /var/lib/svn dir manually or will the mount make it work?) 4) Restart the subversion service Will this be transparent to subversion (i.e. it will not notice) or do I have to do some extra configurations? I am a bit confused about what happens for certain commands, like the mv above. Will it create a svn dir on the target or will it just fill the target with the data? Grateful for any help! (I tried to post a question about this via Gmane but it seems not to reach the list so I post directly now.) -- Bo Berglund Developer in Sweden
Svn server uses up all disk, how to fix?
I have an svn server running as a backup system on an Ubuntu 20.04.6 LTS SERVER. $ svn --version svn, version 1.13.0 (r1867053) compiled May 12 2022, 20:47:08 on x86_64-pc-linux-gnu Today after returning from a 2-week trip I discovered that the Ubuntu server had run out of disk space on / and could not create files of various kinds... After I investigated the situation it turns out that /var/lib/svn/pc/db/txn-protorevs alone uses up 11.9 GB! I don't know if the system was close to full when I went on the trip but it is now... But the latest commits to the /var/lib/svn/pc.. was about a month ago so I cannot understand what has happened. So on this system svn is installed with its data in the default location /var/lib/svn/... What can I do now to make it operational again? Can I move the data to a different disk partition or something like that? But how would that work concerning the svn operations? The drive situation is like this: $ df -h Filesystem Size Used Avail Use% Mounted on udev 6.8G 0 6.8G 0% /dev tmpfs1.4G 3.6M 1.4G 1% /run /dev/nvme0n1p630G 28G 0 100% / < FULL!! tmpfs6.9G 0 6.9G 0% /dev/shm tmpfs5.0M 0 5.0M 0% /run/lock tmpfs6.9G 0 6.9G 0% /sys/fs/cgroup /dev/nvme0n1p8 259G 216G 31G 88% /home /dev/loop1 117M 117M 0 100% /snap/core/14784 /dev/nvme0n1p1 256M 34M 223M 14% /boot/efi /dev/nvme0n1p779G 56M 75G 1% /home/bosse/www/MSNBC/data /dev/loop3 117M 117M 0 100% /snap/core/14946 /dev/loop492M 92M 0 100% /snap/lxd/24061 /dev/loop564M 64M 0 100% /snap/core20/1852 /dev/loop692M 92M 0 100% /snap/lxd/23991 /dev/loop0 9.7M 9.7M 0 100% /snap/canonical-livepatch/202 /dev/loop7 9.7M 9.7M 0 100% /snap/canonical-livepatch/209 /dev/loop864M 64M 0 100% /snap/core20/1879 tmpfs1.4G 0 1.4G 0% /run/user/1000 And using the ncdu utitility: --- /var/lib/svn /.. 13.2 GiB [##] /pc 1.9 GiB [# ] /marketing 686.9 MiB [ ] /eng 402.6 MiB [ ] /pcb 342.2 MiB [ ] /cmp 335.2 MiB [ ] /appdev 258.2 MiB [ ] /web 238.3 MiB [ ] /hw 236.7 MiB [ ] /bosse 170.5 MiB [ ] /ei 84.3 MiB [ ] /newprod 300.0 KiB [ ] /private --- /var/lib/svn/pc -- /.. 13.2 GiB [##] /db 40.0 KiB [ ] /hooks 20.0 KiB [ ] /conf 12.0 KiB [ ] /locks 4.0 KiB [ ] README.txt 4.0 KiB [ ] format Any ideas & suggestions welcome -- Bo Berglund Developer in Sweden
Re: Need Support for Error || serialized hash missing terminator
On Fri, 17 Mar 2023 10:06:18 +, "Kumar, Pradeep (Baker Hughes Contractor) via users" wrote: >HI Support Team, > >Can someone please respond on this and help us on the below issue. > >Regards, >Pradeep Kumar. > You will not get any help until you post a question in a readable way! No unreadable screenshots for example... And this is NOT a "Support Team"! It is a user-to-user help mail list. -- Bo Berglund Developer in Sweden
Re: Need Support for Error || serialized hash missing terminator
On Thu, 16 Mar 2023 11:55:46 +, "Pallapati, Raja (Baker Hughes Contractor) via users" wrote: >Hi Team, This is not a support forum but a user peer-to-peer mail list! > >While doing a check-out in the SVN subversion working copy we are receiving >"serialized hash missing terminator" error, and unable to update the content. >This is delaying our work. > >Kindly support on this to resolve the issue as early as possible. >Thanks & Regards, >Raja Pallapati I suggest (if you really need some peer help) to NOT paste in unreadable screenshots in your post! Instead copy the real text and paste it into your message! And keep the message formatted as plaintext rather than HTML or the like... More likely to get useful responses that way... -- Bo Berglund Developer in Sweden
Re: Problem using svnsync on one of 10 repositories
On Sat, 11 Feb 2023 18:56:34 +0100, Bo Berglund wrote: >Thanks Pavel! >I just want to check so that I get it right: > >1. Modify the command to use --steal-lock like this in the script (all on one >line): >E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize >--steal-lock >--sync-username syncuser https://backupservername/svn/pcb >https://agiengineering/svn/pcb > > >2. Should I do this *once* on the command line to remove the lock or should I >change the daily script to always use this? >Note that the remote backup SVN server is never used for anything else, noone >checks in or out anything from it... >It is only a backup safeguard off-site. > Follow-up: 1) I did a manual run with the command including --steal-lock and it showed there was a stale lock that it could take over and perform the update. So this seems to be the way to do it. 2) I have now added this into the scheduled task script on the server which will run about 12 hours from now, hopefully there will not be any problems then. I made a dummy change and committed it. So tomorrow morning I will see if the backup is synced to reflect this. -- Bo Berglund Developer in Sweden
Re: Problem using svnsync on one of 10 repositories
On Sat, 11 Feb 2023 19:50:41 +0400, "Pavel Lyalyakin via users" wrote: >> E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize >> --sync-username syncuser https://backupservername/svn/pcb >> https://agiengineering/svn/pcb >> Failed to get lock on destination repos, currently held by >> 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' >> .. 8 repeats of the same . >> Failed to get lock on destination repos, currently held by >> 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' >> svnsync: E22: Couldn't get lock on destination repos after 10 attempts >> >> >> Notice: All other repos sync as intended. Only pcb acts up. >> >> What can I do to remedy this? > >You can try running `svnsync` with the `--steal-lock` option: >https://www.visualsvn.com/support/svnbook/ref/svnsync/#svn.ref.svnsync.sw.steal_lock > >> It seems to have stopped working about 3 weeks ago for this single >> repository. >> >> Note that the backup server, which is an Ubuntu 20.04.5 LTS Server box on >> another location, is connected using the Internet when doing the backups. >> This Ubuntu server has been rebooted a few times since the last working >> backup >> was synced. >> >> What can cause a failure to obtain a lock on that remote server for this >> specific repo? > >There is already a lock in the repository. Perhaps the Ubuntu server >was rebooted in the middle of the sync operation, so the lock wasn't >released then. There is a note about svnsync locks in SVNBook: >https://www.visualsvn.com/support/svnbook/reposadmin/maint/#Content_Content_Content_ctl12 >(see "svnsync Bookkeeping"). Thanks Pavel! I just want to check so that I get it right: 1. Modify the command to use --steal-lock like this in the script (all on one line): E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize --steal-lock --sync-username syncuser https://backupservername/svn/pcb https://agiengineering/svn/pcb 2. Should I do this *once* on the command line to remove the lock or should I change the daily script to always use this? Note that the remote backup SVN server is never used for anything else, noone checks in or out anything from it... It is only a backup safeguard off-site. -- Bo Berglund Developer in Sweden
Problem using svnsync on one of 10 repositories
I have a backup system set up for our VisualSVN server running on Windows Server 2016. It consists of a batch file scheduled to run nightly on the SVN server. The batch uses a series of commands, one for each of the backed up repositories and has been in place from 2018. Now when checking the state of the backup I have found that one single repository is not up to date on the backup server, so I accesssed the Windows server to see what was going on. Turns out that when I run the backup command manually on the server for this repository I get the following output: E:\>"C:\Program Files\VisualSVN Server\bin\svnsync.exe" synchronize --sync-username syncuser https://backupservername/svn/pcb https://agiengineering/svn/pcb Failed to get lock on destination repos, currently held by 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' .. 8 repeats of the same . Failed to get lock on destination repos, currently held by 'AGIENGINEERING:2e8676b6-0783-584c-8276-757df1507352' svnsync: E22: Couldn't get lock on destination repos after 10 attempts Notice: All other repos sync as intended. Only pcb acts up. What can I do to remedy this? It seems to have stopped working about 3 weeks ago for this single repository. Note that the backup server, which is an Ubuntu 20.04.5 LTS Server box on another location, is connected using the Internet when doing the backups. This Ubuntu server has been rebooted a few times since the last working backup was synced. What can cause a failure to obtain a lock on that remote server for this specific repo? It is only used as a backup for the main SVN server. The main Windows server is running svn version 1.9.7 (r1800392) and the Linux backup server is running svn version 1.13.0 (r1867053) Is therte some log on the backup server I can access to see what if anything is happening there? -- Bo Berglund Developer in Sweden
Re: Is it possible to export multiple files in one command?
On Sat, 21 Jan 2023 06:14:06 -0500 (EST), "Jon Daley via users" wrote: >I don't believe it is possible - you can export a file or a whole >directory. > >You could export the tree with one command and then move/cherry pick the >files you want afterwards. > Not really useful since the files needed for the setup are only a few (less than 5) out of several hundred in the full source tree... So I will keep the separate exports for the individual files instead. -- Bo Berglund Developer in Sweden
Is it possible to export multiple files in one command?
I have a script, which is used in our installer creation process and it works as follows (on Windows): - Create a new target directory - Run svn commands to get the needed files into that dir - Run svn command to download the installer engine binary into its own dir - Run svn command to download the installer script itself - Start the installer engine with the script as argument This produces a new installation file in the installers directory. The svn command I am using is svn export since I don't want to create a versioned container and I also want to collect files from various different locations including documentation which will be part of the installer. What I would like to know is if there is an svn export command switch of some kind that can be used to export a set of files in one go if they reside in the same subversion directory? Right now I am repeating the following typical sequence, where the svn commands have to be run *inside* the target directory (variable SVNREPO has been set to the repository URL earlier): if EXIST Manager rmdir /s /q Manager mkdir Manager cd Manager svn export %SVNREPO%/Manager.exe .\ if errorlevel 1 goto error svn export %SVNREPO%/ssleay32.dll .\ if errorlevel 1 goto error svn export %SVNREPO%/libeay32.dll .\ if errorlevel 1 goto error svn export %SVNREPO%/doc/Manager_instructions.pdf .\ So to get these 4 files I have to issue 4 different svn commands... And I have had to create the target dir and move into it before doing this because otherwise the command instead of creating a subdir to stuff the file into exports the source file into a file named as the directory it is supposed to go into... Example: svn --force export %SVNREPO%/ssleay32.dll TargetDir This creates a *file* TargetDir with the content of ssleay32.dll instead of ssleay32.dll inside of TargetDir I would like to use a single svn command per source dir and get all the needed files from there at the same time according to a supplied list. Is this possible at all? -- Bo Berglund Developer in Sweden
Re: How to configure minidlna so it is visible on two networks?
On Thu, 26 May 2022 19:01:23 +0200, Daniel Sahlberg wrote: >Are you sure you posted on the correct mailing list? > >Kind regards >Daniel Sorry, I posted on the list that was open in my newsreader assuming it was the ubuntu-user's list. Please disregard! -- Bo Berglund Developer in Sweden
How to configure minidlna so it is visible on two networks?
I have two LAN sections (home and remote) joined together using OpenVPN on the remote router to a dedicated OpenVPN server on my home LAN. They run on addresses 192.168.119.x and 192.168.117.x respectively. The router on the home LAN is set up to route calls to 192.168.117.x via the OpenVPN server, so both LAN sections are effectively connected. I can connect to all devices from all devices. I also have an Ubuntu 20.04.4 server on the home LAN, which is running minidlna to act as a DLNA server for a video library on that server. When I use devices like a smart-TV or Windows computers on tyhe home LAN they see the shared video library. But not so for devices on the remote LAN... Is there some configuration either on the minidlna config or elsewhere that could be made in order to let the remote LAN devices "see" the minidlna server? They are as you see on separate subnets, which are joined together via the VPN tunnel. -- Bo Berglund Developer in Sweden
Re: Moving the entire SVN instance to a newer Windows server
On Mon, 23 May 2022 11:03:32 +, "Morin, Michael" wrote: >>On Mon, May 23, 2022 at 6:16 AM Morin, Michael >>wrote: >>> >>> In my case, I have no choice in the matter of what server and OS to move >>> to. We dont use VisualSVN. >>>We just use Tortoise with Subversion. When we last >did a migration from one >>>Windows server to another, >>>it was a tedious process of contacting the users of the repository, asking >>>them if the repo should be >>>migrated or archived, setting a date for the migration, telling the users to >>>make any outstanding commits, >>>locking down the repository, migrating the >repository, informing users of >>>the new URL of the repository, >>>and asking the users to confirm their ability to access the repo and >>>verifying everything >works as expected. >>>This was done for each repository. This process took us about 4 ½ months. >>>Id like to avoid taking that >>>long this time around. >> >>*Ouch*. Been there, done that. I'm assuming that each repo is, indeed, an >>entirely distinct Subversion >>repo rather than all being distributed under one >master repo? That makes >>migration much, much safer. >> >Yes, each repository is a distinct Subversion repository. We have about 300 >Subversion users located in >different departments and 171 repositories. > Just to clarify for my understanding: Are you saying that the users are accessing the repositories via file sharing in Windows using Tortoise-Svn? I.e. do they point the client (Tortoise-SVN) to a drive letter location where they operate on the repository? In that case you do not even have a *server* running so migrating the *server* is a non-issue. And the whole setup is pretty vulnerable to rogue users with write permissions on the repository side... PS: Please do not top-post, it makes it so much harder to follow the discussion. DS -- Bo Berglund Developer in Sweden
Re: Moving the entire SVN instance to a newer Windows server
On Sun, 22 May 2022 08:40:55 -0400, Nico Kadel-Garcia wrote: >On Sun, May 22, 2022 at 4:24 AM Andreas Stieger wrote: >> >> Hi, >> >> On 5/18/22 16:54, Mark Phippard wrote: >> > If you can use the same DNS hostname for the new server there will be >> > no impact on your clients >> >> >> Except for possibly a change server-side certificate which may have >> changed (and not properly verified before). Can be addressed with >> testing, and it helps to use a service name instead of a host name. >> >> If you are looking to make this seamless, you can set up replication and >> write-through proxying as you move the configuration and scripts first. > >Why would you want to move a Subversion server to a Windows system? I think that he said: >>>We need to move Subversion off of a Windows 2012 server and onto a Windows >>>2019 server. So the relevant question for him is what kind of server they are running... If it is VisualSVN then they should go to that maintainer and ask for help. >There are real performance tuning issues for either httpd or svn+ssh >based access which are more easily handled in a Linux or UNIX >environment, and high reliability and backup setups far more difficult >to resolve in a Windows environment. > >Definitely activate an svnsync to allow the new service to run in >parallel for a while, and to avoid any split-brain issues. I have a similar problem where I have installed VisualSVN back in 2017 on a Windows 2016 Server and now I face problems keeping it updated. It is still on VisualSVN 3.7.0 and since I am remote to the server by 8,500 km I do not really dare experimenting with the updates This server runs SVN version as follows: H:\>svn --version svn, version 1.9.7 (r1800392) compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601 It is still working but should be upgaded, only I don't know how to do it safely. The server is svn synced nightly over the Internet to a server I host in my premises, which is an Ubuntu Server 20.04.4 LTS and this runs: ~$ svn --version svn, version 1.13.0 (r1867053) compiled Apr 8 2022, 09:43:33 on x86_64-pc-linux-gnu On Linux the subversion upgrade is seamless with the apt program used to update/upgrade the whoile computer. So the OP (and myself) really need to create a Linux server to host the Subversion service going forward... What would be the proper way to migrate to a Linux based server and keeping the repository structure the same and allow user seamless access to these? -- Bo Berglund Developer in Sweden
Re: SVN PROBLEM
On Thu, 17 Feb 2022 16:34:16 +0300, NICK Margeyt wrote: >Hello,Please help in solving the problem, why the authorization window >for connecting to the repository does not appear, I have already tried >everything possible from reinstalling SVN to updating, anyway, any >user from the network can go to the repository by URL. Attached is the >configuration file and the authorization window that should come out >but it is not there >Thanks. What you have *not* supplied to your question is: - Which version of subversion are you using? - On which platform are you using svn? - How are you accessing the computer? (GUI, Terminal, SSH or how) - What command did you issue? - What was the actual error? - What are your customization(s) of the svn configuration file? - Are you by any chance using TortoiseSVN? etc etc -- Bo Berglund Developer in Sweden
Re: Subversion environmental variables
On Thu, 3 Feb 2022 14:12:14 -0500, Nathan Hartman wrote: >There exists somewhere in our mail archives >a script for zsh (which I can try to find if you want it) to manually >cache a plaintext password, if you feel this is an acceptable >solution. (There might also be a python script; I don't remember.) I am having problems working with svn on several platforms, like RaspberryPi and Ubuntu Mint. From some updated version of subversion passwords are no longer cached by svn itself and hence the operating system pops up a dialog in the GUI to fill in for executing say an svn update. But I mostly work on the command line, very seldom on the GUI so I don't see this When it first appeared I just saw a failing svn command and could not understand why. Now I know what was going on and so I have to VNC to the machines (they are mostly remote from my location) and thereby getting a GUI. Then I do the svn command in PuTTY and when it stalls I go over to the VNC GUI and sure enough: There is the pop-up window to be filled in. Pretty darn dumb decision to remove the password cache from svn if you ask me... Anyway I would be *very interested* in adding such a script for caching an svn password on my machine to get rid of this problem! -- Bo Berglund Developer in Sweden
Re: CVE-2021-44228 log4j vulnerability
On Mon, 13 Dec 2021 11:55:18 +0300, Pavel Lyalyakin wrote: >The vulnerability CVE-2021-44228 in the Java-based library Log4j affects >Java-based products that depend on the Log4j library. As I said above, >Apache Subversion is not a Java application and it does not use Log4j. >VisualSVN Server is also not a Java application and it does not use Log4j. Thanks you for verifying this to me! Much obliged. :) -- Bo Berglund Developer in Sweden
Re: CVE-2021-44228 log4j vulnerability
On Sun, 12 Dec 2021 15:30:20 +0300, Pavel Lyalyakin wrote: >Apache Subversion and Apache HTTP Server are not Java applications. >Subversion does not depend on log4j. AFAIK, Apache HTTP Server does not >depend on log4j either. Sounds good. We are using VisualSVN on our main SVN server running on Windows Server 2016: H:\>svnadmin --version svnadmin, version 1.9.7 (r1800392) compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601 It has no exposure to the Internet, just sits on the LAN. We have a backup server off-site running on Ubuntu Server 20.04.3: $ svnadmin --version svnadmin, version 1.13.0 (r1867053) compiled Mar 24 2020, 12:33:36 on x86_64-pc-linux-gnu The latter is svnsync'ed from VisualSVN every night and is fully updated. It has no public interface, set to readonly except for the svnsync calls. Do we need to do anything for the "log4j" vulnerability? -- Bo Berglund Developer in Sweden
Re: ASF Subversion version
On Fri, 10 Dec 2021 07:59:02 -0600, Luke Mauldin wrote: >Gotcha, thank you. > >> On Dec 10, 2021, at 7:14 AM, Mark Phippard wrote: >> >> ?On Fri, Dec 10, 2021 at 8:12 AM Luke Mauldin wrote: >>> >>> I noticed that the ASF is still running Subversion 1.9.x which was released >>> quite a few years ago. Does anyone know why they havent at least upgraded >>> to the 10.x LTS release which itself is over 2 years old at this point? >> >> ASF Infra uses the package provided by the Linux distro they are using >> rather than building and maintaining their own package. >> Why is a constrruction company involved in Subversion? http://www.asfinfrastructure.com/about-us.php Strange -- Bo Berglund Developer in Sweden
Re: Compare revisions on different devices, why different?
On Fri, 10 Dec 2021 10:14:24 -0500, Nathan Hartman wrote: >> Why are they not at the samerevision and date? >> >> > >On the debug system, immediately after committing, did you do 'svn update'? > >Nathan No, I assumed that was not needed since the debug system is where I have done code changes lately. But this fixed the issue: $ svn up Updating '.': At revision 4474. $ svn info Path: . Working Copy Root Path: /home/pi/projects/SSRemoteServer ... Revision: 4474 Node Kind: directory Schedule: normal Last Changed Author: bosse Last Changed Rev: 4474 Last Changed Date: 2021-12-10 07:13:39 -0600 (Fri, 10 Dec 2021) So the update did nothing except fix the revision number and time stamp. Do you need to do an svn up after each svn ci in order to fix the state? -- Bo Berglund Developer in Sweden
Compare revisions on different devices, why different?
I have several devices on which I have checked out the same project. One is connected to a debugging external system and the others are not. Now I have been working on the debugging system and committed my changes from that. Then I have updated the project on the non-debug system expecting to get the same code on both. But this is what svn info gets me: Debug system where I just committed: $ svn info Path: . Working Copy Root Path: /home/pi/projects/SSRemoteServer URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source Relative URL: ^/SSRemoteServer/trunk/source Repository Root: https://mysvnserver/svn/pc Repository UUID: 1e489663-c639-2248-90da-e976bc628839 Revision: 4470 Node Kind: directory Schedule: normal Last Changed Author: bosse Last Changed Rev: 4470 Last Changed Date: 2021-09-23 02:55:51 -0500 (Thu, 23 Sep 2021) Code writing system where I just updated: - $ svn info Path: . Working Copy Root Path: /home/pi/projects/SSRemoteServer URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source Relative URL: ^/SSRemoteServer/trunk/source Repository Root: https://mysvnserver/svn/pc Repository UUID: 1e489663-c639-2248-90da-e976bc628839 Revision: 4474 Node Kind: directory Schedule: normal Last Changed Author: bosse Last Changed Rev: 4474 Last Changed Date: 2021-12-10 14:13:39 +0100 (Fri, 10 Dec 2021) I note that these items differ: --- Revision: 4470 vs 4474 Last Changed Rev: 4470 vs 4474 Last Changed Date: 2021-09-23 vs 2021-12-10 Why are they not at the samerevision and date? -- Bo Berglund Developer in Sweden
Re: Migrating Apache Subversion to a new Ubuntu machine - how?
On Sun, 10 Oct 2021 03:42:30 -0400, Nico Kadel-Garcia wrote: >> PS: >> Is it possible to just move the existing hard drive over to the new computer >> and >> start it up? Or clone the content to the new computer's drive? >> I do have a lot of other stuff that needs migration too... > >Maybe? You'd need to mount it, and a 10 year old hard drive is >questionable at best. I'd use rsync: Ensure that you have SSH access >from the new host to the old host, and you should be able to use rsync >to copy material and run svnsync efficiently. And look up "svn >hotcopy" for copying the basic Subversion configuration for copying >over to a new server. UPDATE: To close this thread So I have done the migration now and it was basically painless, although time consuming because of the way I did it... 1) I figured out a way to create space on the new PC disk drive from within the pre-installed Windows 10. This was the easy part. I left 40 GB for Windows 10 and got about 450 GB free space. 2) Then I spent a bunch of time figuring out how to boot both my old PC and the new one from USB live media. Turned out to be impossible on the old eMachine PC but I *could* boot it from a DVD disk with Ubuntu ISO. But no USB drive... The new PC uses UEFI so it took a while to get the USB Ubuntu media to boot, until I found the correct way to modify UEFI settings to allow it. 3) Then I ran the Live DVD on my old PC and using GParted I could clone the partitons on that to a USB connected hard drive, I also made the partition on the target smaller. 4) Booting the new PC from a live USB with Ubuntu 20 I could install it in multi-boot fashion on the new PC in the now freed up space. I let it use just as much partition space as is needed for Ubuntu plus a bit more. 5) Next I started Ubuntu on the new PC and using GParted I copied over the old PC Ubuntu partition to the new PC hard disk after connecting the USB disk to it. 6) Finally once that was done I also updated the GRUB boot loader so it also included the old server in the boot menu. 7) With all that done I could boot into the migrated Ubuntu 18.04 server on the new hardware and it did run! So I could do the apt full-upgrade to get all new stuff and it announced that it was ready for a dist-upgrade too. Did that and now the server is 20.04 and all I have checked works fine. 8) Final stop: I now reprogrammed the port forwards on my router to go towards the new server rather than the old off-line server. And the next svn sync operation from the main server came through successfully and it is back in operation but on a new hardware system and running Ubuntu 20.04 rather than 18.04. My websites also work fine using the existing LetsEncrypt certificates. -- Bo Berglund Developer in Sweden
Migrating Apache Subversion to a new Ubuntu machine - how?
I am running an Apache Subversion server on an oldish Ubuntu 18.04 LTS server and I have realized that rather than upgrading the Ubuntu installation to 20.04 I should move it to new harware (with Ubuntu Server 20.04 LTS). The existing server runs on 10 years old (at least) hardware so it is due for replacement. But this installation serves as a backup svn server for a main server in the company facilities in another location. The main server does an svnsync across the internet each night to keep the two repositories in step. So I figured the migration is a lot more complex than just taking a repository dump and then loading this into a new installation... Repository ID:s etc has to be maintained for example. The server handles 10 different rather big repositories used for different purposes with different aithentication of svn users. This setup was done back in 2017. Can I use rsync to move the binary repository files over from one computer to the other and then somehow tell the new svn where it is located? On the existing server the repos are located in /var/lib/svn. So can I just rsync this tree between the two machines? And how do I go about configuring the new svn that this is where the reopos are? I tried googling and found this, which outlines a move, but does not talk about replicating users, connections, Apache integration etc: https://www.petefreitag.com/item/665.cfm Is this what I should do and how do I make sure the nightly svnsyncs will continue working? What about svn version differences? Info on my existing server version: /var/lib/svn$ svn --version svn, version 1.9.7 (r1800392) compiled Mar 28 2018, 08:49:13 on x86_64-pc-linux-gnu The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - 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 following authentication credential caches are available: * Plaintext cache in /home/bosse/.subversion * Gnome Keyring * GPG-Agent * KWallet (KDE) Grateful for advice / links to howto guides! (I will need to install Ubuntu server from scratch and then subversion and then configure it all...) PS: Is it possible to just move the existing hard drive over to the new computer and start it up? Or clone the content to the new computer's drive? I do have a lot of other stuff that needs migration too... -- Bo Berglund Developer in Sweden
Is it possible to get the location of WC in a post-commit hook?
I wrote a SVN mailer when we converted from CVSNT to SubVersion back in 2017. Its purpose is to send a nocely formatted commit message to subscribers and it has worked fine for years. But now I am missing one item in the mail, the location of the working copy from which the commit was done. I am working on a project where I have several WC in play, on my development device and the prototype and also a 3rd device. I have found it to be a bit difficult to keep track of which wc contains the latest commit so if it is possible to get this info on commit it would help a lot. These devices are all Linux. The mailer gets the data by calling svnlook. The svn server is on Windows Server 2016. -- Bo Berglund Developer in Sweden
Re: Need help in Subversion migration
On Mon, 17 May 2021 17:15:13 -0400, David Newman wrote: >> A few years back I replicated our live SVN repository, to get a backup, by >> using >> a dump followed by a load on the replication server. The dump files were >> moved >> over the Internet in tgz files before being used to load onto the new server. >> >> Then I set up svnsync to get the replica fully updated. That worked even over >> the Internet, but my repo size was not as huge as here, only some 15 GB... >> >> Now the live server has a nightly svnsync script that keeps the two repos in >> sync. If some network issues happen so that such a sync cannot be done then >> the >> following will catch up and make the replica current again. >> >> Something like that but running on the local LAN (for speed) would surely be >> possible to migrate. >> >> > >A faster method of copying the repository than dump while being read >consistent would be svnadmin hotcopy. This allows the repository to be >open while being copied. If possible you can NFS mount the destination >location and hotcopy straight to it. Then you can use incremental >dump/restore from the source to the destination to pick up changes until >you are ready to do the final cutover. I've used this method many times. I had to do the transfer while being 8400 km away... So what I did was to create the dump files on the actual server, then zip them and upload to my ISP webstorage using ftp. Then from there to my new server agin FTP download and after unzipping I could load the dump files onto the new SVN server. That gave me a snapshot in time but all the heavy weight stuff was included. So when I set up svnsync after a few days it figured out what should be transfered to make the repos in sync. Had the backup server been on the same LAN as the source server then the method might have been different. -- Bo Berglund Developer in Sweden
Re: Need help in Subversion migration
On Mon, 17 May 2021 08:24:55 -0400, Mark Phippard wrote: >> The current setup (v1.7) has the repo size of 500GB. we are using svn load >> and svn dump method to migrate the repos from current setup (v1.7) to new >> setup(v1.10) , but it takes a lot of time due to the size of the repo >> (500GB) , Also the current setup (v1.7 is being currently used by the >> customer ,soo even after taking the dump of one particular repo and loading >> it in new setup , a newer revision is being made in the current setup (v1.7 >> by the customer , thus making us to do the svn dump and lsvn load again. >> >> now we need your help in identifying an efficient way in migrating the repo >> from the current setup (v1.7 to the ew setup(v1.10) , Need your expert >> advise on this please >> >> >> Also let us know we can do rsync for this? >> >> Thanks & Regards, >> Jackson J > >You do not have to do anything. Just point the new server at the existing >repositories or move them to new location. You can use rsync, tar or whatever >method you prefer. By the description it looks like the repository is *in use*, so there must be two different Linux machines involved here. Not so easy to point the new server at tyhe same physical repo then. And Jackson says that commits are also done during the migration process, seems like a not so good solution... A few years back I replicated our live SVN repository, to get a backup, by using a dump followed by a load on the replication server. The dump files were moved over the Internet in tgz files before being used to load onto the new server. Then I set up svnsync to get the replica fully updated. That worked even over the Internet, but my repo size was not as huge as here, only some 15 GB... Now the live server has a nightly svnsync script that keeps the two repos in sync. If some network issues happen so that such a sync cannot be done then the following will catch up and make the replica current again. Something like that but running on the local LAN (for speed) would surely be possible to migrate. -- Bo Berglund Developer in Sweden
Re: Does a WC contain all log messages?
On Sat, 24 Apr 2021 11:05:33 -0400 (EDT), Robert Heller wrote: >I believe svn log always connects to the "server". The difference is where >the >"url" comes from. In the first form, the user explicitly provides the url and >in the second the url is formed from information in the .svn directories. This I could in fact test! :) The svn server I use ison a local server at the office and is not exposed externally. I am hooked up to the office network via VPN, so I could disconnect and re-test. Sure enough, no log appeared. So it *is* a server side operation. But there is no timeout on the client side, it just hangs there... And reconnecting to the office while it is "waiting" does nothing at all. Still just hangs there. Test done on Windows 10 with svn client version 1.12.0 Server side svn version is 1.9.7, I believe. -- Bo Berglund Developer in Sweden
Does a WC contain all log messages?
If I check out and work on a project I know that the .svn dir contains "stuff" related to the subversion system. But is it like with GIT that it contains "everything"? I.e. all older revisions too? The reason I ask is that I was looking at svn log in order to figure out how to see what had happened earlier on the project. There are two different ways: 1) Connect to the server and get the log info: svn log -v 2) Run the command in the working copy dir: svn log -v I don't know if the second incarnation will only get whatever I have done myself when working on the project or if it somehow can show the complete log history. All projects I have on my system I originated myself so it is not possible to check (unless I check out some opensource project from the internet of course). When I tested on my project both versions resulted in the same output, but then the project was started by me so I obviously have all of the data on my PC (provided svn saves it inside .svn of course). -- Bo Berglund Developer in Sweden
Re: Easiest way to backup SVN repositories?
On Tue, 20 Apr 2021 19:08:35 +0200, Andreas Stieger wrote: >Hello, > >On 4/20/21 6:48 PM, scotrod wrote: >> I wanted to ask which is the fastest and painless way to backup a SVN >> repos without stopping the service. >> I've heard that people on the Internet do it using rsync, but I am not >> familiar yet with using this tool. > > >Rsync is only suitable if you take specific extra measures on the >repository (locking, hotcopy) > >Start reading here: >http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.backup > >Also note (as a general statement) that an rsync copy is just a copy, >not a backup. A backup is something where you can not only restore one >snapshot but all past states. Also something that is tested to work in >the reverse. > Here is my SVN backup experience: We went from CVSNT to SVN back in 2017 and at the time I had to evaluate the backup/security issues with the repository. THe CVSNT server is completely file based so it could be backed up on a file system base. Not so with SVN, which is database based... Since our CVS server was partitioned in several different CVSROOT trees I had to migrate these as such using scripts available on the Internet. So I wound up with a SVN system with basically the same layout as on CVS as a client/server versioning system (note: I also evaluated GIT but that was too different to be able to import our CVS data into). Next I had to figure out the backup method and quickly got caught by what Andreas mentioned and the linked document outlines too... After a process I finally wound up with an svnsync approach with nightly syncs against a full mirror of the SVN main repository server content. The main server runs on Windows (VisualSVN) and the backup server runs on Ubuntu Server in a completely different location (we are safe from catastrophes like fire, flooding etc this way). After the initial setup, which uses svn dump files to import the exact same data into the remote server, I have a nightly task on the main server to sync the backup server with data changes from the last day and this is run over the Internet. This has worked extremely well now for 4 straight years! -- Bo Berglund Developer in Sweden
Re: How to safely back up an svn repository on ubuntu?
On Wed, 13 Jan 2021 12:58:59 +0100, Pierre Fourès wrote: Thanks for your comments Pierre! :) >I understand your point and have done similar setup. I've first started >using a local svnadmin hotcopy to create a clean and safe copy of my >repository, and then, rsynced this folder to my remote server. As I can >handle a downtime on my svn server (in the middle of the night), I've >switched to shutting down the server, and just rsyncing the /var/lib/svn >sub-folders. This saved a step, a loop, and some disk usage on my local >server. So you mean I need to shut down the svn server first? I don't know how to do that since svn is kind of integrated with apache on my server... OTOH I know exactly when the nightly svnsync is started on the source system to copy over the day's changes to the backup server, so I could choose another time to run my cron job. And this backup svn server on Ubuntu is not used for anything on the synced repositories except receiving the backup data. Concerning rsync, I have first tested what is happening when I use ordinary file system commands towards the nfs share on Synology... What I found was that the owner/group fields look strange to me. Here an example: $ ls -l ~/www/index.php -rw-rw-r-- 1 bosse bosse177 Jan 13 21:32 index.php $ cp ~/www/index.php /nfs/backup/ Then: $ ls -l /nfs/backup/ -rw-rw-r-- 1 nobody 4294967294 177 Jan 13 23:04 index.php Notice how the file ownership has changed in this operation. Is rsync doing something else that keeps the ownership the same as on the source? Or have I set up the wrong kind of options on the mount command for the nfs share? >As an extra-layer of security, what you might consider too, on your >cold-backup NAS system, is to set up a rolling backup strategy scheme. I >was afraid of a corruption of my repositories, for which ever reason, but >mostly from a mistake from my own self. Having multiple copies on my cold >storage helps preventing it. Just using the day of the week while selecting >which folder you want to rsync your files too makes you a 7 days rolling >scheme. > I don't think I will need a rolling scheme here... -- Bo Berglund Developer in Sweden
How to safely back up an svn repository on ubuntu?
I would like to set up a cron job to backup the repositories on an svn server to a Synology NAS. The repositories reside in /var/lib/svn and comprise about 6 Gb worth of files in 12 different directories. These are svnsync:ed nightly from our main SVN server in the main office across the world as a backup of the development activities there. The main svn server is VisualSvn on Windows Server 16 if that matters. The svnsync has worked fine for 2+ years since I set it up. The backup SVN server runs on an Ubuntu 18.4 LTS server in my home network and on that network I also have a Synology NAS, which I want to use as a 3rd level backup for the SVN repositories in case the Ubuntu server here crashes. I got a problem with it a few days ago when we had a power outage and the Ubuntu box did not boot properly when power returned. Now fixed but it raised the concern over backup security. I have now set up an NFS connection between the Ubuntu server and the Synology NAS so I have a target dir in Ubuntu in /nfs/backup where I can write the files. So what I had in mind is to somehow keep a copy of the repository files on the nfs share but I am not sure what command would be suitable to perform this action. I could use tar but that would be complex since there are certainly not many files that change from one day to the other. Only changed files should be copied to reduce the time of backup. Or else perhaps rsync, provided it knows which files have changed and which have not etc. I am a user of Ubuntu Linux for some of my work and have had to learn the basics of managing Linux, but I am not versed in these actions. Daily I am a Windows user. I don't know if some actions should be done towards svn on the ubuntu server in order to safely copy the files either... Please advice... -- Bo Berglund Developer in Sweden
Re: Why is svn not saving my password in Pi-OS?
On Tue, 29 Dec 2020 00:47:32 -0500, Nathan Hartman wrote: >On Mon, Dec 28, 2020 at 3:16 PM Bo Berglund wrote: > >> On Sun, 20 Dec 2020 11:59:11 +0100, Bo Berglund >> >5) Then the commit worked! >> > >> >So it seems like the svn config file must be modified and then it >> >starts working again. >> > >> >> Except now it has reverted to popping up the GUI login dialog when I >> am checking in via a PuTTY session. >> In PuTTY it just sits there doing nothing, if I then open the VNC >> window into the RPi then I see the login dialog there. :( >> >> How should the setting in subversions config file look like? >> Right now it is as follows (uncommented the existing line) >> >> password-stores = gpg-agent,gnome-keyring,kwallet >> >> Should something be taken out or something else added to make it stop >> this behaviour and always demand login on the terminal that issues the >> svn operation? >> >> It seems so strange that svn would use a completely different window >> to get the credentials from than the one where svn itself runs. > > >Hi Bo, > >The order of the 'password-stores' setting is significant. Based on what >you wrote the last time, that means gpg-agent is tried first, followed by >gnome-keyring, followed by kwallet. > >It sounds to me like one of these is putting up the GUI password dialog >that you want to avoid. > >It is probably enough to choose just one of these password caches and set >it up properly, to ensure that you'll only use that one. > >Here is some information about getting gpg-agent and gnome-keyring to >prompt for password in the console, not in the GUI. I'm also including a >link about KWallet, though that one doesn't look as encouraging to me as >the other two... you might want to remove that one from password-stores >(and you might want to remove one of the other two, leaving just one). > > >gpg-agent >= > >To get gpg-agent to prompt for password in the console, see the following >two questions and answers: > >https://superuser.com/questions/520980/how-to-force-gpg-to-use-console-mode-pinentry-to-prompt-for-passwords > >https://stackoverflow.com/questions/17769831/how-to-make-gpg-prompt-for-passphrase-on-cli > >Namely, these explain how to setup gpg-agent to use a console-based >pinentry program, either pinentry-tty or pinentry-curses. > >gnome-keyring >= > >Regarding gnome-keyring, see this question: > >https://superuser.com/questions/141036/use-of-gnome-keyring-daemon-without-x > >and in particular see Stephen Gray's answer (currently the 2nd from the >top). It includes a link to "source material" which is a WANdisco article >but that link is broken; the updated link is: > >https://community.wandisco.com/s/article/How-to-set-up-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh-session > >In particular, see the part about setting up a dbus session to interface >with the GNOME Keyring; I think that's the key step that allows it to work >without X (without a GUI). > >kwallet >=== > >Less encouraging than the other two, but: > >https://bbs.archlinux.org/viewtopic.php?id=253391 > >Hope one of these helps... Well I had a look and it does not seem like there is much of this on the RPi4... .gnupg/ is empty including its subdir private-keys-v1.d/ /etc/pam.d/login has a lot of settings but the referenced so files do not exist (on path at least) I read your links and I did not understand a lot of it. But in the "Gray's answer" part I could follow 1.1 and 1.2 (edit the config file). But for item 2 I drew a blank... The Collabnet keyring_tool does not exist on my system: $ which keyring_tool (no output) So the instruction to "Create a keyring for your password." by the operations below cannot be executed: keyring_tool --create=svn or keyring_tool --setdef=svn And apt is no help either: $ sudo apt install keyring_tool Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package keyring_tool Seems such a pity that a tool like Subversion can be so broken by some "upgrade" that it becomes unusable... -- Bo Berglund Developer in Sweden
Re: Why is svn not saving my password in Pi-OS?
On Sun, 20 Dec 2020 11:59:11 +0100, Bo Berglund wrote: >On Sun, 20 Dec 2020 09:05:52 +0100, Bo Berglund > wrote: > >>>If you do get a list of credential caches that the SVN client >>>recognizes, then you should pick one and ensure it is setup correctly. >> >>How do I "pick one"? >>Inside the ~/.subversion/config ot ~/.subversion/servers files >>And how to "setup"? > >So I made the following test: > >1) Modified the ~/.subversion/config file (note NOT the servers file >as suggested in another thread): >Uncommented the following line: >password-stores = gpg-agent,gnome-keyring,kwallet > >2) Rebooted the RPi just to get rid of possible cached stuff > >3) Edited a documentation file in the project I am working on and >issued the svn ci command. > >4) After entering the log message a login dialog appeared in the PuTTY >terminal, where I could enter my subversion login. > >5) Then the commit worked! > >So it seems like the svn config file must be modified and then it >starts working again. > Except now it has reverted to popping up the GUI login dialog when I am checking in via a PuTTY session. In PuTTY it just sits there doing nothing, if I then open the VNC window into the RPi then I see the login dialog there. :( How should the setting in subversions config file look like? Right now it is as follows (uncommented the existing line) password-stores = gpg-agent,gnome-keyring,kwallet Should something be taken out or something else added to make it stop this behaviour and always demand login on the terminal that issues the svn operation? It seems so strange that svn would use a completely different window to get the credentials from than the one where svn itself runs. -- Bo Berglund Developer in Sweden
Re: Why is svn not saving my password in Pi-OS?
On Sun, 20 Dec 2020 09:05:52 +0100, Bo Berglund wrote: >>If you do get a list of credential caches that the SVN client >>recognizes, then you should pick one and ensure it is setup correctly. > >How do I "pick one"? >Inside the ~/.subversion/config ot ~/.subversion/servers files >And how to "setup"? So I made the following test: 1) Modified the ~/.subversion/config file (note NOT the servers file as suggested in another thread): Uncommented the following line: password-stores = gpg-agent,gnome-keyring,kwallet 2) Rebooted the RPi just to get rid of possible cached stuff 3) Edited a documentation file in the project I am working on and issued the svn ci command. 4) After entering the log message a login dialog appeared in the PuTTY terminal, where I could enter my subversion login. 5) Then the commit worked! So it seems like the svn config file must be modified and then it starts working again. Thanks! -- Bo Berglund Developer in Sweden
Re: Why is svn not saving my password in Pi-OS?
On Sun, 20 Dec 2020 00:29:40 -0500, Nathan Hartman wrote: >On Fri, Aug 14, 2020 at 7:35 AM Bo Berglund wrote: >> How can I configure (?) svn such that it caches the password in the >> same way as it has done on all of my other RPi units before. >> >> I need to be able to work on this device BOTH via SSH login using >> PuTTY and inside the GUI when connecting via VNC. > >I don't think you want to enable plaintext password storage. Also I >don't think that's part of the problem here. You are correct, I don't care how the password is stored just that the login should not move to a *different and invisible window* than the one I am working in when I want to commit something! Especially frustrating when I use an SSH terminal like PuTTY. >The first thing you should do is run "svn --version" on the machine in >question and look for the list of available authentication credential >caches toward the end. On my Debian box, that looks like this: > >[[[ >The following authentication credential caches are available: > >* Gnome Keyring >* GPG-Agent >* KWallet (KDE) >]]] > This is what I get: $ svn --version svn, version 1.10.4 (r1850624) compiled Jul 28 2019, 02:44:06 on arm-unknown-linux-gnueabihf Copyright (C) 2019 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. - with Cyrus SASL authentication - 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 following authentication credential caches are available: * Plaintext cache in /home/pi/.subversion * Gnome Keyring * GPG-Agent * KWallet (KDE) >Those are much better than plaintext storage because the password >caches are stored encrypted. Fine, that is OK for me. I never open any password file anyway. >If you don't have any credential caches listed, you'll need to either >request from the package maintainer(s) to do something about it, or >ensure you have the right dependencies installed and build the SVN >client from sources. Well, as you see they are there, but if they are non-GUI they seem not to be used anyway. >If you do get a list of credential caches that the SVN client >recognizes, then you should pick one and ensure it is setup correctly. How do I "pick one"? Inside the ~/.subversion/config ot ~/.subversion/servers files And how to "setup"? >For example, if your SVN client supports gnome-keyring and you want to >use that, you'll need to ensure you have whatever required packages >installed on the RPi and may need to do some configuration so that the >keyring will be "unlocked" when you login via ssh (with PuTTY). That >should make the stored passwords available automatically and (at least >after the first time to initially enter the password) eliminate the >(GUI) password prompt. I do not know what any of these are, I just want the login dialog to show in the text based SSH window where I issued the svn command Which one of these will make the GUI dialog go away? The names indicate that they are related to Linux GUI desktops, which I don't use.. Subversion was so easy to use on the command line but now it is a PITA... I just want to *use* svn. -- Bo Berglund Developer in Sweden
Re: Why is svn not saving my password in Pi-OS?
On Sat, 15 Aug 2020 11:01:10 +0200, Daniel Sahlberg wrote: >Den lör 15 aug. 2020 07:44Bo Berglund skrev: > >> On Fri, 14 Aug 2020 13:47:59 +0200, Daniel Sahlberg >> wrote: >> >> >TLDR: Saving passwords in plaintext is (from some version) a non-default >> >compile time option. You may try to convince the Pi-OS maintainers to >> >enable this option again. >> >> I posted the same question now on the RPi forum referencing your reply >> here. See: >> https://www.raspberrypi.org/forums/viewtopic.php?p=1712685#p1712685 > > >I realise that you are using version 1.10. I that time, AFIK, it was a >compile time option to disable plain text password stores. So either Pi-os >intentionally disabled it or they backported part of 1.12. However you >should be getting a Pi-os centered answer in the forum. No reasonable reply on the RPi forum, but I believe thios should be an issue on a subversion centered forum/maillist. Question: What happens if one tries to install svn on a server type Linux distro? Ubuntu, Pi-OS, Debian etc? Will the svn tool then be unable to work against any server requiring user login? In such a situation there is no GUI to pop the login into... It is REALLY terribly irritating to have to launch a VNC session onto the server and log into the GUI just for the purpose of entering a subversion login on a command running in an SSH terminal obn that server! -- Bo Berglund Developer in Sweden
How to revert trunk to an earlier revision?
When I look up svn revert it only talks about removing local edits, but what about this: Working on trunk and committing a few changes, which later turns out to be wrong. Now I want to set trunk head to be at the revision where the edits started out from. If I update my wc to that rev I get the state I want but now I cann not commit anymore... So how is this done? (I assume it is possible and if done via svn it should also be reversible). -- Bo Berglund Developer in Sweden
Re: Upgrading visual svn server from 3.7.0 using svn 1.9.7 - how?
On Mon, 5 Oct 2020 11:59:53 +0300, Pavel Lyalyakin wrote: >Opening cmd.exe and simply running `svn --version` is an incorrect way to >find out the version of Subversion the server is built with. This will only >show the version of the svn.exe client and depending on your %PATH% >variable and current directory can show you the version of some other >Subversion client (e.g., TortoiseSVN). Run the *"%VISUALSVN_SERVER%bin\svn.exe >--version"* command instead - it will show you the version of svn.exe which >comes with VisualSVN Server. Here is what I got: H:\>"%VISUALSVN_SERVER%bin\svn.exe" --version svn, version 1.9.7 (r1800392) compiled Nov 21 2017, 12:52:53 on x86_64-microsoft-windows6.1.7601 and: H:\>where svn C:\Program Files\VisualSVN Server\bin\svn.exe So it is really the server version I have checked. BTW, no client tools will ever be installed on a Windows Server in our company, like Tortoise etc. -- Bo Berglund Developer in Sweden
Re: Upgrading visual svn server from 3.7.0 using svn 1.9.7 - how?
On Fri, 2 Oct 2020 19:42:03 +0200, Daniel Sahlberg wrote: >Den fre 2 okt. 2020 kl 18:24 skrev Bo Berglund : > >> We are using this setup: >> - Main server is running on Windows Server 16 Standard using VisualSVN >> version 3.7.0, which apparently uses svn 1.9.7 >> >> - The server is using svnsync nightly to synchronize over the Internet >> to a mirror SVN server version 1.9.7 running on Ubuntu 18.04 Server on >> a different location entirely. >> No user operations are allowed on the mirror, it is just a backup. >> >> My problem is this: >> The VisualSVN server is seriously out of date and needs to be >> upgraded. In its own management console it suggests upgrading to 4.2.2 >> but does not say which version of svn will then be running. >> In fact it seems like they are intentionally hiding the svn version in >> their web pages.. :( >> > >I checked our installation of 4.2.2 and it seems to be running 1.10.6. >VisualSVN Server is installing the Subversion command line tools in >C:\Program Files\VisualSVN Server\bin so I simply opened cmd.exe and >executed svn --version. > >And I suspect that there might be problems concerning the svnsync >> commands if the backup mirror server is not upgraded to the same svn >> version, right? >> > >I checked quickly with a brand new Ubuntu 18.4 VM running svn 1.9.7 and >svnsync works both if initiated from the Ubuntu box (connecting to >VisualSVN Server using https) and if initiated from Windows (using svn+ssh >and plink with public keys). Of course, YMMW. > > >> But how do I do that on Ubuntu when I cannot find out which svn >> version they use? > > >> Or does it not matter, i.e. can the main and mirror servers be using >> different svn versions? >> > >In general use you are free to mix different versions of the server and the >client so I would assume this also goes for svnsync. And it's not too far >between 1.9 and 1.10. Others on the list might be able to give a more >detailed answer but why not test it :-) Thanks! I retrieved the svn version using the same way as you (svn --version on command line)... I will make a test as soon as I have fixed a broken OpenVPN channel to the office. It has stopped working even though I can ping the box. Unfortunately it sits across the ocean in Texas so it is not so easy. And I don't want to risk the upgrade unless I have an extra working OpenVPN server on the system. -- Bo Berglund Developer in Sweden
Upgrading visual svn server from 3.7.0 using svn 1.9.7 - how?
We are using this setup: - Main server is running on Windows Server 16 Standard using VisualSVN version 3.7.0, which apparently uses svn 1.9.7 - The server is using svnsync nightly to synchronize over the Internet to a mirror SVN server version 1.9.7 running on Ubuntu 18.04 Server on a different location entirely. No user operations are allowed on the mirror, it is just a backup. My problem is this: The VisualSVN server is seriously out of date and needs to be upgraded. In its own management console it suggests upgrading to 4.2.2 but does not say which version of svn will then be running. In fact it seems like they are intentionally hiding the svn version in their web pages.. :( And I suspect that there might be problems concerning the svnsync commands if the backup mirror server is not upgraded to the same svn version, right? But how do I do that on Ubuntu when I cannot find out which svn version they use? Or does it not matter, i.e. can the main and mirror servers be using different svn versions? -- Bo Berglund Developer in Sweden
Re: Why is svn not saving my password in Pi-OS?
On Fri, 14 Aug 2020 13:47:59 +0200, Daniel Sahlberg wrote: >TLDR: Saving passwords in plaintext is (from some version) a non-default >compile time option. You may try to convince the Pi-OS maintainers to >enable this option again. I posted the same question now on the RPi forum referencing your reply here. See: https://www.raspberrypi.org/forums/viewtopic.php?p=1712685#p1712685 -- Bo Berglund Developer in Sweden
Re: Why is svn not saving my password in Pi-OS?
On Fri, 14 Aug 2020 13:47:59 +0200, Daniel Sahlberg wrote: >Den fre 14 aug. 2020 kl 13:35 skrev Bo Berglund : > >> This is strange to me since I have not seen it before. >> I have svn installed on a newly set up RPi3 running Pi-OS (previously >> named Raspbian) Linux. >> I installed svn via apt. >> >> Any ideas? >> >> >> -- >> Bo Berglund >> Developer in Sweden >> > >You will most probably find your answer in this mailing list thread >at @Dev: https://svn.haxx.se/dev/archive-2020-08/0004.shtml > >TLDR: Saving passwords in plaintext is (from some version) a non-default >compile time option. You may try to convince the Pi-OS maintainers to >enable this option again. I don't know how that works, do the maintainers of distros really recompile all of the content and modify the code in so doing? >You might be able to get this to work using a keyring, but I don't have any >experience with it (I'm mostly a Windows guy). > >I've been planning to check why the script provided by Daniel Shahaf >doesn't work, because I would also like to be able to save passwords from >time to time. > Is this a client modification and if so from which version? Is it possible to install a specific (older) svn client version in a Linux computer in order to have this fixed? If so how? I am using apt in my scripts to install for example subversion... And I am not really talking about cahching the password in *plaintext*! It could as well be encrypted, but what it should not do is launch a GUI dialog to enter the password when the command is issued in a terminal window! Svn is a command line tool and therefore a password request should be shown inside the terminal that is running the svn operation and not pop up something that is incvisible to the user! Whatever GUI wrappers like Tortoise do is irrelevant since in such usage the entire user interaction is via the GUI. In the terminal case NOT... -- Bo Berglund Developer in Sweden
Why is svn not saving my password in Pi-OS?
This is strange to me since I have not seen it before. I have svn installed on a newly set up RPi3 running Pi-OS (previously named Raspbian) Linux. I installed svn via apt. The RPi3 has a GUI, which I can access via VNC through a VPN tunnel (I am working remotely from home). If I start a terminal in the GUI and navigate to the project wc dir and then issue an svn up command a GUI dialog pops up on the side asking me for a password. This happens every time so it seems not to remember what I have entered. Contrast this to when I access another *non-GUI* RPi using PuTTY. When I use the svn up command there everything just executes as expected and no password is requested because I entered it way back when I checked out the wc. Back to the new RPi3, if I access it through PuTTY instead then the svn up command just does exactly nothing, it just sits there! Probably it pushes a GUI login box onto the invisible GUI... How can I configure (?) svn such that it caches the password in the same way as it has done on all of my other RPi units before. I need to be able to work on this device BOTH via SSH login using PuTTY and inside the GUI when connecting via VNC. One difference of course is that the svn client on the RPi3 is a newer version ( 1.10.4 r1850624) than what I have used before and what is used on the svn server (1.9.7). Any ideas? -- Bo Berglund Developer in Sweden
Re: How to recover from a failed update/merge?
On Mon, 10 Aug 2020 09:52:51 -0400, Nathan Hartman wrote: >> How should I proceed to get the wc in a state like after the last >> successful update so it can now be updated to the repository head >> revision? > > >So, if I understand correctly, you want to throw away *all* modifications >in your working copy. In a situation like this, I would shut down the IDE >so that it won't interfere, and from the topmost directory of the working >copy, do: > >$ svn revert -R . > > >Now, you should be able to "svn update" to get the latest repository >revision. > >Again, since a revert cannot be undone, always be careful with "svn revert" >especially with "-R" (recursive)!! Thanks! I used TortoiseSVN to revert the 7 changed files and then I did an update and got the latest revision without the conflicts popping up! I did not need the recursion because it was only files from a single dir that were compromised. -- Bo Berglund Developer in Sweden
How to recover from a failed update/merge?
I have this multi-platform app in SVN thet I started in Windows but lately have worked on in Linux. The correct latest version is from Linux and I wanted to verify it on Windows. Everything is committed from Linux and the revision there is the current one. Now I made a mistake in Windows and don't know how to get out of it... I had started the IDE and when checking the code I realized it was not current, but the fact that I checked modified local files. Next mistake, I went to the command line and did an svn up to get the latest versions forgetting the IDE was still running, so it now intervened and tried to be clever about the changing files. Meanwhile svn started to offer some merge suggestions which I had never done before and after a while I had this mess So now I need to get a clean slate on the source dir in Windows, i.e I want to get the *repository revision* of all files in the source dir and not bother with bogus changes made in the messup. How should I proceed to get the wc in a state like after the last successful update so it can now be updated to the repository head revision? -- Bo Berglund Developer in Sweden
Re: Getting strange error when updating on Linux
On Fri, 7 Aug 2020 10:34:44 -0400, Nathan Hartman wrote: >On Fri, Aug 7, 2020 at 8:58 AM Bo Berglund wrote: > >> ** Message: 14:45:45.612: Remote error from secret service: >> org.freedesktop.DBus.Error.ServiceUnknown: The name >> org.freedesktop.secrets was not provided by any .service files > > >I think it is trying to cache/lookup your password in gnome-keyring, but >for some reason that package is not installed. > Thanks! I did this: sudo apt install gnome-keyring and now when I used svn up again it did show a password dialog where I could select to save the password too. And no more error messages! Thanks again! -- Bo Berglund Developer in Sweden
Getting strange error when updating on Linux
I am programming on a Raspberry Pi3B with the latest Pi-OS Linux. I have installed subversion via apt two days ago and got version 1.10.4 (r1850624). When I want to update a project on this machine I get the following output, which makes no sense to me (I have obfuscated the svn server name) $ svn up Updating '.': Authentication realm: <https://svnserver:443> VisualSVN Server Password for 'bosse': * ** Message: 14:45:45.612: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files Usource/class_SSRemoteServer.pas UReadme.md Updated to revision 4379. If I do the same on an Rpi4 with a current Raspbian Linux using the same client subversion version I do not get this message, it just works... So what could be the problem here? It seems to work, yet it outputs this message... What is this freedesktop thing? And another thing: On other RPi units I use the svn password is cached so I don't have to enter it again and again, but not on this box, why? -- Bo Berglund Developer in Sweden
Checking out a dir from a different project in a WC?
Can SVN deal with this: /project1 (checked out via SVN) |-- proj1subdir1 |-- proj1subdir2 |-- support (checked out from a different project) I.e. can I combine a main project checkout from SVN with a few extra folders checked out from another project or from an entirely different svn server? The support dir might be an opensource folder from the Internet while the rest is located in an internal server. In a situation as shown will an svn up command issued in the top dir propagate into the support dir and update these files too? -- Bo Berglund Developer in Sweden
Re: How to resolve between working copies?
On Mon, 17 Feb 2020 10:10:53 +0100, Stefan Sperling wrote: >> So what can I do to get rid of this problem? > >First, you should put the file back on disk :) >Moving files away behind the back of SVN is never a good idea. Yes, but the file was a non-versioned duplicate so it should not matter that I renamed it, right. Anyway I put it back since it did not solve my problem. >Then run 'svn resolve' again. When you are unsure what to choose, the option >to "merge" the files should be the best one. It will boil down 'add vs add' >to a text-conflict or perhaps even a clean merge, depending on file content. I have never even seen the resolve command before... >There are more options (try the 'h' option to see them), but generally >any "merge" options in the conflict resolver will always produce a useful >result when possible. > >Hope this helps! Yes it does, thank you! Running svn resolve got me a chance to fix the problem. Since I could not see any difference in the command line svn diff I proceeded to merge etc and then I used tortoise to diff the result and found that tywo lines had an extra space at the end, something WinDiff does not consider a difference... Now I could finally svn rm the file since it did not belong there in the first place, moved into a php dir instead. -- Bo Berglund Developer in Sweden
How to resolve between working copies?
I have a project I am working on in both Windows and Linux. So the project is checked out on both places. Now I have a php file that was created in the Windows WC and copied to the Linux WC where its functions were tested on Apache after copying over to the website. Then I svn added it in the Linux WC and committed it along with other files. Now when I want to update the Windows WC I get a message at the end of the file listing: Updated to revision 2867. Summary of conflicts: Tree conflicts: 1 Searching tree conflict details for 'ServerConfig\putcmdfile.php' in repository: Checking r2861... done Tree conflict on 'ServerConfig\putcmdfile.php': A new file appeared during update to r2867; it was added by bosse in r2861. An unversioned file was found in the working copy. Select: (p) Postpone, (r) Mark as resolved, (m) Merge the files, (h) Help, (q) Quit resolution: q Summary of conflicts: Tree conflicts: 1 Since I was unsure about how to deal with this I selected q to quit, but this was apparently no good because now I cannot get rid of the error message whatever I do. I have tried renaming the file in the file system and then do a svn up to get a fresh file from the server but it also fails: ServerConfig>svn up Updating '.': At revision 2867. ServerConfig>svn st D C putcmdfile.php > local file unversioned, incoming file add upon update Summary of conflicts: Tree conflicts: 1 So what can I do to get rid of this problem? /Bo B
RE: SVN version - confused about support
> From: Paul Hammant [mailto:p...@hammant.org] > Sent: den 8 december 2019 11:26 > To: Bo Berglund > Subject: Re: SVN version - confused about support > > > First of all, get good at backups, and **practice** restores to another > machine. > That is another really unrelated story... I have asked around for how to actually do backups that many howto-pages on the web recommend before attempting the procedure they describe. Quite often this is regarding Raspberry Pi systems (which are the more common Linux stuff I work with). Invariably the response is to take an image of the SD-card running The Raspbian system on Rpi... Obviously that is not really the answer for a Ubuntu Server running with a 500 GB hard disk. On Windows there are ways to backup the system even included on the operating system but it seems you are on your own when dealing with Ubuntu and Linux in general... Unless you mean just backing up the SVN repository files?? Those are a sum of 5.6 GB located on /var/lib/svn/ I could tar the whole tree and put that into a NAS on the network of course... Or is there a better method using svn itself that could be used? Notice that the Ubuntu server ia a backup SVN itself only used with svnsync from the main server. > Separately get experience with nuget and chocolatey. Maybe pair with someone > on these. > I did not know these existed even... However, I cannot really change the software management on already installed programs using other managers, right? Meanwhile, I found my notes for the Ubuntu Server 16.04 LTS SVN mirror server installation (Jan 2017). There I can see that svn was installed using these apt commands: sudo apt-get update sudo apt-get install apache2 sudo apt-get install subversion libapache2-mod-svn libapache2-svn libsvn-dev sudo a2enmod dav sudo a2enmod dav_svn sudo service apache2 restart Followig this there was a number of configuration file edits etc... So given that I used apt-get to retrieve svn and got 1.9.7 I am a bit surprised that I am not given any options to upgrade svn when I regularly do: sudo apt update sudo apt upgrade Why is that? I thought that all software installed via apt will be automatically checked for updates and shown suggested candidates for upgrades when such exist. If I do another "sudo apt install subversion" today will I then get an upgrade to the 1.10.6 stable LTS version? Probably not: $ apt-cache policy subversion subversion: Installed: 1.9.7-4ubuntu1 Candidate: 1.9.7-4ubuntu1 Version table: *** 1.9.7-4ubuntu1 500 500 http://se.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages 500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages 100 /var/lib/dpkg/status So Ubuntu is still on 1.9.7 in their repositories?
RE: SVN version - confused about support
> From: Paul Hammant [mailto:p...@hammant.org] > Sent: den 8 december 2019 10:10 > To: Bo Berglund > Subject: Re: SVN version - confused about support > > > What is stopping you from getting fully up to date with Svn - client and > server? > Well, *how* can I do that? Windows 10 client: -- On the Collabnet site I only found this command line installer for Win x64: CollabNetSubversion-client-1.12.2-1-x64.exe And I have no idea how to upgrade the two servers either (I am just a user turned admin for SVN). Ubuntu mirror server: - So if I installed SVN server on ubuntu 16.04.4 LTS using the Apache SVN and got 1.9.7, then how do I upgrade it to the lates long time support version? It seems I would have to dig into Apache internals etc, which is not my forte... Ubuntu 16 was upgraded to Ubuntu 18 LTS not so long ago and SVN survived without problems. Windows 16 server main SVN server: -- Here I used the VisualSVN installer VisualSVN-Server-3.6.4-x64.msi two years ago and got SVN 1.9.7 But upgrading this to a later version seems like a dangerous endeavour when I read about it on their site... Apparently one gets to 1.10.6 with the newest upgrade. I cannot afford even a low probability chance of failure since this server is company mission critical. What dangers will I encounter if I leave everything as is? Best Regards, Bo Berglund email: bo.bergl...@gmail.com
SVN version - confused about support
I am managing 2 svn servers, one on Windows 16 server (VisualSVN) and one on Ubuntu Server 18.04 LTS (Apache SVN) which is used as a mirror of the first using svnsync. On my Windows 7 dev laptop I installed the Collabnet command line svn back when I started using SVN. These are all running 1.9.7 Now I am setting up a new laptop with Windows 10 and I have installed the Collabnet command line svn for use as a client. The offered download was 1.12.2-1, which is higher than what I had on my old laptop, so I thought it to be a safe bet. However when reading the discussion about "network connection closed" on this list I came across a reply by Nathan Hartman where he writes: "Subversion 1.12.x is no longer a supported release, since that is a 6-month Regular Release. Subversion 1.13.0 was released on October 30th and is a supported release." I did not know this and I had assumed that Collabnet would not post a release that will expire in a few months time... What am I supposed to do in order not to be stuck with a non-supported release? The servers we use have not been touched (yet)... Best Regards, Bo Berglund
Server side copy, will history be copied too?
I need to create a project in the repository where I will use files that have been worked on in different test projects. All projects are part of the same repository. So in the new project I will have both new files and files from two existing projects within the repository. I know I could export the existing files into a directory on the client and collect the old and new files here and then create the new project from this directory. But then there is no history available for the old files preceding the current time... I wonder if I will get the history along with the files if I make a server side copy: svn cp /filename /filename Best Regards, Bo Berglund
Re: Why is svn displaying ! and ? on a file
On Mon, 23 Sep 2019 14:58:58 -0400, Mark Phippard wrote: >> D:\Engineering\Projects\Subversion\HW\TcpCommTest>svn status >> ! TCPCommTest.exe >> ? TcpCommTest.exe >> >> This was an unexpected response I have not seen before... >> >> The TcpComm.exe was about 19 Mb in size before the strip and now it is 1.9 >> Mb. >> I want to commit it but for some reason there is no committable file in >> the WC dir. >> >> What to do? >> > >You essentially renamed the file when you changed the case. Subversion is >case-sensitive even if the OS is not. You could rename the back to the >original case or use the svn mv command to tell Subversion about the rename. Oh Boy! I did not see the TCP being changed to Tcp in the file name! I wonder why the strip command did that? In any case after I changed it back to TCP svn status shows the expected result! Thanks for the speedy reply! -- Bo Berglund Developer in Sweden
Why is svn displaying ! and ? on a file
I just checked out a project from SVN (1.9.7) and it took a lot of time to get the executable. This means that the exe file contains debugging symbols so I used the command strip -s to clean the exe file. Sdomehow I had forgotten this when it was committed 2 years ago. The strip worked fine and the file also works fine after the strip. Then I checked that I could commit it: D:\Engineering\Projects\Subversion\HW\TcpCommTest>svn status ! TCPCommTest.exe ? TcpCommTest.exe This was an unexpected response I have not seen before... The TcpComm.exe was about 19 Mb in size before the strip and now it is 1.9 Mb. I want to commit it but for some reason there is no committable file in the WC dir. What to do? Best Regards, Bo Berglund email: bo.bergl...@gmail.com
RE: Using a backup server as local svn handler?
Gosh, that means updating the production server as well as the Ubuntu backup server then... The production server is on Windows Server 2016 or maybe later and is using VisualSvnServer. Oh, well... Best Regards, Bo Berglund From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: den 22 augusti 2019 18:53 To: Bo Berglund Cc: Subversion Users Subject: Re: Using a backup server as local svn handler? On Thu, Aug 22, 2019 at 7:03 AM Bo Berglund wrote: It runs svn 1.9.7 as does the production server at the company. 1.9.7 has a bug related to files whose size is an exact multiple of 16,384 or 65,536 or something. I don't remember the exact details or whether that's client or server side. But you'll probably want (at least) a later 1.9.x if at all possible. I think it's this issue: https://issues.apache.org/jira/plugins/servlet/mobile#issue/SVN-4722 It's resolved in later 1.9.x.
RE: Questions about a script for regular backups
On Thu, 22 Aug 2019 09:38:02 -0400, Mark Phippard wrote: >My first choice option would be to setup a repository on a second server >and use svnsync from a post-commit hook script to sync the change. After >that, I would use svnadmin hotcopy with the new --incremental option (as of >1.8?). Dump is not a great choice for backups. > >The main advantage of svnsync is you can push the change via HTTP or SVN to >a different system where as hotcopy needs FS access so the only way to get >the repos on to a second server is if you can mount the FS via NFS or >something. That is also what I did! Our main server runs on a Windows Server on the corporate LAN. The backup server is a Linux box in a different location altogether. Both locations have fiber access to the Internet. The backup server is set up with https access (thanks to LetsEncrypt and Certbot) through the router. I have synced the servers after first loading the backup server from dump files so as not to have to use Internet bandwidth for the original data transfer. On the Windows man server I have set up a nightly task that uses svnsync to synchronize the two servers. It has been running just fine for 18 months without fail. Recommended solution. Bo Berglund
RE: Using a backup server as local svn handler?
On Thu, 22 Aug 2019 13:45:52 +0200, "Andreas Stieger" wrote: >Hello, > >> If I create a "Private" repository on this server and store my projects >> in that repository, can it interfere with the backed up repos? > >This works without issues as long as the repository names are separate. > >> AFAIK you cannot write anything in a synced repository except via >> svnsync or the backup system will break > >The granularity for this is the repository, not the server. In other words, >you can run your own repositories separate from that that are svnsynced from >another location. > >The only extra consideration that would need to be made is when using >write-through >proxying (SVNMasterURI). Merely noting for completeness that you would need an >extra Location block in your httpd configuration. But your back-up >configuration >does not include that. >http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy > >Andreas Thanks Andreas for the clarification, I thought this was probably the case but needed confirmation. And it is not set up as write-through, we do nightlies only. Regards, Bo Berglund Sweden
Using a backup server as local svn handler?
I have a fully updated Ubuntu Server 18 LTS sitting in my home LAN acting as a subversion backup server for my company via svnsync. It runs svn 1.9.7 as does the production server at the company. So I have set it up with the same repositories as on the production server (which is on Windows Server) and set these as read-only for everyone except the svnsync user. They were locally populated via dump files moved from the company . I have a nightly task on the production server, which runs svnsync for each repository on it towards my backup server. This has worked fine for 18 months now. Now I would like to also use the Ubuntu server as a versioning server for my own programming, but I don't know if that will interfere with the backup server functionality my company depends on... If I create a "Private" repository on this server and store my projects in that repository, can it interfere with the backed up repos? AFAIK you cannot write anything in a synced repository except via svnsync or the backup system will break I am not very well informed about the inner workings of subversion to make it absolutely certain that no damage will happen... Best Regards, Bo Berglund
Moving WC from one computer to another using tar?
I want to work on a project on a Raspberry Pi computer but this particular one is not networked with the svn server... I do have another RPi on the same network as the svn server so I can check out a WC to that computer via VPN access to the RPi. So I wonder if this would work: 1) Check out project on the remote RÅi accessed via VPN 2) Create a tar file of the resulting working copy 3) Transfer the tar file to my home network via FTP 4) Transfer the tar file on my local network to the target RPi 5) Unpack the wc on the target and work on the project 6) Make a tar file on the target and transfer in reverse to the RPi on the remote network 7) Commit changes from the remote RPi to teh remote svn server. Or are there some hidden tokens used to identify the client in the WC? Best Regards, Bo Berglund Sweden
RE: Svnsync with changed url and ssl certificate?
On Sun, 11 Aug 2019 22:21:24 -0500, Ryan Schmidt wrote: >> svnsync synchronize https://svn..com/svn/bosse >> https://engineering/svn/bosse >> svnsync: E175008: While handling the 'svn:sync-lock' property on >> '/svn/bosse/!svn/bln/0': >> svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit >> code 1) with output: >> Only the syncuser user may change revision properties >> >> How can I force a different svnsync user than the one apparently erroneously >> cached >> somewhere when I test svnsync on the command line? > > Ah yes. You must've told Subversion to save the username and password when > you first set it up. > Saved passwords are saved not by UUID but by URL, since it is possible for an > administrator to > set up different authentication for different URLs, even if they go to the > same repository. > > So, on the repository server where you run the batch script, you need to log > in as (or use > whatever the Windows equivalent of "sudo" is to temporarily become) whatever > operating system > user runs your svnsync batch script, and then, as that user, run svnsync or > the batch script. > It should prompt you for the password and maybe the username, which you can > enter, and tell > it to save, which it should then save, and which svnsync, when run > automatically via the batch > script as that user in the future, should be able to read and use. > Thanks, I ended up doíng this to clean up the mess I created by misinterpreting the prompts when I tried to run the svnsync command manually: I added the --sync-username parameter to the command to force the correct username: svnsync synchronize --sync-username syncuser https://svn..com/svn/bosse https://engineering/svn/bosse I then ran this command manually and was prompted for the password of user "syncuser" after which it completed successfully. Then I made a small change to a file, committed it and waited for the automated sync to run via Windows scheduler. This revision was successfully backed up via the nightly batch file so I think I am good now! Thanks again for your help! -- Bo Berglund
RE: Svnsync with changed url and ssl certificate?
On Thu, 8 Aug 2019 23:12:22 +0200, "Bo Berglund" wrote: >> Subversion keeps track of repository identities not using URLs (since URLs >> can change, and since >> you could even have multiple URLs that refer to a single repository) but >> using UUIDs which are >> assigned at repository creation time. Since the UUIDs of the master and the >> mirror aren't changing >> there shouldn't be a problem. > >Thanks a lot for your explanation! >It makes things much easier. >I have created and configured the svn domain with ddcli set up to manage the >IP updates now. >My initial test on the backup server shows that it connects properly from a >browser even using the new >domain name (same IP address). > >So I am probably good to go as soon as I have figured out how to obtain a >signed cert via certbot >without first having to open up the site to port 80 (http://) access... >I had to do that when I used certbot for my other site on the same server. >During certbot's process >it seems to need access via port 80 to validate the site location. >And I don't want to open it even for a very short time... > >But this is of course not a subversion problem, rather a certbot and apache >one. UPDATE: So now I have used certbot on the backup server to get a certificate covering the new svn. domain address. Installed it into Apache by editing the sites-available/default-ssl.conf file where the self-signed cert was defined. I used the full path to the /etc/letsencrypt/live folder where the cert was placed. After reloading apache2 everything seemed to work, like accessing the web interface of the repositories both from my local PC and from across the world where the production server is located. The padlock symbol which was previously marked as insecure is now green! I could check out a wc of a project from the backup server on the master server using the command line. BUT! Now svnsync has stopped working. I have edited the batch file that runs the backup process and replaced the subdomain "home" with "svn" in all svnsync calls. It should have updated the backup server with a single revision on a test project overnight but it did not. And when I look at the log file from the sync batch file it shows it to still be running hours afterwards. Normally it takes less than 30 min to complete depending on the number of changes to handle. Maybe it is waiting for some user input? So I looked at TaskManager and found svnsync to still be in a running state. Used TaskManager to end it. Then on a command line on the main server I issued the command at the top of the batch file to see what could have gone wrong. This is what I see: H:\>svnsync synchronize https://svn..com/svn/bosse https://engineering/svn/bosse Authentication realm: <https://svn..com:443> Subversion Repository Password for 'Bosse': * Authentication realm: <https://svn..com:443> Subversion Repository Username: bosse Password for 'bosse': * svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0': svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output: Only the syncuser user may change revision properties "syncuser" is the synchronization user I have created on the backup server to write to the repo (it is otherwise read only). It has been put into the master server as the sync user during initialization of svnsync. It is the only backup server user with write permissions. So I tried to repeat the command and planned to enter "syncuser" at the second login prompt, but this time the prompts did not re-appear so I got the error message directly: svnsync synchronize https://svn..com/svn/bosse https://engineering/svn/bosse svnsync: E175008: While handling the 'svn:sync-lock' property on '/svn/bosse/!svn/bln/0': svnsync: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) with output: Only the syncuser user may change revision properties How can I force a different svnsync user than the one apparently erroneously cached somewhere when I test svnsync on the command line? Any other suggestions?
RE: Svnsync with changed url and ssl certificate?
-Original Message- From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] Sent: den 8 augusti 2019 19:25 To: Bo Berglund Cc: Subversion Users Subject: Re: Svnsync with changed url and ssl certificate? >> On Aug 7, 2019, at 00:52, Bo Berglund wrote: >> >> I have a svn 1.9.7 system to maintain. >> The main server (on Windows Server 2016) is backed up using svnsync over the >> Internet to a backup server set up on Ubuntu Server 18 LTS. >> The backups are done using a batch file running once every night on the main >> server. >> Each repository is synced using a command line in the batch file as in the >> following example: >> >> SET SYNCCMD="C:\Program Files\VisualSVN Server\bin\svnsync.exe" >> %SYNCCMD% synchronize https://home.backupdomain.com/svn/cmp >> https://mainserver/svn/cmp >> >> (backupdomain and mainserver are placeholders for the real names) >> >> Now I am planning to change the domain part of the URL of the backup server >> to svn.backupdomain.com >> and also to change the SSL certificate on the server to a signed version >> (currently it is self-signed). >> >> My question is if the svnsync command will handle this without problems >> given that the source >> and target svn servers are the same as before, only the domain name and SSL >> certificate have changed. >> Obviously I have to edit the sync batch file on the server and replace >> "home" with "svn", >> but apart from that do I have to add/do something else? Does the SSL >> certificate change influence things? >> >> Note that each repository on the live server was initialized for sync using >> this command: >> >> svnsync initialize https://home.backupdomain.com/svn/> >> https://mainserver/svn/> --allow-non-empty --sync-username >> syncuser --sync-password [*] >> >> This indicates that the sync is initialized in each repo using the URL of >> the target, so can I just run this command again manually on all repos to >> change to the new URL? >> >> I don't want to use trial and error on a production system, hence my >> question. > Hi Bo, > > Since you're using a self-signed certificate on the backup server, you > presumably told the primary > server at some point to accept that certificate. If you change the backup > server's certificate to > one that is not self-signed, for example one issued by Let's Encrypt using > certbot, then as far > as I know you won't need to change anything on the primary server; it should > be able to verify > the new certificate using the usual methods. > > As far as I know, `svnsync initialize` should only be used in the initial > setup; you shouldn't > use it again now that the link between the master repo and its mirror has > already been set up. > > `svnsync initialize` records some revision properties in the mirror > repository's 0th revision, > so that the mirror knows what repository it's syncing from. As far as I know, > the master does > not keep any record of the fact that it is being mirrored. (You could even > have multiple mirrors > of a single master.) So the master repo does not care if you change the URL > of the mirror repo(s). > > If it were the other way around -- if the URL of the master had changed -- > then you would want > to go to each mirror and edit the svn:sync-from-url property of the mirror's > 0th revision, just > for the sake of good housekeeping. But that URL is only used if you are doing > the sync while on > the backup server and you haven't specified a master URL on the command line. > It doesn't apply > in your case since you're doing the sync on the master server. So all you > should need to change > is the URL of the backup server in the batch file on the server. > > Subversion keeps track of repository identities not using URLs (since URLs > can change, and since > you could even have multiple URLs that refer to a single repository) but > using UUIDs which are > assigned at repository creation time. Since the UUIDs of the master and the > mirror aren't changing > there shouldn't be a problem. Thanks a lot for your explanation! It makes things much easier. I have created and configured the svn domain with ddcli set up to manage the IP updates now. My initial test on the backup server shows that it connects properly from a browser even using the new domain name (same IP address). So I am probably good to go as soon as I have figured out how to obtain a signed cert via certbot without first having to open up the site to port 80 (http://) access... I had to do that when I used certbot for my other site on the same server. During certbot's process it seems to need access via port 80 to validate the site location. And I don't want to open it even for a very short time... But this is of course not a subversion problem, rather a certbot and apache one.
Svnsync with changed url and ssl certificate?
I have a svn 1.9.7 system to maintain. The main server (on Windows Server 2016) is backed up using svnsync over the Internet to a backup server set up on Ubuntu Server 18 LTS. The backups are done using a batch file running once every night on the main server. Each repository is synced using a command line in the batch file as in the following example: SET SYNCCMD="C:\Program Files\VisualSVN Server\bin\svnsync.exe" %SYNCCMD% synchronize https://home.backupdomain.com/svn/cmp https://mainserver/svn/cmp (backupdomain and mainserver are placeholders for the real names) Now I am planning to change the domain part of the URL of the backup server to svn.backupdomain.com and also to change the SSL certificate on the server to a signed version (currently it is self-signed). My question is if the svnsync command will handle this without problems given that the source and target svn servers are the same as before, only the domain name and SSL certificate have changed. Obviously I have to edit the sync batch file on the server and replace "home" with "svn", but apart from that do I have to add/do something else? Does the SSL certificate change influence things? Note that each repository on the live server was initialized for sync using this command: svnsync initialize https://home.backupdomain.com/svn/ https://mainserver/svn/ --allow-non-empty --sync-username syncuser --sync-password [*] This indicates that the sync is initialized in each repo using the URL of the target, so can I just run this command again manually on all repos to change to the new URL? I don't want to use trial and error on a production system, hence my question. Best Regards, Bo Berglund email: bo.bergl...@gmail.com
Changing domain for backup svn server...
About 2 years ago I have created an SVN a setup where the production server runs VisualSvn 3.7 (using svn 1.9.7 I believe) on Windows Server 16. For backup I have set up another svn server on an Ubuntu Server 18 LTS and I am using svnsync nightly to replicate all changes from the production server to the backup. This backup server sits in my home with a 250/100 fiber connection to the Internet so it is plenty fast even though very far away from the production server. As the svnsync is done over the Internet I have opened the SSL port on the backup server's network router and pointed it towards the Ubuntu server. On the production system I have used a dynamic dns domain to point to the backup system. This has worked fine but there are two issues I am not happy about: 1) The dynamic domain name starts with "home", which is what I already had. But I think I would rather have a svn.mydomain.com type address.. So I have created it and also set up a refresh of its address on the actual backup server so it points to the same address as "home" does. Question 1: --- What do I need to do on the production server to let svnsync use the new domain address? Note that it will reach the exact same entry point on the backup server as it does now so the unique ID:s of the svn repositories will nbot be affected. But I guess since the URL will be a bit different something needs to be fixed... Is there something special to handle? 2) The backup server installation uses a self-signed ssl certificate... My backup server was set up when I did not know I could get a signed certificate via Certbot and now I don't really know how to change it into a signed cert. When I set up svn on Ubuntu I just followed the steps and in that chain there was a cert generation followed by self-signing it. Question 2: --- What would be my best approach to change the cert to a certbot provided self-signed one? Will the cert change affect the above mentioned svnsync process? --- Bo Berglund
Re: Basic usage surprise, update does not retrieve new files....
On Fri, 12 Apr 2019 21:13:42 +0200, Bo Berglund wrote: >Surprise! >Only a single file was retrieved and this was a common file used by >both the original project and the Linux project. >No sign of the Linux project files at all! > >Aren't files added on a workstation and committed there supposed to be >retrieved when another workstation performs an update on the same >project? > >What can have gone wrong here? Wrong Depth setting on the WC... >What can I look for on either the Windows or Linux end? svn info showed amongst other things: Revision: 977 Node Kind: directory Schedule: normal Depth: empty <=== Not good Last Changed Author: bosse Last Changed Rev: 977 Remedy: --- svn update --set-depth infinity After this: svn info ... Node Kind: directory Schedule: normal Last Changed Author: bosse Last Changed Rev: 977 Note: No longer Depth: empty and the missing files appeared! -- Bo Berglund Developer in Sweden
Basic usage surprise, update does not retrieve new files....
I have a Freepascal project I develop on both Windows and Linux. I started in Windows and when I wanted to make a version for Linux I checked out the Windows project to Linux. Then I worked on the files over there. The specific project files for linux were added in Linux and committed to svn. They can be viewed via the web interface in a browser so they are definitely there. Today I chose to go back to Windows and wanted to have the files from the project in Linux too. So I issued the command: svn update in the project dir on Windows. Surprise! Only a single file was retrieved and this was a common file used by both the original project and the Linux project. No sign of the Linux project files at all! Aren't files added on a workstation and committed there supposed to be retrieved when another workstation performs an update on the same project? What can have gone wrong here? What can I look for on either the Windows or Linux end? Note: I only use svn via the command line on both Windows and Linux. -- Bo Berglund Developer in Sweden
Re: My server crashed during update, how to handle svn repositories on new installation?
On Sun, 07 Apr 2019 17:11:49 +0200, Bo Berglund wrote: >I have an Ubuntu Server 16.04.2 LTS that is running Apache Subversion >1.9.7 (r1800392). Total size of repositories is 5.5 GB. > >Today I was going to upgrade the Ubuntu server to version 18.04.2 as >suggested when I logged in to the server (using SSH). > >But it went south on me, the do-release-upgrade process chugged along >until it suddenly disappeared from my monitor. Turns out something >went really bad with the upgrade, but all data files seem to be OK. >Except when booting the server goes into PANIC mode. I have now solved the problem as described in this document: https://www.ostechnix.com/how-to-fix-broken-ubuntu-os-without-reinstalling-it/ I used an Ubuntu Server 16.04.6 DVD to reach the install console where I could select Repair... Reinstalled the GRUB loader and then used the command shell to do the commands described in the document above. Apparently apt believed it was on 18.04 already so all fixes and repairs were done towards the upgraded verson. At the end when I exited the shell and commanded a system reboot all went well and now I have a working 18.04.2 system with all the special setups I had done still working! So I am happy! -- Bo Berglund Developer in Sweden
Re: My server crashed during update, how to handle svn repositories on new installation?
On Sun, 7 Apr 2019 18:10:45 -0400, Mark Phippard wrote: >> Where are the svn configurations saved such that I can apply these as >> well when I eventually re-install subversion? >> Basically, what settings do I need to find and back up so I can >> restore the exact same server after Ubuntu has been re-installed? > >There is no absolute answer because it is possible to store them anywhere, >but if you are talking about Apache configuration, the standard location >would be in /etc/httpd OK, I have already tar-ed up the entire /etc dir, so any file there would be contained in the tar file. :-) -- Bo Berglund Developer in Sweden
Re: My server crashed during update, how to handle svn repositories on new installation?
On Sun, 7 Apr 2019 11:27:19 -0400, Mark Phippard wrote: >If you have a tar or other backup you ought to be fine once they are restored. >You just need to make sure the permissions on the files are set properly once >you restore. For example, you do not want them owned by root or something. >So just chown -R the whole thing to the user:group that you run your svnsync >process as and you should be fine. Thanks, I have just done the tar-ing of the different repositories in /var/lib/svn. There are 11 of them. When I tar the directories doesn't then the Linux permissions also get copied into the tar file? I use sudo tar -czf svn_reponame.tgz /var/lib/svn/reponame to do this from a rescue terminal on the not quite dead server. Then I have copied these tgz files over to a USB thumb drive too. They are a total of 5.4 GB in size. Where are the svn configurations saved such that I can apply these as well when I eventually re-install subversion? Basically, what settings do I need to find and back up so I can restore the exact same server after Ubuntu has been re-installed? I am not really used to Linux, the settings for different programs seem to be stored in such diverse places -- Bo Berglund Developer in Sweden
My server crashed during update, how to handle svn repositories on new installation?
I have an Ubuntu Server 16.04.2 LTS that is running Apache Subversion 1.9.7 (r1800392). Total size of repositories is 5.5 GB. It was installed a year ago approximately. This server is acting as a backup to the main repository using svnsync. Today I was going to upgrade the Ubuntu server to version 18.04.2 as suggested when I logged in to the server (using SSH). So I was going to use the week-end to upgrade. But it went south on me, the do-release-upgrade process chugged along until it suddenly disappeared from my monitor. Turns out something went really bad with the upgrade, but all data files seem to be OK. Except when booting the server goes into PANIC mode. So I figured I would have to extract the disk data to an USB disk or similar, before installing Ubuntu Server 16.04.2LTS from scratch again. In the console which I can reach using an earlier kernel I can tar up the SVN repositories, so if I can just move them out of the PC as tgz files I would be OK. Once that has been done and Ubuntu is reinstalled I need to attach the files from the original disk to the svn server. How would that be best done? If I extract the archives into /var/lib/svn would svn be OK with the files then? Does it do some magic like marking the files in any way that will make the sync from the main server fail? Or is the ID of a repository stored in some of the files inside the repo database? The svnsync function relies in some way on the repository ID, right -- Bo Berglund Developer in Sweden
RE: How to safely upgrade svn on ubuntu 16?
>>>Is this a client or a server? >> It is a server. >> >>Ubuntu Server 16.04 LTS headless installation. >>Its purpose is as a backup for the main server through nightly svnsync. >> >If you are only running svnsync from this server there should be no issue >in letting it upgrade the Subversion package along with the OS distribution. > >If you are also running the Apache SVN server, I would not expect any issues >but after the upgrade you might just want to review that it is still working >as expected and perhaps be prepared to review the Apache conf. I doubt there >are any major Apache changes to be concerned about though. OK, thanks. In fact this server is on the receiving end of a svnsync command started at the main SVN server on a Windows Server 16 machine across the Atlantic. It runs VisualSVN and the backups are triggered in the middle of the night via a Scheduled Task on Windows. I guess that if I upgrade the Ubuntu server the svn connection needed for svnsync will not be destroyed and therefore the sync operations would run OK. The VisualSVN server will probably also need an update but on Windows that is a different complexity altogether...
RE: How to safely upgrade svn on ubuntu 16?
>> On Feb 27, 2019, at 5:24 PM, Bo Berglund wrote: >> >>> I am running svn on Ubuntu 16.04.6 LTS. >>> It reports the following: >>> $ svn --version >>> svn, version 1.9.3 (r1718519) >>> compiled Aug 10 2017, 16:59:15 on x86_64-pc-linux-gnu >>> >>> The Ubuntu machine acts as a backup for a Windows 16 based VisualSvn >>> server running at a separate location. >>> Backups are performed using nightly svnsync commands via the Internet. >>> >>> The Ubuntu machine and svn were setup for this purpose about a year >>> ago and since then Ubuntu has been kept updated using apt upgrade and >>> apt dist-upgrade as adviced on the login screen when I regularly check >>> in via PuTTY. >>> >>> But it seems like svn is not being touched by these operations >>> >>> So what is the advice on what to do in order to at least get to the >>> latest 1.9 stable release of svn on this machine? >>> It seems like that would be 1.9.10... >>> >>> Since this is a production backup server I am reluctant to risk >>> breaking it, obviously. >> >> More questions after some extensive googling: >> >> On terminal (PuTTY) login this headless server machine displays: >> >> New release '18.04.2 LTS' available. >> Run 'do-release-upgrade' to upgrade to it. >> >> Since the svn I use is from the Xenial repository (for Ubuntu 16.04 >> LTS) maybe there will never be a later svn version there? >> >> If so is it safe to use do-release-upgrade (as suggested on login) to >> move from Ubuntu 16.04.6 LTS to 18.04.2 LTS instead in order to switch >> to a newer ubuntu update repository and therefore get subversion >> upgradeable to later versions? >> >> Will I risk damaging the svn installation or repository data by doing >> so? >> Or do I have any other option? > >Is this a client or a server? > >If the client then generally it is very safe to do. The only question might >be if you are using any other SVN clients besides the command line that are >using the SVN libraries. Even then it is generally very safe but worth knowing >more details. > >If it is a server it is also fairly safe. The main concern would be the Apache >server version change from the upgrade and whether the Apache conf needed to >be >adjusted. > >Mark > It is a server. Ubuntu Server 16.04 LTS headless installation. Its purpose is as a backup for the main server through nightly svnsync. (Replying directly by email since the Gmane news server seems to have stopped forwarding my messages.)
Re: How to safely upgrade svn on ubuntu 16?
On Wed, 27 Feb 2019 08:44:25 +0100, Bo Berglund wrote: >I am running svn on Ubuntu 16.04.6 LTS. >It reports the following: >$ svn --version >svn, version 1.9.3 (r1718519) > compiled Aug 10 2017, 16:59:15 on x86_64-pc-linux-gnu > >The Ubuntu machine acts as a backup for a Windows 16 based VisualSvn >server running at a separate location. >Backups are performed using nightly svnsync commands via the Internet. > >The Ubuntu machine and svn were setup for this purpose about a year >ago and since then Ubuntu has been kept updated using apt upgrade and >apt dist-upgrade as adviced on the login screen when I regularly check >in via PuTTY. > >But it seems like svn is not being touched by these operations > >So what is the advice on what to do in order to at least get to the >latest 1.9 stable release of svn on this machine? >It seems like that would be 1.9.10... > >Since this is a production backup server I am reluctant to risk >breaking it, obviously. More questions after some extensive googling: On terminal (PuTTY) login this headless server machine displays: New release '18.04.2 LTS' available. Run 'do-release-upgrade' to upgrade to it. Since the svn I use is from the Xenial repository (for Ubuntu 16.04 LTS) maybe there will never be a later svn version there? If so is it safe to use do-release-upgrade (as suggested on login) to move from Ubuntu 16.04.6 LTS to 18.04.2 LTS instead in order to switch to a newer ubuntu update repository and therefore get subversion upgradeable to later versions? Will I risk damaging the svn installation or repository data by doing so? Or do I have any other option? -- Bo Berglund Developer in Sweden
How to safely upgrade svn on ubuntu 16?
I am running svn on Ubuntu 16.04.6 LTS. It reports the following: $ svn --version svn, version 1.9.3 (r1718519) compiled Aug 10 2017, 16:59:15 on x86_64-pc-linux-gnu The Ubuntu machine acts as a backup for a Windows 16 based VisualSvn server running at a separate location. Backups are performed using nightly svnsync commands via the Internet. The Ubuntu machine and svn were setup for this purpose about a year ago and since then Ubuntu has been kept updated using apt upgrade and apt dist-upgrade as adviced on the login screen when I regularly check in via PuTTY. But it seems like svn is not being touched by these operations So what is the advice on what to do in order to at least get to the latest 1.9 stable release of svn on this machine? It seems like that would be 1.9.10... Since this is a production backup server I am reluctant to risk breaking it, obviously. -- Bo Berglund Developer in Sweden
Re: How to commit only top level files?
On Tue, 6 Nov 2018 23:13:08 +0100, Branko ?ibej wrote: >> The problem I have is in the definition of "target"... > >"Target" is any file or directory that you tell the command to operate >on. For example, when you say: > > svn commit foo bar > >"foo" and "bar" are targets for 'svn commit'. You can omit explicit >targets for some commands svn commit is one of them in which case >the implicit target is the current directory; so, > > svn commit > >means exactly the same as > > svn commit . > > >> I am doing the operation inside the top level of the WC tree (where >> the .svn dir is located). >> The command will be: >> svn ci --depth >> >> What should I use as argument so that only the changed files in the >> current dir are committed? > > svn commit --depth files > >(or 'svn commit --depth files .') will only commit /files/ that in the >current directory. On the other hand, > > svn commit --depth immediates > >will commit files /and/ directories, but will not recurse into the >directories. Basically this means that changed files and property >changes on directories in the current dir will be committed, but nothing >else. > > >> empty does not work for me because the dir is NOT empty > >That's not what '--depth empty' means. It means "commit only the target >itself", so if the target is a directory, it will only commit any >property changes on that directory. > > >> files does not work because I don't understand what "file children" is > >Files within the target direcory. > >> immediates clearly would include subdirs too? > >Yes, but nothing inside those subdirs. > >> infinity not what I want, full recursion... >> >> Tried to google but I only get hits that deal with the opposite, how >> to exclude file commit. >> >> I want to block recursion into subdirectories... > >You want either 'svn commit --depth files' or 'svn commit --depth >immediates', depending on whether or not property changes on directories >matter. > >-- Brane Thanks for the complete explanation! I used --depth files and got what I wanted! -- Bo Berglund Developer in Sweden
Re: How to commit only top level files?
On Tue, 6 Nov 2018 15:19:06 -0500, Alfred von Campe wrote: > >> On Nov 6, 2018, at 15:11, Bo Berglund wrote: >> >> What should I use as argument so that only the changed files in the >> current dir are committed? > >Will the -N [non-recursive] option work for you? > Non-recursive would work, but is it really available for svn ci? It is not mentioned in the svnbook http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.commit.html -- Bo Berglund Developer in Sweden
How to commit only top level files?
I have a project where I want to commit the modified sources in the top folder but want to prevent it from recursing to subdirectories, which hold the compiled binaries. These are only to be committed when the sources are stable. I looked at svn ci with the --depth argument, but I do not understand the wording of the docs: http://svnbook.red-bean.com/en/1.7/svn.ref.svn.html#svn.ref.svn.sw.depth it says: --depth ARG Instructs Subversion to limit the scope of an operation to a particular tree depth. ARG is one of empty (only the target itself), files (the target and any immediate file children thereof), immediates (the target and any immediate children thereof), or infinity (the target and all of its descendantsfull recursion). The problem I have is in the definition of "target"... I am doing the operation inside the top level of the WC tree (where the .svn dir is located). The command will be: svn ci --depth What should I use as argument so that only the changed files in the current dir are committed? empty does not work for me because the dir is NOT empty files does not work because I don't understand what "file children" is immediates clearly would include subdirs too? infinity not what I want, full recursion... Tried to google but I only get hits that deal with the opposite, how to exclude file commit. I want to block recursion into subdirectories... -- Bo Berglund Developer in Sweden
Re: Best way to correct directory error?
On Sun, 12 Aug 2018 03:26:38 -0400, Nico Kadel-Garcia wrote: >In practice, I may have a long-term better idea for you. Split the >projects, each into their own much smaller repository with only its >own history. This is also the only good chance you'r likely to get, to >*discard* inappropriate binary files, files that accidentally were >stored with passwords, and seriously obsolete branches.tags, or even >projects altogether. Our SVN repositories are organized in a similar way as the previous CVS repositories were. I migrated the lot back in January and I had to decide on the organization back then. We had about 10 CVS repositories each with a lot of modules (= top level directories). Each repository had different permission settings to allow some employees access while denying all others. To implement a per-project repository in SVN would lead to a management nightmare as far as I could tell, first during migration and second in operation when developers would add their projects to SVN. How could I enforce the permission restrictions in such a scenario? So this is why I have this structure: repository1 |- project1 ||- trunk ||- tags ||- branches |- project2 ||- trunk etc... repository2 |- project1 ||- trunk ||- tags ||- branches |- project2 ||- trunk etc... -- Bo Berglund Developer in Sweden
Best way to correct directory error?
A collegue has put a project into our SVN server. The server is organized such that every project is a top level directory. This shall contain subdirs trunk, tags and branches. Trunk is where the sources for the project live. Now he has put his project sources into: /Projectname/trunk/Projectname What is the best way to fix this so it will reside in /Projectname/trunk instead? - Check out /Projectname/trunk and receive subdir Projectname - Move to trunk on client - svn mv Projectname/* ./* - svn ci -m "log message" Or after checkout: - Move to trunk/Projectname on client - svn mv * ../ - mv .. - svn ci -m "log message" I don't want to mess up the repository, so that is why I am asking.... -- Bo Berglund Developer in Sweden
Re: svnsync fails to replicate large revision
On Fri, 13 Jul 2018 20:01:13 +, Colin Foster wrote: >I'm not sure if this is a "bug", a "configuration issue", or simply a network >issue. FWIW: Back in March I set up a svnsync replication of our main SVN repository (which is on Windows Server 16 with SVN 1.9.7) across the Internet. I also got hit by a failure to initialize the synced repository properly, it stopped in the middle at a revision that contained a *lot* of stuff. It seemed to be caused by the slow network speed and a timeout in the svnsync transfer. So I switched approach and created a dump of the source repository, then transferred the dump file (rather big at several GB even in compressed form) over the Internet to the target server, which is running Ubuntu Server 16.04-3 LTS) and SVN 1.9.3. After loading the dump file into the target I could start svnsync with command switches that recognized the target server as already populated from the dump so no data for existing revisions needed to be transfered. I don't remember the exact commands I used but searching the svn users list for my discussion of this dated 2018-03-24 to 29 with subject: "Subversion 1.9.7 server on Windows, advice on setting up svnsync?" might help you too. I now have a working backup system using svnsync. -- Bo Berglund Developer in Sweden
Re: Hook script common environment variables
On Tue, 19 Jun 2018 18:39:09 -0500, Tom Browder wrote: >The docs mention one can use a common hook environment for multiple repos >but so far I cant find an example of that or any more details. I have >looked at the example hook.env file but I dont see any reference to global >env vars. http://svnbook.red-bean.com/en/1.8/svn.reposadmin.create.html#svn.reposadmin.hooks.configuration.ex-1 and maybe: http://svnbook.red-bean.com/en/1.8/svn.advanced.confarea.html -- Bo Berglund Developer in Sweden
Re: Problem setting Notepad++ as log message editor for svn 1.9.7 (Windows7)
On Fri, 8 Jun 2018 14:57:06 -0400, Mark Phippard wrote: >On Fri, Jun 8, 2018 at 12:29 PM, Bo Berglund wrote: > >> I have configured Notepad++ to be the editor for the log message. >> This works OK if Notepad++ is *not* running at the time of an svn >> operation. Then Npp pops up an edit window and I can enter the message >> as expected and then close the window. >> >> But when Npp is already running with one or several tabs with other >> file edits, then Npp pops up with an edit tab inside the already >> running window. >> Now svn will not recognize my log message but instead pop up the >> following on the command line: >> >> Log message unchanged or not specified >> (a)bort, (c)ontinue, (e)dit: >> >> If I choose c then the commit proceeds but there is no log message... >> >> How can I use Notepad++ as the log editor and not have this happening? >> >> > >See: >http://notes.richdougherty.com/2012/05/using-notepad-to-edit-subversion-commit.html > >You need to add the -multiInst option. > >The full set of options you should add actually seems to be: -multiInst >-noPlugin -nosession -notabbar Thanks, I added the -multiInst option to make the config file line read: editor-cmd = "C:\Programs\Notepad++\notepad++.exe -multiInst" And now it seems to work at least for my use case even though I did not throw in the other switches. Thanks for your help! -- Bo Berglund Developer in Sweden
Problem setting Notepad++ as log message editor for svn 1.9.7 (Windows7)
I have configured Notepad++ to be the editor for the log message. This works OK if Notepad++ is *not* running at the time of an svn operation. Then Npp pops up an edit window and I can enter the message as expected and then close the window. But when Npp is already running with one or several tabs with other file edits, then Npp pops up with an edit tab inside the already running window. Now svn will not recognize my log message but instead pop up the following on the command line: Log message unchanged or not specified (a)bort, (c)ontinue, (e)dit: If I choose c then the commit proceeds but there is no log message... How can I use Notepad++ as the log editor and not have this happening? -- Bo Berglund Developer in Sweden
