RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Great, Thanks. My expectation is that it will all work fine... until you get to file locking - which will fail. -Original Message- From: Alagazam.net Subversion [mailto:s...@alagazam.net] Sent: 03 February 2014 21:51 To: Steve Davis Cc: users@subversion.apache.org Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking Hi everyone. I got curious to see if they are using my VC6 build of Subversio a.k.a. Win32SVN. And my suspision it true, it's the Win32SVN 1.8.4 build for Apache 2.4.x that's is included in the Bitnami Redmine Windows installer. Building Win32SVN and testing is done against a httpd built at the same time (or sometimes a previous build) with the same compiler VC6. I haven't tested Win32SVN with httpd built using more modern VC++. It seems like Bitnami's httpd it built with VS2010 (at least as Dependency Walker shows). If time permit I can try to run the svn testsuite with these installation. Best regards David a.k.a. Alagazam Maintainer of Win32SVN On 2014-02-03 17:31, Steve Davis wrote: Ah - with a bit of digging around the binary libraries, I can see that it looks like subversion was still built using vc6, and apache using a mix of 2008 and/or 2010. This being the case, I'd say that this is a prime candidate for what's causing the problem (based upon the comments in the second link)... So it's not a problem with Redmine or with apache - but it is a problem when the binaries used aren't built using the same version of compiler (this is all theory at the moment of course) -Original Message- From: Steve Davis Sent: 03 February 2014 15:35 To: 'Philip Martin' Cc: users@subversion.apache.org mailto:users@subversion.apache.org Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking All of the Apache and Subversion binaries came from the Bitnami download. I could ask their support people exactly what compiler was used if you think that would help? Anything else I should be asking them at the same time? Thanks for your time on this Regards - Steve -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: 03 February 2014 15:34 To: Steve Davis Cc: users@subversion.apache.org mailto:users@subversion.apache.org Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking Steve Davis steve.da...@uk.rapp.com mailto:steve.da...@uk.rapp.com writes: Response: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL svn: E200035: Additional errors: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL I can generate this error with the 1.8 client by patching mod_dav_svn to return 400: Index: sw/subversion/src/subversion/mod_dav_svn/lock.c === --- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833) +++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy) @@ -670,7 +670,7 @@ DAV_ERR_LOCK_SAVE_LOCK, Path is not accessible.); - if (lock-next) + /*if (lock-next)*/ return dav_svn__new_error(resource-pool, HTTP_BAD_REQUEST, DAV_ERR_LOCK_SAVE_LOCK, Tried to attach multiple locks to a resource.); A trunk client gives a better error: svn: warning: W160040: No lock on path 'f' (400 Bad Request) The question remains why are you getting a 400 Bad Request from the server. As far as I am aware this has only ever been observed by people using Windows and I think it could be an incompatibility between the way Apache and Subversion are built. In this discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065dsMessag eId=894838 a patch/rebuild is reported to fix the problem but the person producing the patch realises that the patch does nothing. Therefore what solved the problem was the rebuild, not the patch. In the same discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065dsMessag eId=905320 somebody else reports a similar incompatibility which was solved by using different binaries. Do you know how your Apache and Subversion binaries were produced? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept
Re: Limit The size of Commit in SVN
hey Johan, all i want is when my developer hit the commit button my script trigger the error if the commit size only commit size no repository size only that perticular commit size is greater than a GB. @echo off :: Stops commits that have size of greated than 1GB. @echo off set REPOS=%1 set TXN=%2 set MAX_BYTES= 1073741824 svnlook changed -t %TXN% %REPOS% svnlook filesize -t %TXN% %REPOS% %changed% for /D /r %%G IN (%TXN%) DO ( if %G% GEQ %MAX_BYTES% (goto :err) else exit 0 ) :err echo Your commit has been blocked because your commit size is exceed. 12 echo Kindly Commit less than 1GB. 12 echo Thanks Regards 12 exit 1 Please Guide will be very great full to you. Regards Mehboob Ahmed -- View this message in context: http://subversion.1072662.n5.nabble.com/Limit-The-size-of-Commit-in-SVN-tp186696p186895.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: svn delete does not warn anymore in some cases
On Tue, Feb 04, 2014 at 11:49:24AM +0200, Florin Avram wrote: Hi, I noticed that SVN 1.8.5 does not give warnings for some situations, when using svn delete (previously, using SVN 1.7.x, it did): 1. have a file replaced with a directory in the working copy: - svn delete file - create new directory, with the same name as the file - svn add file (the directory; item is reported as replaced) - svn delete file - no warning. But, if trying to delete an added file, it warns. Shouldn't be something similar in this case, since replaced = deleted + added ?! I cannot reproduce this. Can you please provide command sequences and their output instead of a verbal description? Below is what I did. $ svn --version svn, version 1.8.5 (r1542147) compiled Jan 2 2014, 00:27:30 on x86_64-unknown-openbsd5.4 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.2 - handles 'http' scheme - handles 'https' scheme $ svn rm epsilon D epsilon D epsilon/zeta $ echo foo epsilon $ svn add epsilon A epsilon $ svn st R epsilon $ svn rm epsilon svn: E195006: Use --force to override this restriction (local modifications may be lost) svn: E195006: '/tmp/svn-sandbox/trunk/epsilon' has local modifications -- commit or revert them first $
Re: Limit The size of Commit in SVN
On 4 February 2014 10:45, Mehboob Ahmed m.mehboobah...@gmail.com wrote: hey Johan, all i want is when my developer hit the commit button my script trigger the error if the commit size only commit size no repository size only that perticular commit size is greater than a GB. @echo off :: Stops commits that have size of greated than 1GB. @echo off set REPOS=%1 set TXN=%2 set MAX_BYTES= 1073741824 svnlook changed -t %TXN% %REPOS% svnlook filesize -t %TXN% %REPOS% %changed% for /D /r %%G IN (%TXN%) DO ( if %G% GEQ %MAX_BYTES% (goto :err) else exit 0 ) :err echo Your commit has been blocked because your commit size is exceed. 12 echo Kindly Commit less than 1GB. 12 echo Thanks Regards 12 exit 1 You're still going to have the 1GB transferred to the server before the script runs... unless I misunderstand... so what is the utility in such a restriction? You won't be saving the server load or the client commit time... the only thing you may catch is somebody committing very large binary files to SVN... which probably suggests a different check anyway Please Guide will be very great full to you. Regards Mehboob Ahmed -- View this message in context: http://subversion.1072662.n5.nabble.com/Limit-The-size-of-Commit-in-SVN-tp186696p186895.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: Limit The size of Commit in SVN
hi Stephen i've shared the incmplete hook. if the commit size is larger than one gb than commit should cancel and prop up the echo msg... and let user commit less than 1GB data. can u provide me hook for windows for Tortoise SVN -- View this message in context: http://subversion.1072662.n5.nabble.com/Limit-The-size-of-Commit-in-SVN-tp186696p186905.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: svn delete does not warn anymore in some cases
Stefan Sperling s...@elego.de writes: On Tue, Feb 04, 2014 at 11:49:24AM +0200, Florin Avram wrote: Hi, I noticed that SVN 1.8.5 does not give warnings for some situations, when using svn delete (previously, using SVN 1.7.x, it did): 1. have a file replaced with a directory in the working copy: - svn delete file - create new directory, with the same name as the file - svn add file (the directory; item is reported as replaced) - svn delete file - no warning. But, if trying to delete an added file, it warns. Shouldn't be something similar in this case, since replaced = deleted + added ?! I cannot reproduce this. Can you please provide command sequences and their output instead of a verbal description? Below is what I did. It's file replaced by directory: svnadmin create repo --compatible-version 1.7 svn import -mm repo/format file://`pwd`/repo/A/f svn co file://`pwd`/repo wc svn rm wc/A/f svn mkdir wc/A/f svn rm wc/A/f with 1.8 the last rm succeeds, with 1.7 the last rm fails unless --force is used: svn: E195006: Use --force to override this restriction (local modifications may be lost) svn: E195006: '/tmp/wc/A/f' has local modifications -- commit or revert them first Some things still cause 1.8 to require force: setting properties on the directory or children, adding file children. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Limit The size of Commit in SVN
Nope I cannot. I don't use windows, and I only use SVN for those projects I work on that are still on SVN. I think you are missing the point that *everyone* has been trying to get you to see... What is the benefit in stopping 1GB+ commits? Either the developer is going to split the commit into two 0.9GB revisions and commit the 1.8GB anyway... so not stopping the repository from becoming bloated... or the developer will keep those files out of source control... so defeating the whole point of source control. I contend that the real issue here is that you don't want developers committing large binary files. In which case the commit hook should look for large binary files and reject commits including them. If you are concerned with server load, a commit hook is too late... the file has already landed on the server when the server side hooks are running. If you are concerned with large binary files in SVN, a different commit hook is what you want, i.e. one that stops the large binary files... not one that prevents what may be a legitimate commit. Consider the case where there are video prompts associated with text messages in a repository. When committing a change to the text messages, you should also commit the updated prompts (because it is a change that should be part of the commit... having an incorrect video prompt for the text message is a bug). If I have to rework 20 of the messages as a result of a single refactoring (introducing another screen, so all the messages now have to have or via the foo screen appended... which requires a re-recording of all affected messages by the talent), that could well mean committing the code for the addition of the foo screen, with the message text changes and the updated video files. Putting a 1GB limit per revision will prevent me committing the change as a single commit (which one can argue is the correct thing to do for this single change). TL;DR it sounds very much like you are solving the wrong problem... ask yourself what is the real problem you want to solve and then solve that problem instead. On 4 February 2014 12:03, Mehboob Ahmed m.mehboobah...@gmail.com wrote: hi Stephen i've shared the incmplete hook. if the commit size is larger than one gb than commit should cancel and prop up the echo msg... and let user commit less than 1GB data. can u provide me hook for windows for Tortoise SVN -- View this message in context: http://subversion.1072662.n5.nabble.com/Limit-The-size-of-Commit-in-SVN-tp186696p186905.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: Limit The size of Commit in SVN
Guten Tag Stephen Connolly, am Dienstag, 4. Februar 2014 um 13:25 schrieben Sie: [...]and then solve that problem instead. ...and don't expect others to do for you, they surely aren't that bored . ;-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: svn delete does not warn anymore in some cases
Florin Avram flo...@sync.ro writes: So, my question is: is this SVN 1.8 svn delete behavior intentional or it should behave like with SVN 1.7 ?! It was a result of a deliberate change in r1442611 to allow the delete of unmodified copies without force: svn cp iota iota2 svn rm iota2 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: svn delete does not warn anymore in some cases
On 04.02.2014 14:51, Philip Martin wrote: Florin Avram flo...@sync.ro writes: So, my question is: is this SVN 1.8 svn delete behavior intentional or it should behave like with SVN 1.7 ?! It was a result of a deliberate change in r1442611 to allow the delete of unmodified copies without force: svn cp iota iota2 svn rm iota2 I think this does not answer completely to my question. If this was a deliberate change to allow the delete of unmodified copies, should reported changes (missing warnings) be considered as a not desired side-effect of this change (and there should be open an issue to be solved), or this is the right svn delete behavior from now on (meaning it is correct to behave such, even if the items are not being copied)?
define files structure in svn (CAD PDM)
Hi all, I'm trying to use svn as a PDM for CAD files. ( http://en.wikipedia.org/wiki/Product_data_management ) It looks working fine but I'd like to do better. -1 structure In my CAD I can create an assembly which is a file where I assembly many parts or subassemblies. Is it possible to create a structure (it could be a txt file) where svn reads the parts which belongs to the assembly, so to commit, update, lock the files linked to the father? I mean I have an assembly which name is car.assy. In this assembly I have 4 files named wheel.part, a file named engine.assy (which contains piston.part, cylinder.part ...) , and so on I'd like to find a way where inporting car.assy, svn will download all the sub asseblies (engine.assy; engine_bay.assy; rear_side.assy) and all the parts (wheel.part piston.part cylinder.part ...) car.assy wheel.part (number 4) engine.assy --piston.part --cylinder.part -- engine_bay.assy -- -- -- . Is it possible? -2 folders To keep ordered my repository I'd like to keep a folders structure (for example steel-parts; plastic-parts; rubber-parts ) but when inporting the project I'd like to keep the files all in a single level. Is it possible? steel_parts --machined-parts -- a.part -- b.part -- . -- c.part -- d.part --rough-parts -- m.part -- n.part -- . -- t.part -- u.part plastic_parts -- w.part -- z.part -- . -- j.part project_1: parts: b.part (from steel_parts/machined-parts) d.part (from steel_parts/machined-parts) j.part (from plastic_parts) u.part (from steel_parts/rough-parts) Thank you and best regards, Roberto -- - Hello world ! Roberto was here !
Re: define files structure in svn (CAD PDM)
Roberto Bartola wrote: Hi all, I'm trying to use svn as a PDM for CAD files. ( http://en.wikipedia.org/wiki/Product_data_management ) It looks working fine but I'd like to do better. -1 structure In my CAD I can create an assembly which is a file where I assembly many parts or subassemblies. Is it possible to create a structure (it could be a txt file) where svn reads the parts which belongs to the assembly, so to commit, update, lock the files linked to the father? [...] -2 folders To keep ordered my repository I'd like to keep a folders structure (for example steel-parts; plastic-parts; rubber-parts ) but when inporting the project I'd like to keep the files all in a single level. Is it possible? [...] have a look at file externals -- Lorenz
AW: Solving problem with space in file names
Hi, Von: Ben Reser [mailto:b...@reser.org] I am wondering if there is a simple way to solve this if without having to compile a new mod_dav or trying to find another version of Apache? Since I am running OpenIndiana I am simply using the apache that is supplied, and no other version seem to be easily installed... I tried the OpenCSW version, which is 2.2.22, but I get segmentation faults when using the same setup (SVN over web_dav, authentication using PostgreSQL)... If you don't want to upgrade httpd you can upgrade Subversion on the server to 1.7.x or newer and only use 1.7.x or newer clients (which you seem to already be doing by using 1.8.x versions of TortoiseSVN). Another workaround which might be applicable for your setup is to use the svn or svn+ssh protocols - they both avoid mod_dav at all. :-) Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
