RE: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
Thank you very much Stefan! Will try out the patch. Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
Re: Subversion 1.7 symlink problems
I opened # 4120. The ticket does not contain a script, but reproduction should be simple enough, I hope I provided all the necessary info. If not, I can send you the complete repo (contains only testing data). * Daniel Shahaf : > > At a guess the problem here is that 'status' dereferences the symlink > when it shouldn't or didn't, so I don't think this is related to #4091. > > Could you file a new issue for this? And, if possible, provide > a reproduction script. > > Thanks, > > Daniel > > > Fridtjof Busse wrote on Thu, Feb 16, 2012 at 16:02:19 +0100: > > Hi, > > > > we've started to test Subversion 1.7.3 on linux and noticed a somewhat > drastaic change in svn behavior. > > Our repo (also 1.7, a svnsync copy) contains a lot of symlinks and > externals. Different from Subversion 1.6, every one of those symlinks shows up > as "M" in "svn status". > > "svn diff" chokes on those files (which point to an external dir), like > this: > > svn: E21: Can't read file '/home/fbusse/repo/symlinktests/link': Is > a directory > > > > "link" is a symlink to a directory one level up. > > > > "svn commit" also fails with this: > > svn: E145001: Commit failed (details follow): > > svn: E145001: Entry '/home/fbusse/repo/symlinktests/link' has > unexpectedly changed special status > > > > Any ideas? It looks very much like a bug, might be related to issue > 4091. > > > > Please CC me, thanks. > > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
I'm able to replicate this failure on my Windows box with my own builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as expected with 1.6.17, so this appears to be a regression. Moving back to the dev list. Investigating... Paul On Thu, Feb 16, 2012 at 3:28 PM, C. Michael Pilato wrote: > Alexey, > > We ask that folks send questions, concerns, and potential bug reports to > users@subversion.apache.org. (I've taken the liberty of dropping dev@ and > adding users@ to the distribution list of this response so that follow-ups > go to the right place.) > > I wasn't able to easily reproduce this using Linux and a trunk version of > the codebase. (I know that's two strikes against me in terms of trying to > match your scenario. My 1.7 client build is horked at the moment, though.) > One thing that comes to mind with the situation you are seeing is the > possibility that an anti-virus software could be actively scanning the > temporary files that Subversion creates and, in doing so, blocking access to > those files from Subversion. Most modern anti-virus software packages offer > a "snooze" feature of sorts -- you might try temporarily disabling your AV > package and re-trying the checkout. If all goes well, consider adding your > checkout area to the AV package's list of excluded scan directories. > > Good luck. > > > On 02/16/2012 12:27 PM, Alexey 0 Moudrick wrote: > > Hello, dev, > > I've encountered an issue with svn copy command. > I report it here because I did not find a way to report in in the issue > tracker. > It cannot copy a directory by its url to local working copy if the directory > contains valid svn:external property. > Instead of correct copying, it shows error like this: > > svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to > 'C:\t\wc\externals-container-copy': Access is denied. > > The repro.bat composed according to recommendations is attached (please > rename it to repro.bat). > > operating systems where I tested: > > Windows 7 Professional x86-32bit SP1 Microsoft Windows [Version 6.1.7601] > Windows Server 2008 R2 Standard x64-64bit SP1 Standard Microsoft Windows > [Version 6.1.7601] > > svn versions where I tested: > > svn, version 1.7.2 (r1207936) > compiled Nov 30 2011, 02:05:23 > > svn, version 1.7.1 (r1186859) > compiled Oct 28 2011, 13:40:58 > > Additionaly, this makes svncopy.pl contribution script fail on this error. > > Full output of repro.bat: > > C:\t>repro.bat > Base url for repo: file:///C:/t/repos > Making a tree for import... > Importing it... > Checking out working copy.. > Creating valid svn:externals property... > property 'svn:externals' set on 'wc\externals-container' > Sending wc\externals-container > > Committed revision 2. > Copying externals container from URL to WC > U wc\externals-container-copy > > Fetching external item into 'wc\externals-container-copy\ext1': > Checked out external at revision 2. > > > Fetching external item into 'wc\externals-container-copy\ext2': > Checked out external at revision 2. > > Checked out revision 2. > svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-169DB674' to > 'C:\t\wc\externals-container-copy': Access is denied. > > -- > > Best Regards > Alexey 0 Moudrick > = > > > > -- > C. Michael Pilato > CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Philip Martin writes: > Paul Burba writes: > >> I'm able to replicate this failure on my Windows box with my own >> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as >> expected with 1.6.17, so this appears to be a regression. Moving back >> to the dev list. >> >> Investigating... > >>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to >>> 'C:\t\wc\externals-container-copy': Access is denied. > > I suspect this is a directory move. Perhaps the wc.db file of the > external is still open? Can a directory be renamed on Windows when one > of the files inside it is still open? Stopping in svn_io_file_rename on Linux I see: Breakpoint 2, svn_io_file_rename ( from_path=0x6b78e0 "/home/pm/sw/subversion/obj/wc/.svn/tmp/svn-E0d1tM", to_path=0x685508 "/home/pm/sw/subversion/obj/wc/ecc", pool=0x6b5978) and $ ls -l /proc/10833/fd | grep subver lrwx-- 1 pm pm 64 Feb 17 15:53 7 -> /home/pm/sw/subversion/obj/wc/.svn/wc.db lrwx-- 1 pm pm 64 Feb 17 15:53 9 -> /home/pm/sw/subversion/obj/wc/.svn/tmp/svn-E0d1tM/e1/.svn/wc.db so we are renaming a dir while a wc.db is open. -- Philip
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
Paul Burba writes: > I'm able to replicate this failure on my Windows box with my own > builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as > expected with 1.6.17, so this appears to be a regression. Moving back > to the dev list. > > Investigating... >> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to >> 'C:\t\wc\externals-container-copy': Access is denied. I suspect this is a directory move. Perhaps the wc.db file of the external is still open? Can a directory be renamed on Windows when one of the files inside it is still open? -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
Re: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
On Fri, Feb 17, 2012 at 10:54 AM, Philip Martin wrote: > Paul Burba writes: > >> I'm able to replicate this failure on my Windows box with my own >> builds of trunk@1245285, 1.7.0 and 1.7.3. Alexey's script works as >> expected with 1.6.17, so this appears to be a regression. Moving back >> to the dev list. >> >> Investigating... > >>> svn: E720005: Can't move 'C:\t\wc\.svn\tmp\svn-8ED6923C' to >>> 'C:\t\wc\externals-container-copy': Access is denied. > > I suspect this is a directory move. Perhaps the wc.db file of the > external is still open? Can a directory be renamed on Windows when one > of the files inside it is still open? Not in my experience.
