Re: Bugreport: invalid xml file produced by: svn log --xml --verbose --use-merge-history --search "msg1"
On Wed, Dec 13, 2017 at 8:50 AM, Paul Hammant wrote: > I would say yes, but I am an end user too. The good news is that it feels > like a bug that would be easy to solve. +1 -- Johan
cvs2svn - is dump file platform portable?
While investigating the methods to use when migrating our CVS repositories from CVS to SVN I converted one of the smaller CVS respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu Server 16.04.3 machine. Then I moved the dump file over to the target Windows 2016 Server where I had just installed VisualSVN and tried to use the VisualSVN GUI tool to load the dump into a new repository. But it threw an error box displaying: "Could not convert ' 2' into a number" Next I tried to load it from the command line: svnadmin load \SVNREPOS\bosse < bosse-dump ' into a number04: Could not convert ' 2 Strange output and it stopped. Same basic error... Then I went back to the Ubuntu machine and loaded the dump file into svn there and it worked just fine. So I made a dump from the newly loaded repository on Ubuntu and went back to Windows 2016 and repeated the load command with the new dump file. This time it worked without errors! So my question is: Is the dump file format from cvs2svn platform dependent such that it will not work if moved from Linux to load it on Windows? It seems like dump files from svn itself work when moved between platforms. (Both systems have svn 1.9.7) -- Bo Berglund Developer in Sweden
error message
Error message when attempting to update subversion on local machine. Any help would be much appreciated, Thanks, Sal --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.1\ext\subversion\subversion\libsvn_wc\update_editor.c' line 3042: assertion failed (status != svn_wc__db_status_normal) --- OK --- STATEMENT OF CONFIDENTIALITY AND PRIVILEGE This e-mail transmission, which includes its attachments, if any, is intended for a particular addressee(s) and may contain confidential and/or attorney-client or work product privileged material. If you are not the named addressee, or if this e-mail transmission has been addressed to you in error, or it is otherwise not clear that you are the intended recipient (or his or her authorized agent), you are hereby notified that you have received this e-mail transmission in error and that any review, disclosure, distribution, dissemination, copying, printing, maintaining, saving, or other use of this e-mail transmission is strictly prohibited. Delivery of this e-mail transmission to any person other than the intended recipient(s) is not intended in any way to waive privilege or confidentiality. If you have received this e-mail transmission in error, please notify me immediately by reply e-mail and permanently delete the e-mail transmission and its attachments, if any. This e-mail transmission and any attachments are believed to have been sent free of any virus or other defect that might affect any computer system into which it is received and opened. It is, however, the recipient's responsibility to ensure that the e-mail transmission and any attachments are virus free, and MedHOK accepts no responsibility for any damage that may in any way arise from their use. Thank you.
Re: cvs2svn - is dump file platform portable?
On 13.12.2017 15:33, Bo Berglund wrote: > While investigating the methods to use when migrating our CVS > repositories from CVS to SVN I converted one of the smaller CVS > respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu > Server 16.04.3 machine. > > Then I moved the dump file over to the target Windows 2016 Server > where I had just installed VisualSVN and tried to use the VisualSVN > GUI tool to load the dump into a new repository. But it threw an error > box displaying: > "Could not convert ' 2' into a number" > > Next I tried to load it from the command line: > > svnadmin load \SVNREPOS\bosse < bosse-dump > ' into a number04: Could not convert ' 2 > > Strange output and it stopped. Same basic error... > > Then I went back to the Ubuntu machine and loaded the dump file into > svn there and it worked just fine. > > So I made a dump from the newly loaded repository on Ubuntu and went > back to Windows 2016 and repeated the load command with the new dump > file. > This time it worked without errors! > > So my question is: > Is the dump file format from cvs2svn platform dependent such that it > will not work if moved from Linux to load it on Windows? It should be. If it's not, then it's not a Subversion dump file and there's a bug in cvs2svn. -- Brane
Upgrading a very old SVN version
Hello, My company had been working with a very old version of SVN - 1.3.2 from 2006 They are planning to upgrade to the latest version - currently 1.9.7 I realize that an upgrade from 1.3.2 to 1.9.7 is a serious jump. * Are there any know issues doing an upgrade such as this? * Is this full upgrade recommended or should the upgrade be done in stages until we reach 1.9.7? * We don't want to lose the check-in history of all the files. Any guidance would be great! Thank you, Joanne
Re: cvs2svn - is dump file platform portable?
On Wed, Dec 13, 2017 at 03:33:45PM +0100, Bo Berglund wrote: > While investigating the methods to use when migrating our CVS > repositories from CVS to SVN I converted one of the smaller CVS > respositories to an svn dump file using cvs2svn 2.5.0 on an Ubuntu > Server 16.04.3 machine. > > Then I moved the dump file over to the target Windows 2016 Server > where I had just installed VisualSVN and tried to use the VisualSVN > GUI tool to load the dump into a new repository. But it threw an error > box displaying: > "Could not convert ' 2' into a number" > > Next I tried to load it from the command line: > > svnadmin load \SVNREPOS\bosse < bosse-dump > ' into a number04: Could not convert ' 2 > > Strange output and it stopped. Same basic error... > > Then I went back to the Ubuntu machine and loaded the dump file into > svn there and it worked just fine. > > So I made a dump from the newly loaded repository on Ubuntu and went > back to Windows 2016 and repeated the load command with the new dump > file. > This time it worked without errors! > > So my question is: > Is the dump file format from cvs2svn platform dependent such that it > will not work if moved from Linux to load it on Windows? > > It seems like dump files from svn itself work when moved between > platforms. > (Both systems have svn 1.9.7) > > -- > Bo Berglund > Developer in Sweden How did you copy the dump file from Windows to Ubuntu? Beware of Windows tools which change line endings! I have seen that happen before and it destroyed dump files. Zip the dump file before copying it away from windows to make sure it does not get mangled on the way.
Re: cvs2svn - is dump file platform portable?
On Wed, 13 Dec 2017 17:22:48 +0100, Stefan Sperling wrote: > >How did you copy the dump file from Windows to Ubuntu? cvs2svn was executed on Ubuntu. The dump file was gzipped and then moved via FTP *to* Windows. >Beware of Windows tools which change line endings! >I have seen that happen before and it destroyed dump files. Yeah, I have seen these as well but not for repository files. Scripts, though, are vulnerable. >Zip the dump file before copying it away from windows to make >sure it does not get mangled on the way. So I have two dump files: bosse-dump made by cvs2svn loads fine in svn on Ubuntu but errors out on Windows bosse.dump made by svnadmin dump on Ubuntu based on the above load. Gzipped and FTP:ed to Windows, loads fine using svnadmin load on windows. Unfortunately it is not possible to run a compare on them because their sources are different and so diffs are everywhere, I believe. Probably a cvs2svn problem -- Bo Berglund Developer in Sweden
Re: error message
On Dec 13, 2017, at 09:09, Sal Palumbo wrote: > Error message when attempting to update subversion on local machine. > Any help would be much appreciated, > Thanks, > Sal > > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > with as much information as possible about what > you were trying to do. > But please first search the mailing list archives for the error message > to avoid reporting the same problem repeatedly. > You can find the mailing list archives at > http://subversion.apache.org/mailing-lists.html > > Subversion reported the following > (you can copy the content of this dialog > to the clipboard using Ctrl-C): > > In file > 'D:\Development\SVN\Releases\TortoiseSVN-1.8.1\ext\subversion\subversion\libsvn_wc\update_editor.c' > line 3042: assertion failed (status != svn_wc__db_status_normal) I guess first try updating to a newer version of TortoiseSVN. Version 1.8.1 is from mid-2013 and probably many bugs have been fixed since then.
Re: Upgrading a very old SVN version
On Dec 13, 2017, at 10:01, Joanne Giammo wrote: > My company had been working with a very old version of SVN – 1.3.2 from 2006 > They are planning to upgrade to the latest version – currently 1.9.7 > > I realize that an upgrade from 1.3.2 to 1.9.7 is a serious jump. > • Are there any know issues doing an upgrade such as this? > • Is this full upgrade recommended or should the upgrade be done in > stages until we reach 1.9.7? > • We don’t want to lose the check-in history of all the files. > > Any guidance would be great! 1.x version are supposed to be compatible with one another. I would just try it. Dump your 1.3.2 repo, load it into a new 1.9.7 repo, see what happens.
Re: Apache svn - how to customize rendering?
On Dec 11, 2017, at 17:58, Bo Berglund wrote: > What really "docker" is eludes me however, could you expand a bit on > it? It must be something general since I noticed this at the bottom of > Dockerfile > #sudo apt-get install docker.io I clicked that link "docker.io", then clicked "What is Docker?" https://www.docker.com/what-docker Maybe that helps.
RE: Upgrading a very old SVN version
Hello Ryan, Thank you for your quick reply. 1.x version are supposed to be compatible with one another. I would just try it. Dump your 1.3.2 repo, load it into a new 1.9.7 repo, see what happens. We will try it out then. Best Regards, Joanne -Original Message- From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] Sent: Wednesday, December 13, 2017 11:43 AM To: Joanne Giammo Cc: Subversion Users ; Jonathan Rose Subject: Re: Upgrading a very old SVN version On Dec 13, 2017, at 10:01, Joanne Giammo wrote: > My company had been working with a very old version of SVN – 1.3.2 > from 2006 They are planning to upgrade to the latest version – > currently 1.9.7 > > I realize that an upgrade from 1.3.2 to 1.9.7 is a serious jump. > • Are there any know issues doing an upgrade such as this? > • Is this full upgrade recommended or should the upgrade be done > in stages until we reach 1.9.7? > • We don’t want to lose the check-in history of all the files. > > Any guidance would be great! 1.x version are supposed to be compatible with one another. I would just try it. Dump your 1.3.2 repo, load it into a new 1.9.7 repo, see what happens.
Re: Upgrading a very old SVN version
On Wed, Dec 13, 2017 at 11:01 AM, Joanne Giammo wrote: > My company had been working with a very old version of SVN – 1.3.2 from > 2006 > > They are planning to upgrade to the latest version – currently 1.9.7 > > > > I realize that an upgrade from 1.3.2 to 1.9.7 is a serious jump. > >- Are there any know issues doing an upgrade such as this? >- Is this full upgrade recommended or should the upgrade be done in >stages until we reach 1.9.7? >- We don’t want to lose the check-in history of all the files. > > Subversion has good compatibility so I recommend doing this in stages. 1. Upgrade your server to 1.9.7 but have it just serve the same repositories as before You do not have to upgrade your repositories and the server should work with them fine. This gives you time to make sure everything is OK with the new version and you have all of the right binaries and it is configured correctly etc. 2. When it is convenient, you can upgrade your repositories using a dump and load (and you can do this one at a time) - Subversion 1.5 introduced merge tracking and it required your repository to be upgrade to enable the feature. So even though you have installed 1.9.7, you will not be able to start using merge tracking until you upgrade the repository format - Many Subversion releases offer improvements in how the repository data is stored. Usually, it is just using less disk space but also sometimes it offers performance improvements just by how the data is stored Going through a dump/load process will allow you to upgrade to the latest version. Step 1 is very safe and easy and you are unlikely to encounter problems. Step 2 is more of an unknown. There are various bugs that existed in older versions that allowed some data to be stored in repository in format that was in violation of what was intended. Newer versions of Subversion detect and enforce those rules better. If you have any of this data you might get errors when loading the repository to the new format. If you do, you can search the archives of this list to find answers on how to proceed. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Upgrading a very old SVN version
On Wed, Dec 13, 2017 at 2:27 PM, Mark Phippard wrote: > On Wed, Dec 13, 2017 at 11:01 AM, Joanne Giammo wrote: > >> >> My company had been working with a very old version of SVN – 1.3.2 from >> 2006 >> >> They are planning to upgrade to the latest version – currently 1.9.7 >> >> >> >> I realize that an upgrade from 1.3.2 to 1.9.7 is a serious jump. >> >> Are there any know issues doing an upgrade such as this? >> Is this full upgrade recommended or should the upgrade be done in stages >> until we reach 1.9.7? >> We don’t want to lose the check-in history of all the files. > > > Subversion has good compatibility so I recommend doing this in stages. > > 1. Upgrade your server to 1.9.7 but have it just serve the same repositories > as before > > You do not have to upgrade your repositories and the server should work with > them fine. This gives you time to make sure everything is OK with the new > version and you have all of the right binaries and it is configured > correctly etc. Seriously, *do not* do this with your live service. It is possible to really, really mess up your working repository with untested update structures from such an old version. There have been numerous structural changes since 1.3.x, especially EOL handlinng for comments. Schedule downtime to avoid split brain, Do a full filesystem backup to a host running Subversion 1.9.x, and test with *that* if you have to. > 2. When it is convenient, you can upgrade your repositories using a dump > and load (and you can do this one at a time) Do you see any compelling reason not to do dump on one, obsolete and load on another? > - Subversion 1.5 introduced merge tracking and it required your repository > to be upgrade to enable the feature. So even though you have installed > 1.9.7, you will not be able to start using merge tracking until you upgrade > the repository format > - Many Subversion releases offer improvements in how the repository data is > stored. Usually, it is just using less disk space but also sometimes it > offers performance improvements just by how the data is stored > > Going through a dump/load process will allow you to upgrade to the latest > version. Amen. > Step 1 is very safe and easy and you are unlikely to encounter problems. > Step 2 is more of an unknown. There are various bugs that existed in older > versions that allowed some data to be stored in repository in format that > was in violation of what was intended. Newer versions of Subversion detect > and enforce those rules better. If you have any of this data you might get > errors when loading the repository to the new format. If you do, you can > search the archives of this list to find answers on how to proceed. Jumping that far between versions, I'd *expect* trouble. The repository is basically a file-system based database. I'd urge *not* updating that in place. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/
Re: cvs2svn - is dump file platform portable?
On Wed, Dec 13, 2017 at 11:31 AM, Bo Berglund wrote: > On Wed, 13 Dec 2017 17:22:48 +0100, Stefan Sperling > wrote: > >> >>How did you copy the dump file from Windows to Ubuntu? > > cvs2svn was executed on Ubuntu. The dump file was gzipped and then > moved via FTP *to* Windows. FTP can manipulate line endings, depending on its settings. I urge you to stop trying to change two things in one step, namely the version of Subversion and the OS or binaries for Subversion at the same time. If you have to do loads and conversions on the Windows server, use the CygWin version of subversion, which is much more consistent and robust in its Subversion server behavior. (That is "in my experience".) >>Beware of Windows tools which change line endings! >>I have seen that happen before and it destroyed dump files. > Yeah, I have seen these as well but not for repository files. Scripts, > though, are vulnerable. > >>Zip the dump file before copying it away from windows to make >>sure it does not get mangled on the way. > > So I have two dump files: > bosse-dump made by cvs2svn > loads fine in svn on Ubuntu but errors out on Windows > > bosse.dump made by svnadmin dump on Ubuntu based on the above load. > Gzipped and FTP:ed to Windows, loads fine using svnadmin load on > windows. > > Unfortunately it is not possible to run a compare on them because > their sources are different and so diffs are everywhere, I believe. > > Probably a cvs2svn problem > > > -- > Bo Berglund > Developer in Sweden
Re: cvs2svn - is dump file platform portable?
On Wed, 13 Dec 2017 17:23:16 -0500, Nico Kadel-Garcia wrote: >> cvs2svn was executed on Ubuntu. The dump file was gzipped and then >> moved via FTP *to* Windows. > >FTP can manipulate line endings, depending on its settings. That is one reason why I compressed the file (gzip) before sending it by FTP, and the second is to reduce the transfer size... >I urge you to stop trying to change two things in one step, namely the version >of >Subversion and the OS or binaries for Subversion at the same time. I don't understand this comment... I am not changing anything here except the platform, both on Linux and Windows I run svn 1.9.7 so there is no difference there. >If you have to do loads and conversions on the Windows server, use the >CygWin version of subversion, which is much more consistent and robust >in its Subversion server behavior. (That is "in my experience".) The reason I brought in Ubuntu 16 Linux is to do the conversion from CVS to SVN on a linux platform (which is less troublesome in general). So I used cvs2svn 2.5.0 to make the actual conversion to the dump file. But what I did not do at first was to load the cvs2svn dump on the Linux side svn and then make a new dump from that. The reason is that each repository took upwards of an hour to convert by cvs2svn and importing the dump to svn was another delay of the same size as was the subsequent dump. So instead of looking at conversion time T I would have 3*T if the dump file is indeed not compatible to Windows svn and I have to "wash" it through Linux svn Since it loads just fine on Linux I assume that whatever problem there is is in the cvs2svn conversion on Linux making "something" that is not liked by svn on Windows even though they are the same version. I will make more tests tomorrow, I have used the smallest dump file so far in my testing in order not to waste so much time. The 3 largest dumps are 5-7 GB each. -- Bo Berglund Developer in Sweden
Re: Bugreport: invalid xml file produced by: svn log --xml --verbose --use-merge-history --search "msg1"
Thanks. Bug is reported: https://issues.apache.org/jira/browse/SVN-4711
