RE: Can the Apache front end and svnserve service run on the sameserver?
See also http://subversion.apache.org/docs/release-notes/1.7.html#per-repos-authz Bert Sent from Mail for Windows 10 From: Thorsten Schöning Sent: woensdag 5 augustus 2015 21:34 To: users@subversion.apache.org Subject: Re: Can the Apache front end and svnserve service run on the sameserver? Guten Tag Stefan Sperling, am Mittwoch, 5. August 2015 um 14:58 schrieben Sie: > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.multimethod.html I have a similar task to do and while your link describes what do to around file permissions, I wonder how to deal with authentication and authorization: Each of my repos has it's own passwd and authz file and I would like to know if it's possible to use those per repo-configs in httpd? For the authentication part I guess it might be possible using mod_perls PerlAuthenHandler[1]. This looks like I could parse passwd per repo on my own using the repo name from the URL and knowing the paths to the repos. But what about "AuthzSVNAccessFile"? It seems like this configuration only accepts one simple path to one single file and there's no per repo logic available. I wouldn't want to merge all my authz files to one big one for maintenance reasons and such. Is there any way to hook into processing of AuthzSVNAccessFile and to dynamically provide the needed data or build the path to the file using some placeholders, where one placeholder is the name of the repo or such? There's PerlAuthzHandler[2] for mod_perl again, but I wouldn't want to reimplement the processing logic of authz files itself, just would like to have more influence which path to choose on each request. [1] https://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthenHandler [2] https://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthzHandler 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 (un)lock commands succeed when pre-(un)lock hooks fail on svn 1.9
Can you confirm that the file is locked after the command? (E.g. by running svn status on the target) Does it lock the file when the hook blocks it… or does ‘svn lock’ return success? At the api level the lock command performs a callback per target to return the failure/success of each target, and it is not clear which part you call succeeded? The number of regression test of this operation was increased significantly for 1.9, as the behavior was made more consistent over the different ra layers and atomicity was improved. Bert Sent from Mail for Windows 10 From: Gustavo Chaves Sent: zaterdag 22 augustus 2015 22:02 To: users@subversion.apache.org Subject: svn (un)lock commands succeed when pre-(un)lock hooks fail on svn 1.9 Hi there, It seems that svn 1.9 changed the behaviour of the "svn lock" and the "svn unlock" commands with regards to the fate of the corresponding pre-lock/pre-unlock hooks. Up to svn 1.8, when those hooks failed (exit code != 0) the commands (svn lock/unlock) failed too. Now, on svn 1.9, the commands always succeed. To reproduce you can execute the atached script, which creates a temporary directory, cd to it, creates a repository and a working copy, commits a file and then tries to lock the file, before and after installing a hook that always fail. With svn 1.8 in you path the results would be like this: $ ./repro-lock.sh The files will be left in the /tmp/tmp.xoidDWLkub directory + cd /tmp/tmp.xoidDWLkub + svnadmin create repo + svn --version + head -1 svn, version 1.8.10 (r1615264) + svn co file:///tmp/tmp.xoidDWLkub/repo wc Checked out revision 0. + cd wc + touch file.txt + svn add file.txt A file.txt + svn ci -mx Adding file.txt Transmitting file data . Committed revision 1. + svn up Updating '.': At revision 1. + svn lock file.txt 'file.txt' locked by user 'gustavo'. + echo lock succeeded without a hook lock succeeded without a hook + cat + chmod +x ../repo/hooks/pre-lock + svn lock file.txt svn: E165001: Lock blocked by pre-lock hook (exit code 1) with no output. + echo lock failed with a failing hook lock failed with a failing hook Now, with svn 1.9 in your path the results are like this: $ ./repro-lock.sh The files will be left in the /tmp/tmp.qGx4oqIlNo directory + cd /tmp/tmp.qGx4oqIlNo + svnadmin create repo + svn --version + head -1 svn, version 1.9.0 (r1692801) + svn co file:///tmp/tmp.qGx4oqIlNo/repo wc Checked out revision 0. + cd wc + touch file.txt + svn add file.txt A file.txt + svn ci -mx Adding file.txt Transmitting file data .done Committing transaction... Committed revision 1. + svn up Updating '.': At revision 1. + svn lock file.txt 'file.txt' locked by user 'gustavo'. + echo lock succeeded without a hook lock succeeded without a hook + cat + chmod +x ../repo/hooks/pre-lock + svn lock file.txt svn: warning: W165001: Lock blocked by pre-lock hook (exit code 1) with no output. + echo lock succeeded with a failing hook lock succeeded with a failing hook The problem was reported to me by the Debian maintainers of my SVN::Hooks Perl module at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795756. -- Gustavo.
RE: Incomplete SVN dump files
In what way was the dump file incomplete? Was it broken halfway through a file? (That should have been caught via the checksums in the file). If a whole node edit is missing it is still a complete dumpfile and there is no way the current dump doesn’t know when a revision is done. (This allows editing the revisions in this format; as is sometimes done on migrations) Bert From: Eric Johnson Sent: dinsdag 15 september 2015 07:16 To: users@subversion.apache.org Subject: Incomplete SVN dump files I'm in a situation where I'm dumping Subversion repositories from remote locations (using svnrdump). The repositories are big enough, and the network connections between destinations just unstable enough that the repositories aren't making it all in one dump call. I've noticed, for one repository in particular, that I actually got a dump file that had only a part of the last commit before the connection broke. When I loaded up the repository, Subversion reported no problems on the svnadmin load, but it seems to me it should have noticed that the final commit recorded in the dump file was incomplete, and discarded it. Instead, it happily loaded it, and reported no problems. At least I was lucky enough to check that it was complete, and I used a technique to drop all but the last revision. Now I can load a new dump file from the commit that was incomplete. This brings me back to my question - shouldn't the load process ignore the last commit if it is incomplete in the dump file? That way I know I have an error to address! Eric.
RE: Redirection "svn info -r HEAD"
The TortoiseSVN build of the commandline binaries in 1.9.0 and 1.9.1 have known issues. Please retry with another release (following the CRT linkage rules), or use a newer 1.9.x daily build of TortoiseSVN where the linkage problem is fixed. I’m not sure if this fixes your specific problem, but I don’t have this known broken set of commandline binaries installed on my system. (I had to track a few similar cases earlier this week, all caused by this CRT linkage problem) Bert From: Fredrik Klasson Sent: vrijdag 18 september 2015 11:34 To: users@subversion.apache.org Subject: Redirection "svn info -r HEAD" TL;DR: "svn info -r HEAD > testfile" produces and empty file with svn 1.9.1 on Windows. But svn 1.8.13 produces expected output in the file. Does this only happen for me? When I updated to TortoiseSVN 1.9.1 (from 1.8.11), which uses svn 1.9.1 it seems redirection of "svn info -r HEAD" (or any other revision specification) no longer works for me in MS Windows. So I wonder if anyone else has experienced this too with subversion 1.9.1? Some steps to reproduce the issue. 1. Install TortosieSVN 1.9.1 2. In a cmd.exe prompt with cwd being a svn working copy, type: svn info (expected output) svn info > testfile type testfile (output that matches running without redirection) 3. Then try with the revisionargument (using -r or --revision): svn info -r HEAD (expected output) svn info -r HEAD > testfile type testfile (nothing, i.e .file is empty; cf. running without the redirect) And just for the sake of testing adding "--xml" makes svn info produce the expected output to the redirected file (that is "svn info -r HEAD --xml > testfile" works). So it seems only "plain"/"old" output is broken. Downgrading to TortoiseSVN 1.8.11 which uses svn 1.8.13 makes "svn info -r HEAD > testfile" produce the expected file contents in the test file again. For good measure, I've also tested building on a Linux machine, using subversion 1.9.1 (build from the svn tag/1.9.1). Redirection of "svn info -r ..." works as expected with that build. (My distro uses 1.8.13 currently so that's why I build from vanilla sources to test that). So this seems to only affect Windows. Some additional info: OS version: Windows 7 Professional (x64) I couldn't find any bug report for this, but maybe I just didn't ask the database the right question. I haven't had time to try to build trunk or 1.9.1 vanilla on Windows, and I don't know if TortoiseSVN applies any patches on top of the svn it includes (I'd guess they do not apply any though). Passing a path to a repo does not affect the behavior. Passing an invalid revision (e.g. "-r FOOBAR") produces an error message (as expected). Cheers /Fredrik -- ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn
RE: Redirection "svn info -r HEAD"
https://msdn.microsoft.com/en-us/library/ms235460.aspx “Potential Errors Passing CRT Objects Across DLL Boundaries” And really the first paragraph summarizes what happens here: “When you pass C Run-time (CRT) objects such as file handles, locales, and environment variables into or out of a DLL (function calls across the DLL boundary), unexpected behavior can occur if the DLL, as well as the files calling into the DLL, use different copies of the CRT libraries.” TortoiseSVN started to use a statically used CRT in all their .DLLs and just passed the CRT file handle of stdout between them. They reverted to using a shared CRT in the latest builds which fixes these problems. Bert From: Fredrik Klasson Sent: vrijdag 18 september 2015 13:36 To: b...@qqmail.nl Cc: users@subversion.apache.org Subject: Re: Redirection "svn info -r HEAD" Ok thanks for the input :) Sounds reasonable to suspect CRT linkage issues since stdout/stderr I/O operations probably rely on the CRT behaving. I'll see if a TortoiseSVN daily fixes the problem as soon as I get time. But if that doesn't fix it, so I should file a bug with TortoiseSVN instead then? (Just out of curiosity, is there a particular set of bugs/mailinglist messages about the root cause for those CRT linkage problems? (being a developer I find it interesting to learn from other's linker/-age issues)) On Fri, Sep 18, 2015 at 11:47 AM, wrote: The TortoiseSVN build of the commandline binaries in 1.9.0 and 1.9.1 have known issues. Please retry with another release (following the CRT linkage rules), or use a newer 1.9.x daily build of TortoiseSVN where the linkage problem is fixed. I’m not sure if this fixes your specific problem, but I don’t have this known broken set of commandline binaries installed on my system. (I had to track a few similar cases earlier this week, all caused by this CRT linkage problem) Bert From: Fredrik Klasson Sent: vrijdag 18 september 2015 11:34 To: users@subversion.apache.org Subject: Redirection "svn info -r HEAD" TL;DR: "svn info -r HEAD > testfile" produces and empty file with svn 1.9.1 on Windows. But svn 1.8.13 produces expected output in the file. Does this only happen for me? When I updated to TortoiseSVN 1.9.1 (from 1.8.11), which uses svn 1.9.1 it seems redirection of "svn info -r HEAD" (or any other revision specification) no longer works for me in MS Windows. So I wonder if anyone else has experienced this too with subversion 1.9.1? Some steps to reproduce the issue. 1. Install TortosieSVN 1.9.1 2. In a cmd.exe prompt with cwd being a svn working copy, type: svn info (expected output) svn info > testfile type testfile (output that matches running without redirection) 3. Then try with the revisionargument (using -r or --revision): svn info -r HEAD (expected output) svn info -r HEAD > testfile type testfile (nothing, i.e .file is empty; cf. running without the redirect) And just for the sake of testing adding "--xml" makes svn info produce the expected output to the redirected file (that is "svn info -r HEAD --xml > testfile" works). So it seems only "plain"/"old" output is broken. Downgrading to TortoiseSVN 1.8.11 which uses svn 1.8.13 makes "svn info -r HEAD > testfile" produce the expected file contents in the test file again. For good measure, I've also tested building on a Linux machine, using subversion 1.9.1 (build from the svn tag/1.9.1). Redirection of "svn info -r ..." works as expected with that build. (My distro uses 1.8.13 currently so that's why I build from vanilla sources to test that). So this seems to only affect Windows. Some additional info: OS version: Windows 7 Professional (x64) I couldn't find any bug report for this, but maybe I just didn't ask the database the right question. I haven't had time to try to build trunk or 1.9.1 vanilla on Windows, and I don't know if TortoiseSVN applies any patches on top of the svn it includes (I'd guess they do not apply any though). Passing a path to a repo does not affect the behavior. Passing an invalid revision (e.g. "-r FOOBAR") produces an error message (as expected). Cheers /Fredrik -- ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn -- ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn
RE: Bug report: The auto-props setting of svn:mime-type is impossibleto avoid.
The problem with xml in general is that is used in many scenarios. In some usages it can be handled as text, while in other usages it is really binary data where every whitespace change could be a breaking change. Xml is just a container format that makes many usages possible. We can't make that decision for every xml user in Subversion by just flipping the behavior. (We discussed this many times before) The best fix would be that magic really detects your xml form from the other xml forms, like it already detects many other forms. In many cases it can do this based on a xmlns definition or other hint. If your format is really text like application/* is a mismatch for you, but when you are storing signed information -with a signature at the end- in xml you really don't want to see automatic merges. I think the original decision to register an application/* type by the xml inventers was a safe decision. Your files are just not 'generic xml', and should have a more specific type. Bert From: Ivan Zhakov Sent: zondag 4 oktober 2015 11:35 To: Edward d'Auvergne Cc: users@subversion.apache.org Subject: Re: Bug report: The auto-props setting of svn:mime-type is impossibleto avoid. On 2 October 2015 at 11:06, Edward d'Auvergne wrote: > Hi all, > > I was wondering if this should be considered a bug. At the FlightGear > project we have a 6 GB data svn repository for aircraft ( > https://sourceforge.net/projects/flightgear/ , > https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/ ). A large > quantity of the files, almost 30,000 in number, are XML text files. > > The problem is that modern Subversion clients appear to all be using > libmagic to determine the file type, to then set the svn:mime-type > property. However this is rather problematic: > > $ file -ib Aircraft/747-400/747-400-set.xml > application/xml; charset=us-ascii > > Libmagic detects all these XML files as "application/xml". Hence they > are treated as binary files! There are many other text files with > extensions such as *.ac, *.nas, etc. present in the repository that in > the future might be detected by libmagic as "application/xyz". > Easy fix would be change svn_mime_type_is_binary() to consider 'application/xml' as text file. We can also extend for other specific application/* mimetypes that are text files. We already have special handling for 'image/x-xbitmap' to consider it as text file. Does it make sense? -- Ivan Zhakov
RE: Commit Size Restriction
How do you define ‘commit size’? With delta compression, re-use on copies of files and directory trees, etc. it is very hard to define what size a commit would be. And as we have pluggable filesystem backends we don’t know what amount of disk space would be used after a commit. Personally I would just use a simple commit filter if necessary, to avoid users accidentally committing DVD images. Bert Sent from Mail for Windows 10 From: Siva Sent: woensdag 13 juli 2016 16:07 To: subversion-users Subject: Commit Size Restriction Hi All, My Subversion Edge is installed in Windows Server. Is it possible to restrict commit size by repository or whole server? Regards, Sivaram
Re: subversion changes file permissions on commit
Does the file have any specific properties, such as svn:eol-style or svn:keywords? Bert From: Thorsten Schöning Sent: Tuesday, October 22, 2013 8:05 AM To: users@subversion.apache.org Guten Tag Branko Čibej, am Dienstag, 22. Oktober 2013 um 07:13 schrieben Sie: > No, because Subversion does not promise to restore original file > permissions, and therefore you shouldn't rely on it to do so. It's not about restoring, but not changing them during/after a commit. 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: crash report
> -Original Message- > From: lieven.govae...@gmail.com [mailto:lieven.govae...@gmail.com] On > Behalf Of Lieven Govaerts > Sent: vrijdag 8 oktober 2010 19:59 > To: Wolff, Dave > Cc: users@subversion.apache.org > Subject: Re: crash report > > On Fri, Oct 8, 2010 at 6:32 PM, Wolff, Dave wrote: > > The following happens every time I try to update a development branch to > the > > head of another branch. Let me know if theres anything I can do to help > > get you more information. > > > > This looks like the previously reported issue in sliksvn: > http://svn.haxx.se/users/archive-2010-09/0065.shtml The 1.6.13 binaries with a fix for this error should be on the site soon. (I provided the binaries, but they have to be placed on the public site) Bert > hth, > > Lieven
RE: German console output
> -Original Message- > From: svn-u...@web.de [mailto:svn-u...@web.de] > Sent: donderdag 21 oktober 2010 1:48 > To: 'Mark Phippard' > Cc: users@subversion.apache.org > Subject: AW: German console output > > Hi Mark, > > So I want to post to the list, that I am a user who IS looking for > German output. That was quite an installation procedure, first to > install > then deinstall CollabNet's binaries (because not internationalized) > then the same for WANdisco's binaries. > Also both, CollabNet and Wandisco, don't include the BDB module. > > Finally I found the full compilation including German support and BDB > at > Win32Svn at http://alagazam.net. These are the binaries I am now > working with. > I was just wondering why CollabNet doesn't also offer a full > compilation will all modules and internationalized. > (Since Svn origined at CollabNet.) The binaries from the Slik Subversion client (http://www.sliksvn.com/en/download) also support localization (and BDB + Sasl), but they only support the client parts of Subversion; not the server. Bert
RE: Feature request: Support of Windows Codepage 850
> -Original Message-
> From: svn-u...@web.de [mailto:svn-u...@web.de]
> Sent: zondag 31 oktober 2010 19:35
> To: users@subversion.apache.org
> Subject: Feature request: Support of Windows Codepage 850
>
> Hi there!
>
> All output, that comes from the svn internationalization, shows
> correctly
> on both codepages, 850 and 1252. E. g. error messages or "svn help ci".
> Good.
> (Font in use is Lucida Console.)
>
> This shows, that it *is* possible for svn, to produce correct output on
> both
> codepages, 850 and 1252.
>
> But output that comes from file data ("svn cat file") only prints
> correct with
> Codepage 1252. Seems, that this output goes through a different piece
> of code,
> that is not able to adjust to the Codepage in use.
>
> So at the moment the behaviour of svn with Codepage 850 is
> inconsistent:
> sometimes supported ("svn help ci"), sometimes not ("svn cat").
>
> Currently I need Cygwin's cat command to convert the output of "svn
> cat" to
> Codepage 850:
> svn cat file | cat
>
> Feature request:
> "svn cat file" should also work with Codepage 850.
>
> Who agrees, that this feature request is worth a prio P4 issue?
>
> (I have to use Codepage 850, because Cygwin needs it.)
'svn cat file' doesn't perform any translation at all. It just writes what
is in 'file' to the standard output device.
(Subversion doesn't know which character encoding is used in 'file')
Bert
RE: pre-lock.bat Failed in Repo browser
I don't think %VISUALSVN_SERVER% is set in your lock script. Subversion
explicitly clears most environment variables before calling hook scripts.
Most likely your script can't find svnlook.exe
Bert
From: Waseem Bokhari [mailto:waseem.bokh...@netsoltech.com]
Sent: dinsdag 8 maart 2011 7:52
To: users@subversion.apache.org
Subject: pre-lock.bat Failed in Repo browser
Hi Experts!
Below is the "pre-lock.bat " Script
Only User who lock the file can unlock the file. Other users are forbidden
to Unlock file.
@echo off
:: Set all parameters
set repository=%1
set repopath=%2
set user=%3
:: Set path to svnlook
set svnlook=%VISUALSVN_SERVER%bin\svnlook.exe
:: First check that the lock exists already.
:: In that case svnlook prints the lock description.
"%svnlook%" lock "%repository%" %repopath% | findstr /B /L "UUID Token:" >
NUL 2>&1
:: If the lock does not exist, allow locking
if ERRORLEVEL 1 exit 0
:: Now check the lock's owner
"%svnlook%" lock "%repository%" %repopath% | findstr /C:"Owner: %user%" >
NUL 2>&1
:: If the person locking matches the lock's owner, allow locking
if %ERRORLEVEL% EQU 0 exit 0
:: Otherwise, return failure
echo "Error: %repopath% is locked already." >&2
exit 1
Issue/Problem!!
This scenario failed in Repo Browser. Any one can Unlock File/Folder through
Repo Browser.
Please advice me accordingly.
Thanks
DISCLAIMER: This e-mail and any file transmitted with it are confidential
and intended solely for the use of the addressee. If you are not the
intended recipient, you are hereby advised that any dissemination,
distribution or copy of this email or its attachments is strictly
prohibited. If you have received this email in error, please immediately
notify us by return email and destroy this email message and its
attachments. This communication may contain forward-looking statements
relating to the development of NetSol Technologies' products and services
and future operations. The words "believe," "expect," "anticipate,"
"intend," variations of such words, and similar expressions, identify
forward looking statements, but their absence does not mean that the
statement is not forward-looking. Views and opinions contained herein are
those of the author of this email and do not necessarily represent those of
NetSol Technologies. Statements contained herein are not guarantees of
future performance and are subject to certain risks, uncertainties and
assumptions that are difficult to predict. The company will not undertake to
update any statements contained herein.
WARNING: The recipient should check this email and any attachment for the
presence of viruses. Although the company has taken reasonable precautions
to ensure no viruses are present in this email, the company does not accept
responsibility for any loss or damage arising from the use of this email or
attachment. Note: Please consider the environment before printing this
e-mail.
RE: XML parsing and checksum mismatch errors at updates and checkouts
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: vrijdag 8 april 2011 11:11 > To: Daniel Shahaf > Cc: Aleksandr Platonov; d...@subversion.apache.org; > users@subversion.apache.org > Subject: Re: XML parsing and checksum mismatch errors at updates and > checkouts > > Daniel Shahaf writes: > > > [ summary for dev@: bug in trunk that doesn't reproduce in 1.6.16; > > I can reproduce it with trunk/ra_serf but not with trunk/ra_neon ] > > > > Aleksandr Platonov wrote on Thu, Apr 07, 2011 at 17:52:13 +0400: > >> > >> I build Subversion as a part of TortoiseSVN (see > >> > http://tortoisesvn.googlecode.com/svn/trunk/ext/build/subversion.build) > >> > >> This problem happens when I try to checkout following url: > >> http://svn.webdav.org/repos/projects/neon/tags/0.29.5 > >> > > > > I can reproduce it (with trunk svn): > > > > * Checking out that URL over ra_neon proceeds normally. > > > > * Checking out that URL over ra_serf is > > (a) noticeably slower > > (b) fails with a checksum error: > > > > svn: E200014: Checksum mismatch for '/tmp/svn/neon-0.29.5-via- > serf/src/ne_auth.c': > >expected: 4ce0a5989ad4d1b0f7f66ae08c1e05c1 > > actual: 5848237f8c173bd25a118db45cd5574a > > I was getting that error last month: > > http://svn.haxx.se/dev/archive-2011-03/0745.shtml > > What I find is that the problem sometimes appears and sometimes does > not. It's not predictable either, repeating a failed export/checkout > will sometimes work and sometimes fail at a different place. That is > the case when I try that neon URL: > > svn: E200014: Checksum mismatch for > 'subversion/tests/xx/src/ne_openssl.c': >expected: 3bd789b372ca14793e8ac228cdf43a15 > actual: be72d4221d805da2484b1cd0182b9049 > > svn: E200014: Checksum mismatch for 'subversion/tests/xx/src/ne_ssl.h': >expected: 6fbb6c5dda02229623c887a9a08b1533 > actual: 4f0c8e04845b70ebf1e88adbb780a2f0 > > I suspect the pool/memory handling in serf or libsvn_ra_serf, but I'm > not certain. The update in one fetch operation in neon doesn't receive all checksums in all places. Serf receives a few more, because it uses a request per file. For trunk I fixed the missing checksums for 1.7, so a trunk server with a trunk client gets all the checksums editor v1 supports. But using an older server or an older client will not. In that case you just get the calculated checksums in your working copy. I think this server is pre 1.5, but it is certainly possible to get invalid checksums in a checkout when you encounter the problems mentioned in issue #3711. But you don't encounter these problems with trunk clients. Bert
RE: repo on Windows -- why not?
> -Original Message- > From: Blair Zajac [mailto:bl...@orcaware.com] > Sent: donderdag 28 april 2011 19:39 > To: Danil Shopyrin > Cc: Michael Hüttermann; Bob Archer; users@subversion.apache.org > Subject: Re: repo on Windows -- why not? > > On 4/28/11 9:42 AM, Danil Shopyrin wrote: > >> are there any arguments to prefer Windows? (beside arguments that you > drive > >> a Windows shop) > >> ok, looks like I have to adjust the section a bit. > > > > It's also very important to integrate Subversion seamlessly with > > Active Directory and other existing Windows infrastructure (it applies > > to Windows shops, of course). > > Just to add a bit to this, if one has Active Directory but uses Unix servers, > one doesn't have to deploy on Windows to authenticate, can use LDAP in > httpd to > authenticate against AD. But currently this doesn't support NTLM/SSPI yet where you don't have to use/cache your credentials. Using mod_auth_sspi in Apache on Windows (or VisualSVN server, which does the same thing + adds their own extensions) does support that. Bert
RE: Chkeckout only a portion of a repoistory
> -Original Message- > From: Gavin "Beau" Baumanis [mailto:gavin.bauma...@palcare.com.au] > Sent: woensdag 11 mei 2011 3:22 > To: Subversion Users > Subject: Chkeckout only a portion of a repoistory > > Hi there, > > We have a web application that uses Jenkins CI for keeping our staging server > up to date via svn update. > > Due to not thinking abut it properly in the beginning, > The staging site is actually a working copy of the entire repo (branches and > tags included) > > We however, only require the trunk. > > Is there a way, so that I can remove the branches and tags from a working > copy, leaving the trunk in place AND > not have any subsequent updates replace the now missing directories and > still have a clean WC? If you call svn up --set-depth exclude PATH on your tags and branches folder, they should be completely removed from your working copy, leaving a marker that they shouldn't be updated. (You can bring them back by --set-depth infinity on a parent or an explicit update of PATH itself). This option is available for directories since Subversion 1.6. (In 1.7 you can also use it to exclude a specific file) Bert
RE: svnadmin: Path '....' is not in UTF-8 - svnadmin load fails
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 31 mei 2011 0:10 > To: Torsten Krah > Cc: users@subversion.apache.org > Subject: Re: svnadmin: Path '' is not in UTF-8 - svnadmin load fails > > Torsten Krah wrote on Mon, May 30, 2011 at 23:47:30 +0200: > > Am Dienstag, den 31.05.2011, 00:30 +0300 schrieb Daniel Shahaf: > > > Solution is to recode the pathnames (those that are neither in ASCII > > > nor in UTF-8). > > > > Sorry but your "solution" seems really a little bit odd to me. > > If <1.6 did not enforce this and 1.6 does - why does 1.6 not recode it > > at the time it does encounter such "things" - at least via some optional > > command line option? > > > > Do you really want to tell me that subversion (the "tool" used to manage > > my code) is not able to load its own "dump", at least by providing some > > "fix" tool by itself if it did things not "right" before - why should i > > need or bother with "third-party" tools here - this should be done by > > svn, shouldn't it? > > > > As Stefan said, it would be nice if Subversion itself could fix that, > given that old released versions produced such (malformed) filesystems. > > To my knowledge, currently there is no code in Subversion itself to do > this, hence my suggestion to use third-party tools. The problem is: We just know it isn't utf-8. But that doesn't tell us how to fix it. But which encoding does it have, if it isn't utf-8 as expected? Without telling Subversion could choose from hundreds of different encodings (iso-8859-1?, etc., etc.), which might just contain the one you would like. (Or maybe your filesystem used format 101). Subversion defines that it must be utf-8, so it can't answer this question for you. Bert
RE: How to undo a switch?
> -Original Message- > From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] > Sent: dinsdag 7 juni 2011 17:06 > To: users@subversion.apache.org > Subject: Re: How to undo a switch? > > On Tuesday 07 June 2011, Bill Herring wrote: > > I have just selected a file and chose ‘switch to’ a tag recently used to > > tag a release of my complete project. I mistakenly assumed that in doing > > so I would just switch the particular file to the version in the tagged > > release. > > The reason that this doesn't work is that Subversion is a versioned storage > for files. What many people consider tags or branches is completely > irrelevant > to Subversion itself, so it can't determine the "correct" file within your > "project" when you switch a file to a certain "tag". > > BTW: In case you wonder if that is a bug or feature, I have used this feature > to switch a file to a directory. The current Subversion 1.7 development snapshot warns you when you do this and requires that you pass --ignore-ancestry if you really want to switch to something unrelated. Bert
RE: 1.7.0-alpha1 feedback (Issue #3933)
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: dinsdag 21 juni 2011 10:31 > To: Daniel Shahaf > Cc: users@subversion.apache.org; Uwe Schuster > Subject: Re: 1.7.0-alpha1 feedback > > On Tue, Jun 21, 2011 at 10:51:08AM +0300, Daniel Shahaf wrote: > > FWIW it's not just a problem with (explicit) port specifications, there > > is a similar issue when an external definition uses https://svn.a.o and > > my checkout URL uses https://svn.eu.a.o. > > > > The 'same repos' checks could use UUID rather than URL. > > Yeah, looking at the URL is not right. (See my last comment to the issue.) That depends on where you look at it. This error is raised in the ra layer (Inside svn_ra_reparent) where you have a connection to a single repository via its url: In that location it should fail on every url not pointing to exactly the same repository. I think this issue is caused by the ra_serf code that removes default port numbers when you connect to a repository by using APR. Neon used its own rules so it wouldn't fail. But with our strict rules that any uri passed to our apis must be canonical, we shouldn't see this problem. But as I found out (and fixed in r1137927) our uri canonicalization for user provided uris didn't check port numbers at all. Bert
RE: Possible bug moving file and then deleting directory
Patrick,
I can't reproduce the tree conflict in either of those cases using the
combination of a trunk client and repository. (I can reproduce it with 1.6)
Can you please verify if you really used the right binaries for your test?
I can reproduce it up to the out of date error:
svn.exe ci -m "" svn-test-work\working_copies\tree_conflict_tests-24
Deleting svn-test-work\working_copies\tree_conflict_tests-24\A\B
svn: E155011: Commit failed (details follow):
svn: E155011: Directory
'R:\Svn-2010\tests\subversion\tests\cmdline\svn-test-work\working_copies\tre
e_conflict_tests-24\A\B' is out of date
svn: E160028: Directory '/A/B' is out of date
But an update after that doesn't raise a tree conflict for me.
The test script I wrote is:
def update_dir_with_not_present(sbox):
"lock status update shouldn't flag tree conflict"
sbox.build()
wc_dir = sbox.wc_dir
newtxt = sbox.ospath('A/B/new.txt')
main.file_write(newtxt, 'new.txt')
sbox.simple_add('A/B/new.txt')
sbox.simple_commit()
sbox.simple_move('A/B/new.txt', 'A/C/newer.txt')
sbox.simple_commit()
sbox.simple_rm('A/B')
# We can't commit this without updating (ra_svn produces its own error)
run_and_verify_svn(None, None, "svn: E(155011|160028): Dir.*B.*out of
date",
'ci', '-m', '', wc_dir)
# So we run update
run_and_verify_svn(None, None, [],
'up', wc_dir)
# And now we can commit
run_and_verify_svn(None, None, [],
'ci', '-m', '', wc_dir)
(It is actually part of
http://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/tr
ee_conflict_tests.py now)
Bert
From: Patrick Quirk [mailto:p.qu...@smt.com]
Sent: donderdag 23 juni 2011 15:08
To: Johan Corveleyn; Mark Phippard
Cc: users@subversion.apache.org
Subject: RE: Possible bug moving file and then deleting directory
Using the Collabnet binaries rolled from r1136035 I see the same behavior
using the script from my original email.
It does sound pretty similar to 3526, though my repro script is a bit
different. However I created a script to reproduce issue 3526 and that also
fails for me. To summarize, both of these sets of steps have the same
outcome:
Issue 3526:
1.) Add a file in a directory, commit
2.) Delete that directory, commit fails saying the directory is not up to
date
3.) Update -> tree conflict
My initial email:
1.) Add a file in a directory, commit
2.) Move that file to another directory, commit
3.) Delete the first directory, commit fails saying the directory is not up
to date
4.) Update -> tree conflict
Regarding Mark's pointer to the FAQ, I realize the tree conflicts are
expected behavior in a sense, but I feel like the steps before that should
work regardless. Especially since I'm committing at a level above the
directory in question that does have operations done on it to advance the
current revision number. I doubt anyone would know that an update is
required in the middle of these steps.
I've attached the script I used to reproduce 3526, maybe someone could
review it and make sure I'm matching what the issue is describing, and
confirm that it does/doesn't work for them either? It's a windows batch
file (zipped and renamed).
_
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: Wednesday, June 22, 2011 7:03 PM
To: Mark Phippard
Cc: Patrick Quirk; users@subversion.apache.org
Subject: Re: Possible bug moving file and then deleting directory
It seems this behavior has changed in 1.7 (to be released soon). It will no
longer flag this as a tree conflict. See
http://subversion.tigris.org/issues/show_bug.cgi?id=3526.
AFAICS, the case described here is similar to the one described in issue
#3526.
Patrick, if you have some time, maybe you can test this with one of the
pre-releases of 1.7? See
http://subversion.apache.org/packages.html#pre-release.
Cheers,
--
Johan
On Wed, Jun 22, 2011 at 10:44 PM, Mark Phippard wrote:
See http://subversion.apache.org/faq.html#self-tree-conflict
On Wed, Jun 22, 2011 at 4:04 PM, Patrick Quirk wrote:
I've run into this issue the past few days and I don't feel like this is
expected behavior. I'm using client version 1.6.17 (Collabnet binaries).
Simply put, I move a single file, commit that, then try to delete the
directory the file was in (it's empty now) and commit that. This fails,
saying the directory I'm attempting to commit/delete is out of date. If I
update it, I get a tree conflict.
Am I wrong in expecting this to work without an update in the middle? I've
provided a batch file to reproduce the behavior on a Windows machine (unzi
RE: access denied errors Windows 7
> -Original Message- > From: Ken G. Brown [mailto:kbr...@mac.com] > Sent: maandag 27 juni 2011 19:13 > To: users@subversion.apache.org > Subject: access denied errors Windows 7 > > Hi, new here, > I'm trying to get TortoiseSVN 1.6.16, Build 21511 - 32 Bit , 2011/06/01 19:00:35, > and Subversion 1.6.17 working on fully updated Windows 7 running under > VMware Fusion Version 3.1.3 (416484) on my Mac. > When I do an export from a repo into a new folder, I always get an error, > 'Can't move 'C:svn-451D8A18' to 'C:\myFolder': Access is denied'. I've found a > lot of talk about this access denied error in Win 7 on the Net, have tried > everything I've found with no luck. Can someone point me in the right > direction please. Are you sure this error is something like ''C:svn-451D8A18' and not like ''C:\svn-451D8A18'? (Can you copy an exact error message?) This is an export from a url to a directory and not an export from a directory to a directory? Bert
RE: Doing svn checkouts on top of svn checkouts?????
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 12 juli 2011 5:47 > To: Nico Kadel-Garcia > Cc: Geoff Hoffman; Subversion > Subject: Re: Doing svn checkouts on top of svn checkouts? > > Nico Kadel-Garcia wrote on Mon, Jul 11, 2011 at 23:42:07 -0400: > > On Mon, Jul 11, 2011 at 10:21 PM, Daniel Shahaf > wrote: > > > Geoff: you cannot point a single working copy item at more than one > URL. > > > (well, unless you create two externals with the same target file. Don't > > > do that.) > > > > > > Nico: explain /exactly/ what you have been doing (best: a script(1) > > > transcript). I don't know if you are complaining about nested working > > > copies, or about running svn co $URL $dir where $dir is a subdir or root > > > of a working copy, or something else altogether. > > > > Oh, it's not *me* doing it. Someone, as part of their software build > > environment, is doing the moral equivalent in their setup scripts of > > this: > > > >svn checkout $URL $targetdir > >make -C $targetdir install > > > > Then, for testing, they do this > > > >cd $targetdir > > # Edit local files, not necessarily submitted to > > upstream repository > > > > Then a day or a week later, they re-run the script. > > > > svn checkout $URL $targetdir > > AFAIK, this will run 'svn up' and not lose local mods. This will just verify if $URL matches the URL of $targetdir and if it doesn't you will get an error. If the test passes it will just perform an update to the requested revision (or in this case HEAD) This was originally designed so you could create restartable scripts that perform a checkout. So if the checkout fails you can just rerun checkout and it continues where it stopped the last time. (For scripts this might be easier than running 'svn update $targetdir) Bert
RE: Doing svn checkouts on top of svn checkouts?????
> -Original Message- > From: Andreas Krey [mailto:a.k...@gmx.de] > Sent: dinsdag 12 juli 2011 10:07 > To: Geoff Hoffman > Cc: Subversion > Subject: Re: Doing svn checkouts on top of svn checkouts? > > On Tue, 12 Jul 2011 00:30:06 +, Geoff Hoffman wrote: > ... > > To clarify what I meant - say you have Repo-A/Path-B and Repo-X/Path-Y. > You > > could cd into your working copy of Path-B and do svn checkout Repo- > X/Path-Y > > Y and end up with B/Y in your working copy such that changes under Y > commit > > to Repo-X and changes under B not under Y commit to Repo-A. I have a > hunch > > this (not throwing an error) is by design, because it is *almost* identical > > to how svn:externals work. I just tested this and Y shows up as ? when > > doing svn status under B. > > I didn't test that, but I suppose that Y is not known to the 'outer' > svn sandbox, and changes in the 'inner sandbox (Y) wouldn't be committed > or shown in 'svn status'. > > Can you 'svn switch' a subtree to a different repo? And what happens > then on a commit? :-) No, you can't switch a subtree to a different repository. You can exclude a directory and perform a new checkout in its place though. But this starts a new working copy. Bert
RE: Perplexing results of SVN commit
> -Original Message- > From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > Sent: dinsdag 12 juli 2011 4:13 > To: Warren Jones > Cc: users@subversion.apache.org > Subject: Re: Perplexing results of SVN commit > > On Jul 11, 2011, at 14:07, Warren Jones wrote: > > > One of our developers got perplexing results from an SVN commit. As far > as I can tell, this is what happened: > > > >1. Developer checks out trunk of SVN project to working directory. > >2. "svn copy" some files from branch into working directory. > >3. Edit and modify files copied from branch. > >4. "svn commit" in working directory. > > > > After the commit: > > > >1. "svn status" shows the working directory is up to date. > >2. "svn diff" shows no modified files in the working directory. > >3. Repository contains files copied from branch to trunk. > >4. Repository **does not** contain subsequent mods to those files. The > commit somehow missed these changes. > >5. File mods are still in the working directory, although not shown by "svn > diff". > >6. After file time stamps are updated with "touch", "svn diff" shows > changes. > > > > I'm unable to reproduce this odd state of affairs, but I have the repository > and the developer's working directory to prove that something went wrong > with the commit. I don't know whether it was operator error or a bug in SVN. > > Sounds to me like operator error of the following kind: the developer > modified the files in the working copy, and also made identical modifications > to the corresponding pristine files in .svn/text-base (frequently this happens > when using a batch search-replace tool). Because even after the edits the > contents of the pristine files match the regular files, "svn st" and "svn di" > don't show the changes and they don't get committed. > > If this is what happened, check out a fresh working copy, manually copy over > the changed files, and commit them. And ensure that in the future you do > not edit anything in the .svn directories. Some batch search-replace tools let > you define directories they're not to touch. 'svn status' only notices that files are modified if either the size or the date changed since the last subversion operation that modified the file. (Subversion automatically waits for some time to make sure other tools can't change files in the same second when the filesystem has less than or exactly 1 second timestamp precision) A clock skew between tool and filesystem might introduce this problem if you have a script that updates files directly after update. But personally I would guess that Ryan's answer is far more likely as usually at least some file sizes change. Bert
RE: 1.7 alpha3 bug (assert/exception) during update
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: woensdag 20 juli 2011 1:19 > To: Gunnar Dalsnes; d...@subversion.apache.org > Cc: users@subversion.apache.org > Subject: Re: 1.7 alpha3 bug (assert/exception) during update > > tldr for dev@: assertion that Gunnar and I can both reproduce easily > using 1.7.0-beta1: > > % $svn checkout -q https://zlibnet.svn.codeplex.com/svn test > % $svn update test > (asserts) Note that codeplex doesn't run a real subversion server. It uses svnbridge (see http://svnbridge.codeplex.com ). Their documentation says that they created svnbridge by reverse engineering the wire protocol of TortoiseSVN (somewhere around Subversion 1.5) Bert
RE: Subversion: existing users
> -Original Message- > From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] > Sent: woensdag 20 juli 2011 4:31 > To: Nico Kadel-Garcia > Cc: Bob Archer; users@subversion.apache.org > Subject: Re: Subversion: existing users > > > > On 07/20/2011 05:24 AM, Nico Kadel-Garcia wrote: > > On Tue, Jul 19, 2011 at 12:16 PM, Bob Archer > wrote: > >>> The most obvious authorization scheme is that of the host server; > >>> if > >>> there is a user named "andy" on that server with a password > >>> "jackel" > >>> then I would like to simply be able to talk to the subversion > >>> server as > >>> user named "andy" password "jackel". This is how ssh and sftp work. > >>> But > >>> apparently subversion can't handle that. True? > >> I would say FALSE. > >> > >> BOb > > It's feasible, but problematic. The solution involves giving "andy" a > > valid account on that machine, one with a local or network password, > User 'andy' already has a valid ssh/sftp login account on that machine. > Access to anything is controlled by the usual *nix mechanisms (in this > case OS X). > > because the "andy" account needs to be able to run the "svnserve" > > program. And doing this leads to risks of exposing the rest of the > > system to all your Subversion users. Also, group ownership to a shared > > repository needs to be carefully managed, and it puts the repository > > at risk of malcious users simply logging in and deleting bits from the > > Subversoin database. > My concept, which may be wrong, was that snvserve is run at boot time, > probably as user 'root' but possibly as a different user set up for this > task. I had assumed that the repositories in /var/svn/* are owned by the > svnserve user, and that the client (svn) can run on any computer in the > network. Then svn talks to svnserve via port 3690 and svnserve checks > the authentication (valid user name & password) and authorization > (permissions) and then svnserve does whatever is requested to the > particular repository (/var/svn/RepoName). > > Apparently I'm wrong, since you say that user 'andy' has to run svnserve > himself. If we do this for 'andy' and "bill' does this mean we're > running two copies of svnserve at the same time, one as user 'andy' and > the other as user 'bill'? Svnserve can be used in two different modes. If you use svnserve via svn:// things work as you assumed. But if you use svn+ssh:// svnserver is started as the user who creates the ssh tunnel (as described in this mail). Bert
RE: Logging Subversion client HTTP requests
> -Original Message- > From: Manuel Lemos [mailto:mle...@acm.org] > Sent: zondag 31 juli 2011 5:00 > To: Geoff Hoffman > Cc: users@subversion.apache.org > Subject: Re: Logging Subversion client HTTP requests > > Hello, > > on 07/30/2011 10:57 PM Geoff Hoffman said the following: > > Does httpclient work if you switch it to the cURL option? You may need > > to extend the class to provide https specific curl options [1]. > > > > [1] > > http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https- > ssltls-protected-sites/ > > I just figured the problem. It was not working with Curl either because > I was resolving the IP address of the server before opening the SSL > connection and I should have used the original host name for servers > like this for some reason related with the way PHP establishes SSL > connections. > > Anyway, this problem is solved now. Thanks for the interest in helping out. > > I still have a problem with CodePlex SubVersion, which is also accSSL, > but I think I will figure out comparing with requests sent by the svn > program to non-SSL sites. I will let you know otherwise. Codeplex is a reimplementation of the svn server by reverse engineering (instead of looking at the developer documentation), so it might be different in ways not detected by the standard libraries. (And they have quite a list of 'known' issues that aren't resolved yet) Bert > > > -- > > Regards, > Manuel Lemos > > JS Classes - Free ready to use OOP components written in JavaScript > http://www.jsclasses.org/
RE: Do svn:externals changes need to be committed to work?
> -Original Message- > From: Markus Schaber [mailto:m.scha...@3s-software.com] > Sent: dinsdag 2 augustus 2011 10:27 > To: André Hänsel; users@subversion.apache.org > Subject: AW: Do svn:externals changes need to be committed to work? > > Hi, André, > > Von: André Hänsel [mailto:an...@webkr.de] > > I am trying to add an svn:externals definition to a working copy. I set > > the property on a directory and ran svn update on that directory, but > > nothing is fetched. > > > > I found this article: > > http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/ > > However, from other documentation it's unclear to me if a commit is really > > necessary for svn:external to work. Of course, I don't want to commit an > > untested external definition. > > > > I am using TortoiseSVN 1.6.15 built with Subversion 1.6.16. > > From my experience with Subversion 1.6, the directory needs to be > committed, but not the svn:external definition itsself. > > So maybe you can commit the empty directory, and then add the externals > properties and test them before committing them. In Subversion 1.7 externals definitions don't have to be committed to work correctly. In 1.6 I would recommend committing them before applying, but in many cases it will work if you don't do that. We integrated the tracking of which externals a working copy has in the new working copy store. The next 'svn update' will apply the changes even if the directory on which they are defined was never committed. Bert
RE: 1.7 'svn upgrade' issue on windows vista
> -Original Message- > From: Stephen Meechan [mailto:s...@smeechan.co.uk] > Sent: vrijdag 5 augustus 2011 1:04 > To: users@subversion.apache.org > Subject: 1.7 'svn upgrade' issue on windows vista > > While testing out the svn upgrade feature in 1.7 beta 2, on some working > copies the upgrade failed with an error E155036. > > The problem was that the svn upgrade command is case sensitive on the WC > folder name and failed if the name doesn't match exactly. Windows itself is > case insensitive and none of the other svn commands are case sensitive to > the WC folder name. > > The following test case shows the steps to reproduce the problem using a > public server: Thanks for reporting (and the nice reproduction recipe). I just fixed the issue in r1154165. (This patch won't make beta 3, but I'll nominate it for backport for 1.7.0) Bert
RE: 1.7 corrupts WC when reverting add of changelist member
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: dinsdag 9 augustus 2011 23:29 > To: Stein Somers > Cc: users@subversion.apache.org > Subject: Re: 1.7 corrupts WC when reverting add of changelist member > > On Tue, Aug 09, 2011 at 09:53:37PM +0200, Stein Somers wrote: > > When you revert an addition in your working copy, and the item > > appeared in a changelist, the working copy becomes corrupt and you > > can't ever use the filename again. I built a maintainer mode version > > from /branches/1.7.x@1155504 which balks (after a boring stack > > trace): > > > > svn: E155016: Corrupt data for './sandbox/wc/x' > > > > at the end of this test script: > > I can reproduce this on trunk. > Can you please file an issue? Thanks! Ok, we reproduced this issue in our test suite and fixed it on trunk in r1156098. (The fix is nominated for backport to 1.7) Bert
RE: [Subversion] Rational Rhapsody files, lock unlock philosophy
> -Original Message- > From: Keller Eric [mailto:ekel...@hamilton-medical.ch] > Sent: woensdag 10 augustus 2011 17:22 > To: users@subversion.apache.org > Cc: Hug Martin > Subject: [Subversion] Rational Rhapsody files, lock unlock philosophy > > Hi everybody, > > We are finally switching from PVCS to subversion, and I would like to get > more input from you other user concerning the lock/modify/unlock > philosophy! > > Subversion as PVCS allow the use of locks. The description in your reference > book: http://svnbook.red-bean.com/en/1.0/ch02s02.html also presents the I see a /1.0/ there. > Copy modify merge solution, which is more commonly used. Yet our > manager people are not convienced that this method is better than a lock > unlock modify solution. Please (also) check the more recent versions of the book on the same site. The version you are looking at was written for Subversion 1.0 and a lot has changed since then. (I think svn lock wasn't introduced until 1.1 or 1.2) Bert
RE: svn command line client SNI
> -Original Message- > From: Mario Brandt [mailto:jbl...@gmail.com] > Sent: vrijdag 12 augustus 2011 19:44 > To: users@subversion.apache.org > Subject: svn command line client SNI > > Hi, > is there any chance that the standart svn client supports SNI? If your Subversion client is compiled against a recent openssl and neon/serf version it supports SNI. (I think most binary distributions fall in this category) Bert > > Cheers > Mario
RE: Proxy authentication with Negotiate uses wrong host
> -Original Message- > From: 1983-01...@gmx.net [mailto:1983-01...@gmx.net] > Sent: woensdag 24 augustus 2011 10:47 > To: users@subversion.apache.org > Subject: Re: Proxy authentication with Negotiate uses wrong host > > > On Wed, Aug 24, 2011 at 09:25:49AM +0200, 1983-01...@gmx.net wrote: > > > I'll do but why is Negotiate auth activated in session.c if the target > > host is ssy only? This should be on the user to decide not subversion. > > > > I don't know who made this decision and why. > > Maybe svn blame on that file leads to more info? > > I checked blame already. There was a rather long explanation but still no > argument to me. The Subversion parts of this code were written when neon only supported NTLM via Negotiate. NTLM is known to be insecure when not used over https. Then somebody added Kerberos support to neon, but the api wasn't updated to allow different behavior for the specific implementations. As Stefan already noted: this discussion belongs on the neon mailinglist. Once neon supports the necessary hooks/apis to enable Negotiate for the secure protocols we can enable them in Subversion. (Or maybe neon can just enable the safe protocols all the time?) @serf developers: This should probably be handled in serf too. Bert
RE: 1.7.0-rc2: abnormal program termination on Windows
> -Original Message- > From: Marc Strapetz [mailto:marc.strap...@syntevo.com] > Sent: woensdag 7 september 2011 14:40 > To: users@subversion.apache.org > Subject: 1.7.0-rc2: abnormal program termination on Windows > > With the pre-built CollabNet binaries from > https://ctf.open.collab.net/sf/go/rel2972, I get an abnormal program > termination, if the URL is not valid: > > D:\temp>svn --version > svn, version 1.7.0-rc2 (Release Candidate 2) >compiled Aug 26 2011, 11:47:28 > > D:\temp>"C:\program files (x86)\Subversion\svn.exe" checkout > file://d:\temp\test\repo.svn d:\temp\wc.svn > svn: E235000: In file '..\..\..\subversion\libsvn_client\checkout.c' > line 94: assertion failed (svn_uri_is_canonical(url > , pool)) > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. I can reproduce this problem and will look into fixing this. There are two problems with your URL that will probably make it fail even after this assertion is fixed. The correct url format is file:///d:/temp/test/repo.svn with three slashes after file:. file://server/share/ would translate to \\server\share, so your path points to \\d:\temp\test\repo.svn. Bert
RE: Recursion / reentrancy in SVN 1.7
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 15 september 2011 11:28 > To: Markus Schaber > Cc: users@subversion.apache.org > Subject: Re: Recursion / reentrancy in SVN 1.7 > > On Thu, Sep 15, 2011 at 10:41:58AM +0200, Markus Schaber wrote: > > Hi, > > > > In our SharpSVN-based software, we happened to have recursive calls to > > GetStatus inside the progress notification handlers. This worked fine > > using SVN 1.6, but now with SVN 1.7, some operations like Checkout throw > > an Exception, due to the working copy database being locked. > > > > Maybe our internal design is suboptimal in this case, and I've > > successfully developed a workaround, so it is not critical. > > > > But this still is a regression. > > This is an sqlite limitation. We cannot do much about it without > taking a huge performance hit. No, it doesn't have to be a sqlite limitation, it could be a difference between the old loggy code and how we handle the working queue now. If there are workingqueue operations we don't allow opening the database at all, while we used to allow reading the entries for things like status. What kind of error do you get? (The SharpSvn stacktrace isn't really interesting for the users on this list, but the message that is part from the trace matches exactly what you would get from svn) Bert
RE: Authentication realm
Passwords are stored per hostname (+realm), not per working copy like in your webbrowser, so using a different hostname requires adding a new username+password in your credential cache. Storing it in a different way would allow tricking subversion to send the username and password to any other server. Bert From: Gavin Baumanis [mailto:gav...@thespidernet.com] Sent: vrijdag 30 september 2011 5:14 To: Subversion Users Subject: Authentication realm Hi Everyone, We recently created a DNS entry for our subversion repository. Prior to this we just use the private LAN IP address to access the repo via http (Apache) Post the change to having a hostname to use I created a new branch - and used the host name to do this. Subsequently when I perform an svn update I a now prompted for username and password for the named instance of our repo. I did some reading in the "good" book. and used svn switch (svn switch old_IP_address new_HostName_Address at the root of my working copy. svn info confirms that the repo address is now set to the hostname version of the URL. However I am still getting prompted for a username and password. If I enter the "usual" password - all is good... but the prompt is playing havoc without Continuous Integration scripts. Some more reading suggests that I might need to add a new authentication realm and users via; conf/svnserve.conf I was hoping that I might just get some confirmation that is indeed what I need to do - before I go "playing" with the config scripts. As always - a big thanks for your help. Gavin.
RE: TortoiseSVN exception dialog improvements?
> -Original Message- > From: Stefan Küng [mailto:tortoise...@gmail.com] > Sent: maandag 17 oktober 2011 21:28 > To: Mark Phippard > Cc: users@subversion.apache.org > Subject: Re: TortoiseSVN exception dialog improvements? > > On 17.10.2011 19:46, Mark Phippard wrote: > > I wonder if the TortoiseSVN team could create a link to a Google > > search for the error code on the dialog where they ask the user to > > report the problem? It could ask them to check that link first for > > other reports of the same problem. > > > > That might cut down on the list spam and also get the user an answer > faster. > > I've already removed the email address of the users group from the error > message, only the link to the web page for the mailing list is still there. > > As you may recall, I've always been opposed to the assert statements. I > prefer clear error messages and a proper cleanup of resources, > especially if there _is_ a chance to do so. Maybe now you guys > understand why. > > > Alternatively, maybe we could add some kind of error code lookup URL > > on our site? Something like: > > > > http://subversion.apache.org/errorcode/E235000 > > > > TortoiseSVN could link user to this URL and our page could direct the > > user to a wiki page for known errors or a Google search otherwise? > > When an error becomes really common we could add a wiki page for that > > code, otherwise just do a search. > > > > Just some thoughts. > > Since I was repeatedly told that assert statements are only used if > there's no chance to return an error and clean up the resources, I can't > use a custom dialog in that case but must rely on the windows own > message box. Because that's the only dialog that's guaranteed to work > even in situations where stack and heap are corrupted. > And that means no clickable links, no buttons to start a browser, ... assert() is only used in these cases, but this is automatically disabled in release builds. In both these reported cases the code calls SVN_ERR_ASSERT() which can simply return an error code from the handler. See the documentation in svn_error.h. Only SVN_ERR_ASSERT_NO_RETURN() has the problems you describe as 'no return possible', but you get a boolean in the handler to see in which variant you are. Another option is to throw a C++ exception and catch it when the call stack is back in your code. If you then clean the pool you passed to the function your own code should work reliable again. (You can't be sure that calling into Subversion is safe, but from what I hear from AnkhSVN users it appears to just work even though I do recommend them to restart Visual Studio if this problem occurs) Bert
RE: Very big problems with access rights (authz file using) in SVN v1.7.0
> -Original Message- > From: Andrey [mailto:and...@online-solutions.ru] > Sent: dinsdag 18 oktober 2011 11:54 > To: users@subversion.apache.org > Subject: Very big problems with access rights (authz file using) in SVN v1.7.0 > Importance: High > > Hello! > > We had upgraded from SVN v1.6.5 to SVN v1.7.0, and now we have a > really big problems, because SVN v1.7.0 is not working as previous SVN > versions and incorrectly working with restrictions for some > directories in authz. > > A simple example of the issue: > > Let's assume this authz file: > === > [repos:/PROJECT/trunk/Sample] > ax = rw > mh = rw > lk = rw > sa = r > ep = rw > > [repos:/PROJECT/trunk/Sample/AnyDir/RestrictedDir] > ax = rw > mh = rw > * = > === > > SVN v1.6.5 and all clients worked with it in the following manner: > 1. They are allowed to use 'svn update' command on the "Sample" directory. > 2. They are showed "Sample/AnyDir/RestrictedDir" in repo-browser >(TortoiseSVN GUI), but did not allowed to update/commit or view >content of this directory. > 3. There are no any problems to make svn update in any part of the >"/Sample" dir and subdirs using svn client (command line) or any >other (GUI) client. > > After upgrading our server to SVN v1.7.0 we had a really big problems, > because now when we try to make update in the root directory (/Sample) > we see something like: > > == > == > Updating '.': 13:5 > Restored 'Sample\AnyDir\RestrictedDir' > svn: E155000: Failed to mark > 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir' > absent: item of the same name is already scheduled for addition > == > == > > So, SVN update failed! > > No we cannot use our BUILD SERVER, also coders are unable to make SVN > UPDATE locally with the same problem! > > We have a complicated access rules for different users. Now it does > not work AT ALL! Because if some directory is available for user to > see that it is exist (it is made to give a possibility to make a > commits in a root directory, and do not split commits to a few dirs), > he will unable to make svn update in the root -- svn will fail on this > directory, that must be easly skipped, as SVN v1.6.5 server/clients > done before! > > This is a really serious problem for us, we can't work now. Can you post a simple walkthrough script that describes your exact problem. By just reading your mail I would guess the script is: As user lk do: $ svn co http://server/repos/PROJECT/trunk/Sample sample $ svn up sample (repeat the update) But this simple scenario appears to work correctly for me as it doesn't check out AnyDir/RestrictedDir in my tests. The ouput of svn says that you update the directory above 'Sample'. Things I'm interested in are like: * Do multiple users share a single working copy? So AnyDir/restricteddir is checked out by one user, but wouldn't be by the user updating. Or the other way around. * Is the configuration changed between updates? Is some change in a specific location required between updates? E.g. one in AnyDir, RestrictedDir, etc. I can see some problems, which might need fixing but I'm still not sure what your specific problem is. (I'm not sure if the problems I currently see are regressions. Still looking into that) The error you see would only make sense if the working copy doesn't know about RestrictedDir, except that it is a locally added file or directory. When the server then tells that there should be a restricted path there you get this error. But giving a working copy with a single user, that is +- impossible to read in your mail. Bert
RE: E155010: "The node was not found" when updating a sparse working copy
> -Original Message- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > Sent: dinsdag 18 oktober 2011 15:38 > To: users@subversion.apache.org > Subject: E155010: "The node was not found" when updating a sparse working > copy > > Hi! > > When I have a sparse wc and there have been some changes in the > omitted subdirectories, > the "svn up" command may produce spiritous warnings trying to update > files that do not exist locally. > > I am using 1.7.0, http: or https: protocol, Neon library. > > Script that reproduces this issue with apache.org repository: > [[[ > svn co http://svn.apache.org/repos/asf/tomcat/site/trunk/@1183302 wc > svn up -r 1183302 wc/docs --set-depth empty > svn up -r 1183305 wc > ]]] > svn: E155010: The node '(...)\wc\docs\security-6.html' was not found. Ok, this one is easy to reproduce with this clean reproduction script. (Confirming this as an issue) I will look into this. Bert
RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0
> -Original Message- > From: Andrey [mailto:and...@online-solutions.ru] > Sent: dinsdag 18 oktober 2011 15:53 > To: Johan Corveleyn > Cc: Stefan Sperling; Bert Huijben; users@subversion.apache.org > Subject: Re[4]: Very big problems with access rights (authz file using) in SVN > v1.7.0 > > Здравствуйте, Johan. > > Вы писали 18 октября 2011 г., 17:43:48: > > JC> 2011/10/18 Andrey : > >> Здравствуйте, Stefan. > >> > >> Вы писали 18 октября 2011 г., 17:20:56: > >> > >>>> But when we using SVN v1.7.0 (console client from the same build as > >>>> server; or TortoiseSVN), we had a problem. When user (who is > >>>> restricted to access /RestrictedDir) tries to make svn update on the > >>>> root dir (/Sample), he got error as I described above. > >>>> > >>>> Updating '.' > >>>> Restored 'Sample\AnyDir\RestrictedDir' > >>>> svn: E155000: Failed to mark > 'D:\BUILD_ROOT\PROJECT\trunk\Sample\AnyDir\RestrictedDir' > >>>> absent: item of the same name is already scheduled for addition > >>>> > >>>> SVN does not skip this directory, it creates is locally(!) as empty > >>>> directory(!) and stop/fail on svn update after this. > >>>> > >>>> That's all. > >> > >> SS> Can you please clarify which versions were running on the client > >> SS> and which version was running on the server when the problem > appeared? > >> > >> SS> Both running 1.7? > >> SS> Server 1.6 and clients 1.7? > >> SS> Clients 1.6 and server 1.7? > >> > >> SS> From what you're saying the only thing I understand is that both > >> SS> 1.6 client and 1.6 server was working. > >> > >> All for users, who have no access to restricted dir: > >> > >> 1. Server: SVN v1.7.0 (WANdisco build) > >> Client: TortoiseSVN v1.7.0 > >> > >> NOT WORKING (update problem; empty directory created, update > failed) > >> > >> 2. Server: SVN v1.7.0 (WANdisco build) > >> Client: Console SVN v1.7.0 (WANdisco build) > >> > >> NOT WORKING (update problem; empty directory created, update > failed) > >> > >> 3. Server: SVN v1.7.0 (WANdisco build) > >> Client: TortoiseSVN v1.6.15 (Subversion v1.6.16) > >> > >> [!] WORKING as previous behaviour! > >> > >> So, the problem is really inside CLIENT interpretation of server > >> statuses. Both new version of console svn.exe (svn client) and > >> TortoiseSVN working incorrectly now. > > JC> Is it broken only for working copies that were upgraded from 1.6 to > JC> 1.7, or also for new checkouts done with your 1.7 client? > > JC> I'm wondering if it's a bug in the upgrade code (server-excluded nodes > JC> being incorrectly upgraded), or in the general handling of > JC> server-exluded nodes in 1.7. > > Yes, you are right, it is a bug with upgrade procedure. > > I made an expirement: > > 1. Made a clean checkout to a new place on a computer of user with >restricted access. Checkout was without any problem. > 2. After this I tried to make svn update -- all was fine. > 3. After this from my computer I made a "cross" commit (one commit >includes a change to a files, where users have no access, and to a >files accessed by them). >I used SVN update on root directory on restricted-users -- all was >fine. > > So, if a clean checkout (without upgrade) is made, there is no such > problem. Ok, with that information I reproduced this problem in the Subversion test suite on upgrading a working copy with server excluded (or 'absent') nodes. After the upgrade updates fail. I will look into fixing this problem tomorrow. (If somebody else wants to look first, please let me know ;-) Bert
RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: dinsdag 18 oktober 2011 19:43 > To: 'Andrey'; 'Johan Corveleyn' > Cc: 'Stefan Sperling'; users@subversion.apache.org > Subject: RE: Re[4]: Very big problems with access rights (authz file using) in > SVN v1.7.0 > Ok, with that information I reproduced this problem in the Subversion test > suite on upgrading a working copy with server excluded (or 'absent') nodes. > After the upgrade updates fail. > > I will look into fixing this problem tomorrow. (If somebody else wants to > look first, please let me know ;-) The problem is fixed on trunk and I nominated it for backport. Please ping your favorite committer to make him review the patch for inclusion in 1.7.1 ;) All upgrades of working copies that contains information on subdirectories where the user doesn't have access to, have this same problem. I think the only real way to resolve this issue on a working copy is checking out again. Bert
RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: woensdag 19 oktober 2011 0:32 > To: Bert Huijben > Cc: Andrey; Stefan Sperling; users@subversion.apache.org > Subject: Re: Re[4]: Very big problems with access rights (authz file using) in > SVN v1.7.0 > > On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben wrote: > >> -----Original Message- > >> From: Bert Huijben [mailto:b...@qqmail.nl] > >> Sent: dinsdag 18 oktober 2011 19:43 > >> To: 'Andrey'; 'Johan Corveleyn' > >> Cc: 'Stefan Sperling'; users@subversion.apache.org > >> Subject: RE: Re[4]: Very big problems with access rights (authz file > > using) in > >> SVN v1.7.0 > > > >> Ok, with that information I reproduced this problem in the Subversion > test > >> suite on upgrading a working copy with server excluded (or 'absent') > > nodes. > >> After the upgrade updates fail. > >> > >> I will look into fixing this problem tomorrow. (If somebody else wants to > >> look first, please let me know ;-) > > > > The problem is fixed on trunk and I nominated it for backport. > > > > Please ping your favorite committer to make him review the patch for > > inclusion in 1.7.1 ;) > > > > All upgrades of working copies that contains information on subdirectories > > where the user doesn't have access to, have this same problem. I think the > > only real way to resolve this issue on a working copy is checking out again. > > Would 'svn up -r0 path/to/restrictedDir' on an > already-upgraded-but-broken-wc also be able to repair it? No, this won't work. This trick relies on receiving the update from the current state to r0 from the server, but you don't have the authorization to get this update from the server. Bert
RE: Re[4]: Very big problems with access rights (authz file using) in SVN v1.7.0
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: woensdag 19 oktober 2011 9:26 > To: Bert Huijben > Cc: Andrey; Stefan Sperling; users@subversion.apache.org > Subject: Re: Re[4]: Very big problems with access rights (authz file using) in > SVN v1.7.0 > > On Wed, Oct 19, 2011 at 12:45 AM, Bert Huijben wrote: > > > > > >> -Original Message- > >> From: Johan Corveleyn [mailto:jcor...@gmail.com] > >> Sent: woensdag 19 oktober 2011 0:32 > >> To: Bert Huijben > >> Cc: Andrey; Stefan Sperling; users@subversion.apache.org > >> Subject: Re: Re[4]: Very big problems with access rights (authz file > > using) in > >> SVN v1.7.0 > >> > >> On Wed, Oct 19, 2011 at 12:17 AM, Bert Huijben wrote: > >> >> -Original Message- > >> >> From: Bert Huijben [mailto:b...@qqmail.nl] > >> >> Sent: dinsdag 18 oktober 2011 19:43 > >> >> To: 'Andrey'; 'Johan Corveleyn' > >> >> Cc: 'Stefan Sperling'; users@subversion.apache.org > >> >> Subject: RE: Re[4]: Very big problems with access rights (authz file > >> > using) in > >> >> SVN v1.7.0 > >> > > >> >> Ok, with that information I reproduced this problem in the Subversion > >> test > >> >> suite on upgrading a working copy with server excluded (or 'absent') > >> > nodes. > >> >> After the upgrade updates fail. > >> >> > >> >> I will look into fixing this problem tomorrow. (If somebody else wants > > to > >> >> look first, please let me know ;-) > >> > > >> > The problem is fixed on trunk and I nominated it for backport. > >> > > >> > Please ping your favorite committer to make him review the patch for > >> > inclusion in 1.7.1 ;) > >> > > >> > All upgrades of working copies that contains information on > > subdirectories > >> > where the user doesn't have access to, have this same problem. I think > > the > >> > only real way to resolve this issue on a working copy is checking out > > again. > >> > >> Would 'svn up -r0 path/to/restrictedDir' on an > >> already-upgraded-but-broken-wc also be able to repair it? > > > > No, this won't work. > > > > This trick relies on receiving the update from the current state to r0 from > > the server, but you don't have the authorization to get this update from > the > > server. > > And 'svn up -r0 path/to/parentOfRestrictedDir'? This has the same effect as a normal update op parentOfRestricted dir. So you probably receive a tree conflict (restricted dir is not unmodified) *and* the failed update (security problem). Bert
RE: Case-only renames
> -Original Message- > From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > Sent: vrijdag 21 oktober 2011 5:49 > To: Subversion Users > Subject: Case-only renames > > The Subversion 1.7 release notes say: > > http://subversion.apache.org/docs/release-notes/1.7.html#windows-case- > change > > > Changing case of file and directory names on Windows > > > > Subversion on Windows now fully supports changing the case of file and > directory names. No more special workarounds, a simple 'svn mv file.java > File.java' just does the right thing. > > Is this fix really Windows-specific, or is this also now fixed on OS X and other > systems with case-insensitive filesystems? > It is fixed on all operating systems where APR implements it's 'truename' handling for converting from 'aNYcASE' to 'TrueCase'. But this is currently only implemented on Windows and some tests still fail on OS/X. Some problems are fixed on OS/x by moving to SHA1 based pristines, but the APR api fix is needed to detect naming collisions properly. Bert
RE: Property encoding (was: Error during svnadmin load (svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' property))
> -Original Message- > From: Markus Schaber [mailto:m.scha...@3s-software.com] > Sent: woensdag 26 oktober 2011 16:49 > To: Subversion Users (users@subversion.apache.org) > Subject: Property encoding (was: Error during svnadmin load (svnadmin: > E125005: Cannot accept non-LF line endings in 'svn:log' property)) > > Hi, > > Von: Stefan Sperling [mailto:s...@elego.de] > > BTW, another trick to fix the issue is to copy the repository using > > svnsync. As of Subversion 1.6.3 (which is fairly old), svnsync normalizes > > all svn:* properties to LF line-endings automatically. > > Out of curiosity: how do Svn and svnsync distinct between binary and text > properties? > > Could svnsync mistakenly "fix" a binary property which happens to contain > CR-LF byte sequences? Within the svn:* namespace there are no binary properties. Svnsync doesn't transform other properties. Bert
RE: "Couldn't open rep-cache database" (post commit FS processing)
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: woensdag 16 november 2011 16:37
> To: Aleksandr Sidorenko
> Cc:
> Subject: Re: "Couldn't open rep-cache database" (post commit FS
> processing)
>
> Aleksandr Sidorenko writes:
>
> > But it seems it's not this error that is triggered; it's the one a few
lines down
> (I changed the error message to detect it):
> >
> > #if APR_HAS_THREADS
> > /* Wait for whichever thread is performing initialization to finish.
*/
> > /* XXX FIXME: Should we have a maximum wait here, like we have in
> > the Windows file IO spinner? */
> > else while (status != SVN_ATOMIC_INITIALIZED)
> > {
> > if (status == SVN_ATOMIC_INIT_FAILED)
> > return svn_error_create(SVN_ERR_ATOMIC_INIT_FAILURE, NULL,
> > "Couldn't perform atomic
initialization");
>
> Wow! The atomic operations are failing! Which OS? Which distribution?
> Which complier? 32-bit or 64-bit?
You get in this branch if a previous atomic initialization call failed: the
callback function failed and returned an error. This result is then ignored
in some code paths.
It is most likely not caused by the atomic operations failing itself, but
more likely by an initialization error in a third party library.
Bert
RE: Crash after upgrading to 1.7.2 from 1.6.1 in KDevelop
> -Original Message- > From: Aaron Williams [mailto:aaron.willi...@cavium.com] > Sent: dinsdag 24 januari 2012 8:29 > To: users@subversion.apache.org > Subject: Crash after upgrading to 1.7.2 from 1.6.1 in KDevelop > > Hi all, > > I upgraded Subversion in OpenSUSE 12.1 from the default 1.6.1 to 1.7.2 > compiled from sources. > > After upgrading I am seeing kdevelop crash each time I right click in the > editor. It gives me the following stack trace: > > Thread 2 (Thread 0x7f36f4b84700 (LWP 8151)): > [KCrash Handler] > #6 svn_wc__db_wcroot_parse_local_abspath (wcroot=0x7f36f4b835b0, > local_relpath=0x7f36f4b835b8, db=0x0, local_abspath=0x7f3700d4b758 > "/home/aaronw/projects/tot/sdk/bootloader/u- > boot/drivers/mmc/octeon_mmc.c", > result_pool=0x7f3700d41028, scratch_pool=0x7f3700d41028) at > subversion/libsvn_wc/wc_db_wcroot.c:383 This looks like a bug in kdevelop to me. The DB parameter must be a valid reference. My best guess would be that kdevelop just initializes a svn_wc_client_context_t with all 0s, while it should have used svn_client_create_context (). In Subversion <= 1.6 this worked ok for some operations although it was documented as *don't do this* since well before 1.0. Since Subversion 1.7 it will create this crash. Googling for kdevelop and Subversion got me: https://bugs.kde.org/show_bug.cgi?id=284061 Which validates my guess, and says it has been fixed since October 2011. So you should probably upgrade your kdevelop. Bert
RE: Seeking recommendations on sharing Subversion config within a development team
The easiest way to do this on Windows is storing the relevant entries in the registry. The standard Windows management tools make it easy to keep those synchronized over multiple tools. The per user settings are under: HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config And the common settings are under: HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Config (add WOW6432 when necessary for Win64) You can also use a configuration file in the all users appdata, just like you can use setting files in /etc/ on unix. Bert From: Timothy Astle [mailto:timothy.as...@caris.com] Sent: dinsdag 24 januari 2012 14:02 To: Nico Kadel-Garcia Cc: users@subversion.apache.org Subject: Re: Seeking recommendations on sharing Subversion config within a development team We mainly use Windows for development, so I'm thinking more about sharing the %APPDATA%\Subversion\config file. (Which if I recall correctly is the same as the $HOME/.svn/config on a *nix system.) I'm okay with sharing the entire directory contents or just a single file. Since we have a team of about 50 developers, it'd be really beneficial to keep everyone up to date. Maybe it's just as simple as having the system administrators push out updates to everyone's system. Has anyone tried to tackle this problem before I possibly go re-invent the wheel. :) Tim On 24/01/2012 12:02 AM, Nico Kadel-Garcia wrote: On Mon, Jan 23, 2012 at 2:22 PM, Timothy Astle <mailto:timothy.as...@caris.com> wrote: Does anyone have any recommendations for sharing the Subversion config file to a team of developers? I'd like to be able to ensure that all of the developers always have the latest corporately-approved configuration. Individual config files, s in $HOME/.svn config files? Or a Subversion published configuration for development environments? -- Timothy Astle, BCS Web Development Manager <http://www.caris.com> CARIS 115 Waggoners Lane Fredericton, New Brunswick CanadaE3B 2L4 Tel: +1.506.458.8533 Fax: +1.506.459.3849 <http://www.caris.com> www.caris.com Join us for CARIS 2012 - Exploration and Discovery June 25-28, 2012, Vancouver, British Columbia, Canada Visit <http://www.caris.com/caris2012> www.caris.com/caris2012 for details today Connect with CARIS <http://www.twitter.com/CARIS_GIS> Twitter | <http://www.linkedin.com/groups?mostPopular=&gid=3217878> LinkedIn | <http://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669? v=app_4949752878> Facebook | <http://www.youtube.com/user/CARISGIS> YouTube Download your free copy of CARIS Easy View today! <http://www.caris.com/easyview> www.caris.com/easyview _ This email and any files transmitted with it are confidential and intended only for the addressee(s). If you are not the intended recipient(s) please notify us by email reply. You should not use, disclose, distribute or copy this communication if received in error. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company.
RE: Issue report: subversion 1.7.2 windows command line client cannot copy URL -> WC if URL contains externals
> -Original Message- > From: Paul Burba [mailto:ptbu...@gmail.com] > Sent: woensdag 22 februari 2012 17:42 > To: Nico Kadel-Garcia > Cc: Philip Martin; C. Michael Pilato; Subversion Development; Alexey 0 > Moudrick; users@subversion.apache.org > Subject: 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 12:46 PM, Nico Kadel-Garcia > wrote: > > 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. > > I added an issue for this: > http://subversion.tigris.org/issues/show_bug.cgi?id=4123 > and a test also: > http://svn.apache.org/viewvc?view=revision&revision=1292090 > > The attached patch fixes this problem on Windows. Could any wc-ng > gurus take a look and see if this seems reasonable? > > [[[ > Fix issue #4123 'URL-to-WC copy of externals fails on Windows'. > > * subversion/include/private/svn_wc_private.h > (svn_wc__externals_close): New declaration. > > * subversion/libsvn_wc/externals.c > (svn_wc__externals_close): New definition. > > * subversion/libsvn_client/copy.c > (repos_to_wc_copy_single): Use new function to close handles to >externals' DB files before trying to rename the whole temp WC. > > * subversion/tests/cmdline/externals_tests.py > (url_to_wc_copy_of_externals): Remove XFail decorator and update > comments >re failure status. > ]]] I don't think the code should be conditional for Windows. On other platforms we should also close databases that we are about to move as our references to it (via abspath) are no longer valid anyway. (And who knows what sqlite does with the path internally...) I don't know what svn_wc__db_drop_root() does exactly, but the code should also flush some of the svn_wc__db_t internal state which maps abspaths to db handles. It might even be easier to resolve this problem this way: just release all databases below a specific path? Bert > > Even with this fix I'm still seeing odd behavior post-copy (the > following example uses a WC-to-WC copy, but the same problem occurs > with a URL-to-WC copy): > > ### We have a working copy at a uniform revision with an external: > > >svn up -q > > >svn st > X A\C\external > > Performing status on external item at 'A\C\external': > > >svn pl -vR > Properties on 'A\C': > svn:externals > ^/A/D/G external > > ### We copy the directory with the external definition: > > >svn copy A/C WC-to-WC-Copy-of-C > A WC-to-WC-Copy-of-C > > ### But the external shows up as unversioned: > > >svn st > X A\C\external > A +WC-to-WC-Copy-of-C > ? WC-to-WC-Copy-of-C\external > > Performing status on external item at 'WC-to-WC-Copy-of-C\external': > > Performing status on external item at 'A\C\external': > > ### Even if we commit an update the WC we see the same problem: > > >svn ci -m "" > Adding WC-to-WC-Copy-of-C > > Committed revision 3. > > >svn up > Updating '.': > > Fetching external item into 'WC-to-WC-Copy-of-C\external': > External at revision 3. > > > Fetching external item into 'A\C\external': > External at revision 3. > > At revision 3. > > >svn st > X A\C\external > ? WC-to-WC-Copy-of-C\external > > Performing status on external item at 'WC-to-WC-Copy-of-C\external': > > Performing status on external item at 'A\C\external': > > > > > To fix this we need to remove the external via the OS then update to > restore it (note that this problem occurs without my patch applied, so > this is a separate issue). > > Paul
RE: HTTPS with Serf: Certificate untrusted?
> -Original Message- > From: Joel Low [mailto:j...@joelsplace.sg] > Sent: donderdag 8 maart 2012 14:08 > To: users@subversion.apache.org > Subject: HTTPS with Serf: Certificate untrusted? > > Hello, I was recently trying to check out my source tree from Sourceforge over > HTTPS with Serf, and Subversion (command line client, TortoiseSVN was > affected too) complained that the certificate the server presented was not > trusted. I added the root cert to ssl-authority-files in servers, to no effect. > Switching over to Neon made the prompts go away (even with the ssl-authority- > files directive commented out). > > Am I missing something, or should the behaviour between the two RA layers be > the same? Serf reports a generic failure on some certificate errors, where neon reports an authority untrusted. Subversion only allows saving certificates as accepted for explicit errors like out of date or authority untrusted. When the certificate processing in the serf library is fixed Subversion will automatically work as expected. Bert > > Regards, > Joel
RE: Building Subversion For Windows
Hi, If you are using Subversion 1.7.3 for your test, please upgrade to 1.7.4. Subversion 1.7.3 always tries to build with apache httpd. This issue was fixed in 1.7.4. Bert From: Brad Lemings [mailto:b...@rebit.com] Sent: vrijdag 9 maart 2012 19:21 To: users@subversion.apache.org Subject: Building Subversion For Windows Hello all, I'm trying to build Subversion on Windows. When I run the gen-make.py script, I get this: >python gen-make.py --release -t vcproj --vsnet-version=2008 BDB not found, BDB fs will not be built Generating for Visual Studio 2008 Could not detect Ruby version, assuming 1.8. Ruby bindings will be linked with msvcrt-ruby18.lib Found installed perl version number. Perl bindings will be linked with perl512.lib Could not find installed SWIG, assuming version 1.3.25 Found JDK version 1.6 in C:\Program Files\Java\jdk1.6.0_27 Found SQLite version 3.7.10 Found ZLib version 1.2.6 Found neon version 0.29.6 Wrote: build\win32\vcnet-vcproj\build_zlib.bat Wrote: build\win32\vcnet-vcproj\build_locale.bat swig not found; skipping SWIG file generation... Wrote: build\win32\vcnet-vcproj\svn_config.vcproj Wrote: build\win32\vcnet-vcproj\svn_locale.vcproj Wrote: build\win32\vcnet-vcproj\zlib.vcproj Wrote: neon\neon.vcproj Wrote: build\win32\vcnet-vcproj\__ALL_TESTS__.vcproj Wrote: build\win32\vcnet-vcproj\__ALL__.vcproj Wrote: build\win32\vcnet-vcproj\__JAVAHL_TESTS__.vcproj Wrote: build\win32\vcnet-vcproj\__JAVAHL__.vcproj Wrote: build\win32\vcnet-vcproj\__LIBS__.vcproj Wrote: build\win32\vcnet-vcproj\atomic_ra_revprop_change.vcproj Wrote: build\win32\vcnet-vcproj\test_auth.vcproj Wrote: build\win32\vcnet-vcproj\test_cache.vcproj Wrote: build\win32\vcnet-vcproj\test_checksum.vcproj Wrote: build\win32\vcnet-vcproj\test_client.vcproj Wrote: build\win32\vcnet-vcproj\test_compat.vcproj Wrote: build\win32\vcnet-vcproj\test_config.vcproj Wrote: build\win32\vcnet-vcproj\test_db.vcproj Wrote: build\win32\vcnet-vcproj\diff.vcproj Wrote: build\win32\vcnet-vcproj\test_diff_diff3.vcproj Wrote: build\win32\vcnet-vcproj\diff3.vcproj Wrote: build\win32\vcnet-vcproj\diff4.vcproj Wrote: build\win32\vcnet-vcproj\test_dirent_uri.vcproj Wrote: build\win32\vcnet-vcproj\test_entries_compat.vcproj Wrote: build\win32\vcnet-vcproj\entries_dump.vcproj Wrote: build\win32\vcnet-vcproj\test_error.vcproj Wrote: build\win32\vcnet-vcproj\test_fs_pack.vcproj Wrote: build\win32\vcnet-vcproj\test_fs.vcproj Wrote: build\win32\vcnet-vcproj\test_hashdump.vcproj Wrote: build\win32\vcnet-vcproj\javahl_callback_javah.vcproj Wrote: build\win32\vcnet-vcproj\javahl_compat_java.vcproj Wrote: build\win32\vcnet-vcproj\test_javahl_compat.vcproj Wrote: build\win32\vcnet-vcproj\javahl_java.vcproj Wrote: build\win32\vcnet-vcproj\javahl_javah.vcproj Wrote: build\win32\vcnet-vcproj\test_javahl.vcproj Wrote: build\win32\vcnet-vcproj\javahl_types_javah.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_client_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_delta_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_diff_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_fs_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_fs_fs.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_fs_util.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_ra_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_ra_local.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_ra_neon.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_ra_svn.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_repos_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_subr_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_test.vcproj Wrote: build\win32\vcnet-vcproj\libsvn_wc_dll.vcproj Wrote: build\win32\vcnet-vcproj\libsvnjavahl.vcproj Wrote: build\win32\vcnet-vcproj\test_locks.vcproj Wrote: build\win32\vcnet-vcproj\test_mergeinfo.vcproj Traceback (most recent call last): File "gen-make.py", line 317, in main(conf, gentype, skip_depends=skip, other_options=rest.list) File "gen-make.py", line 65, in main generator.write() File "build\generator\gen_vcnet_vcproj.py", line 214, in write self.write_project(target, fname, deplist) File "build\generator\gen_vcnet_vcproj.py", line 86, in write_project configs = self.get_configs(target) File "build\generator\gen_win.py", line 476, in get_configs libdirs=self.get_win_lib_dirs(target, cfg), File "build\generator\gen_win.py", line 1000, in get_win_lib_dirs fakelibdirs.append(self.apath(self.httpd_path, cfg)) File "build\generator\gen_win.py", line 361, in apath if os.path.isabs(path): File "C:\Program Files\Python\27\lib\ntpath.py", line 57, in isabs s = splitdrive(s)[1] File "C:\Program Files\Python\27\lib\ntpath.py", line 125, in splitdrive if p[1:2] == ':': TypeE
RE: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
> -Original Message- > From: David Weintraub [mailto:qazw...@gmail.com] > Sent: woensdag 14 maart 2012 2:14 > To: Simon Dean > Cc: Nico Kadel-Garcia; Les Mikesell; Andreas Krey; Giulio Troccoli; > users@subversion.apache.org > Subject: Re: Feature request - SVN command to clean a working copy of all > unversioned and ignored files and directories > > On Mon, Mar 12, 2012 at 1:05 PM, Simon Dean > wrote: > > I suspect TortoiseSVN uses the official Subversion client code under the > hood. There's no way they'd > > re-implement a whole SVN client from scratch. > > I don't know if Tortoise uses any Subversion command line client code, > but TortoiseSVN does use the official Subversion API libraries. That's > what made Subversion so different from CVS. With CVS, you either had > to reimplement the client yourself, or use the offical CVS client as a > backend. In Subversion you write your own client, and just use the > API. > > SVNKit is very different. SVNKit is a Java third party > reimplementation of the Subversion API, and it's not the complete API > either. On the other hand, the JavaHL API is a front end to the > official Subversion API. > > So, it's possible for someone to write a Subversion client that does > do a "clean up". In fact, the Jenkins Continuous build system has the > option of doing a thorough clean before doing an update. > > > Other people have commented on the fragility of the "clean" task of a build > script. If you use things like NuGet > > and Bundler in codebases, they result in multiple directories that need > "cleaning" - e.g. .\vendor\bundle, > > .\packages etc. You'd be surprised how many unversioned files creep into a CI > build when all you're relying > > on is the build script's "clean" task > > For some reason, the .NET/C# world is behind in this concept when > compared to the Java world. By default, there's a "clean" target in > VisualStudio builds, but it doesn't do a very good job of cleaning. The standard files produced by Visual Studio should clean up everything, but if you customize your build you should also customize the cleanup. (This assumes that you pass the same custom variables to the build as the cleanup step of MSBuild. If not it cleans up a different build) And Visual Studio makes adding custom build tasks very easy, but doesn't provide an easy way to add your own cleanup tasks. (I see too many scripts that just call things like xcopy and assume this magically cleans up) When running from Visual Studio it appears that there are leftovers, but this is mostly because the Intellisense uses the same infrastructure to get its information. If you do find places where the common tasks leave files behind please report them as Microsoft is still taking bug reports for Visual Studio 11. And if these are Subversion and/or AnkhSVN specific problems please also send me a mail so I might be able to reach out via a few other channels. Bert
RE: svn 1.7: how to recover from a lost pristine file
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: woensdag 28 maart 2012 15:47 > To: Philip Martin > Cc: users@subversion.apache.org > Subject: Re: svn 1.7: how to recover from a lost pristine file > > On Wed, Mar 28, 2012 at 3:08 PM, Johan Corveleyn > wrote: > > On Wed, Mar 28, 2012 at 2:12 PM, Philip Martin > > wrote: > >> Johan Corveleyn writes: > >> > >>> For some reason, I lost a pristine file [*] in a 1.7 working copy. I'm > >>> trying to recover from this without having to throw away my entire > >>> working copy. So far I'm unsuccessful. Any help is appreciated. > >>> > >>> svn-1.7 is SlikSVN 1.7.4 (On Windows 7, 64bit): > >>> [[[ > >>> C:\Work\WC-root>svn-1.7 update -r0 the\file\with\missing\pristine.java > >>> svn: E155037: Previous operation has not finished; run 'cleanup' if it > >>> was interrupted > >>> > >>> C:\Work\WC-root>svn-1.7 cleanup the\file\with\missing > >>> svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' > locked. > >>> svn: E155004: 'C:\Work\WC-root' is already locked. > >>> svn: E155037: Previous operation has not finished; run 'cleanup' if it > >>> was interrupted > >>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) > >>> > >>> C:\Work\WC-root>svn-1.7 cleanup > >>> svn: E720002: Can't open file > >>> 'C:\Work\WC- > root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn- > base': > >>> The system cannot find the file specified. > >>> ]]] > >>> > >>> (the fact that the working copy is locked to begin with, was because a > >>> normal 'svn update' failed because of the missing pristine, with "svn: > >>> E155004: There are unfinished work items in 'C:\Work\WC-root'; run > >>> 'svn cleanup' first.", which is why I first found out about the > >>> problem) > >>> > >>> Anything I can do to investigate further? > >> > >> Use the sqlite3 utility > >> > >> sqlite3 .svn/wc.db "select * from work_queue" > > > > Thanks for your help, Philip. > > > > $ sqlite3 .svn/wc.db "select * from work_queue" > > 1|(file-install trunk/rootdir/the/file/with/missing/pristine.java 1 0 1 1) > > > >> These may show something: > >> > >> sqlite3 wc/.svn/wc.db "select * from nodes where local_relpath = > '/the/file/with/missing/pristine.java'" > >> > >> sqlite3 wc/.svn/wc.db "select * from nodes where checksum like > '%6d6e0892990e945b03a15b8e518dbef26848dc75'" > > > > Both of the above show the same: > > > 1|the/file/with/missing/pristine.java|0|the/file/with/missing|1|trunk/rootdi r/t > he/file/with/missing/pristine.java|176219|normal|||file|(svn:eol-style > > > native)||$sha1$6d6e0892990e945b03a15b8e518dbef26848dc75||175563|1332 > 375850493000|username|56722|1332709446087164|| > > > >> sqlite3 wc/.svn/wc.db "select * from pristine where checksum like > '%6d6e0892990e945b03a15b8e518dbef26848dc75'" > > > > That shows nothing. > > > >> Depending on what the work_queue shows you may be able to further > >> corrupt your working copy and then recover by doing this: > >> > >> sqlite .svn/wc.db "delete from work_queue" > >> svn up -r0 file > >> > >> IMPORTANT! Deleting the work_queue does generally make the working > copy > >> invalid, it is then up to you to ensure it returns to a valid state. > > Hm, no luck: > > [[[ > $ sqlite3 .svn/wc.db "delete from work_queue" > > $ sqlite3 .svn/wc.db "select * from work_queue" > > > C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java > svn: E155004: Working copy 'C:\Work\WC-root\the\file\with\missing' locked. > svn: E155004: 'C:\Work\WC-root' is already locked. > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) > > C:\Work\WC-root>svn-1.7 cleanup > > > > C:\Work\WC-root>svn-1.7 up -r0 the/file/with/missing/pristine.java > Updating 'the\file\with\missing\pristine.java': > svn: E720002: Can't open file > 'C:\Work\WC- > root\.svn\pristine\6d\6d6e0892990e945b03a15b8e518dbef26848dc75.svn- > base': > The system cannot find the file specified. > > > > $ sqlite3 .svn/wc.db "select * from work_queue" > 2|(file-install the/file/with/missing/pristine.java 1 0 1 1) > > ]]] > > Any other suggestions? Maybe 'svn up --set-depth exclude X' instead of -r0. And then a 'svn up X' Bert
RE: svn 1.7: how to recover from a lost pristine file
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: woensdag 28 maart 2012 17:25 > To: Daniel Shahaf > Cc: Bert Huijben; Philip Martin; users@subversion.apache.org > Subject: Re: svn 1.7: how to recover from a lost pristine file > > On Wed, Mar 28, 2012 at 5:06 PM, Daniel Shahaf > wrote: > > Johan Corveleyn wrote on Wed, Mar 28, 2012 at 16:38:41 +0200: > >> Thanks both for your help. Maybe this will help others running in the > >> same situation ... > > > > Do you know what cause the pristine to disappear in the first place? > > No, not yet. When I have some more time I'll try to reproduce it. > > In the meantime, I experimented a bit more with '--set-depth exclude', > just to see what happens when you do this on a modified file. It's > interesting (but maybe this is all normal, can't say ... just > interesting :-)): > > [[[ > C:\WC>echo test >> build.properties > > C:\WC>svn-1.7 st > M build.properties > > C:\WC>svn-1.7 up --set-depth exclude build.properties > Dbuild.properties > > C:\WC>svn-1.7 st > ? build.properties > > C:\WC>svn-1.7 up build.properties > Updating 'build.properties': >C build.properties > At revision 176270. > Summary of conflicts: > Tree conflicts: 1 > > ### argh, a tree conflict. Panic! :-) > > C:\WC>svn-1.7 st > D C build.properties > > local unversioned, incoming add upon update > Summary of conflicts: > Tree conflicts: 1 > > ### let's try to recover from this. > > C:\WC>svn-1.7 resolve --accept=working build.properties > Resolved conflicted state of 'build.properties' Don't assume that svn resolve --accept= makes much sense for tree conflicts. Sorry. We accept this format as a way to accept the tree conflict, but it assumes that you did the actual resolving yourself. > C:\WC>svn-1.7 st > D build.properties > > ### hm, how do I get it back as un-deleted without losing my mods We don't have obstruction conflicts (yet), so an incoming file that is blocked by something unversioned is marked as deleted. This should really be some kind of obstruction conflict to make sure Subversion doesn't try to change the local file on other operations. Currently [D]eleted is the only state with that behavior. > C:\WC>svn-1.7 add build.properties > A build.properties This adds a replacement over your deleted file. So I would expect this > C:\WC>svn-1.7 st > RM build.properties And I think your settings automatically applied properties here. (The M is for properties modified) > ### cool! I've never seen 'RM' before. Anyway, this is not what I wanted :-( Bert
RE: Problem with partial check out
Hi, Are you sure you checked out the right directory from boost. I performed a $ svn co http://svn.boost.org/svn/boost/trunk boost (as recommended on http://www.boost.org/users/download/#repository) on my 2 year old notebook without solid state disk. (Just a simple 7200rpm 2.5 drive) And I got a working copy with just a 29 MB .svn/wc.db The working coy contains 37383 nodes And 33537 pristine files. An fully recursive svn update from the root of this working copy takes about 2.5 seconds on the working copy. (A bit more if updates come in) Probably with a hot filesystem cache, but stil... My guess is that you accidentally checked out the root of the repository instead of just trunk. You should never do that unless you really understand what you are doing. (That would check out all files in all different variants, etc.) The only this item update performs a single operation with network initiation for every selected item. Usually that is orders of magnitude slower than performing a recursive operation on the root. (Subversion is fully optimized for recursive operations; not for single item operations) Bert From: Elmar Teitge [mailto:elmar.tei...@ultra-it.de] Sent: vrijdag 30 maart 2012 23:35 To: users@subversion.apache.org Subject: Problem with partial check out Hello, I have a problem with partial checkout of the repository from the boost c++ library. First I guessed, that this is a problem with Tortoise SVN, because there have been problems with the TSVN cache in the past. Switching off the caching mechanism showed, that this is not the cause of the problem. The total discussion with the TSVN developers is attached below. Deleting the whole content of a folder from the working copy by doing an update to revision with option only this item is running over 30 hours and there is absolutely no measurably progress with a solid state disk. Doing an clean-up process takes only about an hour. Is this an known issue can anyone help with this topic ??? Thanks. Best regards, Elmar Hello Elmar, What you mean by a bug? That database access when database is stored on a solid state drive is slow? I would say it is not a bug, it is physics. In essence I would say that there are many small transactions and each updates the database, and writes are slow. If you want to dig further 1) look for SQLite knowledge. There are some subtle ways how the database can be tuned. It is some specific subject and I cannot help you with it. 2) look at the mailing lists at subversion.apache.org and their archives . Performance of working copy operations is sometimes discussed there. Though usually people are faced with it when trying to work over network (e.g. client running on Windows accessing wc stored on a network drive somewhere). That is one more scenario where performance is known to be poor. 3) the database size of 500 Mb is bad. You have too many single files to manage. :/ As I mentioned, svn cleanup would not shrink it. There exist some sqlite commands that can claim unused space in a database file, but you would need an sql client to execute them, not svn client. Best regards, Konstantin Kolinko Hello Konstantin, thanks for your response. I have done a new trial for checking out the repository ... Two folders were checked out, the branches and the sandbox folder ... I I tried again dumping the content of the sandbox folders by "update to revision" with option "only this item" ... that was running about 5 hours, than I cancelled this process in the update dialog ... I had a look in the .svn folder and found out, that the SQLite database file was 570 MB in size ! So I decided to do an experiment and deleted all pristine content and all the files in the working copy folders ... in the next step I have done the clean-up process like you described it ... After the clean-up process, the database file is still 570 MB large ... ... and an update process with "only this item" is still in progress with no result ... I am sure, that my problem is caused by a bug. But how to do a trace, that helps to find that bug ? Best regards, Elmar -Ursprüngliche Nachricht- Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Gesendet: Sonntag, 25. März 2012 22:37 An: us...@tortoisesvn.tigris.org Betreff: Re: Partial Checkout Problem 2012/3/25 Elmar Teitge : > Hello Konstantin, > > thank you for your advice. > > To point 1, I have selected the folder that shall be cleared from > subfolders, called "sandbox" and then selected "update to revision" in the > context menu with selected option "only this item". > > To point
RE: Feature request: Easy tree conflick resolve mechanism
> -Original Message- > From: Sune Fischer [mailto:suneprogram...@gmail.com] > Sent: vrijdag 13 april 2012 10:27 > To: users@subversion.apache.org > Subject: Feature request: Easy tree conflick resolve mechanism > > Hi, > > In the old days the .svn folder was in every folder and resolving a tree > conflict was as easy as deleting the conflicting folder and doing an > update. This solved 90% of our issues. > This is no longer possible as the only the .svn is now at the root of > the whole project! > I assume there are some valid reasons for this, but how do you go about > solving tree conflicts efficiently then? > > We typically get a tree conflict if one guy as deleted a file and > another guy as made changes to the file. > In the old days, the guy deleting the file could simply remove his > folder, do an update and the delete the file again. > This is not possible now, if he deletes the folder and does an update > subversion won't give him the file back. Svn just keep claiming a tree > conflict. > > What is the best way to resolve this? > We did try clean-up and resolve etc.. svn revert -R will have the same result as you had in 1.6 when you removed the folder and then performed the update. The data that got missing in 1.6 when you got the tree conflict is now already stored in the pristine store so the update is no longer necessary, but it doesn't hurt to update anyway. In 1.6 you should have resolved the tree conflict in the same way, but the recovering process from missing data was about the same thing. In 1.7 we can usually also recover from the missing conflicted data, so you get the conflicted data back. Bert
RE: "svn cl" input from "svn st"
> -Original Message- > From: Andreas Krey [mailto:a.k...@gmx.de] > Sent: donderdag 26 april 2012 11:26 > To: Gary; svn-list > Subject: Re: "svn cl" input from "svn st" > > On Thu, 26 Apr 2012 10:39:23 +, Stefan Sperling wrote: > ... > > M alpha > > M epsilon/zeta > > $ svn status | grep '^[A-Z]' | sed 's/^. \(.*\)$/\1/' > > $ svn status | sed -n 's/^[A-Z] \(.*\)$/\1/p' # From memory, untested This filters property changes and tree conflicts (column 2 and 3 set to something). Bert > > Andreas > > -- > "Totally trivial. Famous last words." > From: Linus Torvalds > Date: Fri, 22 Jan 2010 07:29:21 -0800
RE: How to ignore a versioned subdirectory within the whole tree during svn update?
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 26 april 2012 20:42 > To: frame > Cc: users@subversion.apache.org > Subject: Re: How to ignore a versioned subdirectory within the whole tree during > svn update? > > On Thu, Apr 26, 2012 at 11:15:12AM -0700, frame wrote: > > Hi, > > > > Our team's whole repository tree is like: > > > > build.xml > > 1.txt > > 2.txt > > dir_a/ > > dir_big_and_un_related_to_me/ > > .. > > dir_h/ > > > > The dir_big_and_un_related_to_me/ is very, very big and it is not relevant > > to my own work. Every time, when I run "svn update" at the top, I hope that > > directory is ignored. But I don't know how to do it. I am wondering if svn > > has a feature for this purpose. > > Use the 'sparse checkout' feature. > > svn update --set-depth exclude dir_big_and_un_related_to_me > > > The whole tree has been checked out to my local area. > > When getting a fresh checkout you might want to something like this: > > svn checkout --depth empty URL > svn ls (view items that could be here) > for each item of interest: > svn checkout --set-depth infinity item_of_interest Replace this 'checkout' with 'update', or you get just many separate working copies. In this case you can also drop the '--set-depth infinity' as that is the default for new nodes that come in from the repository this way. Bert
RE: Getting SVN E155035 after multiple updates of repository
> -Original Message- > From: Adam Mercer [mailto:ramer...@gmail.com] > Sent: vrijdag 11 mei 2012 16:28 > To: users@subversion.apache.org > Subject: Getting SVN E155035 after multiple updates of repository > > Hi > > I am trying to debug and problem with one of the repositories we host. > When you make a fresh checkout of the repository it seems to be > successful: > > $ svn checkout https://hostname/path/to/repo/ > > Checked out revision 1952. > $ > > if I get do into the repository and run "svn update", I get more files > being checked out, i.e.: > > $ svn update > Updating '.': > > Atrunk/community_environment > Atrunk/community_environment/index-content.html > Atrunk/community_environment/subnavigation.txt > Updated to revision 1952. > $ > > and if I do another "svn update" > > $ svn update > Updating '.': > > Atrunk/sp/css/master.css > Atrunk/sp/css/screen.css > Atrunk/sp/css/slider.css > Atrunk/css/screen.css > Atrunk/students_teachers_public/read-content.html > Updated to revision 1952. > > i.e. more files, running "svn update" again: > > $ svn update > Updating '.': > Atrunk/multimedia/gallery/lho-images/groundssnow_t.jpg > Atrunk/multimedia/gallery/lho-images/dcp_3659_t.jpg > Atrunk/sp/style/header.php > Atrunk/sp/images/encapsgallery/catalog_item.html > Atrunk/sp/science/outreach-content.html > svn: E155035: Cannot delete '/Users/ram/svn/repo/trunk/images' as > '/Users/ram/svn/repo/trunk/images/btn_next.gif' is excluded by server > $ > > Why would this file be excluded by the server, AFAIK we don't have an > exclusions in place. The supported way of introducing server exclusions is applying authorizations on directories in a repository. (We used to call these nodes 'absent' before 1.7) Are you sure there are/were no authorizations applied on your server for these files? You should only get this error if btn_next.gif was somehow not accessible before your update and now the parent directory is deleted. (And with a quick look through the code I think you also need a tree conflict before you would get in this error. I will try to do some testing in this direction later this week) If you just did a checkout and then an update, this should never happen. My guess would be that you have other problems, but it is hard to tell without a reproduction. Some information on the authorization settings of the repository would help us get further in diagnosing your problem. Bert > > I'm using svn-1.7.4 on the client and the server is running 1.4.2. > > Cheers > > Adam
RE: Directory as part of the changelist - possible?
> -Original Message-
> From: Alexey Neyman [mailto:sti...@att.net]
> Sent: zondag 27 mei 2012 0:13
> To: users@subversion.apache.org
> Subject: Directory as part of the changelist - possible?
>
> Hi all,
>
> Is it possible to add a directory to a change list? I have a property
> modification on one of the directories - however, an attempt to include it
in
> the changelist fails:
Directories are currently not allowed on changelists, because when we
designed changelist we couldn't find a proper way how changelists on
directories should behave. Especially when combined with the then relative
new --depth.
We decided to just not allow changelists on directories, to allow setting
them later when we would get the behavior defined.
During 1.7 development we tried again to define a valid behavior, and failed
again :(
Suggestions and helping design the feature welcome on
dev{_AT_}subversion.apache.org :-)
Bert
RE: Issues with externals
> -Original Message- > From: Philip Prindeville [mailto:philipp_s...@redfish-solutions.com] > Sent: vrijdag 1 juni 2012 1:47 > To: users@subversion.apache.org > Subject: Issues with externals > > I'm using svn 1.6.11 of Centos 6.2. > > I've noticed the following two issues with externals. > > (1) If I have an external and then do a "svn propedit svn:externals ..." and > delete a path, the file that was previously exported into my space by "svn > update" persists in a state of limbo. > > (2) An "svn merge" seems to apply svn:mergeinfo property changes to > externals. This seems extremely unwise. Should "svn merge" (and perhaps > other commands) skip over external files? > > I love externals... they're very handy for multiple projects sharing partial > common sources... but they aren't as easy to use as they should be, and > come with some bizarre (non-intuitive) semantics. > > Is this bugworthy? This was fixed in Subversion 1.7.0+, using the new working copy database. We now keep track of exactly what externals were installed during update to allow removing them later, even when they were only referenced from uncommitted svn:externals properties. Bert
RE: svn status leaves out changes in externals
Hi, Did you create the externals by using 'svn checkout' or did you create 'your own externals' by checking out a separate working copy and assumed Subversion would just use it as an external? Svn status works correctly for me when I bring in externals using 'svn checkout' or 'svn update'. Bert From: Matthias Meixner [mailto:matthias.meix...@verifone.com] Sent: vrijdag 1 juni 2012 10:37 To: users@subversion.apache.org Subject: svn status leaves out changes in externals Hello! In all versions up to 1.6.x "svn status" used to list all changed files including those found in directories referenced using svn:externals. Using version 1.7.5 this is not the case any longer. Even with option --depth infinite, changed files are not listed. I consider this a bug since it is not possible any more to recursively check for changed files, instead now I have to manually check all subdirectories one by one. Regards, Matthias Meixner _ This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.
RE: Externals: sqlite: constraint failed
> -Original Message- > From: Andreas Krey [mailto:a.k...@gmx.de] > Sent: dinsdag 5 juni 2012 13:50 > To: Subversion Users > Subject: Re: Externals: sqlite: constraint failed > > On Tue, 05 Jun 2012 11:20:52 +, Stefan Sperling wrote: > ... > > Can you reproduce this problem reliably, with a fresh repository and > > working copy? > > I didn't even try; I never had anything like that beforehand. > > > In an earlier thread[1], you were showing problems with externals and > > command cancellation. Is this the same working copy? If so, you might > > be seeing a side-effect of the bug you already reported. > > Can't rule that out. I did the final runs for that one in another WC, > but I may have ^C'ed this one, too. I mostly reported this because > of the 'externals, again' note in one of the reactions in the ^C thread, > so for now -> irreproducible. Are you using a release build of Subversion or do you use a maintainer build? The maintainer build installs additional validations when opening the working copy, that may cause this error when coupled with specific Sqlite versions. (This would be a known issue and upgrading Sqlite to 3.7.9 or later the recommended action) Some specific builds of Sqlite may enable foreign key constraints by default; this may also cause this issue. But in that case I would call it a bug in Subversion. Bert
RE: Status after svn_client_move6
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 7 juni 2012 10:46 > To: Thuan Seah Tan > Cc: users@subversion.apache.org > Subject: Re: Status after svn_client_move6 > > On Thu, Jun 07, 2012 at 05:08:40PM +1000, Thuan Seah Tan wrote: > > Hi all, > > > > > > > > I am new to subversion and subversion api, and I have a question which I > > hope someone can point me in the right direction. I am trying to do a > > subversion integration in the tool I am working on, and to rename a file, I > > believe I need to call the svn_client_move6 function. That's all good, I can > > see the file is being renamed in Windows Explorer after the call. What > > puzzles me is the svn_client_status5 call straight after. If I have an > > unmodified file A.txt, renaming it to B.txt and back to A.txt should give me > > the node status as "replaced" but text status should remain "normal". I > have > > TortoiseSVN installed, and using the file properties dialog, I can see that > > the file goes into "replaced" and "normal" state. But trying to call > > svn_client_status5 straight after the svn_client_move6 returns the file as > > "replaced" and "modified" in the status5 callback. It is only on subsequent > > call to svn_client_status5 (after some arbitrary time) the status is > > correctly marked as "replaced" and "normal". Wondering is there > something I > > am doing wrong? This is how I am calling svn_client_status5: > > The second move creates a new file A.txt with a new modification > timestamp. > > To avoid full content comparison, 'svn status' reports a file as modified > if the pristine file's modification timestamp and size differ from the > working file's timestamp and size. > Else, it compares file content to determine whether a file was modified. > > There are also cases where the cached timestamp becomes invalid, the > full content is compared regardless of timestamp differences, and the > cached timestamp is then corrected. I believe this is why you're seeing > the node status flip from modified to normal. > > For details, take a look at the function svn_wc__internal_file_modified_p() > in libsvn_wc/questions.c. If you set appropriate debugger breakpoints in > there you should be able to observe the code paths taken when the file is > reported as modified vs. when the file is reported as unmodified. > > Note also that Subversion sometimes sleeps deliberately to wait for > on-disk timestamp updates. See svn_io_sleep_for_timestamps(). What you might see is that the file is somehow still blocked for reading when you are calling status on it. If the timestamps don't match (see anser Stefan), then a compare is performed. But if the file is (temporarily) not readable, because some other process blocks that the file is marked as 'modified'. This other process could be a file indexer, a virusscanner, a disk status monitor, etc. What you see later is probably that the file was closed and the status succeeds again. Bert
RE: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
> -Original Message-
> From: Daniel Widenfalk [mailto:daniel.widenf...@iar.se]
> Sent: donderdag 7 juni 2012 11:06
> To: d...@subversion.apache.org; users@subversion.apache.org
> Subject: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
>
> Hi,
>
> First off: I'm sorry if I post this in the wrong way.
>
> I've found a potential issue in the function "find_identical_prefix"
> in libsvn_diff/diff_file.c
>
> The faulty code looks like this:
>
> diff_file.c:432 (as per 1.7.1, code identical to 1.7.5)
> ---
> is_match = TRUE;
> for (delta = 0; delta < max_delta && is_match; delta +=
> sizeof(apr_uintptr_t))
> {
> apr_uintptr_t chunk = *(const apr_size_t *)(file[0].curp +
delta);
> if (contains_eol(chunk))
> break;
>
> for (i = 1; i < file_len; i++)
> if (chunk != *(const apr_size_t *)(file[i].curp + delta))
> {
> is_match = FALSE;
> delta -= sizeof(apr_size_t);
> break;
> }
> }
> ---
>
> The problem is that the 64-bit build I'm using (ColabNet) have
> different sizes for apr_uintptr_t and apr_size_t.
>
> From looking at the disassembly I can deduce that
> sizeof(apr_uintptr_t) = 4 and sizeof(apr_size_t) = 8. This leads
> to these two issues:
>
> 1) Data is truncated in the initial read-up to "chunk" and the compare
>in the inner loop will fail because the second read-up will compare
>a 64-bit value against a 32-bit value.
>
> 2) When the test fails it will back up delta by 8, not 4, resulting in
>a buffer advance of -4 later in the code. Once the search code has
>advanced another 4 character if will be back at the same spot.
>
>Rinse and repeat.
>
> Are these a known issues?
>
> In my case this results in an infinite loop on the following input
> string:
>
> 23 0a 23 20 54 68 69 73 20 70 72 6f 6a 65 63
>
> I found this out when my svn-client spiraled into an infinite loop
> and would not respond to ctrl-c during a "svn up" command.
Which apr version did you use?
I think this issue was fixed in Subversion 1.7.2:
(From http://svn.apache.org/repos/asf/subversion/tags/1.7.2/CHANGES)
* properly define WIN64 on Windows x64 builds (r1188609)
Not by a code change here in this piece of the code, but by making sure that
the pointer size is defined correctly in apr.
So that would fix this issue and maybe several others.
Bert
RE: Potential issue in libsvn_diff:diff_file.c:find_identical_prefix
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: donderdag 7 juni 2012 11:34
> To: 'Daniel Widenfalk'; d...@subversion.apache.org;
> users@subversion.apache.org
> Subject: RE: Potential issue in
libsvn_diff:diff_file.c:find_identical_prefix
>
>
>
> > -Original Message-
> > From: Daniel Widenfalk [mailto:daniel.widenf...@iar.se]
> > Sent: donderdag 7 juni 2012 11:06
> > To: d...@subversion.apache.org; users@subversion.apache.org
> > Subject: Potential issue in
libsvn_diff:diff_file.c:find_identical_prefix
> >
> > Hi,
> >
> > First off: I'm sorry if I post this in the wrong way.
> >
> > I've found a potential issue in the function "find_identical_prefix"
> > in libsvn_diff/diff_file.c
> >
> > The faulty code looks like this:
> >
> > diff_file.c:432 (as per 1.7.1, code identical to 1.7.5)
> > ---
> > is_match = TRUE;
> > for (delta = 0; delta < max_delta && is_match; delta +=
> > sizeof(apr_uintptr_t))
> > {
> > apr_uintptr_t chunk = *(const apr_size_t *)(file[0].curp +
> delta);
> > if (contains_eol(chunk))
> > break;
> >
> > for (i = 1; i < file_len; i++)
> > if (chunk != *(const apr_size_t *)(file[i].curp + delta))
> > {
> > is_match = FALSE;
> > delta -= sizeof(apr_size_t);
> > break;
> > }
> > }
> > ---
> >
> > The problem is that the 64-bit build I'm using (ColabNet) have
> > different sizes for apr_uintptr_t and apr_size_t.
> >
> > From looking at the disassembly I can deduce that
> > sizeof(apr_uintptr_t) = 4 and sizeof(apr_size_t) = 8. This leads
> > to these two issues:
> >
> > 1) Data is truncated in the initial read-up to "chunk" and the compare
> >in the inner loop will fail because the second read-up will compare
> >a 64-bit value against a 32-bit value.
> >
> > 2) When the test fails it will back up delta by 8, not 4, resulting in
> >a buffer advance of -4 later in the code. Once the search code has
> >advanced another 4 character if will be back at the same spot.
> >
> >Rinse and repeat.
> >
> > Are these a known issues?
> >
> > In my case this results in an infinite loop on the following input
> > string:
> >
> > 23 0a 23 20 54 68 69 73 20 70 72 6f 6a 65 63
> >
> > I found this out when my svn-client spiraled into an infinite loop
> > and would not respond to ctrl-c during a "svn up" command.
>
> Which apr version did you use?
>
> I think this issue was fixed in Subversion 1.7.2:
>
> (From http://svn.apache.org/repos/asf/subversion/tags/1.7.2/CHANGES)
> * properly define WIN64 on Windows x64 builds (r1188609)
>
> Not by a code change here in this piece of the code, but by making sure
that
> the pointer size is defined correctly in apr.
> So that would fix this issue and maybe several others.
And since then then also APR was patched to properly check for _WIN64
instead of WIN64 for defining these variable types correctly.
Bert
>
> Bert
>
RE: Subversion SCC providers?
> -Original Message-
> From: Cooke, Mark [mailto:mark.co...@siemens.com]
> Sent: woensdag 20 juni 2012 12:01
> To: JussiJ; subversion_us...@googlegroups.com
> Cc: users
> Subject: RE: Subversion SCC providers?
>
> > -Original Message-
> > From: JussiJ [mailto:jus...@zeusedit.com]
> > Sent: 20 June 2012 10:22
> > To: subversion_us...@googlegroups.com
> > Cc: users
> > Subject: Re: Subversion SCC providers?
> >
> > On Monday, March 22, 2010 10:54:10 AM UTC-7, Itamar O wrote:
> >
> > > I am trying to integrate SVN as a source control provider
> > > for Active-HDL (from Aldec).
> > > I understand that Active-HDL supports the SCC API ("MSSCCI"?),
> >
> > FWIW Agent SVN is a plug-in for Subversion that implements
> > the MS-SCCI but it is not is not free.
> >
> > Jussi Jumppanen
>
> I am also interested in this for LabView which also supports the MSSCCI.
A
> quick search yesterday indicated that AnkhSVN supported MSSCCI but it was
> just an initial search, can anyone confirm / deny this?
AnkhSVN implements the newer MSSCCI VAPI implementation of Visual Studio
2005 and later, which allows updating the workflow to what you are used with
Subversion.
You really need the old checkout-checkin based implementation of the MSSCCI
spec for those other tools and AnkhSVN doesn't implement this (yet).
(There are some ideas on how we can provide a limited set of the AnkhSVN
features to other MSSCCI based tools, but some of the tools we really would
loved to have support for, have yet another SCC implementation)
Bert
>
> ~ mark c
RE: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings)
> -Original Message- > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > Philip Martin > Sent: maandag 25 juni 2012 15:05 > To: Attila Nagy > Cc: users@subversion.apache.org > Subject: Re: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings) > > Attila Nagy writes: > > > I suffer from the slowness of svn rm since the upgrade to 1.7 from > > 1.6, but I couldn't find the time to profile it until now. > > My setup is: FreeBSD 9-STABLE/amd64 with zfs, eight fast cores, SAN, > > 32 GiB of RAM. > > Versions: > > svn, version 1.7.5 (r1336830) > > sqlite: 3.7.12.1 2012-05-22 02:45:53 > > 6d326d44fd1d626aae0e8456e5fa2049f1ce0789 > > > Any ideas about how could it be made even faster without ditching > > sqlite? Deleting 100 files and committing the change shouldn't take 40 > > (10, with the above indexes) minutes, even with 2 million files... I > > guess. > > SUbversion 1.8 (trunk) has various speed improvements to the working > copy library. Is your working copy on the SAN? Depending on how the > SAN works you may find that the exclusive locking patch in issue 4176 > helps: http://subversion.tigris.org/issues/show_bug.cgi?id=4176 This sounds like the scalability problem that was fixed by upgrading Sqlite 3.7.9 or later. (Without that we perform a full table scan, which in this case would be 2 million times (the number of nodes) slower than deleting with the proper index usage) Bert > > -- > Philip
RE: Issue: svn:externals syntax does not accept -rHEAD
> -Original Message- > From: Ruhe Julian [mailto:jr...@axway.com] > Sent: vrijdag 22 juni 2012 14:57 > To: Stephen Butler > Cc: Daniel Shahaf; users@subversion.apache.org > Subject: AW: Issue: svn:externals syntax does not accept -rHEAD > > Hello Daniel, > > >The update command accepts -rHEAD, but not necessarily -rHEAD plus peg > revision. HEAD is a keyword for "latest in the repository", not "latest in the > history of URL@REV". If an item has been deleted, it's no longer part of the > >HEAD, as you've seen. > > That is not the point. I did not state this. In the svnbook in the chapter > regarding peg revisions you can find a clear statement that recreated objects > on the same path are not the same things. That's why it's perfectly valid to > ask "give me the HEAD version of an object existing @peg." And the result > should be either > a) if the same object exist on HEAD on that path => give that object > b) if no object exists on HEAD that path => give me an error > c) if another object (recreated) after deletion exists on HEAD that path => > give me an error > > This is how svn checkout (svn co -rHEAD path@peg) works. I do not > understand why I should not be allowed to advise svn:externals to do the > same. Just to follow the specification of operating revision and peg revsions. > > > It sounds like you want Subversion to search for the latest revision in the > history of URL@REV. What if that item was deleted and later restored? > > No. Not at all. Forward history of an object is another topic. > > > >> -rHEAD > >> ^/mapping_services/global/testing/full_test/globalresource6.xml@109 > => > >> gives me an error on svn up if gr.xml6@109 does no longer exist on > >> HEAD ^/mapping_services/global/testing/full_test/globalresource6.xml > >> (your proposal) => gives me the wrong object I am not interested in > > >Who put the wrong object there? If you can solve that organizational > problem, the technical problem outlined above will no longer be relevant, > and your Subversion usage will be much simpler and more robust. > > Wrong object? I just said that two objects on the same path are different to > me. And I actually just want an answer on question "Does the file external > path@peg exist on HEAD?". Answer: "Yes" or "No" or technically "object > returned" or "error". > > I cannot even answer this question with the given syntax. What is so difficult > to allow -rHEAD on svn:externals? We don't have forward history searching in Subversions filesystems. So allowing this option requires extending the filesystem layer. And given that usually -r follows copies, there could be multiple answers, which makes designing this option in the filesystem hard and the result inconclusive. Bert
RE: Nested status if external link folder have another external link folder under it
The nested status is a TortoiseSVN specific status that tells you that there is a working copy below the parent working copy (a ‘nested’ working copy). This is exactly how externals are implemented in Subversion, so I would recommend leaving it at this. Bert From: 許阿光 [mailto:huikuang@gmail.com] Sent: dinsdag 26 juni 2012 04:42 To: users@subversion.apache.org Subject: Nested status if external link folder have another external link folder under it Hi, I have use svn:externl command to manage my source code (actually I am using TortoiseSVN 1.7.7) When setup svn:externel like: local_folder/ Url1 local_folder/hierarchy2/ Url2 to get 2 remote repository into my local folder This folder would be in NESTED status Can I fix this status or just leave it? or any suggestion to achieve same layout of folder heirarchy Thanks a lot.
RE: Possible svnsync data loss bug?
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: dinsdag 26 juni 2012 22:14 > To: kmra...@rockwellcollins.com > Cc: Mark Phippard; Trent Fisher; users@subversion.apache.org > Subject: Re: Possible svnsync data loss bug? > > On Tue, Jun 26, 2012 at 8:07 PM, wrote: > >> > I was about to ask if svnsync would get access denied errors... but I > >> > did > >> > another test which, I think, answered my own question: If I run "svn > >> > log" > >> > against a repository to which I have only access to part of, revs in the > >> > areas I don't have access to will show up as "(no author) | (no date)". > >> > Presumably svnsync is doing some variant of a "log" call and then > >> > getting > >> > the contents of each rev and faithfully reproduces what seem to be > empty > >> > revs. > >> > > >> > So, I guess svnsync is arguably doing the right thing. But even if it > >> > were > >> > declared to be incorrect, and a fix were checked in right now, it > >> > wouldn't > >> > address any of my existing replicas. So, I'll have to develop some > >> > auditing for these sorts of things. Which brings up another question: > >> > is > >> > there any other reason you would ever see "(no date)" in a log entry? > >> > >> I cannot speak to all scenarios because I have not tested them. For > >> example, if the svnsync user simply had no read access to anywhere in > >> the repository it seems like it ought to error. But that scenario > >> aside, the way that svnsync works is actually a huge feature. Imagine > >> you have a remote team of contractors that you want to give a local > >> replica of your repository. These contractors are not allowed access > >> to parts of your repository. The contractors can use svnsync to crete > >> a local replica using their credentials and their local repository > >> will only contain the content they are allowed to access. The > >> revisions that altered other paths will simply be empty commits. > >> > >> As I started, there may be other scenarios where this could be handled > >> differently, but overall I think this is a great feature of svn. > > > > Both are valid use cases. I frequently use the current access behavior > > to "filter" large repositories instead of using svndumpfilter which > > would require terabytes of scratch space and days of downtime to filter. > > It's also sometimes used to recover from some forms of repository > corruption (lacking proper backups), if the corruption is limited to a > single file (or a set of files) in history. By configuring an authz > policy that denies access to that file, one can svnsync to a new > repository, which is then free of corruption (without the corrupted > file of course). > > > Any reason svnsync couldn't grow a "--fail-on-access-error" option? > > Sure, I think that could be useful (as long as it's not the default > (backwards compat)). The problem here is that we don't get an access denied error. Svnsync just notes an empty revision, which is somehow valid. (We try not to create empty revisions, but there are quite a few repositories that have them via different tricks or bugs). So we should have a way to detect that this happens. Bert > > -- > Johan
RE: Issue #2243 still exists with svn 1.6.17
The 'no_ignore' flag is only used for recursive targets. Explicitly passed targets (such as via 'svn add *') are always processed. If you would like to use the ignore feature you should call 'svn add --force .', or the api equivalent of that. This adds the directory and everything below that ignoring the case that with proper ignore handling. The --force allows calling it on an already versioned directory. Bert From: Alan McGovern [mailto:a...@xamarin.com] Sent: zaterdag 30 juni 2012 01:34 To: users@subversion.apache.org Subject: Issue #2243 still exists with svn 1.6.17 Hey, We use libsvn in our project and have hit an issue [0] which appears to be a recurrence of libsvn bug #2243 [1]. Essentially we invoke 'svn_client_add3' and pass false for no_ignore but files in the ignore list are still added to the repository. Invoking "svn add thatfile" from the commandline results in the file being added too. Alan [0] https://bugzilla.xamarin.com/show_bug.cgi?id=5069 [1] http://subversion.tigris.org/issues/show_bug.cgi?id=2243
RE: Issue #2243 still exists with svn 1.6.17
'svn status' and/or the api equivalent svn_client_statusX() also process the
ignore status to provide the status if you have an unversioned or ignored
item.
The SharpSvn users list should have more details on these cases. (Googling
for SharpSvn will also provide answers on StackOverflow). More than a few
users asked similar and related questions there over the years.
SharpSvn is a thin layer over the client api, so most questions equally
apply to direct users of the libsvn_client api.
Bert
From: Alan McGovern [mailto:a...@xamarin.com]
Sent: zaterdag 30 juni 2012 15:26
To: Bert Huijben
Cc: users@subversion.apache.org
Subject: Re: Issue #2243 still exists with svn 1.6.17
This leaves me with a bit of a conundrum. Our IDE would normally
automatically call "svn add" when you add a new file to the solution. It is
possible that this file could be in the svn ignore list. The result is that
by attempting to make the developers life easy we will instead always add
files which should be ignored. Is there any API for me to check if a file
would normally be ignored so i can filter those paths out before calling
svn_add to avoid this issue?
My only other alternative would be to call something like svn add . --force
and then see what files have been added and revert all of them except for
the one I actually wanted. Or is there another way to achieve what I want?
Alan
On 30 Jun 2012, at 08:27, Bert Huijben wrote:
The 'no_ignore' flag is only used for recursive targets.
Explicitly passed targets (such as via 'svn add *') are always processed.
If you would like to use the ignore feature you should call 'svn add --force
.', or the api equivalent of that. This adds the directory and everything
below that ignoring the case that with proper ignore handling. The --force
allows calling it on an already versioned directory.
Bert
From: Alan McGovern [mailto:a...@xamarin.com]
Sent: zaterdag 30 juni 2012 01:34
To: users@subversion.apache.org
Subject: Issue #2243 still exists with svn 1.6.17
Hey,
We use libsvn in our project and have hit an issue [0] which appears to be a
recurrence of libsvn bug #2243 [1]. Essentially we invoke 'svn_client_add3'
and pass false for no_ignore but files in the ignore list are still added to
the repository. Invoking "svn add thatfile" from the commandline results in
the file being added too.
Alan
[0] https://bugzilla.xamarin.com/show_bug.cgi?id=5069
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=2243
RE: svnsync does not pass username
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: dinsdag 3 juli 2012 14:04 > To: users@subversion.apache.org > Subject: Re: svnsync does not pass username > > Guten Tag Warden, Neil, > am Dienstag, 3. Juli 2012 um 12:49 schrieben Sie: > > > Content of the logfile: > > "Arguments: > > "E:\Programs\svn_repository\vpl_slave\hooks\pre-revprop-change.bat" > > E:\Programs\svn_repository\vpl_slave 0 "" svn:sync-lock A" > > "Repo: E:\Programs\svn_repository\vpl_slave Rev: 0 User: "", """ > > "Arguments: > > "E:\Programs\svn_repository\vpl_slave\hooks\pre-revprop-change.bat" > > E:\Programs\svn_repository\vpl_slave 0 "" svn:sync-lock A" > > "Repo: E:\Programs\svn_repository\vpl_slave Rev: 0 User: "", """ > > "Arguments: > > "E:\Programs\svn_repository\vpl_slave\hooks\pre-revprop-change.bat" > > E:\Programs\svn_repository\vpl_slave 0 "" svn:sync-lock A" > > "Repo: E:\Programs\svn_repository\vpl_slave Rev: 0 User: "", """ > > "Arguments: > > "E:\Programs\svn_repository\vpl_slave\hooks\pre-revprop-change.bat" > > E:\Programs\svn_repository\vpl_slave 0 "" svn:sync-lock A" > > "Repo: E:\Programs\svn_repository\vpl_slave Rev: 0 User: "", """ > > Looks to me your username somewhere is changed to "", because this is > logged as %userName% and %3. If %3 would be an empty string, it > wouldn't get replace to "" in my opinion. If username is "" somehow, > your if fails, of course. Are you sure the target repository doesn't allow anonymous access? If it allows anonymous access the client will only upgrade to authentication when it needs to. Bert
RE: svn_wc_prop_set4 not working as expected.
Every svn_wc API that changes the working copy requires its caller to obtain a write lock. In the past that was done via the access batons and now it requires another call. But the most common ones are still private. Bert Huijben (Cell phone) From: Daniel Shahaf Sent: 7-7-2012 1:02 To: lfdon...@rockwellcollins.com; users@subversion.apache.org Cc: d...@subversion.apache.org Subject: Re: svn_wc_prop_set4 not working as expected. Stefan Sperling wrote on Mon, Jun 25, 2012 at 10:21:22 +0200: > On Fri, Jun 22, 2012 at 11:15:57AM -0500, lfdon...@rockwellcollins.com wrote: > > Hello, > > I'm trying to use svn_wc_prop_set4 to set a property on my local working > > copy (1.7) and I keep getting the error: > > > > No write-lock in 'T:\VIP00192\test_1.7\LFD_Dev_14' > > > > OS: Windows > > Compiler: visual c++ > > SVN package: svn-win32-1.7.5 > > > > Leslie Donaldson > > > > Boiled down code: > > > > apr_pool_t*pool = NULL; > > pool = svn_pool_create(NULL); > > svn_fs_initialize (pool); > > svn_config_ensure (NULL, pool); > > apr_hash_t* cfg_hash= NULL; > > svn_config_get_config(&cfg_hash, NULL, pool); > > svn_config_t* cfg_config = (svn_config_t *)apr_hash_get(cfg_hash, > > SVN_CONFIG_CATEGORY_CONFIG, APR_HASH_KEY_STRING); > > svn_wc_context_t* wc_ctx = NULL; > > svn_wc_context_create(&wc_ctx,cfg_config,result_pool,scratch_pool); > > > > char * name = "svn:externals"; > > > > svn_wc_prop_set4(wc_ctx,FullPath,name,&value,svn_depth_empty,FALSE,NULL,NULL,NULL,NULL,NULL,scratch_pool); > > It looks like svn_wc_prop_set4() was made a public API in 1.7 by mistake. > Please try using svn_client_propset_local() instead. > > You'd need to acquire a write lock on the working copy before calling > svn_wc_prop_set4(). However the APIs to obtain this lock are not public > APIs so you cannot use them in your application. > Let's deprecate svn_wc_prop_set4() then, and replace it by an svn_wc_private.h version? > To ease maintainability of Subversion we're currently phasing out all > public libsvn_wc APIs, with the goal of providing related functionality > at the libsvn_client layer instead. > > > > >char* FullPath = "T:/VIP00192/test_1.7/LFD_Dev_14" > >svn_string_t value; is a list of externals. > >
RE: "svn cleanup" fails because it can't find a temp file
> -Original Message- > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > Philip Martin > Sent: dinsdag 10 juli 2012 11:20 > To: Johan Corveleyn > Cc: Dave Huang; users@subversion.apache.org > Subject: Re: "svn cleanup" fails because it can't find a temp file > > Johan Corveleyn writes: > > > I think you should file an issue for the unrecoverable working copy > > after a "blocked by file-in-use" reverse-merge (maybe also for a > > normal merge?). It would be nice though if you could come up with a > > nice reproduction recipe, > > Just about any merge will do. repos_diff.c:get_file_from_ra passes NULL > when calling svn_stream_open_unique and that causes the system > temporary > dir to be used--we should be passing the .svn temporary dir. (We should > probably continue to pass NULL if this is a diff, rather than a merge, > since the working copy might be read-only.) Other part of this problem: shouldn't the install operation be ignored if the to-be installed file cannot be found? The workqueue operation should be restartable, which it won't be if the file is already moved, but some later operation (like obtaining the timestamp) fails. Bert
RE: Square brackets in file names and authz (in VisualSVN 2.5.5)
[Please try to keep the mails in plain-text] The problem with using a ‘\’ would be that you break the ‘\’ character in existing files to fix ‘]’. Things might be simpler when defining that lines that start with ‘[‘ and end with ‘]’ should parse everything in between as section markers. But then, I don’t know how that affects the current comment syntax. We should really check the source before making a decision. Bert From: Jason Heeris [mailto:jason.hee...@gmail.com] Sent: donderdag 12 juli 2012 11:37 To: Johan Corveleyn Cc: Matthew Pounsett; users@subversion.apache.org Subject: Re: Square brackets in file names and authz (in VisualSVN 2.5.5) On 12 July 2012 17:28, Johan Corveleyn wrote: I think the only character that causes problems is ']' (which ends the section name parsing). It seems not too hard to change that parsing function to make it handle some kind of escape sequence for ']' (perhaps ']]'). Would you care to write a patch [2]? I doubt I'll have time to write a patch any time in the next few days, but I'll file the bug now and take a look at writing a patch next week. I'd suggest avoiding inconsistencies like the double-]. I certainly wouldn't think to try that. It might be better to use a backslash sequence, or simply capture everything up to the *last* "]" on a line instead of the first. I don't think that would be more complex than needing to detect a "]]" ...but then, I haven't written the patch :P — Jason
RE: "svn cleanup" fails because it can't find a temp file
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: dinsdag 10 juli 2012 16:52 > To: 'Philip Martin'; 'Johan Corveleyn' > Cc: 'Dave Huang'; users@subversion.apache.org > Subject: RE: "svn cleanup" fails because it can't find a temp file > > > > > -Original Message- > > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > > Philip Martin > > Sent: dinsdag 10 juli 2012 11:20 > > To: Johan Corveleyn > > Cc: Dave Huang; users@subversion.apache.org > > Subject: Re: "svn cleanup" fails because it can't find a temp file > > > > Johan Corveleyn writes: > > > > > I think you should file an issue for the unrecoverable working copy > > > after a "blocked by file-in-use" reverse-merge (maybe also for a > > > normal merge?). It would be nice though if you could come up with a > > > nice reproduction recipe, > > > > Just about any merge will do. repos_diff.c:get_file_from_ra passes NULL > > when calling svn_stream_open_unique and that causes the system > > temporary > > dir to be used--we should be passing the .svn temporary dir. (We should > > probably continue to pass NULL if this is a diff, rather than a merge, > > since the working copy might be read-only.) > > Other part of this problem: shouldn't the install operation be ignored if > the to-be installed file cannot be found? > > The workqueue operation should be restartable, which it won't be if the file > is already moved, but some later operation (like obtaining the timestamp) > fails. The most likely cause for this issue (svn merge applying a 'trivial' merge), is now fixed on trunk and the fix is nominated for backport in r1361119. The less trivial merges already had a similar code path that 'fixed' this problem. Bert
RE: How to prefer ipv4 over ipv6?
> -Original Message- > From: James Cloos [mailto:cl...@jhcloos.com] > Sent: woensdag 18 juli 2012 19:46 > To: users@subversion.apache.org > Subject: How to prefer ipv4 over ipv6? > > Can one configure the subversion clients to prefer ipv4 over ipv6 when > both route to the target server? > > I presume, if so, that it would be done via --config-option, yes? > > I'm on 1.7.5, with neon for webdav. > > I see that svnserve prefers ipv4 and has an option to instead prefer > ipv6, but I haven't found anything for the clients, yet. There is no configuration setting for this. I would recommend fixing your dns (probably by adding an ipv4 alias to the server) or running your server (also) on ipv6 as that immediately fixes it for all users of your repository. A client setting would require all clients to be configured specifically, while DNS was invented to avoid that. Bert
RE: error on SVN upgrade working copy when repository has been relocated
> -Original Message- > From: Johannes Lengler [mailto:johannes.leng...@googlemail.com] > Sent: vrijdag 27 juli 2012 10:52 > To: users@subversion.apache.org > Subject: error on SVN upgrade working copy when repository has been > relocated > > The error message has been reported previously, but I did not see that > the problem has been resolved: > (I had to type by hand as c&p did not work) This assertion is caused by a tree conflict containing a url that is not normalized properly according to the 1.7 rules. This issue has been fixed on trunk and the fix will be part of Subversion 1.7.6. (The fix is of course that we normalize this url on import) If possible I would recommend marking the tree conflict as resolved using an old client and then upgrading again. Bert
RE: AW: Corrupt .svn directory using Subversion 1.7
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: maandag 20 augustus 2012 22:10 > To: Philip Martin > Cc: Steven Lee; Markus Schaber; users@subversion.apache.org > Subject: Re: AW: Corrupt .svn directory using Subversion 1.7 > > On Mon, Aug 20, 2012 at 1:21 PM, Philip Martin > wrote: > > Steven Lee writes: > > > >> On Aug 19, 2012 11:45 PM, "Steven Lee" wrote: > >>> > >>> Yes, I tried "svn update --set-depth infinity" and nothing happened. > >> Many of the files are still missing from my working copy. It does seem > >> like that should have worked. > >>> > >> > >> Just to be clear, I tried "svn update --set-depth infinity" in the foodir > >> directory and "svn update --set-depth infinity foodir" in foodir's parent > >> directory. > > > > The problem is that in 1.7 the operation you interrupted is not properly > > atomic so foodir is probably still marked as depth infinity despite > > haoving missing children. > > Can / should this be fixed? Should an issue be created for this? svn update --set-depth exclude was not atomic in 1.7, but is fully atomic on current trunk. (Fixed about one and a half month ago) svn update --set-depth infinity is not atomic, but is fully able to recover from problems by restarting the same operation. Until the operation is completed on some subtree the directory is marked incomplete and this will make the next update (after interruption) load missing children. (This 'incomplete' behavior was implemented far before 1.0) Bert
RE: E200030 error on checkout
Withut knowledge of your setup: My guess would be that your setup accidentally picks up an older Sqlite as this syntax is supported by all our supported Sqlite versions. (Maybe by using a different library at runtime that at compile time). If you are upgrading Sqlite specifically I would recommend going to a very recent 3.7 version as there are relevant optimizer fixes that may speed up several operations. Bert From: Ferreira, Matthew [mailto:mferre...@navisite.com] Sent: woensdag 22 augustus 2012 14:15 To: users@subversion.apache.org Subject: RE: E200030 error on checkout Correcting the subject line to reflect the actual error code From: mferre...@navisite.com Sent: Tuesday, August 21, 2012 1:45 PM To: users@subversion.apache.org Subject: e20300 error on checkout When using the svn client, seeing the following: svn: E200030: near "OLD": syntax error, executing statement 'CREATE TRIGGER nodes_insert_trigger AFTER INSERT ON nodes WHEN NEW.checksum IS NOT NULL BEGIN UPDATE pristine SET refcount = refcount + 1 WHERE checksum = NEW.checksum; END; CREATE TRIGGER nodes_delete_trigger AFTER DELETE ON nodes WHEN OLD.checksum IS NOT NULL BEGIN UPDATE pristine SET refcount = refcount - 1 WHERE checksum = OLD.checksum; END; CREATE TRIGGER nodes_update_checksum_trigger AFTER UPDATE OF checksum ON nodes WHEN NEW.checksum IS NOT OLD.checksum BEGIN UPDATE pristine SET refcount = refcount + 1 WHERE checksum = NEW.checksum; UPDATE pristine SET refcount = refcount - 1 WHERE checksum = OLD.checksum; END; ' When I searched around I found a lot of users seeing issues with CygWin, but I'm using Solaris 9 Sparc w/ sqlite 3.6.18 It creates the directory with the wc.db file and a couple others but doesn't check anything out Thanks in Advance Matt Ferreira Web Services Engineer, Sr. - Managed Web Serivces NaviSite - A Time Warner Cable Company mferre...@navisite.com Office: (978) 946-7747 Mobile: (978) 631-9810 Description: cid:image001.jpg@01CC038E.F3B18AC0 _ This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. <>
RE: Pristiine copy not present
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: vrijdag 24 augustus 2012 18:32 > To: Simon Heffer > Cc: users@subversion.apache.org > Subject: Re: Pristiine copy not present > > Simon Heffer wrote on Fri, Aug 24, 2012 at 15:55:29 +: > > > > We seem to have a deadlock of some kind... > > At the end of a system build we commit our built components to a binary > repository... > > > > svn cleanup --username x --password x > > > > Last I checked, 'cleanup' does not access the repository (well, maybe > except for upgraded 1.0 working copies or something like that, Bert > would know :)), so it doesn't need these arguments. svn upgrade needs access to the repository for 1.0 working copies, but svn cleanup never. (Very early in 1.7 development we used svn cleanup for the upgrade, but we never released that code) > > svn commit -m "build msg" --username x --password > > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe' > not present > > svn: E155004: Commit failed (details follow): > > svn: E155004: Working copy 'D:\xx\Base' locked. > > svn: E155004: 'D:\x\Base' is already locked. > > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) > > > > If I run svn cleanup again I get: > > svn: E155010: Pristine text 'd9b41b57756396b9cb236801fc02e0da0a83dffe' > not present > > > > or update: > > svn update > > svn: E155004: Working copy 'D:\xx\Base' locked. > > svn: E155004: 'D:\x\Base' is already locked. > > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) > > > > The working copy is quite new i.e. not much opportunity to screw it up :( Which build system do you use? Some very popular java based buildsystems automatically use svnkit, and in that case we might have to call in others to help in diagnosing the problem. Bert > > > > Great! Can you show a complete command sequence that starts with a > clean checkout and ends with the above error? > > What's your svn --version? > > > > > Simon Heffer > > > > > > Please consider the environment before printing this e-mail. > > > > Micro Focus Limited is registered in England and Wales. Registered number: > 01504593 Registered office: The Lawn, 22-30 Old Bath Road Newbury, > Berkshire, RG14 1QN, UK > > This message has been scanned by MailController - > portal1.mailcontroller.co.uk
RE: problem with dialog box uisng Tortoisesvn
$ svn ci -m "comment" Is a common way for documentation to tell that you should type exactly what is behind the $. The '$' itself is a placeholder for your prompt which could be something like 'C:\Windows>' on Windows or something like '~/svn-site (bert@host)' on another system. If you leave out the $ and installed the commandline binaries things should work for you. Bert PS. Please use plain text on this mailing list as that makes it much easier/possible to answer in-line. From: Carmit Shiran [mailto:carmit.shi...@gmail.com] Sent: woensdag 5 september 2012 11:15 To: Cooke, Mark Cc: users@subversion.apache.org Subject: Re: problem with dialog box uisng Tortoisesvn On Wed, Sep 5, 2012 at 11:43 AM, Cooke, Mark wrote: > -Original Message- > From: Carmit Shiran [mailto:carmit.shi...@gmail.com] > Sent: 05 September 2012 09:25 > To: users@subversion.apache.org > Subject: problem with dialog box uisng Tortoisesvn > > hello, > I downloaded Tortoisesvn to my computer. > I want the following command to be executed without opening > the dialog box at the end (I don't want the user to enter any data): > > TortoiseProc.exe /command:commit > /path:"C:\Projects\Widget3_Dev" /closeonend:1 > > The /closeonend:1 doesn't seem to work. I still get the pop-up dialog. > > I also tried changing the settings and switched the: > General->Dialogs 1-> Autoclose to : Auto-close if no errors. > > But this also doesn't work. > > Can you help me out? > What am I not doing right? > > Thanks, > Carmit Why not just use the svn command line tools (they are an optional component when you install TortoiseSVN)? You could then call `svn commit`, see the on-line book help:- http://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html#svn.tour.cycle.commit ~ mark c OK- I tired now: c:\Program files\TortoiseSVN\bin> $svn commit I got the following message: '$svn' is not recognized as an internal or external command, operable program or batch file. Where exaclty am I supposed to write this command. I dont' see in the book In what path on the cmd line? Is this how to use it? Do I write $svn? or just svn (which also didn;t work for me)? Am I supposed to download anything else besides TortoiseSvn? (I downloaded it form <http://tortoisesvn.net/downloads.html> http://tortoisesvn.net/downloads.html, for 32-bit OS) I appreciate your help. Thanks, Carmit
RE: SVN keeps getting my AD password revoked.
> -Original Message- > From: Wendell Nichols [mailto:wc...@shaw.ca] > Sent: maandag 17 september 2012 18:16 > To: users@subversion.apache.org > Subject: SVN keeps getting my AD password revoked. > > I have many eclipse subversion based projects. I work on them as > needed. the probelm is that if I open a project that I haven't accessed > in some time and the cached svn password is old (and therefore wrong) by > the time I notice it has tried three times (or more) under the covers to > login and AD revokes my userid. If I'm working when the helpdesk is not > manned, I'm screwed till the next day! > I would like to have a setting that restricts auth errors to one attempt > before notifying me. That includes, for instance, opening three old > projects at once. This is how active directory is setup on your system. The number of allowed attempts and the block time are completely configurable by your enterprise admin and what you describe are certainly not the common defaults. Where I used AD before we had a limit of 5 attempts which automatically reset to 0 when a successful login was attempted. And it only blocked for 15 minutes. (Which would allow about 500 unique password attempts in 24 hours. Low enough to keep a half year valid good password safe) Subversion over http/https should usually only attempt once before prompting so I don't see why you see it blocking your access. Maybe there are scenarios where Eclipse/Subclipse/Subversion retries for you, but that is not something we can fix with a single generic solution in Subversion itself. In my case my mail client and VPN access were more likely to get me locked out. Bert > > Does this sound familiar? > Thanks Wendell Nichols
RE: Apache won't start after upgrade
Are you sure you need these DLLs. Dependeny walker also shows missing
*optional* dlls, such as the IEHIMS.DLL you mention in your list. I've never
found that with dependency walker, even on applications that work perfectly
fine.
I don't know about devmgr.dll, but WER would point me to Windows Error
reporting and I would guess that it is optional as well.
Bert
From: Hawkins, John [mailto:john.hawk...@transcore.com]
Sent: vrijdag 21 september 2012 09:54
To: Hawkins, John; Mark Phippard
Cc: users@subversion.apache.org; TCORE-CM
Subject: RE: Apache won't start after upgrade
Mark. The "Dependency Walker" allowed me to find three missing DLL's
(DEVMGR.DLL, IESHIMS.DLL, WER.DLL) with the Collabnet SVN/Apache 1.7.6.
Do you know the procedure for restoring these DLL's?
Thanks JCH
From: Hawkins, John
Sent: Wednesday, September 19, 2012 2:14 PM
To: Mark Phippard
Cc: users@subversion.apache.org; TCORE-CM
Subject: RE: Apache won't start after upgrade
Thanks Mark. Excellent help! Thank you again. JCH
From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Wednesday, September 19, 2012 2:02 PM
To: Hawkins, John
Cc: users@subversion.apache.org
Subject: Re: Apache won't start after upgrade
It probably means when mod_dav_svn.so is loaded it then tries to load the
dependent DLL's it uses. Most likely you have an older version of one or
more of those DLL's in PATH. Maybe a reboot would help if PATH was changed.
You can download and install Dependency Walker and then drag and drop the
mod_dav_svn.so file into the window. That will tell you what DLL's it loads
and likely point to the one with the problem.
On Wed, Sep 19, 2012 at 4:41 PM, Hawkins, John
wrote:
I upgraded Collabnet SVN 1.6.3 to 1.7.6. (On Windows)
Now Apache won't start.. The error is below. It is complaining during the
load of MOD_DAV_SVN.SO.
"The specified procedure could not be f ."
The module is in the modules folder. Which procedure it is looking for, and
where is expected, is unknown!
I updated Java, added the modules dir to the path, added .\httpd\bin to the
path.
No change.
Any ideas?
Thanks JCH
Event Type: Error
Event Source: Apache Service
Event Category: None
Event ID: 3299
Date:9/19/2012
Time:9:31:46 AM
User:N/A
Computer: SD-VCMSVN02
Description:
The Apache service named reported the following error:
>>> httpd.exe: Syntax error on line 86 of C:/Program Files (x86)/CollabNet
Subversion Server/httpd/conf/httpd.conf: Cannot load C:/Program Files
(x86)/CollabNet Subversion Server/httpd/modules/mod_dav_svn.so into server:
The specified procedure could not be f .
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Help needed: 'History scheduled with commit'
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: woensdag 10 oktober 2012 03:49 > To: David Aldrich > Cc: 'users@subversion.apache.org' (users@subversion.apache.org) > Subject: Re: Help needed: 'History scheduled with commit' > > That's 1.7, isn't it? Have you tried just committing? If you commit > using the cmdline client you'll get a second list of files in the editor > window, and even if you don't you can always revert the commit (via > reverse merge) or test by committing the merge to a newly-created > temporary branch. Committing an copy of a directory includes all the files inside. Before Subversion 1.7 merges would have reported all the files individually added, while it only committed the copy of the parent directory. We fixed this issue when switching to the new working copy backend. The result in the repository will be identical to what it was before 1.7, but status explains better what really happens. And now it can also report 'M +' when the file is scheduled to be added via its parent, but is itself modified. Bert
RE: Vc2012 support
> -Original Message- > From: Philip Herron [mailto:philip.her...@wandisco.com] > Sent: maandag 15 oktober 2012 11:52 > To: users@subversion.apache.org > Subject: Vc2012 support > > Hey > > Just wondering how far off vc2012 support is for gen-make.py? I tried to > use it and let vc upgrade the .project files etc but it didn't really > seem to work well throwing all kind of weird .proj errors and kind of > compiling some things. VC2012 support is available on trunk, but we haven't backported this to 1.6 or 1.7 (yet) as the changes are not trivial and upgrading the project files should just work. (Backport patch welcome of course) When you upgrade using Visual Studio, make sure you also update the referenced toolchain from v100 to v110 when upgrading from 2010 to 2012. (Should be available in the right click menu on the project and solution levels) Bert > > --Phil
RE: rsvndump crash
Hi, rsvndump is not part of the subversion project. It has its own site on http://rsvndump.sourceforge.net/ Recent Subversion versions have a similar tool ‘svnrdump’, which can create a remote dump file for you. It should be part of recent commandline binary packages. So maybe it is easier to test if svnrdump works for your specific task, before (or next to) reporting the problem to the author of rsvndump. Bert From: tom.malfr...@telenet.be [mailto:tom.malfr...@telenet.be] Sent: dinsdag 4 december 2012 13:26 To: users@subversion.apache.org Subject: rsvndump crash hi, I am trying to make a dump from a svn repository with rsvndump but it crashes every time. Can somebody help me finding out what is wrong? Tom
RE: Troubleshooting Gnome keyring
> -Original Message- > From: Nico Kadel-Garcia [mailto:nka...@gmail.com] > Sent: woensdag 19 december 2012 04:42 > To: Mark Phippard > Cc: Aubrey Barnard; users@subversion.apache.org > Subject: Re: Troubleshooting Gnome keyring > > On Tue, Dec 18, 2012 at 11:09 AM, Mark Phippard > wrote: > > On Mon, Dec 17, 2012 at 8:17 PM, Aubrey Barnard > wrote: > > > >> I am having trouble getting Subversion to work with the Gnome keyring > and > >> would like some advice on how to troubleshoot the situation. At this point > I > >> have tried everything I can find (Google, these archives), so I need to find > >> how/where things are failing. > >> > >> I am using the svn+ssh protocol to access a server within my organization. > >> Even with what I understand is the proper configuration, I am still > prompted > >> for my SSH password and Subversion never mentions a keyring or asks for > a > >> keyring password. The environment is RHEL 6, so I expected this to work > >> out-of-the-box with the default svn. More information is below. > > > > Subversion does not really do any authentication when you use SSH, so > > there are no credentials for it to cache and none of those settings > > come into play. > > > > When you use SSH, the authentication process is managed by your SSH > > client. I think most Unix users use something like ssh-agent to > > manage their keys and I believe there are flavors of that which > > interact with a GUI such as GNOME. > > But the "gnome-keyring" is supposed to manage this for you with Gnome > up and running. Aubry, which Subversion are you using? I've published, > SRPM tools at https://github.com/nkadel/subversion-1.6.18-srpm which > you may find useful to build a fully equipped Subveriosn 1.6.18, > compatible with Red Hat's, but with all the latest features such as > gnome-keyring support as much as can be activated with RHEL 5. Nico, when the user uses svn+ssh:// the Subversion authentication handling isn't used. I don't think your binaries add gnome keyring support to the system default ssh? Bert
RE: problem when upgrading my working copy
> -Original Message- > From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of > Philip Martin > Sent: donderdag 20 december 2012 16:20 > To: Pia Unte > Cc: users@subversion.apache.org > Subject: Re: problem when upgrading my working copy > > Pia Unte writes: > > > In file > > 'D:\Development\SVN\Releases\TortoiseSVN- > 1.7.10\ext\subversion\subversion\libsvn_wc\entries.c' > > line 1666: assertion failed (parent_node || entry->schedule == > > svn_wc_schedule_normal) > > I think that's a new one. Can you describe your working copy? Can you > use Subversion 1.6 and run status? Do you have adds, deletes, copies, > switches? Is your working copy mixed revision? Was there any output > before the assertion? This is caused by upgrading an added directory without its parent directory. Most likely caused by moving a single working copy directory. This state (added to a parent that does not exist) is not supported by the new working copy database introduced in 1.7. The database always requires the root of the working copy to exist in the repository. Bert
RE: branching WC folder fails with files marked as deleted
This issue sounds like a combination of issues #2763 and #3569.
The ‘svn up --depth empty’ in 1.6 triggers issue #3569:
http://subversion.tigris.org/issues/show_bug.cgi?id=3569 ‘svn update --depth
allows making a working copy incomplete’
While #2763 handles some similar cases in copies:
http://subversion.tigris.org/issues/show_bug.cgi?id=2763 ‘del -> ci -> cp =
missing directory?’
Both issues were fixed for 1.7 and are very hard to fix for 1.6 and earlier, as
the fix for both relies on the additional layers in WC-NG.
The easy fixes you might try break in other cases, as the data to do the right
thing is just not stored in the working copy in 1.6.
Bert
From: Roman Kellner [mailto:muzu...@gmx.net]
Sent: vrijdag 11 januari 2013 09:02
To: Daniel Shahaf; users@subversion.apache.org
Subject: Re: branching WC folder fails with files marked as deleted
Hello Daniel, hello Stefan
Sorry for the empty email. Dont know what happened to the web email.
I guess I found the issue and implemented the following feature in our MSSCCI
wrapper.
If you can confirm that, when I find a "deleted" line in the .svn/entries file
to a WC controlled file as shown below, then the file was only deleted in the
WC and is marked for deletion in the repo which will be done with the next
commit. Is this the exact meaning of "deleted" the the WC control area entries
file? And there is no other meaning?
c1cf5a64-afc7-45b3-963c-f8ce2ed2cecf.mtx
file
124877
< : >
deleted
Feature justification:
When a file is added to the repo, sync'd
(checked out/updated) to the working copy (by MTPE/MWT/MSSCCI),
later the same file is deleted from the repo and the working copy
sync'd (by MTPE/MWT/MSSCCI) again, this file is NOT 'updated'
(svn up file) which with SVN would remove the file from the working
copy but instead is (falsely) 'deleted' (svn del file) which removes
the working copy file and marks this file as scheduled to be deleted
in the working copies control area (.svn/entries).
Feature:
A 'SccGet' immediately following a 'SccPopulateList' where the
folders (SccPopList) and the file folders (SccGet) do match between
the two calls, will trigger a user dialogue asking whether to
update the folders instead of the file list passed to SccGet.
The feature can be controlled by setting the list size either
to <= 0 to disabled, or to > 0 to enable and configure the max.
file / folder list length in the dialog.
Use case:
MTPE/MWT sync.
Original-Nachricht
Datum: Thu, 10 Jan 2013 00:33:38 +0200
Von: Daniel Shahaf
An: Roman Kellner , users@subversion.apache.org
Betreff: Re: branching WC folder fails with files marked as deleted
Stefan Sperling wrote on Wed, Jan 09, 2013 at 14:21:06 +0100:
> On Wed, Jan 09, 2013 at 02:02:32PM +0100, Roman Kellner wrote:
> > - Now the user-A needs to branch his WC and gets the following error
> > message on commit
> > (the file shown in the error message is the one that was created and later
> > deleted):
>
> Please do not attach images when posting to a mailing list.
> Instead, copy/paste the error message into your email in plain text.
>
> > I would consider this a bug. Why does the client not simply ignore deleted
> > marked file entries?
>
> Subversion represents renames as a copy and a delete operation.
>
> Subversion does not allow you to commit deletions of outdated items,
> because this would prevent some tree conflicts from being detected.
I don't think one needs to understand tree conflicts to understand why
deleting out of date files is prevented. You can't delete a file that
has been committed to after you checked it out for the same reason you
can't modify such a file: because allowing you to go through would lead
to silently discarding the changes were done made in the newer revision
that your wc doesn't have.
('svn cp foo@oldrev bar' excepted)
RE: Local modification on checkout?
> -Original Message- > From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] > Sent: donderdag 17 januari 2013 23:46 > To: Laird Nelson > Cc: users@subversion.apache.org > Subject: Re: Local modification on checkout? > > > On Jan 17, 2013, at 15:30, Laird Nelson wrote: > > > Hello; we're seeing a local modification being reported on a particular file > on a clean checkout. We're using svn 1.7.7. > > > > The file in question has the svn:eol-style property set to native. > > > > What I mean by this: > > > > A fresh checkout happens (svn co ...). > > > > Down comes the whole project. So far so good. > > > > Then another part of our build infrastructure does an svn status. > > > > svn status reports that this file is locally modified (M). There are no > intervening steps. That is, it's checkout, then svn status. > > > > Does automatic eol conversion show up as a local modification in svn status > output? > > No, it shouldn't. > > > I can't reproduce this on either a Windows or a Mac. It appears to be only > on this machine, which, I know, sounds mad. > > When a file has svn:eol-style set to native, the Subversion client is supposed > to normalize the file to LF line endings before sending it to the repository to > be committed. The Subversion server does not verify that this has been > done, so it is possible for badly-written Subversion clients to commit files > with the wrong line endings. If a third-party svn client (git-svn?) was used to > commit this file, that might be a possible cause to investigate. Although it's > strange you only see the problem on one system. > > When checking out (or updating) a working copy, if any files have svn:eol- > style set to native, then the Subversion client transforms the line endings of > those files from LF to whatever svn:eol-style says to do before placing them > in the working copy. This can lead to unexpected situations if you check out a > working copy on an OS with one line ending style and then look at it or > update it from an OS with a different line ending style. If you think this might > have happened, check out a new working copy, and use it only on a single > system. > > Or perhaps again if you checked out or updated using a third-party svn client > that did not transform line endings in response to svn:eol-style native, then > you might later have a problem. A lot of users have SvnKit in their Jenkins installation. Are you sure that you aren't mixing a normal svn with some svnkit version? Bert
RE: Local modification on checkout?
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: vrijdag 18 januari 2013 11:50 > To: Ryan Schmidt > Cc: Laird Nelson; users@subversion.apache.org > Subject: Re: Local modification on checkout? > > Further, when mixing SVNKit with native svn usage, it's possible that > last-mod-times are already mismatching immediately after checkout. > That's because of an issue in SVNKit [2], where it only notes the > last-mod-time in the svn metadata up to millisecond precision. So if > you 'svnkit co', followed by 'nativesvn status', all files will have > mismatching timestamps, so they'll all be checksummed. Thanks for bringing this up.. I expected a problem like this, but was never able to confirm this. (if you have a pointer to more details, please let me know) This would exactly explain this problem. (Just like it explained a similar problem in our testsuite yesterday. Python appears to have a similar problem in its file timestamps) Bert
RE: Working copy corrupted by branch deletion
I'm not 100% sure how to reproduce this yet, but updating the folder to r0
and then updating it again should give you all children again. (You can also
use -set-depth excluded, and then an explicit update on the target)
I don't have suggestions on how you can do this with TortoiseSVN.
Bert
From: Maxwell Ballenger [mailto:maxwell.ballen...@spacex.com]
Sent: zaterdag 19 januari 2013 00:44
To: users@subversion.apache.org
Subject: Working copy corrupted by branch deletion
Hi Subversion Users,
We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14
(Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client
library 1.7.7). We noticed this using TortoiseSVN, but some folks on their
mailing list believe that this is a result of the Subversion client library,
not Tortoise. I am not sure whether this is a bug or intended behavior. Here
is what happens:
1. Branch a subfolder of your working copy
2. Switch that subfolder onto that branch
3. Delete that branch using another working copy or the repo-browser
4. Update your working copy
5. That subfolder disappears. There is no way to recover that subfolder and
have your working copy match the trunk again without doing a fresh checkout.
In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much
easier to recover from. Commanding a switch of a parent folder to trunk
would restore the missing subfolder.
Is this intended behavior, or could it qualify for a bug fix? Does anyone
know of a faster way to recover than a fresh checkout?
Thanks!
Max Ballenger
RE: Working copy corrupted by branch deletion
Hi, Thanks for a very interesting issue to look at. I'm happy to report that I would now call this issue fixed: I think we can call this a known issue as it has been known for quite some time. A workaround for this issue would be to do an explicit update of the missing target. (Or reducing and increasing the depth of the node). I documented the issue as issue #4295 with the following recipe $ svnadmin create repos $ svn mkdir --parents file:///%CD%/repos/A/B/C -m "" $ svn cp file:///%CD%/repos/A file:///%CD%/repos/AA -m "" $ svn co file:///%CD%/repos/A A $ svn switch ^/AA/B A/B $ svn rm file:///%CD%/repos/AA $ svn up A On 1.7 this reproduces your issue And a $ svn up A/B Will bring back the missing directory. When trying the same thing on trunk I found a completely different issue, where the complete update failed. I'm not going to bother you with the details of this report, as thanks to your bug report that huge regression will never be in a released version of Subversion. (Thanks!!!) To close issue #4295, I added a small check to the update code that handles incoming deletes. When it encounters a delete of a switched path it will now place a similar hidden marker as you would get when you update a path to r0 (or commit a file delete). The next update will now bring in the missing node. I will nominate the fix for backporting to a future 1.7 release. Bert From: Maxwell Ballenger [mailto:maxwell.ballen...@spacex.com] Sent: zaterdag 19 januari 2013 00:44 To: users@subversion.apache.org Subject: Working copy corrupted by branch deletion Hi Subversion Users, We're experiencing some new behavior after upgrading from TortoiseSVN 1.6.14 (Subversion client library 1.6.16) to TortoiseSVN 1.7.10 (Subversion client library 1.7.7). We noticed this using TortoiseSVN, but some folks on their mailing list believe that this is a result of the Subversion client library, not Tortoise. I am not sure whether this is a bug or intended behavior. Here is what happens: 1. Branch a subfolder of your working copy 2. Switch that subfolder onto that branch 3. Delete that branch using another working copy or the repo-browser 4. Update your working copy 5. That subfolder disappears. There is no way to recover that subfolder and have your working copy match the trunk again without doing a fresh checkout. In TortoiseSVN 1.6.14 (Subversion 1.6.16), a mistake like this was much easier to recover from. Commanding a switch of a parent folder to trunk would restore the missing subfolder. Is this intended behavior, or could it qualify for a bug fix? Does anyone know of a faster way to recover than a fresh checkout? Thanks! Max Ballenger
RE: URL based commands not working in hooks\
Usually you shouldn't use 'svn log' from a hook. When using hooks you want to use the 'svnlook' command instead of 'svn' as you are looking directly at a transaction in progress. (And 'svnlook log' is more efficient than using the server that calls your hook again to access the same repository) 'svn log' looks at the committed state, while 'svnlook log -t REPOS_PATH' looks at a transaction in progress. But as Ryan mailed, we can't really help you without knowing what your script tries to do. (Looking at this error it might be that you try to commit while the hook is invoked as part of another commit) Bert From: Ramachandran Raghavendran [mailto:ramachandran.raghavend...@flsmidth.com] Sent: maandag 4 februari 2013 11:55 To: users@subversion.apache.org Subject: URL based commands not working in hooks\ Hi, I have a hook that runs svn log. My VisualSVN server is set up to run on Windows authentication. When I do a commit, svn log command doesn't at all. The event log says the following Could not MERGE resource "/svn/Test/!svn/txn into [409, #0] Can you help me what could have gone wrong please. Best regards, Ramachandran Raghavendran IT Project Consultant Direct +91 44 4748 3961 . ramachandran.raghavend...@flsmidth.com _ IT Operations - Infrastructure Management Services FLSmidth 34 Egatoor, Kelambakkam . Tamil Nadu . 603 103 . India Tel +91 4447481000 . Fax +91 4427470301 www.flsmidth.com Income Tax Permanent Account Number: AAACF4997N _ Important note! Please note that this mail including any attachment may contain confidential or privileged information for the intended recipient only. If you receive this mail in error you should refrain from making any use of the contents and from opening any attachment, but instead notify the sender immediately by phone or mail. Thank you. Please also note that the exchange of non-encrypted communication via the Internet may be compromised electronically and for that reason we take no responsibility for the integrity of such communication. This e-mail message has been swept by antivirus systems for the presence of computer viruses. In doing so, however, we cannot warrant that virus or other forms of data corruption caused by such may not be present. We expect any recipient of e-mail communication to have in place protection systems of his own choice.
RE: FreeBSD project and subversion.
> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: woensdag 6 februari 2013 00:08 > To: Johan Corveleyn > Cc: Alexey Neyman; users@subversion.apache.org; Alfred Perlstein > Subject: Re: FreeBSD project and subversion. > > On Tue, Feb 05, 2013 at 09:18:33PM +0100, Johan Corveleyn wrote: > > Hmm, okay, but I would have preferred some more discussion before you > > implemented this. It's not clear to me that this decreases the > > surprises. I can perfectly imagine just as many questions being asked > > on users@ with the question: "Why does 'svn diff left.txt right.txt' > > give me an empty diff, while 'svn diff ^/left.txt right.txt' does the > > right thing?" > > > > I think it would be better to consistently point users to the > > --old/--new syntax, so as to educate users more (so I'm okay with the > > change in the error message), not hide it even more from them. > > Well, the point that convinced me was that previously 'svn diff' raised > an error in the case of 'svn diff ^/left.txt right.txt'. > That's clearly intended to be a comparison between a URL and a path, > which the diff code already supports. So I think the diff code should > just show an appropriate diff. I don't see how people could be conflating > a URL->WC or WC->URL diff with a WC->WC diff. > > BTW, I'm thinking about adding more shortcuts: > > svn diff UNVERSIONED-PATH WCPATH > svn diff WCPATH UNVERSIONED-PATH > svn diff UNVERSIONED-PATH1 UNVERSIONED-PATH2 > > All of which are supported by 'svn diff --old=X --new=Y' (in 1.8-to-be, > not in 1.7), but not by plain 'svn diff'. I'm not sure if I like these variants with unversioned paths. This might make users think that these paths are versioned and without warning who wouldn't expect that? The new unversioned/arbitrary diff is nice in specific situations, but it shouldn't' break the normal cases where 'svn diff *' would do one thing completely differently if it happens to match exactly two files, where one is versioned and one is not, or both are unversioned. If we want something like that we should support that with a flag like --unversioned (better name suggestions welcome) I really like the url vs path diff changes though. Bert
RE: How to change password when is about to expire
> -Original Message- > From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com] > Sent: donderdag 7 maart 2013 13:15 > To: LARRAIN, GUIDO MARTIN (AG-Contractor/5000) > Cc: users@subversion.apache.org > Subject: Re: How to change password when is about to expire > > Hello Guido, > > > I'm newbie on Subversion and I have a few questions about some > particular > > configurations on SVN. > > > > Let me gives you the scenario. > > > > We have a subversion installed on a Linux box and its working fine! We > have > > some repos there that developers across the company use to store code > and > > some other things. > > > > We also have SVN configured to use LDAP authentication to allow users to > use > > the right repo. > > > > But we are facing a problem that when users account expire they don't get > > any message saying that is about to expire and then, of course, they can't > > login because of that. > > > > So my question is if there is a way to configure apache to allow users to > > change their password when is about to expire. > > VisualSVN Server can help you here. However it's Windows-only > Subversion server package: http://www.visualsvn.com/server/. Do you > have some special technical requirement to install Apache Subversion > server on a Linux box? > > * If you are in Active Directory environment you can benefit from > Windows authentication which allows users to access VisualSVN Server > with their Windows credentials. > > Windows authentication relies on Active Directory users and groups so > you can manage authorization settings based on existing AD accounts. > In other words you don't need to manage separate user list. So when > user's Windows password expires he will be prompted to change on > Windows logon (as usual, in fact). > > Integrated Windows Authentication, which is available in Enterprise > edition, enables AD Single Sign-On and improves password security. I > advise you to check the feature description at > http://www.visualsvn.com/server/features/windows-auth/. While (as far as I know) VisualSVN is the only tool that makes it this easy to setup, you can also use Active Directory as LDAP server with almost every Subversion server package. (Wandisco, CollabNet, etc.) And if you setup Apache httpd yourself you can avoid typing passwords by setting up mod_authz_sspi. (I think VisualSVN uses a combination of these systems) Bert
How to set default conflict style?
Hi, I would like to set the conflict presentation style to svn_diff_conflict_display_modified_original_latest. How do I do this? Thanks. Regards, Bert Wesarg
RE: Where are the plaintext passwords stored
> -Original Message- > From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > Sent: donderdag 21 januari 2010 16:41 > To: users@subversion.apache.org > Subject: Where are the plaintext passwords stored > > I always thought the passwords were stored in the .subversion/auth folder > (I'm using Linux). And for plaintext passwords I expected to actually see it > there, is some files, in, well, plain text. But I don't. So, just out of curiosity (I > don't store passwords anyway), where are they? Looking at your e-mail headers, I guess you are using Windows. On Windows (NT 4 and later) the passwords are stored in the auth folder, but encrypted with the per user cryptographic key managed by the Windows CryptoAPI. I think this feature was added around Subversion 1.3/1.4. Before that and on other operating systems than Windows the password is stored in there as plain text if there is no specific store available. Since Subversion 1.6 you get a warning from svn when the password will be stored as plain text. Bert
