visualsvn error connecting to a Subversion server with SSL client certificates
Dear list, a colleague is using Visualsvn to access a Linux-based Subversion server with SSL client certificates. It is working with TortoiseSVN, but within Visualsvn doing checkouts or commits he got a 'SSL handshake failed' error. Is anyone familiar with that settings ? Many greetings from NY Volker
Re: one doubt on subversion
Vani, subversion comes with a commandline client only. There are several Open Source and paid GUI clients out there. On Windows, I mostly use TortoiseSVN (open source) On OSX, I use Versions (paid). On Linux, I mostly use the CLI. For development, there's also several Eclipse and Visual Studio Plugins, for Eclipse I use subclipse and CollabNet Desktop. For more, please see http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients Kind regards, Volker Am 25.01.2011 um 16:29 schrieb vani yadav: Hello sir, I downloaded subversion-1.6.15, i installed all the dependency package. i built berkeley, built apache then configured subversion and built subversion. after building subversion i Run the win-tests.py script to test Subversion. now all the binaries are created, if i run svn.exe (C:\SVN\src-trunk\Release\subversion\svn) from command line it works. I am able to see SVN commands on command line but not able to find svn GUI. My question is i am not able to make GUI up, so please let me know how to create subversion-setup.exe file. -- Thanks and Regards Vani
svn: E235000: In file '..\..\..\subversion\libsvn_client\commit_util.c' line 474: assertion failed ((copy_mode_root && copy_mode) || ! copy_mode_root)
Hi, we just upgraded from svn 1.6.4 to 1.7.2 and ran our usual "daily build" batch file. Commands stat, revert, update seemed to work like expected, but copy failed in an unexpected way. This is our command line: w:\setuptools\subversion\svn.exe copy . http://server.tc.local:8088/svn/shipped/chart/111230_version21158 -m "Tagging version 21158." This is the reproducible error message: svn: E235000: In file '..\..\..\subversion\libsvn_client\commit_util.c' line 474: assertion failed ((copy_mode_root && copy_mode) || ! copy_mode_root) Triggering the same(?) command interactively using Tortoise 1.7.3 works fine. Which additional info do you need to tell if this is a known problem, and possibly how it can be avoided or when it will be fixed? Would you recommend downgrading back to 1.6.4 for the time being? Thanks Volker -- Volker Schöch | vscho...@think-cell.com Senior Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl
Re: svn: E235000: In file '..\..\..\subversion\libsvn_client\commit_util.c' line 474: assertion failed ((copy_mode_root && copy_mode) || ! copy_mode_root) - Bayesian Filter detected spam
Philip, Thank you for getting back to me. svn info: Path: . Working Copy Root Path: C:\svn_vschoech\dev\chartbranch21000 URL: http://server:8088/svn/dev/chartbranch21000 Repository Root: http://server:8088/svn Repository UUID: ad1beaad-0fd3-4144-8000-4b573cec81f8 Revision: 44554 Node Kind: directory Schedule: normal Last Changed Author: schoedl Last Changed Rev: 44530 Last Changed Date: 2011-12-23 17:41:04 +0100 (Fr, 23 Dez 2011) Looking at this info made me aware of the problem: In our infrastructure, "server" and "server.tc.local" are synonymous. My working copy is checked out from "server", but the command that crashes svn refers to "server.tc.local". When I change the command to refer to "server", svn does not crash and the copy is correctly executed. This solves my problem at hand, but surely svn should not crash in this case and either handle it as intended or exit with some helpful error message. Thanks again! Volker -- Volker Schöch | vscho...@think-cell.com Senior Software Engineer think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl
Dump of subversion repository itself?
Hi, I wonder if there is a dump file downloadable somewhere that contains the complete subversion code base. Would be a perfect repository for load/stress testing my subversion server;) Beste Grüße, kind regards, Volker Kopetzky vzk Beratung Germany & Thailand phone +49.6809.2163.30 phone +66.86.143.77.27 skype volker.kopetzky email v...@vzkb.de wsite http://www.vzkb.de smime.p7s Description: S/MIME cryptographic signature
Re: Dump of subversion repository itself?
Stefan, Markus, thanx a lot for the fast answers! That really is a huge beast to load :) let's see how my humble server can handle it. Beste Grüße, kind regards, Volker Kopetzky Am 03.08.2012 um 18:54 schrieb Stefan Sperling: > On Fri, Aug 03, 2012 at 06:29:02PM +0700, Volker Kopetzky wrote: >> Hi, >> >> I wonder if there is a dump file downloadable somewhere that contains the >> complete subversion code base. >> Would be a perfect repository for load/stress testing my subversion server;) > > Probably larger than you hoped for, but the entire ASF repository > (which includes Subversion's own code) is available here: > http://svn-master.apache.org/dump/ smime.p7s Description: S/MIME cryptographic signature
Re: SvnAdmin: impossible to load dump generated by "cvs2svn"
Julien, a dump file is designed to work with the commandline pipe. So it might be that the binary transport might have changed something. (if your sending os is different than suse) A safer way to transport it is to tar it before sending it over the wire: (1) cvs station $ tar czvf dump.tar.gz Send the file via ftp binary. (2) svn station $ tar xzvf dump.tar.gz Import via svnadmin. If this still does not work, please send us the log files created by using redirects similiar to this: $ svnadmin load /path/to/target/repo < dumpfile 2> /tmp/load.stderr > /tmp/load.stdout Beste Grüße, kind regards, Volker Kopetzky vzk Beratung Germany & Thailand smime.p7s Description: S/MIME cryptographic signature
Wrong last changed rev after "svn cp"
Hi. I have the an issue, which I already found referenced in a mailing list posting (for example here: http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3Calpine.561.2.00.1003301058490.1236@daniel2.local%3E). However I couldn't find any related issues in the bug-tracker, or other indications whether this is an intended behaviour or a bug that will be fixed. In short the behavior can be reproduced like this: I start from a new repository and a fresh checkout wc of the repository root: --- > mkdir A; touch A/file > svn add -q A > svn ci -q -m "add A" A > svn cp ^/A ^/A2 -m "add A2" Committed revision 2. > svn up -q > svn info A A/file | grep "Last Changed Rev" Last Changed Rev: 1 Last Changed Rev: 1 > svn info A2 A2/file | grep "Last Changed Rev" Last Changed Rev: 2 Last Changed Rev: 1 --- Why do the directory "A2" and the file "A2/file" have different Last Changed Revision? For my use case this is very bad, as we are using keyword substitution for $URL$ and $Rev$ in "A2/file" to uniquely identify printouts of that file, with its electronic copy in the repository. With the above behaviour that's not possible, as "A2/file" does not exist at revision 1. I reproduced the bug with version 1.7.6 (linux server and command line client; test installation), and also with an 1.6.12 server (linux production server) combined with a 1.6.17 and 1.7.6 tortoiseSVN windows client. Cheers, Volker
Re: Wrong last changed rev after "svn cp"
Hi Johan. Thanks for your reply. I was already afraid of that... Do you have any suggestion how I could solve my use case anyway (embedding a PEG revision in the file)? Text substitution in a pre-commit hook? The client knows the PEG revision of its working copy files I guess. So one could hack a keyword substitution for that into the client. How difficult would that be? Volker Original-Nachricht > Datum: Wed, 26 Sep 2012 17:31:02 +0200 > Von: Johan Corveleyn > An: Volker Daum > CC: users@subversion.apache.org > Betreff: Re: Wrong last changed rev after "svn cp" > On Wed, Sep 26, 2012 at 4:58 PM, Volker Daum wrote: > > Hi. > > > > I have the an issue, which I already found referenced in a mailing list > posting (for example here: > http://mail-archives.apache.org/mod_mbox/subversion-users/201003.mbox/%3Calpine.561.2.00.1003301058490.1236@daniel2.local%3E). > However I couldn't find any related issues in the bug-tracker, or other > indications whether this is an intended behaviour or a bug that will be > fixed. > > In short the behavior can be reproduced like this: > > > > I start from a new repository and a fresh checkout wc of the repository > root: > > --- > >> mkdir A; touch A/file > >> svn add -q A > >> svn ci -q -m "add A" A > >> svn cp ^/A ^/A2 -m "add A2" > > > > Committed revision 2. > >> svn up -q > >> svn info A A/file | grep "Last Changed Rev" > > Last Changed Rev: 1 > > Last Changed Rev: 1 > >> svn info A2 A2/file | grep "Last Changed Rev" > > Last Changed Rev: 2 > > Last Changed Rev: 1 > > --- > > > > Why do the directory "A2" and the file "A2/file" have different Last > Changed Revision? > > > > For my use case this is very bad, as we are using keyword substitution > for $URL$ and $Rev$ in "A2/file" to uniquely identify printouts of that > file, with its electronic copy in the repository. With the above behaviour > that's not possible, as "A2/file" does not exist at revision 1. > > > > I reproduced the bug with version 1.7.6 (linux server and command line > client; test installation), and also with an 1.6.12 server (linux production > server) combined with a 1.6.17 and 1.7.6 tortoiseSVN windows client. > > > > Hi Volker, > > The short answer is: this is intended behavior, and you shouldn't use > the LastChangedRev as a peg revision identifier in combination with > the URL. This is not a supported use case. > > See this recent dev-thread for some more discussion: > > > http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663 > > The thread actually started with another issue related to > LastChangedRev (which was identified as a real issue, which was filed > here: > http://subversion.tigris.org/issues/show_bug.cgi?id=4203). But during > the (rather long) discussion the issue you mention actually came up. > See this mail in the thread: > > > http://thread.gmane.org/gmane.comp.version-control.subversion.devel/136663/focus=136719 > > where C. Michael Pilato says: "Finally, (LCR, URL) was never intended > to be used a unique coordinate pair for identifying resources. That > it work out as such most of the time might be a benefit, but was not a > feature designed into the system." > > > -- > Johan
Re: Unsupervised svn import
Hi Tom, svn version 1.6.5 supports them, at least in the CLI client. 'svn help ci' documents these options, I'm using them in my own bash importer script: Global options: --username ARG : specify a username ARG --password ARG : specify a password ARG --non-interactive: do no interactive prompting ...works smoothely in versions 1.6.x and 1.5.5. Dunno if they are available in subversion's PHP API, though :-D Beste Grüße, kind regards, Volker Kopetzky vzk Beratung Germany & Thailand phone +49.6809.2163.30 phone +66.86.143.77.27 skype volker.kopetzky email v...@vzkb.de wsite http://www.vzkb.de Am 13.04.2010 um 14:12 schrieb Tom Van de Putte: Hey, I need to do an unsupervised 'svn import' from within a php script run in bash (so PHP CLI). The svn server runs on a different machine using apache + webDAV. I found that in previous versions (svn 1.2) that corresponding manual indicates the use of --username and --password switches, but these have diappeared since the 1.4 version. Is there any reason for this, and or other means to do an svn import without user intervention? Thanks in advance, Tom Van de Putte -- Met vriendelijke groet, Tom Van de Putte | PHP/MySQL Developer bSeen.be Vlaanderenstraat 30/2 B-9000 Gent Tel. +32 (0)9 331 55 50 Fax +32 (0)9 331 55 51 BE 0473.071.275 Mail: t...@bseen.be URL: www.bSeen.be bSeen blogt... Volg ons op www.bseen.be/blog
Re: svn export on long paths failed
Hartmut, Another reason I received this is that there were duplicate files in the subversion directory which are share the same name and extension but in different letter case (e.g. CHANGES versus changes). Windows FS is case insensitive by default. Regarding the problem of using long pathnames, you might want to use the subst cli tool to reduce the length of the path string. This and some other ideas are described in http://superuser.com/questions/37737/extend-maximum-file-path-size-in-windows-7. Beste Grüße, kind regards, Volker Kopetzky vzk Beratung Germany & Thailand Am 23.04.2010 um 18:42 schrieb Schroeder, Hartmut: hi all, an 'svn export' under Windows results on a long path in: svn: Can't open 'current\externaltools\build\sources\mavenplugins\pde-maven-plugin\tutor ials\PDE_Plugin_Tutorial\plugins\test.pde_maven_plugin.simple_applicatio n\src\main\java\test\pde_maven_plugin\simple_application\ApplicationWork benchWindowAdvisor.java.tmp': Das System kann den angegebenen Pfad nicht finden. with tortoise it's ok. we have to run that as windows batchfile. any idas? Thanks Hartmut
Re: Hello, please help subversion using
Alex, the command to use to create a copy without svn metadata (if this is your intention) is: svn export /usr/src/svn/php-3.2.0 /some/target/path You're getting the error because you are trying to access the working copy, but due to the file:/// prefix subversion expects this to be the location of the repository itself. Beste Grüße, kind regards, Volker Kopetzky vzk Beratung Germany & Thailand Am 28.05.2010 um 21:03 schrieb Alex: I have subversion copy of repository ex. php-3.2.0 path: /usr/src/svn/php-3.2.0 when im in this folder i can do anything: svn update, svn info, svn log and everything is work well. but if i want to make a non subversion copy: svn co file:///usr/src/svn/php-3.2.0 /usr/src/php-src svn doesn't do that and i see error svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///usr/src/php-3.2.0' anybody can help ?
Re: How to get the client hostname while user committing the code to the repository?
Ramkumar, the client and server information is part of the HTTP header information. You could use apache's mod_rewrite to rout the call to an additional (warpper) script on the server to get this information. Could you please clarify more about what information is to be displayed and how the use case scenario looks like? Beste Grüße, kind regards, Volker Kopetzky vzk Beratung Germany & Thailand phone +49.6809.2163.30 phone +66.86.143.77.27 skype volker.kopetzky email v...@vzkb.de wsite http://www.vzkb.de Am 28.07.2010 um 11:30 schrieb ram kumar: Hi, We are using http protocal. Please find the server and client details below. We have to popup some window on the client machine either in pre or post commit operation. Prototype is working fine so need to know how to get the client ip adress or hostnmae in pre/post commit trigger. SVN Server: Linux SVN Clients: Windows XP Regards, Ramkumar > Hi, > > > > I need your help. > > > > I need the client host information in either pre or post-commit trigger. Good luck with that!! If you're using a single protocol of access, such as ssh+svn or HTTPS, it's conceivable that you could adopt a wrapper to do something clever and deduce the hostname. But it seems awkward. Why do you want this?
problem with path based authorization
Hello, I have set up path based authorization on a repository. If I check out the project, everything works as expected. My problem however is, that if I change permissions of a file / path and then update the working copy the files I should have no longer access to are still there. Is there a way of updating the working copy so that permissions are rechecked? Or is the only possibility to check out the whole project again (I'd like to avoid that because of the size)? Thanks, Volker
Re: problem with path based authorization
Am 13.01.2017 um 15:47 schrieb Daniel Shahaf:
> Volker Cordes wrote on Fri, Jan 13, 2017 at 10:51:19 +0100:
>> Hello,
>>
>> I have set up path based authorization on a repository. If I check out
>> the project, everything works as expected. My problem however is, that
>> if I change permissions of a file / path and then update the working
>> copy the files I should have no longer access to are still there. Is
>> there a way of updating the working copy so that permissions are
>> rechecked?
> 'Update' does recheck permissions (that's done server-side and cannot be
> opted out of). There ought to be some other difference. Maybe the
> authz'd files have local mods so they weren't deleted from the tree
> ('svn st' will show '?'). Maybe the two working copies (old and new)
> don't use the same username or don't come from the same URL.
Hello,
that's it than. I'm changing the username during the update with "svn up
--username=...". Is there any way to recheck permissions in that case?
Thanks,
Volker
--
Tel: +49 (0) 4489 408753
Fax: +49 (0) 4489 405735
mailto: v...@fdatek.de
freeline Datentechnik GmbH & Co.KG
Wiekesch 1
26689 Apen
www.freeline-edv.de
Amtsgericht Oldenburg HRA 203347
persönlich haft. Gesellschafterin: freeline Holding GmbH, Amtsgericht Oldenburg
HRB 206967
Geschäftsführer: Volker und Tobias Cordes
svn_dirent_t::size: often not the "real" file size
Hi SVN developers, I am working on an TotalCommander plugin to browse SVN repositories. Now I have the problem that on some repositories the filesize reported by svn_client_list3 is different from the "real" file size of the working copy - so comparing the SVN repo with the working copy is impossible. So here are my questions on this issue: · Is there a way for a SVN client to detect the "real" filesize? · Does this behavior change with the server version? I have one server where the filesize seems to match, another server where it does not match. · If there are servers that reports "real" file sizes: is there a client functionality to detect if he is connected to a server with "good" behavior? This may be not the correct way to do a compare, there would be better ways using the SVN interface. But I am limited to the TC plugin interface. And in this interface there is no "Compare with file" function. I have just to deliver the correct properties, and TC itself does the operation in a way the user has configured it. Cheers, Volker Bijewitz BAUM Systeme GmbH Industriestr. 15 74909 Meckesheim E-Mail : v.bijew...@baum.de <mailto:v.bijew...@baum.de> Internet: www.baum.de <http://www.baum.de/> Geschäftsführer: Wolfgang Baum - Thomas Friehoff Registergericht Mannheim, HRB 333567 Gerichtsstand: Heidelberg VAT Nr: DE 143260354 IK 590820251 Bankverbindungen: Commerzbank Heidelberg IBAN: DE63 6724 0039 0193 5808 00 BIC: COBADEFFXXX Postbank Karlsruhe IBAN: DE40 6601 0075 0202 5007 54 BIC: PBNKDEFF
AW: svn_dirent_t::size: often not the "real" file size
Ok, thank you for explaining this. Yes, I understand that SVN is normalizing the text files, so their real size may differ from client to client. Unfortunately I do not know if the user has got an working copy and where it can be found . So the only way to solve this is creating once a local copy of each file and store the real size in a DB referenced by the file URL and revision number L. Volker Von: Bert Huijben [mailto:b...@qqmail.nl] Gesendet: Donnerstag, 2. Februar 2017 10:39 An: Bijewitz, Volker; users@subversion.apache.org Betreff: RE: svn_dirent_t::size: often not the "real" file size The size reported is the size of the file in repository form. The size might be different when a different line end encoding is used and/or when keyword expansion is enabled. (Can be larger or smaller) svn_client_statusX() reports both sizes when the file is a 'normal' working copy file. The list function works 100% repository side and we simply don't know the size the file would be in some working copy, as the size might be different in other working copies. Bert From: Bijewitz, Volker [mailto:v.bijew...@baum.de] Sent: donderdag 2 februari 2017 09:22 To: users@subversion.apache.org Subject: svn_dirent_t::size: often not the "real" file size Hi SVN developers, I am working on an TotalCommander plugin to browse SVN repositories. Now I have the problem that on some repositories the filesize reported by svn_client_list3 is different from the "real" file size of the working copy - so comparing the SVN repo with the working copy is impossible. So here are my questions on this issue: · Is there a way for a SVN client to detect the "real" filesize? · Does this behavior change with the server version? I have one server where the filesize seems to match, another server where it does not match. · If there are servers that reports "real" file sizes: is there a client functionality to detect if he is connected to a server with "good" behavior? This may be not the correct way to do a compare, there would be better ways using the SVN interface. But I am limited to the TC plugin interface. And in this interface there is no "Compare with file" function. I have just to deliver the correct properties, and TC itself does the operation in a way the user has configured it. Cheers, Volker Bijewitz BAUM Systeme GmbH Industriestr. 15 74909 Meckesheim E-Mail : v.bijew...@baum.de Internet: www.baum.de <http://www.baum.de/> Geschäftsführer: Wolfgang Baum - Thomas Friehoff Registergericht Mannheim, HRB 333567 Gerichtsstand: Heidelberg VAT Nr: DE 143260354 IK 590820251 Bankverbindungen: Commerzbank Heidelberg IBAN: DE63 6724 0039 0193 5808 00 BIC: COBADEFFXXX Postbank Karlsruhe IBAN: DE40 6601 0075 0202 5007 54 BIC: PBNKDEFF
AW: AW: svn_dirent_t::size: often not the "real" file size
Hi Brane, > > Unfortunately I do not know if the user has got an working copy and > > where it can be found . So the only way to solve this is creating once > > a local copy of each file and store the real size in a DB referenced > > by the file URL and revision number L. > > Why would you do that? You'd effectively have to check out the file in a > Subversion working copy to get the correct size (or reimplement > Subversion's end-of-line conversion and keyword expansion logic, which I'd > not recommend). > > The size of the file in the repository is as real as any other size. As are the > contents. Does your plugin show file contents? If yes, does it perform > keyword expansion and newline substitution, like the Subversion client > would? If no, don't bother about tweaking the reported size. Ok, the situation is the following. The left widow of my TC file manager is feed by my plugin with the contents of a folder coming from SVN. The right window points to a location on the harddisk - maybe the working copy, but maybe not. Now I choose the fuction to compare/synchronize these "folders". On the synchronize pane I want so see the files correctly marked as new, identical or different. And in the plugin I have no access to the file list on the other side. Now three situations can happen based on the settings: * Standard compare: does not work, date and time is generally different * Ignore date/time: problem caused by incorrect size (comparing just file sizes) * Compare by contend: not supported for plugins :-(. So there is not any way to compare the content of a SVN repo with a folder on disk that is not a working copy - it is not even possible as plugin to get any info about the other side file/folder list. Yes, I show the contents of a file on demand, using a temporary file. I hope I do it correctly. I do the following: - apr_open_file - svn_stream_from_aprfile2 - svn_client_cat2 - svn_stream_close I hope the file I created this way is identically to the file of a SVN working copy. Do you now, are they? Thank you, Volker
unsubscribe
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
+1 on *plonk*. I admit, I had fun reading and this is a perfect end to the thread. Thank-yous to Stefan, Branko and the other contributors in the thread. There was definitely learning involved on my side (I did not learn most from Ze's replies) "Let's just stop and think, before I lose face Surely I can't fall, into a game of chase" - Crave you Peace, Volker Am 19.05.2013 um 19:37 schrieb Nico Kadel-Garcia : > On Sat, May 18, 2013 at 3:01 PM, Zé wrote: >> On 05/18/2013 07:16 PM, David Chapman wrote: >>> >>> >>> You are pretty insistent that there is One True Way to use branches in >>> development. >> >> >> No, I'm stating that if all a SCM does is track changes made to the contents >> of a directory and you rely on changes made to that directory to emulate >> branches, then there are some significant downsides to this approach when >> compared with SCM systems which do offer support for branching. > > You've been doing a lot more. I've read what you've written. You > consistently ignore your own previous claims, guidance or refutations > or information from others. You clearly want what you want, the way > you want it, and will accept nothing less than absolute confirmation > of your frankly unfounded claims about what branching and tagging > actually are and how they work, despite numerous references and > explanations. > > I hate to do this on a really useful technical mailing list. But > you're clearly wasting everyone's time, and it's time to killfile you. > > *plonk*.
