Subversion Exception!
--- 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.9.4\ext\subversion\subversion\libsvn_client\cleanup.c' line 227: assertion failed (svn_dirent_is_absolute(dir_abspath)) --- OK --- Mit freundlichen Grüßen / Best Regards Heinz-Norbert Wiesmann Teamleiter / team leader Entwicklung / Development RIB Information Technologies AG Ein Unternehmen der RIB Gruppe Vaihinger Straße 151 70567 Stuttgart tel.: +49(711)7873-322 fax: +49(711)7873-231 mobil: - mailto: heinz-norbert.wiesm...@rib-software.com http://www.rib-software.com -- HRB 23983 Stuttgart Vorstand: Marcus Lörz Christian Höntschke Helmut Schmid Aufsichtsrat: Michael Sauer (Vorsitzender) -- Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte umgehend den Absender. Danach löschen Sie bitte diese E-Mail. Das unerlaubte Benutzen, Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. --
Re: A couple thousand mp3 files (this is not spam I swear )
Hi, On 8/13/2016 2:56 AM, Adam Jensen wrote: My primary concerns are related to any potential file corruption, any data duplication, and/or any excessive network or disk I/O (other than the expected load of direct data communication). Just to have this mentioned: Be aware that the working copy (aka: the checked out data of the repository) will have a 2x storage requirement on the data since it will keep a copy of the pristine version of the file in addition to the "actual" file. If this is a concern for your use-case, you could export the files and only use a working copy in cases where you need to commit or reorder files. To clarify: This is purely a client side storage requirement. It does not apply to the storage requirements on the server side. -- Regards, Stefan Hett
Re: Subversion Exception!
> On Aug 16, 2016, at 7:26 AM, Wiesmann, Heinz Norbert > wrote: > > --- > 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. What were you 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.9.4\ext\subversion\subversion\libsvn_client\cleanup.c' > line 227: assertion failed (svn_dirent_is_absolute(dir_abspath)) > --- > OK > ---
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/16/2016 09:17 AM, Stefan Hett wrote: > Just to have this mentioned: Be aware that the working copy (aka: the > checked out data of the repository) will have a 2x storage requirement > on the data since it will keep a copy of the pristine version of the > file in addition to the "actual" file. The type of system that I am imagining might typically have several terabytes of instrumentation data in a repository[1]. Various client machines might need to check-out a few gigabytes or a few hundred gigabytes at a time to run data analysis (automated compute jobs) or to perform a study (scientist/human-interest). [1]: Version control isn't a requirement in this use-case/hypothetical-system. Sophisticated access control is much more of a concern. Mandatory audit trails and distributed contract based data handling are examples of more relevant architectural characteristics. I am currently looking at the possibility of using Subversion (in a non-traditional, off-label fashion) to bootstrap a [very] simplified demonstration-of-concept type of setup. My current data-set is only about 25GB and growing at a rate of about 1GB/week. A desktop server and laptop client shouldn't have any storage space problems (in this case as a small demonstration system). > If this is a concern for your use-case, you could export the files and > only use a working copy in cases where you need to commit or reorder files. By "export the files" do you mean something like an NFS share of the repository, thus bypassing svnserve and the check-in/check-out process? That seems like a clever possibility worth remembering, but for now the system I am currently building/imagining is headed in a different direction. > To clarify: This is purely a client side storage requirement. It does > not apply to the storage requirements on the server side. To reduce network load, are there any client-side caching options for Subversion? Does the svn program account for the files already in the working copy (on the local disk) and avoid transferring those files over the network during a subsequent check-out [that requires those files]? Is it possible to clone or mirror all or part of a Subversion repository? This probably isn't relevant to Subversion, but in the system I am imagining it might be reasonable for clients to check-out data-sets via torrent connections with other full/partial repositories.
My mixed revision working copy remains after a 'svn update'
My mixed revision working copy remains mixed revision after multiple attempts with 'svn update'.Here's the final status output: [linux] >> svn st -u X vobs/common/cpCommon X vobs/common/dclCommon X vobs/ots/broadcom/BCM_SDK_6.4.11 X vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API X vobs/ots/osm4/Target/PldImages/lim400g_1 X vobs/ots/osm4/Tests/framework/tl1probe/mteraiv X vobs/ots/uboot/u-boot-2009.06 X vobs/ots/uboot/u-boot-2013.01.01 X vobs/ots/wrlplat/tlab_qemuppc X vobs/ots/wrlplat/tlab_xeoncore50 X vobs/ots/wrlplat/tlabqoriq50_small X vobs/prod Status against revision: 13673 Performing status on external item at 'vobs/ots/osm4/Target/PldImages/lim400g_1': Status against revision: 87468 Performing status on external item at 'vobs/ots/uboot/u-boot-2009.06': Status against revision: 475 Performing status on external item at 'vobs/common/cpCommon': Status against revision: 101 Performing status on external item at 'vobs/common/dclCommon': Status against revision: 101 Performing status on external item at 'vobs/ots/uboot/u-boot-2013.01.01': Status against revision: 475 Performing status on external item at 'vobs/ots/wrlplat/tlab_xeoncore50': Status against revision: 539 Performing status on external item at 'vobs/prod': Status against revision: 1290 Performing status on external item at 'vobs/ots/broadcom/BCM_SDK_6.4.11': Status against revision: 614 Performing status on external item at 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv': X vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library Status against revision: 2575 Performing status on external item at 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library': Status against revision: 65663 Performing status on external item at 'vobs/ots/wrlplat/tlabqoriq50_small': Status against revision: 672 Performing status on external item at 'vobs/ots/wrlplat/tlab_qemuppc': Status against revision: 403 Performing status on external item at 'vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API': Status against revision: 73002 [Linux] >> svnversion 475:13673S There are two 'uboot' svn:externals pegged at 475 so I deleted the parent directory (i.e. rm -rf vobs/ots/uboot) and did another 'svn update' but that didn't clean it up. The svnversion is still reporting 475:13673S. The svn client version is 1.8.14. Thanks in advance for any insights. Brent Brent
Re: Blank line in historic svn:mergeinfo
Johan Corveleyn wrote on Thu, Aug 11, 2016 at 15:46:54 +0200: > svndumptool (if you want, you might be able to visually verify if it's > fixed by opening the dumpfile before and after with a text editor (but > caution: do not edit by hand, there are checksums and content-lengths; > it's easy to corrupt the dumpfile)). Some text editors corrupt binary files that they open, even if no editing operation is done. The safe thing is either to use a pager (such as /usr/bin/more or /usr/bin/less) or to edit a copy of the dumpfile.
Re: My mixed revision working copy remains after a 'svn update'
> On Aug 16, 2016, at 2:54 PM, webster.br...@rogers.com wrote: > > My mixed revision working copy remains mixed revision after multiple attempts > with 'svn update'. > Here's the final status output: > > [linux] >> svn st -u > Xvobs/common/cpCommon > Xvobs/common/dclCommon > Xvobs/ots/broadcom/BCM_SDK_6.4.11 > Xvobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API > Xvobs/ots/osm4/Target/PldImages/lim400g_1 > Xvobs/ots/osm4/Tests/framework/tl1probe/mteraiv > Xvobs/ots/uboot/u-boot-2009.06 > Xvobs/ots/uboot/u-boot-2013.01.01 > Xvobs/ots/wrlplat/tlab_qemuppc > Xvobs/ots/wrlplat/tlab_xeoncore50 > Xvobs/ots/wrlplat/tlabqoriq50_small > Xvobs/prod > Status against revision: 13673 > > Performing status on external item at > 'vobs/ots/osm4/Target/PldImages/lim400g_1': > Status against revision: 87468 > > Performing status on external item at 'vobs/ots/uboot/u-boot-2009.06': > Status against revision:475 > > Performing status on external item at 'vobs/common/cpCommon': > Status against revision:101 > > Performing status on external item at 'vobs/common/dclCommon': > Status against revision:101 > > Performing status on external item at 'vobs/ots/uboot/u-boot-2013.01.01': > Status against revision:475 > > Performing status on external item at 'vobs/ots/wrlplat/tlab_xeoncore50': > Status against revision:539 > > Performing status on external item at 'vobs/prod': > Status against revision: 1290 > > Performing status on external item at 'vobs/ots/broadcom/BCM_SDK_6.4.11': > Status against revision:614 > > Performing status on external item at > 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv': > X > vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library > Status against revision: 2575 > > Performing status on external item at > 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library': > Status against revision: 65663 > > Performing status on external item at 'vobs/ots/wrlplat/tlabqoriq50_small': > Status against revision:672 > > Performing status on external item at 'vobs/ots/wrlplat/tlab_qemuppc': > Status against revision:403 > > Performing status on external item at > 'vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API': > Status against revision: 73002 > > [Linux] >> svnversion > 475:13673S > > There are two 'uboot' svn:externals pegged at 475 so I deleted the parent > directory (i.e. rm -rf vobs/ots/uboot) and did another 'svn update' but that > didn't clean it up. The svnversion is still reporting 475:13673S. > > The svn client version is 1.8.14. > > Thanks in advance for any insights. Presumably, those externals were deliberately pegged to those revisions, so this is behaving as intended. If you want those externals to point to newer versions, change the revision in the svn:externals property, then svn update again.
Re: A couple thousand mp3 files (this is not spam I swear )
> On Aug 16, 2016, at 2:13 PM, Adam Jensen wrote: > > On 08/16/2016 09:17 AM, Stefan Hett wrote: >> Just to have this mentioned: Be aware that the working copy (aka: the >> checked out data of the repository) will have a 2x storage requirement >> on the data since it will keep a copy of the pristine version of the >> file in addition to the "actual" file. > > >> If this is a concern for your use-case, you could export the files and >> only use a working copy in cases where you need to commit or reorder files. > > By "export the files" do you mean something like an NFS share of the > repository, thus bypassing svnserve and the check-in/check-out process? > That seems like a clever possibility worth remembering, but for now the > system I am currently building/imagining is headed in a different direction. He means avoid the 2x disk use by using "svn export" instead of "svn checkout". >> To clarify: This is purely a client side storage requirement. It does >> not apply to the storage requirements on the server side. > > To reduce network load, are there any client-side caching options for > Subversion? Does the svn program account for the files already in the > working copy (on the local disk) and avoid transferring those files over > the network during a subsequent check-out [that requires those files]? Of course Subversion only transfers changes. > Is it possible to clone or mirror all or part of a Subversion repository? svnsync > This probably isn't relevant to Subversion, but in the > system I am imagining it might be reasonable for clients to check-out > data-sets via torrent connections with other full/partial repositories.
I need help in SVN mv and SVN cp
Hi , Please someone guide me how to generate svn diff which can capture svn mv or svn cp operations carried out in a workspace? So when i use svn patch, it should delete old file and replace it with new file resulted from svn mv. Also is there any way to see dummy commit? try dummy commit but it should not actually commit into repo. My email ID is rags@gmail.com Regards, Raghav
