Re: Single-commit import with properties and SVN 1.7
On Monday 22 August 2011, Markus Schaber wrote: > We need to add a new directory including files and properties to a > subversion repository "in-place". There are two more things that came to mind that could help you solve your problem: 1. You could try to "svn switch" the workspace where you added the file tree to its own child. In theory, the metadata should be locally present already, so no network traffic is required. If SVN is smart enough to re-use the existing files, this could be a very cheap operation. 2. You could create the directory remotely, then check it out and add the content there. This requires two commits, which isn't ideal, but by reversing the steps it avoids importing the content and then checking out the whole content again. Cheers! Uli -- ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html FAQ: http://subversion.apache.org/faq.html Docs: http://svnbook.red-bean.com/ ** 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: Single-commit import with properties and SVN 1.7
On Tue, 23 Aug 2011 09:30:43 +, Ulrich Eckhardt wrote: ... > 1. You could try to "svn switch" the workspace where you added the file tree > to its own child. In theory, the metadata should be locally present already, > so no network traffic is required. If SVN is smart enough to re-use the > existing files, this could be a very cheap operation. I would bet that svn 1.6 doesn't do this optimization, and I doubt that 1.7 will avoid refetching the data by finding out beforehand that copies of them are already in the pristine store. The latter would be somewhat clever, however. Would speed up 'normal' switches as well, at the expense of more space being used for the pristine store (the latter being the case for 1.7 anyway -- no pristine GC). Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
AW: Single-commit import with properties and SVN 1.7
Hi, Uli, Von: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] > On Monday 22 August 2011, Markus Schaber wrote: > > We need to add a new directory including files and properties to a > > subversion repository "in-place". > > There are two more things that came to mind that could help you solve your > problem: > > 1. You could try to "svn switch" the workspace where you added the file > tree to its own child. In theory, the metadata should be locally present > already, so no network traffic is required. If SVN is smart enough to re- > use the existing files, this could be a very cheap operation. Nice idea. I will try to check whether Subversion can handle that. > 2. You could create the directory remotely, then check it out and add the > content there. This requires two commits, which isn't ideal, but by > reversing the steps it avoids importing the content and then checking out > the whole content again. This is exactly what I described as our current workaround for SVN 1.7, or did I miss something? 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: Single-commit import with properties and SVN 1.7
On Tuesday 23 August 2011, Markus Schaber wrote: > This is exactly what I described as our current workaround for SVN 1.7, > or did I miss something? No, you didn't. Sorry for the noise... Uli -- ML: http://tortoisesvn.tigris.org/list_etiquette.html FAQ: http://tortoisesvn.net/faq ** 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. **
AW: Single-commit import with properties and SVN 1.7
Hi, Von: Markus Schaber [mailto:m.scha...@3s-software.com] > Von: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] > > On Monday 22 August 2011, Markus Schaber wrote: > > > We need to add a new directory including files and properties to a > > > subversion repository "in-place". > > > > There are two more things that came to mind that could help you solve > > your problem: > > > > 1. You could try to "svn switch" the workspace where you added the > > file tree to its own child. In theory, the metadata should be locally > > present already, so no network traffic is required. If SVN is smart enough to > > reuse the existing files, this could be a very cheap operation. > > Nice idea. I will try to check whether Subversion can handle that. It seems that this idea works, at least with TortoiseSVN. It needs a connection to the repository, but it displays "116 Bytes transferred" so I think it did not actually transfer the pristine data. Thanks for the suggestion! 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: How to solve svnadmin load "File already exists" error?
I tried to edit a 5 Gb file on a Linuxserver we have with vi, it took some 30 minutes to open the file but it did work! The format is quite simple : a revision starts with the string : Revision-number: Just delete all the lines until the next Revision-number: And the revision is removed from the dump. I am not quite sure if you need to renumber the revisions afterwards though, but I don't think so. There is a problem though if what you delete is referenced later on in the dump, then the load will fail. Geir Note : All inquiries regarding Subversion, MKS and general Development servers should be directed to "EDB SourceControl System" > -Original Message- > From: Dennis Jones [mailto:djo...@grassvalleysoftware.com] > Sent: 21. august 2011 22:12 > To: Engebakken Geir > Subject: Re: How to solve svnadmin load "File already exists" error? > > - Original Message - > From: "Engebakken Geir" > To: "Daniel Shahaf" ; "Dennis Jones" > > Cc: > Sent: Sunday, August 21, 2011 12:22 PM > Subject: RE: How to solve svnadmin load "File already exists" error? > > > Isnt it possible to just remove the N records from the dump file and > restart > the svnadmin load? I seem to think I have tried that with success > before. > > You are the second person to suggest this. There are two problems with > that > approach, both of which *can* be solved, but will take some effort: > > 1) The file is 5GB. I haven't been able to find an editor that can > handle a > file that big. I can solve this by splitting the file into smaller > pieces > and editing the piece containing the bad revision and splicing them > back > together afterwards. Just a pain to do. > > 2) I don't understand the file format. What are the beginning and end > markers for a particular revision? > > - Dennis
Re: How to solve svnadmin load "File already exists" error?
> I tried to edit a 5 Gb file on a Linuxserver we have with vi, it took some > 30 minutes to open the file but it did work! > > The format is quite simple : a revision starts with the string : > > Revision-number: > > Just delete all the lines until the next > > Revision-number: > > > And the revision is removed from the dump. I am not quite sure if you need > to renumber the revisions afterwards though, but I > don't think so. > > There is a problem though if what you delete is referenced later on in the > dump, then the load will fail. Unfortunately, this did not work. I was able to split the file into smaller, editable pieces, cut out the bad revision, and paste it all back together. However, when I attempted to start loading at the revision following the bad one, I got checksum mismatches. So I tried again with a new repository and tried to load a new dump file with everything in it except the bad revision (so it started from 0 again), and this time it failer even earlier than before, but again with a checksum mismatch. Ugh. Subversion is a great tool overall, but getting this particular process to work has been utterly frustrating and ridiculously slow, not to mention error-prone, with no real explanation for the failing behaviors. - Dennis
Re: How to solve svnadmin load "File already exists" error?
On 8/23/2011 10:38 AM, Dennis Jones wrote: And the revision is removed from the dump. I am not quite sure if you need to renumber the revisions afterwards though, but I don't think so. There is a problem though if what you delete is referenced later on in the dump, then the load will fail. Unfortunately, this did not work. I was able to split the file into smaller, editable pieces, cut out the bad revision, and paste it all back together. However, when I attempted to start loading at the revision following the bad one, I got checksum mismatches. So I tried again with a new repository and tried to load a new dump file with everything in it except the bad revision (so it started from 0 again), and this time it failer even earlier than before, but again with a checksum mismatch. Ugh. Subversion is a great tool overall, but getting this particular process to work has been utterly frustrating and ridiculously slow, not to mention error-prone, with no real explanation for the failing behaviors. Is there any chance of getting the original repository to upgrade or to get a file-level copy so you could do a server upgrade on the copy? It is always painful to try to work around bugs that have long been fixed. -- Les Mikesell lesmikes...@gmail.com
Re: Proxy authentication with Negotiate uses wrong host
Stefan Sperling schrieb: > On Mon, Aug 22, 2011 at 01:41:59PM +0200, 1983-01...@gmx.net wrote: >> no, I did not set that value neither on Windows nor on FreeBSD. Using Negotiate does require setting a username. That's what the credentials cache is for. > > You expect svn to get the proxy username from the ~/.subversion/auth > cache? That expection is not unreasonable, but it is not what the > implementation does, as far as I undestand (see > subversion/libsvn_ra_neon/session.c). Stefan, any news on this? I made some digging in the subversion and neon code and notices some interesting and odd stuff. If you take a look at the aforementioned session.c in line 865 [1] you'll see that the code is correct, Negotiate auth is added if no proxy_username is set. So my assumption was correct. It should work out-of-the box. Digging deeper into that file shows that Negotiate auth for servers (not proxy servers) is done only when the server is servered with HTTPS [2]. I took a look back at neon_auth.h (define NE_AUTH_NEGOTIATE) [3] and it constantly says that Digest and Negotiate are unsecure and require a secure connection which is complete non-sense. Kerberos was designed to provide security in unsecure networks. This is definitively wrong documentation. What do you say? Mike [1] http://svn.apache.org/viewvc/subversion/tags/1.6.17/subversion/libsvn_ra_neon/session.c?view=markup#l865 [2] http://svn.apache.org/viewvc/subversion/tags/1.6.17/subversion/libsvn_ra_neon/session.c?view=markup#l852 [3] http://svn.webdav.org/repos/projects/neon/tags/0.29.6/src/ne_auth.h
Re: Proxy authentication with Negotiate uses wrong host
On Tue, Aug 23, 2011 at 10:47:35PM +0200, Michael-O wrote: > I made some digging in the subversion and neon code and notices some > interesting and odd stuff. > > If you take a look at the aforementioned session.c in line 865 [1] > you'll see that the code is correct, Negotiate auth is added if no > proxy_username is set. So my assumption was correct. It should work > out-of-the box. Yes, you're right. It seems I misread this and didn't notice the 'else' part which also enables Negotiate auth. Sorry. > Digging deeper into that file shows that Negotiate auth for servers > (not proxy servers) is done only when the server is servered with > HTTPS [2]. Having taken a brief glance it looks as if you can override this via the http-auth-types option in ~/.subversion/servers. Have you tried that? > I took a look back at neon_auth.h (define > NE_AUTH_NEGOTIATE) [3] and it constantly says that Digest and > Negotiate are unsecure and require a secure connection which is > complete non-sense. Kerberos was designed to provide security in > unsecure networks. This is definitively wrong documentation. Not sure if this documentation is generally wrong. It can depend on what kinds of assumptions people make about security. Please verify this question with the neon devs.
Re: How to solve svnadmin load "File already exists" error?
2011/8/23 Dennis Jones : >> I tried to edit a 5 Gb file on a Linuxserver we have with vi, it took some >> 30 minutes to open the file but it did work! >> >> The format is quite simple : a revision starts with the string : >> >> Revision-number: >> >> Just delete all the lines until the next >> >> Revision-number: >> >> >> And the revision is removed from the dump. I am not quite sure if you need >> to renumber the revisions afterwards though, but I >> don't think so. >> >> There is a problem though if what you delete is referenced later on in the >> dump, then the load will fail. > > > Unfortunately, this did not work. I was able to split the file into > smaller, editable pieces, cut out the bad revision, and paste it all back > together. However, when I attempted to start loading at the revision > following the bad one, I got checksum mismatches. Apparently you cannot edit the dump file with vi. It is mentioned somewhere in the SVN Book that the dump just looks like a textual file but actually it is binary. It explicitly does not recommend editing it in a text editor. (So the problem with checksums that you are facing is documented). Can you generate a dump file for a range of revisions? Looking at [1] you can specify a range of revisions to be dumped by rsvndump tool. [1] http://rsvndump.sourceforge.net/ Have you tried to compare old and new repository at revision 3186. E.g. do a checkout and compare whether files and folders all exist and are the same? Especially the files and folders touched by r3187. Best regards, Konstantin Kolinko
Seeking talented developers to work on Subversion clients and merge
We are seeking developers to work on Subversion clients, Subversion merge, and related innovations in open source subversion. We are looking for experts and hackers to work on our distributed team, writing open source code, full time or part time. * Subversion merge fix * EasySVN -- a backrgound process to replicate files, similar to Dropbox * Packaging these items into TortoiseSVN for distribution * SVN clients for Mac and Linux that include these innovations The skills that we can use include: * Subversion core development * Subversion client development * Experience or computer science knowledge of merge processes and algorithms outside of Subversion ABOUT ASSEMBLA: Assembla accelerates software development by providing tools for distributed teams. We currently work with 40 full time and part time developers and team leads in 15 countries. Please contact us by selecting "Apply" on one of the following job forms: 1) *C/C++ developer with knowledge about code merge algorithms* (https://www.assembla.com/search/show_job/884) 2) *C++ developer to create custom Subversion clients* (https://www.assembla.com/search/show_job/862)
