Re: subversion upgrade from 1.4.6 to 1.7
Am 21.09.2011 06:28, schrieb PR: of course client side push to all the dev desktops with subversion 1.7 will also be done simultaneously. This is not necessary, you can switch one client first, then other clients and finally switch the server. BTW: 1.7 is still not yet released, though it's really really close now, AFAICT. is it really that simple? Yes, your approach is correct. I'd suggest testing that though, e.g. by using a separate system. I had read about previous upgrades to 1.6 (from 1.4.x or 1.5 ) and that the dump and load was mandatory ... This is not mandatory, but the organisation of the repository changed to the better in recent versions, so a dump and reload is strongly suggested. In particular things like merge tracking have improved, IIRC. I did try a quick repo tar and bring up in the new 1.7 rc3 subversion server environment, access with file protocol and a local checkout and verified all the subversion magic in place with the top level .svn, log with diff option, the amazing checkout speeds and hence am really excited with the prospect of quick move. The only fact that left me a bit puzzled was that the repository format still showed 5, inspite of doing a svnadmin verify with subversion 1.7 rc3 with no error reported, ... Well, an "svnadmin verify" hopefully doesn't modify the repository. Good luck! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: subversion upgrade from 1.4.6 to 1.7
On Wed, Sep 21, 2011 at 2:36 AM, Ulrich Eckhardt wrote: > Am 21.09.2011 06:28, schrieb PR: >> >> of course client side push to all the dev desktops with >> subversion 1.7 will also be done simultaneously. > > This is not necessary, you can switch one client first, then other clients > and finally switch the server. BTW: 1.7 is still not yet released, though > it's really really close now, AFAICT. > > >> is it really that simple? > > Yes, your approach is correct. I'd suggest testing that though, e.g. by > using a separate system. > > >> I had read about previous upgrades to 1.6 (from 1.4.x or 1.5 ) and that >> the >> dump and load was mandatory ... > > This is not mandatory, but the organisation of the repository changed to the > better in recent versions, so a dump and reload is strongly suggested. In > particular things like merge tracking have improved, IIRC. A dump / load when upgrading Subversion has never been mandatory. There may have been added benefits from doing so, but old repositories will continue to function under new versions of Subversion. When upgrading Subversion installations, I'd encourage you to read the relevant release notes: http://subversion.apache.org/docs/release-notes/ >> I did try a quick repo tar and bring up in the new 1.7 rc3 subversion >> server >> environment, access with file protocol and a local checkout and verified >> all >> the subversion magic in place with the top level .svn, log with diff >> option, >> the amazing checkout speeds and hence am really excited with the prospect >> of >> quick move. >> >> The only fact that left me a bit puzzled was that the repository format >> still showed 5, inspite of doing a svnadmin verify with subversion 1.7 rc3 >> with no error reported, ... This is no server-side format changes between 1.6 and 1.7. Since you are moving from 1.4 to 1.7, however, you may want to run 'svnadmin upgrade' on the new repositories, to enable new features available since 1.4. This should all be covered in the relevant release notes. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: subversion upgrade from 1.4.6 to 1.7
Am 21.09.2011 11:00, schrieb Hyrum K Wright: [repository upgrade] Since you are moving from 1.4 to 1.7, however, you may want to run 'svnadmin upgrade' on the new repositories, to enable new features available since 1.4. Wait: I was under the impression that this enabled new features _as far as possible_, but that some extensive internal changes (sharding? reverse deltas? something?) actually required a dump/load cycle to make full use of, or am I mistaken? Greetings! Uli ** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden. E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **
Re: subversion upgrade from 1.4.6 to 1.7
Guten Tag PR, am Mittwoch, 21. September 2011 um 06:28 schrieben Sie: > The only fact that left me a bit puzzled was that the repository format > still showed 5, inspite of doing a svnadmin verify with subversion 1.7 rc3 > with no error reported, ... This is because svnadmin verify doesn't change anything and only replacing the binaries won't either upgrade your repositories. Upgrading them is a separate process, where you have to options: svnadmin upgrade will just upgrade the repositories to the most current version your binaries are capable of, but only with doing the most minimal work needed, therefore you won't benefit of the new improvements with the old versions. svnadmin dump & load will upgrade you repositories with improvements for all your old versions, for example less occupied space due to enabled rep-sharing. svnadmin upgrade is pretty fast, svnadmin dump & load won't be in most cases, of course depending on your repository sizes. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: subversion upgrade from 1.4.6 to 1.7
2011/9/21 Ulrich Eckhardt : > Am 21.09.2011 11:00, schrieb Hyrum K Wright: > [repository upgrade] >> >> Since you are moving from 1.4 to 1.7, however, you may want to run >> 'svnadmin >> upgrade' on the new repositories, to enable new features available >> since 1.4. > > Wait: I was under the impression that this enabled new features _as far as > possible_, but that some extensive internal changes (sharding? reverse > deltas? something?) actually required a dump/load cycle to make full use of, > or am I mistaken? You're right: sharding may require a load to enable (though I seem to recall a script somewhere would would do it to a live repo). Things like packing can be enabled with a simple upgrade of the repository. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
SVN dump & load vs ftp
Besides the time what is the advantage of svn dump & load vs ftp for moving a Repository to a new location ? What type of "clean-up" might take place to reduce disk space when using the dump & load method vs ftp ?
Re: SVN dump & load vs ftp
On Wed, Sep 21, 2011 at 7:26 AM, Phil Pinkerton wrote: > Besides the time what is the advantage of svn dump & load vs ftp for moving > a Repository to a new location ? > > What type of "clean-up" might take place to reduce disk space when using > the dump & load method vs ftp ? Dump/Load of a repository using the same format repository should give the same results. If you are moving to a newer format repository where there have been changes to reduce space then you might see a reduction. For example, repositories created with SVN 1.6 only stores files whose contents are identical once. This can potentially save space depending on how many identical files you have. The repository format is not always changed to reduce space, so you really would have to look at what the new format brings for changes. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: SVN dump & load vs ftp
Guten Tag Phil Pinkerton, am Mittwoch, 21. September 2011 um 13:26 schrieben Sie: > What type of "clean-up" might take place to reduce disk space when > using the dump & load method vs ftp ? This depends on the version of your old repository and the version installed on the new location. Newer versions of Subversion, 1.6+ I think, but I'm not sure, use and enable rep-sharing by default, for example. Rep-sharing is some kind of deduplication mechanism. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Citrix Access
Hi, I have Subversion installed on a server and access with tortoisesvn clients. Is it possible to setup and access remotely from Citrix XenApps if I move to a remote location . Thanks Nigel Smith
[no subject]
Hello: Subversion encountered a serious problem. d:\development\svn\tortoisesvn\ext\subversion\subversion\libsvn_wc\update_editor.c line 1582 assertion failed(action == svn_wc_confilict_action_edit || action = ..) wintra...@163.com 2011-09-21
subersion exception
usershello: The latest version --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list (users@subversion.apache.org) 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 'C:\Users\kueng\nightlybuilds\latest\TortoiseSVN\ext\subversion\subversion\libsvn_wc\update_editor.c' line 1582: assertion failed (action == svn_wc_conflict_action_edit || action == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) wintra...@163.com 2011-09-21
Network overlay icons
Hi, I was wondering if there is a way to enable network overlay icons for all machine users instead of each user needing to modify there settings? Regards Adam Hird * To view the terms under which this email is distributed, please go to http://www2.hull.ac.uk/legal/disclaimer.aspx *
RE: Network overlay icons
> -Original Message- > From: Adam Hird [mailto:a.h...@hull.ac.uk] > Sent: 21 September 2011 09:38 > To: users@subversion.apache.org > Subject: Network overlay icons > > Hi, > > I was wondering if there is a way to enable network overlay > icons for all machine users instead of each user needing to > modify there settings? > > Regards > > Adam Hird > Subversion does not provide any overlays. You would be better to take this up with whoever supports whichever client you are using... As you do not provide any information as to your platform or client or version, I'm afraid that is all I can suggest for now. ~ mark c
Re: subersion exception
2011/9/20 韦余涛 : > usershello: > The latest version > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > (users@subversion.apache.org) > 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 > > 'C:\Users\kueng\nightlybuilds\latest\TortoiseSVN\ext\subversion\subversion\libsvn_wc\update_editor.c' > line 1582: assertion failed (action == svn_wc_conflict_action_edit || action > == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) > wintra...@163.com > 2011-09-21 Please read the whole message. Especially the parts where it asks you to include as much information as possible about what you're trying to do (you have provided none), and to search the mailing list archives (http://www.google.com/search?q=update_editor.c+line+1582)
AW: Citrix Access
Hi, Nigel, Von: Nigel at IT Works [mailto:ni...@itworkscompany.com] > I have Subversion installed on a server and access with tortoisesvn clients. Is it possible to setup and access remotely from Citrix XenApps if I move to a remote location What exactly do you want to setup or access remotely? If you want to setup (maintain, configure?) the server remotely, it depends on the server OS which method is used best for remote administration. To access the server remotely, you do not need any special XenApps or other solution - SVN servers are able to serve remote machines as well as local ones (using SSL encryption or VPN to secure it). You can simply install TortoiseSVN on your local machine, and access the remote server then. If you want to access TortoiseSVN remotely: I did such things using VNC and Windows RDP, so it should work with other solutions, too. But remember when using those methods, your whole working environment should be virtualized - it will not be possible to use a remote-accessed TortoiseSVN to update a local working copy on your machine without further tricks. Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: subversion exception
Thank you for your report! > Please take the time to report this on the Subversion mailing list > (users@subversion.apache.org) with as much information as possible > about what you were trying to do. Please consider the last part of this sentence, too... > But please first search the mailing list archives for the error message > to avoid reporting the same problem repeatedly. ...after of course considering this part of the message. ;) As it is now, nobody can do much with this little information. Greetings! Uli ** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden. E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **
Re: subversion upgrade from 1.4.6 to 1.7
Hyrum K Wright wrote on Wed, Sep 21, 2011 at 05:44:33 -0500: > 2011/9/21 Ulrich Eckhardt : > > Am 21.09.2011 11:00, schrieb Hyrum K Wright: > > [repository upgrade] > >> > >> Since you are moving from 1.4 to 1.7, however, you may want to run > >> 'svnadmin > >> upgrade' on the new repositories, to enable new features available > >> since 1.4. > > > > Wait: I was under the impression that this enabled new features _as far as > > possible_, but that some extensive internal changes (sharding? reverse > > deltas? something?) actually required a dump/load cycle to make full use of, > > or am I mistaken? > > You're right: sharding may require a load to enable (though I seem to > recall a script somewhere would would do it to a live repo). > > Things like packing can be enabled with a simple upgrade of the repository. > Except that sharding is a prerequisite to packing.
Request for a successfully configured or compiled 'client' of Apache Subversion 1.7.0-rc3 release for AIX
Have tried to configure every release so far of Apache Subversion 1.7.0 for client with the same error given for apr_util. Also have varied the configuration trying to satisfy the error with each attempt on our AIX test servers. None have ever completed without this error. If there is any correction for our configuration or a completed compiled version for AIX we would appreciate a link to it. We do appreciate all the responses the group has provided for our numerous attempts also. Our last base attempt at this latest version. Please note we had already successfully run the get-deps.sh for dependencies: r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-rc3 ->ls -l total 3728 -rw-rw-r--1 3300 3300 0 Sep 09 16:40 .swig_checked -rw-rw-r--1 3300 3300 94 Feb 22 2010 BUGS -rw-rw-r--1 3300 3300 187437 Sep 09 16:39 CHANGES -rw-rw-r--1 3300 3300 12956 Jun 27 11:16 COMMITTERS -rw-rw-r--1 3300 3300 64417 Jul 08 05:40 INSTALL -rw-rw-r--1 3300 3300 14214 Feb 03 2010 LICENSE -rw-rw-r--1 3300 3300 34568 Jul 16 07:50 Makefile.in -rw-rw-r--1 3300 3300593 Mar 27 23:54 NOTICE -rw-rw-r--1 3300 3300 2301 Jun 30 13:54 README -rw-rw-r--1 3300 3300 2028 Dec 07 2009 aclocal.m4 drwxr-xr-x 25 1000 1000 1536 Sep 20 14:13 apr drwxr-xr-x 19 1000 1000 1024 May 19 10:58 apr-util -rwxrwxr-x1 3300 3300 6256 Jul 04 06:24 autogen.sh drwxrwxr-x6 3300 3300 1024 Sep 09 16:41 build -rw-rw-r--1 3300 3300 568820 Sep 09 16:41 build-outputs.mk -rw-rw-r--1 3300 3300 34702 Aug 04 16:18 build.conf -rw-rw-r--1 root system16090 Sep 20 14:13 config.log -rwxrwxr-x1 root system 267 Sep 20 14:06 config.nice -rwxrwxr-x1 3300 3300 790822 Sep 09 16:41 configure -rw-rw-r--1 3300 3300 46675 Aug 17 09:01 configure.ac drwxrwxr-x4 3300 3300512 Sep 09 16:40 doc -rw-rw-r--1 3300 3300 23 Sep 09 16:41 gen-make.opts -rwxrwxr-x1 3300 3300 10604 Mar 25 2011 gen-make.py -rwxrwxr-x1 3300 3300 3444 Jun 25 20:23 get-deps.sh drwxrwxr-x7 500 cfgsoft1024 May 03 08:25 neon drwxr-xr-x6 1000 1000512 Mar 12 2011 serf drwxr-xr-x2 root system 512 May 19 09:35 sqlite-amalgamation drwxrwxr-x 33 3300 3300 1024 Sep 09 16:41 subversion drwxrwxr-x 14 3300 3300512 Sep 09 16:40 tools -rw-rw-r--1 3300 3300 27426 Jul 12 14:30 win-tests.py drwxr-xr-x 12 csi_acct perf 1536 Apr 20 2010 zlib r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-rc3 -> r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-rc3 ->export CC=/usr/vac/bin/xlc r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-rc3 ->./configure \ > --with-ssl \ > --with-zlib \ > --with-apr \ > --with-apr-util \ > --without-berkeley-db \ > --without-serf \ > --without-swig \ > --disable-nls \ > --disable-shared \ > --prefix=/usr/local/subversion configure: Configuring Subversion 1.7.0 configure: creating config.nice checking for gcc... /usr/vac/bin/xlc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /usr/vac/bin/xlc accepts -g... yes checking for /usr/vac/bin/xlc option to accept ISO C89... none needed checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking how to run the C preprocessor... /usr/vac/bin/xlc -E checking for a sed that does not truncate output... /bin/sed checking build system type... powerpc-ibm-aix5.3.0.0 checking host system type... powerpc-ibm-aix5.3.0.0 checking target system type... powerpc-ibm-aix5.3.0.0 checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking whether ln -s works... yes checking for a BSD-compatible install... /opt/freeware/bin/install -c configure: Apache Portable Runtime (APR) library configuration checking for APR... configure: error: --with-apr requires a directory or file to be provided r...@sligo.ncdc.noaa.gov:/tmp/subversion-1.7.0-rc3 ->./configure \ > --with-ssl \ > --with-zlib \ > --with-apr \ > --with-apr-util=/tmp/subversion-1.7.0-rc3/apr-util/xml/expat \ > --without-berkeley-db \ > --without-serf \ > --without-swig \ > --disable-nls
Re: Difference between Dump & Load and an FTP'd Repository ?
On Tue, Sep 20, 2011 at 6:25 PM, Phil Pinkerton wrote: > I here there are some advantage to both. > > > My primary interest to to save disk space with heavily modified > Repositories. > > What exactly get's "Cleaned-up" when doing a dump & load? > > Besides the "time" savings what is the real difference between a the 2 > methods ? > > Phil You can do updates and leave out troublesome revisions in a dump and load. The new repository also does not have the same uuid, which helps prevent "split brain" problems, which will bite you at the *worst* possible moments. Also, "ftp" is not a good tool for this: individual file transfers may fail and cause chaos. If you have to mirror a repository by file transfer, use "rsync", which preserves symlinks and hardlinks and file ownership in ways that a load/dump or simple FTP transfer can only do with considerable extra effort..
Re: SVN dump & load vs ftp
On Wed, Sep 21, 2011 at 7:44 AM, Mark Phippard wrote: > On Wed, Sep 21, 2011 at 7:26 AM, Phil Pinkerton wrote: >> Besides the time what is the advantage of svn dump & load vs ftp for moving >> a Repository to a new location ? >> >> What type of "clean-up" might take place to reduce disk space when using >> the dump & load method vs ftp ? > > Dump/Load of a repository using the same format repository should give > the same results. If you are moving to a newer format repository Dump/load does *not* reproduce hook scripts or authenticaton configuratons, that kind of repository metadata has to be mirrored separately. Even "hotcopy" doesn't handle file ownership completely. > where there have been changes to reduce space then you might see a > reduction. For example, repositories created with SVN 1.6 only stores > files whose contents are identical once. This can potentially save > space depending on how many identical files you have. The repository > format is not always changed to reduce space, so you really would have > to look at what the new format brings for changes. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ >
