RE: is it necessary to svnsync copy-revprops all reversions everytime executing svnsync?
No, Just using svnsync will handle copying revprops while synchronizing revisions just fine. But revprops may change later if you enable that option in your repository, so if you use svnsync to keep two repositories completely synchronized you might want to use this feature to sync those changes. Bert From: Keva-Slient [mailto:356730...@qq.com] Sent: vrijdag 20 april 2018 14:48 To: users <users@subversion.apache.org> Subject: is it necessary to svnsync copy-revprops all reversions everytime executing svnsync? is it necessary to svnsync copy-revprops all reversions everytime executing svnsync?
RE: File not accepted as valid addition to svn
> -Original Message- > From: Bo Berglund [mailto:bo.bergl...@gmail.com] > Sent: maandag 12 februari 2018 18:42 > To: users@subversion.apache.org > Subject: Re: File not accepted as valid addition to svn > > On Mon, 12 Feb 2018 15:54:00 +, Philip Martin > <phi...@codematters.co.uk> wrote: > > >Bo Berglund <bo.bergl...@gmail.com> writes: > > > >> svn add Fasadändring > >> svn: warning: W155010: 'D:\Bosse\Fasadändring' not found > > > >'&' has special meaning to the shell and needs to be quoted or escaped. > > I always thought that this was the case only for Linux, since & is a > perfectly valid part of a file name on Windows... > But I will refrain from such characters in paths in the future. F:\>echo q q 'r' is not recognized as an internal or external command, operable program or batch file. F:\> It is a separator between multiple operations on the same line. You could quote the argument with "-characters, which usually just pressing TAB would do for you on Windows if the file exists. Another option is adding a ^ in front of the &. Bert
RE: Searching for a C++ API
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: maandag 29 januari 2018 13:54 > To: users@subversion.apache.org > Subject: Re: Searching for a C++ API > > On 29.01.2018 11:45, R developer wrote: > > Hello all, > > > > I have been involved in writing a closed source application that among > > other things maintains a checkout from an SVN repository, the > > application used to be written in C# so at the moment we are used to > > SharpSvn. Recently the decision was made to incorporate the > > functionality into a mobile c++ app (yes, I do wish we could use a > > different language, but for now that's out of our scope). > > > > Is there a C++ library available somewhere? > > One that can be used in a closed source app and compiles both on > > Windows and Linux (and preferably other platforms like OSx, iOS, Android). > > Usage of c++11, boost and/or Qt frameworks is fine as our app already > > uses them. It is not a real C++ library, but there might be some code that you can copy from the SharpSvn library code for your usage. SharpSvn is C++/CLI, to allow operation with the .Net environment, but there is enough plain C++ inside that might be able to get you started with the C library. The code is Apache licensed so you can mostly use it however you like. Bert
RE: when will file ./svn/tmp/svn-XXXXXX be created? and why?
In many cases Subversion will create files there, then write its contents and when done move the file to the required location in your working copy. This makes sure that you will never see half written files during operations… and by that loose valuable information. Bert From: Keva-Slient [mailto:356730...@qq.com] Sent: donderdag 21 december 2017 08:29 To: users <users@subversion.apache.org>; 王运 <694591...@qq.com>; bluecat <690853...@qq.com> Subject: when will file ./svn/tmp/svn-XX be created? and why? we use svn managing our config files. in client side environment, check out repos in client side, processes could open the config file and read or write the config file. some of them could keep file handler for a long time. now we get some problems: the config file will be moved to .svn/tmp directory and be deleted. for example: online_assist process: online_assist will open some config files in /wns/etc/config/ directory. /wns/etc/config/ is a repo. use losf to see which files online_assist are opening. #lsof |grep online_assist |grep .svn/tmp 704 /wns/sbin/online_assist /wns/etc/config/.svn/tmp/svn-ynboPV (deleted) 704 /wns/sbin/online_assist /wns/etc/config/.svn/tmp/svn-sTknMU (deleted) 704 /wns/sbin/online_assist /wns/etc/config/.svn/tmp/svn-39HEsA (deleted) online_assist should open config files which are not in .svn/tmp directory. in usual, online_assist should open config files like : /wns/etc/config/db/ap_data.db ... #pidof online_assist 704 #ls -l /proc/704/fd/* -l |grep config |sort -k 10 lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/19 -> /wns/etc/config/.svn/tmp/svn-39HEsA (deleted) lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/18 -> /wns/etc/config/.svn/tmp/svn-sTknMU (deleted) lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/15 -> /wns/etc/config/.svn/tmp/svn-ynboPV (deleted) lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/23 -> /wns/etc/config/db/china_province_city.db lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/20 -> /wns/etc/config/db/phonelocation.db lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/16 -> /wns/etc/config/wac/data/ouiol.db lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/21 -> /wns/etc/config/wac/data/ouiol.db lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/17 -> /wns/etc/config/wac/data/sta_login_stat.db lrwx-- 1 root root 64 Dec 20 08:22 /proc/704/fd/22 -> /wns/etc/config/wac/data/wti.db some files opened by online_assist in /wns/etc/config are correct, like /wns/etc/config/wac/data/ouiol.db. but some are moved to /wns/etc/config/.svn/tmp and deleted. why is this ? why would the file opend by process be moved to .svn/tmp and why would the file moved to .svn/tmp be deleted? -- . Vanity...My favourite sin. --<>
RE: Access Violation problem in Code Collaborator tool
Hi, You just posted this to a publicly archived mailing list. I would recommend changing the password you use for this Subversion server now. I can't really tell you what caused this problem, but I would recommend upgrading your Subversion client first. We (as Subversion project) are no longer providing patches for Subversion 1.7.7. Bert From: gopayya.devarako...@dell.com [mailto:gopayya.devarako...@dell.com] Sent: donderdag 23 november 2017 14:31 To: users@subversion.apache.org Subject: Access Violation problem in Code Collaborator tool Dell - Internal Use - Confidential Hi, PFA, for trouble shooting the problem I am facing in Code Collaborator. Thanks in Advance.
RE: GitHub svn bridge corrupting working copies
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: zondag 15 oktober 2017 21:28 > To: Ryan Schmidt <subversion-2...@ryandesign.com> > Cc: Subversion Users <users@subversion.apache.org> > Subject: Re: GitHub svn bridge corrupting working copies > > Ryan Schmidt wrote on Sun, Oct 15, 2017 at 14:00:10 -0500: > > On Oct 15, 2017, at 13:07, Daniel Shahaf wrote: > > > Ryan Schmidt wrote on Sun, 15 Oct 2017 12:49 -0500: > > >> And the problem will just occur again sometime later with a different > node. The node it complains about is always a directory that someone else > committed to recently, [...] > > > > > > Have you looked at these commits? Is there anything unusual in them, > > > e.g., do they involve renames? > > > > Nothing unusual; just modifying one file and adding another: > > > > https://github.com/macports/macports- > ports/commit/2198debd25b02bcf7f6b17f79b415690449a85f0 > > Okay, so perhaps the problem has to do with revisions that add new > files. > > > Somehow I don't think specific revisions are the problem. I mean, I > > can now check out a new working copy at revision 139307 and > > successfully update it to 139308. Meanwhile, on our server, once, > > back in August, it encountered a corruption already halfway through > > the process of checking out a new working copy. And on the next > > checkout attempt it worked. > > Indeed, there is little we can do without knowledge of the bridge. > There is any number of ways in which these observations might be > confounders. > > > > You might be able to reproduce the problem by backdating your working > > > copy, 'svn up -r N-1 && svn up -r N kde'. > > > > Inside the kde directory, I ran: > ⋮ > > $ svn up -r 139308 > > Updating '.': > > UU kdepimlibs4/Portfile > > Skipped 'kdepimlibs4/files/patch-do_not_include_cpp.diff' -- An > obstructing working copy was found > > That's interesting; why would there be an obstruction? > > Maybe a file by this name already existed at some point, and was not > removed cleanly? > > Or perhaps github reported the 'add' to the client twice? One probable cause for this would be that they somehow changed the revision number to hash mapping. I would hope they change the repository UUID in this case, but given how easy it is to change history in git, I wouldn't count on this. Is this problem reproducible on a clean checkout from the same base revision? Bert
RE: Problem with file name encoding during merge - URL Encoding (Percent Encoding)
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: vrijdag 6 oktober 2017 16:24 > To: Bartosz Pierzchlewicz <bartosz.pierzchlew...@komputronik.pl>; > users@subversion.apache.org > Subject: Re: Problem with file name encoding during merge - URL Encoding > (Percent Encoding) > > I can't reproduce your problem using a trunk client and httpd-2.4.25 on Linux. > > Is there any http proxy or reverse proxy in your setup? That could cause some issues. Some specific bad httpd versions or selective backports of those 'fixes' could do that too... But I wouldn’t be surprised to see some of these issues with Subversion 1.6 or earlier under some specific circumstances. We didn't have all these nice url and path helper functions with strictly defined behavior in those older releases. Bert
RE: override global-ignores from server side
> -Original Message- > From: Balogh Péter [mailto:balogh.pe...@xcite.hu] > Sent: dinsdag 19 september 2017 10:59 > To: users@subversion.apache.org > Subject: Re: override global-ignores from server side > > Hi, > > Yes, I'm aware that adding the .a file manually is possible, but it does not > solve the issue, that we have to check manually after every library update, if > a new .a file is added And the issue won't show up, until we commit the > changes, and the CI build fails with a linking error The default list is not > large, > that's why overriding it does not seem to be an irrational request But right > now, if I put a .a file in an SVN, I have no way to make it show up in the > status without client side modifications, and I think it's a really important > missing feature Where I work we have a strict policy that we don't release binaries that are built on normal workstations, just those on regulated build systems where we can 100% reproduce previous builds. Having a default that would make users commit locally build artifacts would go against that. We manage these artifacts using different tooling that was designed for that purpose. Bert
RE: override global-ignores from server side
> -Original Message- > From: Balogh Péter [mailto:balogh.pe...@xcite.hu] > Sent: dinsdag 19 september 2017 10:45 > To: users@subversion.apache.org > Subject: override global-ignores from server side > > Hi, > > I think our use case is not covered even with the recent features in > subversion By default, for example the .a files are ignored in the svn clients > Since we're developing mobile multi platform titles, it's common to add > certain libraries as .a files to the repository Is there a way, to override > the > client's default global-ignores with a repository specific one? The ignores are only applied to files that are not already added, so in your case just adding the files and applying the ignore rule on a system where you do want to add these would just work fine. The default list of ignores is not that large and you can add items via svn:ignore and svn:global-ignores properties on a directory. Bert > > Best regards, > Peter
RE: Subversion svn+ssh, sshd 100% CPU
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: donderdag 14 september 2017 22:10 > To: Matt Simmons <band...@gmail.com> > Cc: Zoran Petkovic <zo...@ietcombustion.com>; > users@subversion.apache.org > Subject: Re: Subversion svn+ssh, sshd 100% CPU > > On Wed, Sep 13, 2017 at 7:20 AM, Matt Simmons <band...@gmail.com> > wrote: > > On Tue, Sep 12, 2017 at 12:14 PM Zoran Petkovic > > <zo...@ietcombustion.com> > > wrote: > Perhaps the windows client and the linux client are performing the checkout > in a different way for some reason (I'm thinking of the so-called "skelta > mode" vs. "bulk mode", see http://subversion.apache.org/docs/release- > notes/1.8.html#serf-skelta-default). 'Skelta vs bulk' is specific to operations over http(s), so this wouldn't apply here. The relevant part here is probably which ssh client is used here. On most *nix systems this would be openssh, while on most Windows systems I would see some putty based tools. Bert > > -- > Johan
RE: Checksum mismatch bug in 1.8.18
This specific error message was added in the last release, so yes it is new in the last versions. The last 1.9.x version also added it and I'm surprised that you see the error on 1.8 and not 1.9 (or vice versa). It tries to tell you that you have two files with an identical SHA-1 hash, but different contents. A case that we accidentally didn't catch before, that might have caused some data loss under extreme circumstances. This scenario is pretty unlikely to trigger, unless you specifically try to do that. I'll try to verify what exactly is in your dump file to see if you really hit this scenario, or that we have a bug in our code that tries to catch this scenario. Assuming you properly verified with 1.9.6 (and not 1.9.5 or earlier) I assume that this is a bug in 1.8.18, as other scenarios are really extremely unlikely. I'm not sure I'll have time to look into this before Monday though, so perhaps one of the other developers beats me to it. Bert From: David Engel [mailto:den...@magnitude.com] Sent: zaterdag 29 juli 2017 00:01 To: users@subversion.apache.org Subject: Checksum mismatch bug in 1.8.18 Hi, I think I'm running into a bug in svnadmin in the latest 1.8 release (1.8.18). It is not present in 1.8.17 nor 1.9.5 nor 1.9.6. I'm guessing it's related to the recent changes around strict repsharing. I'm not subscribed to the mailing list, so please CC me on any responses. Here are the relevant details: OS: Windows 10 and Windows 2012 R2 Subversion release: 1.8.18 Both SlikSVN release: svnadmin, version 1.8.18-SlikSvn-1.8.18-X64 (SlikSvn/1.8.18) X64 compiled Jul 17 2017, 13:03:37 on x86_64-microsoft-windows6.2.9200 And Collabnet release: svnadmin, version 1.8.18 (r1800620) compiled Jul 7 2017, 05:51:59 on x86_64-microsoft-windows6.2.9200 Performing an svnadmin load results in the following error: ... <<< Started new transaction, based on original revision 650 * editing path : Dev/Common/Utils/External/StampVerData/MetaBuilderVersion.inf ... done. * editing path : Dev/Common/Utils/External/StampVerData/MetaBuilderVersionDBG.inf ... done. * editing path : Dev/Common/Utils/External/StampVerData/OracleVersion.inf ...svnadmin: E16: SHA1 of reps '-1 0 45 132 a6ea37d29094deece56250ebe167ce46 6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1 650-i2/_8' and '-1 136 45 132 a6ea37d29094deece56250ebe167ce46 6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1 650-i2/_8' matches (6a2d6bc4c7e58c0d2627a1b0dd5b23e542aec4d1) but contents differ svnadmin: E160004: Filesystem is corrupt svnadmin: E200014: Checksum mismatch while reading representation: expected: a6ea37d29094deece56250ebe167ce46 actual: 5f696f5d0755f3bcb5e927bdfba4bfa8 In order to reproduce the error, you can use the attached VersionStamps3 repository dump file. It was taken with the same version of svnadmin from a multi-GB repository that's been around for over a decade and pruned (svndumpfilter) to a small set of files and revisions in one folder while still encountering the error. I first encountered the error another place very quickly in an incremental load on top of a repo that was loaded from 1.8.14, but that one was on a revision north of 120,000+. This is way easier to reproduce. I tried filtering the dump further and dropping empty revisions, but the error did not occur in those cases. The error also did not occur using 1.8.17, 1.9.5., and 1.9.6. It also did not occur in 1.8.18 if I set enable-rep-sharing = false before performing the load. Repro.bat script: @echo off :defineCommands rem You might need to adjust these lines to point to your rem compiled-from-source Subversion binaries, if using those: for %%i in (svn.exe) do set SVN="%%~$PATH:i" for %%i in (svnadmin.exe) do set SVNADMIN="%%~$PATH:i" :defineUrls rem Only supported access method: file:// <file:///> . If http:// or svn://, then rem you'll have to configure it yourself first. set URL=file:///%CD%/repos set URL=%URL:\=/% echo Base url for repo: %URL% :cleanAllDirsAndCreateRepo if exist repos rmdir /s /q repos if exist import-me rmdir /s /q import-me if exist wc rmdir /s /q wc %SVNADMIN% create repos pause :prepareGreekTree echo Making a Tree for import... mkdir import-me\Dev\Common\Utils\External echo Importing it... cd import-me %SVN% import -q -m "Initial import." %URL% cd .. rem This is where your reproduction recipe goes. svnadmin --version svnadmin load repos < VersionStamps3 goto :eof Thanks, David
RE: "Unable to parse reversed revision range" when merging from trunk to branch
Can you point to the discussion on the mailinglist where this issue was discussed before creating the issue in our tracker? (We only create issues to track confirmed issues on the tracker *after* discussion here, or on the development list) This is the first time I hear about this issue, but perhaps I missed the earlier discussion. Bert From: Paul Hammant [mailto:p...@hammant.org] Sent: vrijdag 7 juli 2017 13:25 To: Jens Restemeier <j...@playtonicgames.com> Cc: Stefan Sperling <s...@elego.de>; Johan Corveleyn <jcor...@gmail.com>; users@subversion.apache.org Subject: Re: "Unable to parse reversed revision range" when merging from trunk to branch Done: https://issues.apache.org/jira/browse/SVN-4686 Jumping in with something that's in the same area - https://issues.apache.org/jira/browse/SVN-4635 is a merge tracking (or merge info/range props) bug that is still there in v1.9.6, in case anyone wants a scripted reproduction (30 seconds of bash script invocation). -ph
RE: --editor-cmd not working with paths with spaces?
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: vrijdag 7 juli 2017 09:23 > To: users@subversion.apache.org > Subject: --editor-cmd not working with paths with spaces? > > Hi all, > > I need to commit to some SVN repo in a Git bash/MinGW environment and > recognized the following error: > > > $ svn ci --editor-cmd "/usr/bin/vi" > > Der Befehl "C:/Program" ist entweder falsch geschrieben oder konnte nicht > gefunden werden. > > svn: E200012: Commit failed (details follow): > > svn: E200012: system('C:/Program Files/Git/usr/bin/vi svn-commit.4.tmp') Where is your vi.exe located? If it is in C:\usr\bin\vi.exe I would recommend using --editor-cmd "C:\usr\bin\vi.exe" or if VI is in your path you could just use --editor-cmd vi. (I often use --editor-cmd notepad2, which is just located somewhere in my PATH dirs.) Bert
RE: "Unable to parse reversed revision range" when merging from trunk to branch
> -Original Message- > From: Jens Christian Restemeier [mailto:j...@playtonicgames.com] > Sent: maandag 3 juli 2017 16:31 > To: 'Johan Corveleyn' <jcor...@gmail.com> > Cc: 'Stefan Sperling' <s...@elego.de>; users@subversion.apache.org > Subject: RE: "Unable to parse reversed revision range" when merging from > trunk to branch > > I narrowed it down to the code in subversion/libsvn_subr/mergeinfo.c line > 892-898 in adjust_remaining_ranges. At that point next_range actually starts > before modified_range, so my guess is svn_sort__array_insert has some > unexpected behaviour. > >x892 svn_merge_range_t *new_modified_range = > x >x893 apr_palloc(result_pool, > sizeof(*new_modified_range)); > x >x894 new_modified_range->start = next_range->end; > x >x895 new_modified_range->end = modified_range->end; > x >x896 new_modified_range->inheritable = FALSE; > x >x897 modified_range->end = next_range->start; > x >x898 (*range_index)+=2; > x > >x899 svn_sort__array_insert(rangelist, > _modified_range, > x > *range_index); > x >x901 /* Recurse with the new range. */ > x >x902 adjust_remaining_ranges(rangelist, range_index, > result_pool); > x > > Intuitively it seems to be awfully complicated to expand a range to the end of > a change, and then cut it down recursively with adjust_remaining_ranges. > My first thought would be to step through "rangelist" and "changes" side by > side in svn_rangelist_merge2, and to modify, insert or skip a range in either > list until you're at the end. Though obviously I have no idea about all the > edge > cases the current code most likely fixes... > > So how should I proceed from here? Should I open a bug with my findings > and the test case? I see you already opened an issue. To me it looks like the issue is related to mixing recursive and non-recursive mergeinfo inside the same range... (The ranges with and without a '*' in the string). I see that your example case in the issue has quite a bit of overlap with both these kinds of ranges. It looks like your case triggers a very interesting edge case. Bert
RE: "svn status" does not show unversioned items been deleted but not committed
> -Original Message- > From: Andrey [mailto:an...@inbox.ru] > Sent: woensdag 14 juni 2017 12:22 > To: users@subversion.apache.org > Subject: Re: "svn status" does not show unversioned items been deleted but > not committed > > So, what about this issues? I see it as not opened yet. Will it be fixed? It is not easy to really describe 'the issue'. How would you handle 'svn rm --keep-local ', where the current behavior is the expected behavior. In Subversion <= 1.6 versioned directories would always be available locally until the delete was committed and we explicitly handled this case this way. On the API level there is no real issue, as the information that something exists locally is already available there... So the thing that is missing is how to show this information from the 'svn' tool without breaking backwards compatibility. Bert
RE: "svn pget svn:externals -r . -R" dramatically slow
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: donderdag 18 mei 2017 15:19 > To: users@subversion.apache.org > Cc: Andrey <an...@inbox.ru> > Subject: Re: "svn pget svn:externals -r . -R" dramatically slow > > On 18.05.2017 13:51, Andrey wrote: > > Branko Čibej <br...@apache.org> писал(а) в своём письме Thu, 18 May > > 2017 14:41:17 +0300: > > > >>> However, I don't want to revert anything, i am talking about > >>> possibility of forget to add files because they are obscured by the > >>> deletion state in the status. > >> > >> So what do you suggest we do instead? > >> > >> There's a file named 'foo' that was deleted with 'svn rm' but not > >> committed, and also a file named 'foo' that you created on disk before > >> committing the deletion (or rename). What do you propose 'svn status' > >> should show? > > may be add file content hash to represent 2 statuses of the same file > > paths? At least it will protect file from accidental remove and miss > > of add to commit? > > There will be no accidental remove; when you commit, your new file will > remain unversioned in the working copy: > > brane@zulu:~/test/wc$ svn mv foo bar > A bar > D foo > brane@zulu:~/test/wc$ echo foo > foo > brane@zulu:~/test/wc$ svn st > A +bar > > moved from foo > D foo > > moved to bar > brane@zulu:~/test/wc$ svn ci -mm > Adding bar > Deleting foo > Committing transaction... > Committed revision 2. > brane@zulu:~/test/wc$ svn st > ? foo > > So far, this is what you reported. Now see what happens when you > actually run 'svn add' to replace the deleted file: > > brane@zulu:~/test/wc$ touch qux > brane@zulu:~/test/wc$ svn add qux > A qux > brane@zulu:~/test/wc$ svn ci -mm > Adding qux > Transmitting file data .done > Committing transaction... > Committed revision 3. > brane@zulu:~/test/wc$ svn mv qux baz > A baz > D qux > brane@zulu:~/test/wc$ echo qux > qux > brane@zulu:~/test/wc$ svn add qux > A qux > brane@zulu:~/test/wc$ svn st > A +baz > > moved from qux > ? foo > R qux > > moved to baz > brane@zulu:~/test/wc$ svn ci -mm > Adding baz > Replacing qux > Transmitting file data .done > Committing transaction... > Committed revision 4. > brane@zulu:~/test/wc$ svn st > ? foo > > > In the first case, I suppose we could display something like the following: > > D +foo > > moved to bar > > or: > > D ?foo > > moved to bar > > > to indicate that the file was deleted, but still exists on disk. > > The more interesting question is how, if at all, this would affect the > Subversion API. The api already has this information, as there is some on-disk info in the status api that isn't reported by 'svn' (but is used by other clients). Note that 'svn rm --keep-local Q' is the only thing necessary to trigger this case. And before 1.7 (pre WC-NG) we always had to keep deleted directories until after they were committed, but we didn't want to report these as still existing. That is probably why nobody bothered adding UI for this to 'svn' yet. Bert
RE: "svn pget svn:externals -r . -R" dramatically slow
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: woensdag 17 mei 2017 19:57 > To: Andry <an...@inbox.ru> > Cc: users@subversion.apache.org > Subject: Re: "svn pget svn:externals -r . -R" dramatically slow > > On Tue, May 16, 2017 at 11:42 PM, Andry <an...@inbox.ru> wrote: > > Hello Users, > > > > Original issue: https://issues.apache.org/jira/browse/SVN-4681 > > > > Just discovered a really strange case where exactly titled command bring > really slow response. > > > > The repository contains more than 1000 revisions. The WC is in the middle, > say at rev 1193 (the current), the show log shows 1191 at the last revision, > the HEAD revision say 1300. > > Trying to cd into WC directory and run the command. Needs about 1 > minute to wait it's response. The Process Hacker shows traffic with the > server up to about 2MB. > > > > If try to run command w/o -R flag - command returns immediately. > > > > The content of the externals property without the -R flag is: > > https://domain.ab/svn/proj2/trunk - ^/../proj3/trunk/cmake cmake_proj3 > > ^/solutions/project1/sdk proj2-sdk > > > > The content of the externals property with the -R flag is: > > https://domain.ab/svn/proj2/trunk - ^/../proj3/trunk/cmake cmake_proj3 > > ^/solutions/project1/sdk proj2-sdk > > https://domain.ab/svn/proj2/trunk/proj2-gui - > > https://domain.ab/svn/proj2/trunk/proj2-gui/lib/Resource/Files - > > > > I think the 2 last records draws the svn mad and it begin to crawl the > > server > for something for about 1 minute. > > > > I tries variations of the command. For example all these having the same > result as above: > > svn pget svn:externals -r "1193" "https://domain.ab/svn/proj2/trunk; -R -- > non-interactive > > svn pget svn:externals -r "1193" > "https://domain.ab/svn/proj2/trunk@1193; -R --non-interactive > > svn pget svn:externals "https://domain.ab/svn/proj2/trunk@1193; -R -- > non-interactive > > > > Dig a bit further and found this: > > svn info https://domain.ab/svn/proj2/trunk/proj2-gui > > svn: warning: W17: URL 'https://domain.ab/svn/proj2/trunk/proj2-gui' > non-existent in revision 1300 > > svn: E29: Could not display info for all targets because some targets > don't exist > > > > Seems the 2 last records reference URL's what does not exist anymore in > the HEAD. > > > > These 2 records are left after an upgrade from a previous version of > database, but why is the svn runs so slow about it? Anyway, i can't just > cleanup the externals because they are from 3dparty repository in which i > have no access. > > Thanks for bringing the issue here to the list. There is no optimized code path for retrieving properties recursively directly from the server. The implementation of this specific command is like running 'svn ls' on every directory + fetching the properties on every file and every directory. (It is slightly more optimized than that, but not much) Bert
RE: svn generates long lists of empty diffs with --diff-cmd
> -Original Message- > From: Alexey Neyman [mailto:sti...@att.net] > Sent: donderdag 20 april 2017 02:59 > To: users@subversion.apache.org > Subject: svn generates long lists of empty diffs with --diff-cmd > > Hi, > > I noticed that SVN generates a lot of spurious diffs when using a > --diff-cmd option that look like this: > > Index: arch/alpha/boot/tools/objstrip.c > == > = > Index: arch/alpha/boot/Makefile > == > = > > Is it possible to suppress such empty diffs? This makes the tools like > ReviewBoard (www.reviewboard.org) examine a lot of unchanged files and > slows them down considerably and unnecessary. What argument do you pass to --diff-cmd ? Is it possible that the files are actually different, but your diff command reports that they are not different (e.g. after normalizing whitespace). I think this header is printed on changed files, right before invoking the diff command. Bert > > Regards, > Alexey.
RE: Using UTF8 in repository name?
This message on the forum is 100% about the server side configuration. The client has no known problems encoding paths in a url, but the url specification itself doesn’t document an explicit encoding and as such Apache Httpd has to do the translation of the first part of the URL to the local path. When this fails you see errors as in this forum post. The part after the repository location is 100% handled inside the Subversion code and is always UTF-8 safe as it has no relation to real on-disk paths. On platforms like MAC/OS or Windows the server handles UTF-8 paths directly, but on unix based platforms like Linux where paths are at the core just formed by a bunch of bytes without a special meaning, you have to use a proper configuration. If the configuration mismatches there is no way to convert from the path form to UTF-8 and the other way around. Bert From: Doug Robinson [mailto:doug.robin...@wandisco.com] Sent: maandag 10 april 2017 22:17 To: Branko Čibej <br...@apache.org> Cc: users@subversion.apache.org Subject: Re: Using UTF8 in repository name? Brane: Thank you for replying. Based on this post: https://www.svnforum.org/forum/opensource-subversion-forums/general-setup-and-troubleshooting/79832-why-repository-name-should-not-be-utf-8 I am wondering if the SVN client is properly URL-encoding the repository name? Based on: https://en.wikipedia.org/wiki/Percent-encoding I'm beginning to wonder if it is even possible (sort of similar to what Mac/OS does to UTF8 text...)? Thank you. Doug On Mon, Apr 10, 2017 at 8:53 AM, Branko Čibej <br...@apache.org <mailto:br...@apache.org> > wrote: On 10.04.2017 14:44, Doug Robinson wrote: > Folks: > > I understand that UTF8 is the standard inside of Subversion repositories. > My question is whether having the repository name itself be UTF8? For > instance zh_CN.utf8 ? I googled around a bit and don't see an answer. > > If it is supported, is there some Apache setting that is required? > > Thanks in advance. As long as the underlying filesystem supports it, there should be no problems. -- Brane -- DOUGLAS B ROBINSON SENIOR PRODUCT MANAGER T +1 925 396 1125 E <mailto:doug.robin...@wandisco.com> doug.robin...@wandisco.com <https://www.wandisco.com/assets/blt060cff94156d66e0/wd_email_0.png> World Leader in Active Data Replication™ Find out more <http://wandisco.com/> wandisco.com THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
RE: [BUG] svn update produces unexpected result
The last change revision is documented to be the last revision in which that node changed. The revision number in Subversion is global for the repository, so not changing every file in every revision is 100% expected behavior. And this is the reason we show these different revisions. See the Subversion documentation for the fine details. (E.g. http://svnbook.red-bean.com ) The help from --revision shows that we have even more interesting revisions tied to a file: -r [--revision] ARG : ARG (some commands also take ARG1:ARG2 range) A revision argument can be one of: NUMBER revision number '{' DATE '}' revision at start of the date 'HEAD' latest in repository 'BASE' base rev of item's working copy 'COMMITTED' last commit at or before BASE 'PREV' revision just before COMMITTED Bert From: Deng, Xiao [mailto:xiao.d...@garmin.com] Sent: vrijdag 10 maart 2017 19:48 To: users@subversion.apache.org Subject: [BUG] svn update produces unexpected result Hi, When using svn update on a file with -r flag from one revision to another where the content of the file at both revisions are identical, the last commit of result file appears to be out of sync. Example: Foo.txt have identical content at r100 and r200 Foo.txt is at base revision r100 svn update Foo.txt -r200 svn status Foo.txt -v --xml Expected: base revision === last commit revision === 200 Actual: base revision === 200 !== last commit revision === 100 Best Regards, Xiao Deng Software Engineer 2 Aviation | Garmin International xiao.d...@garmin.com _ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
RE: Is Subversion compatible and supported for Windows 10?
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: woensdag 22 februari 2017 09:43 > To: Stefan Hett <ste...@egosoft.com> > Cc: users@subversion.apache.org > Subject: Re: Is Subversion compatible and supported for Windows 10? > > Stefan Hett wrote on Tue, Feb 21, 2017 at 15:12:25 +0100: > > That said: All the current builds for MaxSVN [1] (an experimental SVN > > developer focused distribution) are tested on Windows 10 and work fine > > there. > > MaxSVN is maintained by Stefan. (The svn devs know this, but not > everyone on users@ does.) It really depends on the distribution you use for the fine details, but I can say that for the CollabNet and SlikSVN Subversion binaries and other products based on SharpSvn (including AnkhSVN), Windows 10 is a fully supported platform. Bert > > > [1] http://www.luke1410.de/typo3/index.php?id=97 > > > > -- > > Regards, > > Stefan Hett > >
RE: How to check which branches have specific commit
> -Original Message- > From: Thijs de Ridder [mailto:thijs.de.rid...@mep-info.com] > Sent: woensdag 22 februari 2017 10:10 > To: users@subversion.apache.org > Subject: How to check which branches have specific commit > > We have an svn repository with several branches and tags. > > - trunk/ > - branches/ > - stable_1 > - stable_2 > - etc. > - tags/ > - stable_1_release_a > - stable_1_release_b > - etc. > > We develop our software in trunk (or in a development branch which will be > reintegrated to trunk). We merge the changes from trunk to a stable branch. > Sometimes we discover a bug which has been introduced quite some time > ago. > Because the list of branches becomes quite long, I would like to know if it > is possible to easily see in which branches / tags the bug is? So if for > instance the bug was introduced in r50 in trunk and currently we are at > r100, is there an svn command to see which branches / tags have r50 of trunk > merged? So we could easily see which branches are infected by this bug? > An svn command or via tortoisesvn will help us a lot (although for > tortoisesvn I should ask this on the tortsoisesvn mailing list) Subversion currently doesn't track where something was branched to, only where something was branched from... so there is no feature that can tell you which of all locations miss a certain 'merge'. For a specific branch you can see if it still needs specific merges via 'svn mergeinfo --show-revs=eligible' [[ $ svn help mergeinfo mergeinfo: Display merge-related information. usage: 1. mergeinfo SOURCE[@REV] [TARGET[@REV]] 2. mergeinfo --show-revs=WHICH SOURCE[@REV] [TARGET[@REV]] 1. Summarize the history of merging between SOURCE and TARGET. The graph shows, from left to right: the youngest common ancestor of the branches; the latest full merge in either direction, and thus the common base that will be used for the next complete merge; the repository path and revision number of the tip of each branch. 2. Print the revision numbers on SOURCE that have been merged to TARGET (with --show-revs=merged), or that have not been merged to TARGET (with --show-revs=eligible). Print only revisions in which there was at least one change in SOURCE. If --revision (-r) is provided, filter the displayed information to show only that which is associated with the revisions within the specified range. Revision numbers, dates, and the 'HEAD' keyword are valid range values. SOURCE and TARGET are the source and target branch URLs, respectively. (If a WC path is given, the corresponding base URL is used.) The default TARGET is the current working directory ('.'). REV specifies the revision to be considered the tip of the branch; the default for SOURCE is HEAD, and the default for TARGET is HEAD for a URL or BASE for a WC path. The depth can be 'empty' or 'infinity'; the default is 'empty'. ]] With some simple scripting you should be able to run this on all branches below a specific directory, etc. Thanks / Met vriendelijke groeten, Bert
RE: [Bug] svn export -r of single file fails if there is a newer revision available than the exported one
The -r123 and @123 functions have completely different behavior. The @ syntax looks up the url as it was in in revision r123 and fetches the file from there The -r checks the path as it currently exists, back to the path it had in revision 123… following copies, renames, etc. (Note: you can combine these functions to trace a url backwards starting with a specific revision) So this is most likely the completely documented behavior. See the Subversion book on <http://svnbook.red-bean.com> http://svnbook.red-bean.com Bert From: Schedel, Andreas [mailto:andreas.sche...@harman.com] Sent: donderdag 16 februari 2017 11:31 To: users@subversion.apache.org Subject: [Bug] svn export -r of single file fails if there is a newer revision available than the exported one SVN server: V1.8.14 (r1692801) Hi, When trying to export a dedicated file of a special revision by using # svn export –r https://svn-server/trunk/myfile.txt everything is working fine as long as no newer revision of this file is available in the repository. If a newer revision is available on the server, the following error message is returned: svn: E195012: Unable to find repository location for in revision The “@syntax” is working fine: # svn export https://svn-server/trunk/myfile.txt@ <https://svnserver/trunk/myfile.txt@%3crevision> Is this an already known bug of SVN or perhaps an undocumented feature? Thanks and best regards Andreas Harman Becker Automotive Systems GmbH Sitz der Gesellschaft: Karlsbad Amtsgericht Mannheim: HRB-Nr. 361395 Geschäftsführung: Michael Mauser, Dr. Udo Hüls Vorsitzender des Aufsichtsrats: Dr. Frank Groth __ ANDREAS SCHEDEL BMW MGU Harman International Automotive Division Parkring 3 85748 Garching, Germany Phone: +49 (89) 35870 – 040 Fax:+49 (89) 35870 – 170 Email: <mailto:juergen.lo...@harman.com> andreas.sche...@harman.com Web:<http://www.harman.com/> www.harman.com Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
RE: how to detect read-only branch from client?
> -Original Message- > From: Torsten Mueller [mailto:muelle...@runbox.com] > Sent: woensdag 15 februari 2017 08:41 > To: users@subversion.apache.org > Subject: Re: how to detect read-only branch from client? > > Andrew Reedick <jreed...@incomm.com> schrieb: > > > Not a complete solution, but it's a start. Craft a "svn mkdir" that > > includes the url to test and a url that will always fail > > That's it. The key is to create a nested directory in a branch, this > means a directory which has a non-existing parent, and doing that > without the --parent parameter: > > Test/ro is a readonly branch > Test/rw is a normal (read/write) branch > > trying to create directory "a/b": > > $ svn mkdir -m"xx" https://repository/svn/Binaries/Test/ro/a/b; > svn: E175013: Access to '/svn/Binaries/!svn/txr/50-1u/Test/ro/a/b' > forbidden > > $ svn mkdir -m"xx" https://repository/svn/Binaries/Test/rw/a/b; > svn: E160013: Try 'svn mkdir --parents' instead? > svn: E160013: File not found: transaction '50-1v', path '/Test/rw/a/b' > > This gives two distiguishable messages: in the first case it fails > because of the readonly property, in the second case because of the > missing --parent parameter. No revision is made iin both cases - great. A better way would be to perform the operation, but *not* specify a log message and configure no editor either. In that case the operation will fail client side after these checks via the missing log message. But then there is always the option that the read-only-ness is applied via a hook script... And in this case this trickery just fails. Bert
RE: svn_dirent_t::size: often not the "real" file size
The size reported is the size of the file in repository form. The size might be different when a different line end encoding is used and/or when keyword expansion is enabled. (Can be larger or smaller) svn_client_statusX() reports both sizes when the file is a normal working copy file. The list function works 100% repository side and we simply dont know the size the file would be in some working copy, as the size might be different in other working copies. Bert From: Bijewitz, Volker [mailto:v.bijew...@baum.de] Sent: donderdag 2 februari 2017 09:22 To: users@subversion.apache.org Subject: svn_dirent_t::size: often not the "real" file size Hi SVN developers, I am working on an TotalCommander plugin to browse SVN repositories. Now I have the problem that on some repositories the filesize reported by svn_client_list3 is different from the real file size of the working copy so comparing the SVN repo with the working copy is impossible. So here are my questions on this issue: * Is there a way for a SVN client to detect the real filesize? * Does this behavior change with the server version? I have one server where the filesize seems to match, another server where it does not match. * If there are servers that reports real file sizes: is there a client functionality to detect if he is connected to a server with good behavior? This may be not the correct way to do a compare, there would be better ways using the SVN interface. But I am limited to the TC plugin interface. And in this interface there is no Compare with file function. I have just to deliver the correct properties, and TC itself does the operation in a way the user has configured it. Cheers, Volker Bijewitz BAUM Systeme GmbH Industriestr. 15 74909 Meckesheim E-Mail : v.bijew...@baum.de <mailto:v.bijew...@baum.de> Internet: www.baum.de <http://www.baum.de/> Geschäftsführer: Wolfgang Baum - Thomas Friehoff Registergericht Mannheim, HRB 333567 Gerichtsstand: Heidelberg VAT Nr: DE 143260354 IK 590820251 Bankverbindungen: Commerzbank Heidelberg IBAN: DE63 6724 0039 0193 5808 00 BIC: COBADEFFXXX Postbank Karlsruhe IBAN: DE40 6601 0075 0202 5007 54 BIC: PBNKDEFF
RE: How to hide unversioned files from svn status
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: dinsdag 22 november 2016 18:26 > To: users@subversion.apache.org > Subject: Re: How to hide unversioned files from svn status > > On 22.11.2016 16:30, Olaf van der Spek wrote: > > On Tue, Nov 22, 2016 at 10:40 AM, Daniel Shahaf <d...@daniel.shahaf.name> > wrote: > >> Johan Corveleyn wrote on Tue, Nov 22, 2016 at 09:43:26 +0100: > >>> If you want to add that option to every status command, maybe you can > >>> use a shell alias or something similar for that? > >> For Bourne-like shells: > >> > >> svn() { > >> case "$1" in > >> st|stat|staus) command svn -q "$@";; > >> *) command svn "$@";; > >> esac > >> } > >> > >> (Put that in your shell's dotfiles.) > > I'm not a fan of such hacks.. ;) > > Wouldn't it make sense to have a conf file option for this? > > > In short ... no. The svn:ignore property already does what you need, > with less chance of shooting yourself in the foot. You can always set > svn:ignore to * if you really want that ... Or set [miscellany] global-ignores = * In ~/.subversion/config Bert
RE: discrepancies between 'svn -R list' and 'svn -R propget' (on windows using TSVN build command line client)
> -Original Message- > From: Lorenz [mailto:loren...@yahoo.com] > Sent: woensdag 16 november 2016 15:02 > To: users@subversion.apache.org > Subject: Re: discrepancies between 'svn -R list' and 'svn -R propget' (on > windows using TSVN build command line client) > > Bert Huijben wrote: > >[...] > >The difference is that 'svn ls' is really a repository operation, working on > >URLS (or part of urls). On URLs we always use the url / platform independent > >'/' separator. > > > >'svn propget' usually works on local paths, in which case we use the local > >path (or technically 'dirent') separator, which is a '\' on Windows. > > > >This behavior was explicitly implemented this way years ago. > >[...] > > ok, that explains the slash mystery 8-) > > > > but what about the leading subpath vs. no subpath difference? > > svn -R ls path/subpath > > file1 > subsubpath/file2 > ... I don't think this was designed behavior... But it follows from the previous answer: we just return the items relative from the url that you listed. There is no easy way to do this differently as local paths might not match remote paths, like when you have switched paths. So when we would show 'path/subpath/subsubpath/file2', it might be a completely different result than the local relative path with the same name. > > vs. > > svn -R pg svn:keywords path/subpath > > subpath/file1 - ... > subpath/subsubpath/file2 > ... And in this case we try to return the paths exactly in the form that you used on the commandline, to allow you to match the result of multiple arguments with multiple locations. (Internally we convert to the absolute path and then back on output these days, but we used to process everything in the original form before Subversion 1.7) If you don't pass something like @rev or -r REV (or a URL instead of a path), this will always match your local files. Note that in both cases we recommend using --xml if you are going to parse the output via tools as that has a more stable output format in case we add new features in new releases. Bert
RE: discrepancies between 'svn -R list' and 'svn -R propget' (on windows using TSVN build command line client)
> -Original Message- > From: Lorenz [mailto:loren...@yahoo.com] > Sent: woensdag 16 november 2016 10:02 > To: users@subversion.apache.org > Subject: discrepancies between 'svn -R list' and 'svn -R propget' (on windows > using TSVN build command line client) > > Hi all, > > navigating to a working copy folder (or a subfolder thereof) and > issuing 'svn -R list path/sub' or 'svn -R list path\sub' results in: > > file1 > subsub/file2 > ... > > > whereas 'svn -R pg svn:keywords path/sub' > or 'svn -R pg svn:keywords path\sub' results in: > > sub\file1 - Id URL > sub\subsub\file2 - Id URL > ... > > > There are two discrepancies the first of which looks like it is not > windos depended: > > 'svn propget' always lists the 'sub' part of the path, > 'svn list' does not. > > is this the same under linux, and if so is it intended behaviour? The difference is that 'svn ls' is really a repository operation, working on URLS (or part of urls). On URLs we always use the url / platform independent '/' separator. 'svn propget' usually works on local paths, in which case we use the local path (or technically 'dirent') separator, which is a '\' on Windows. This behavior was explicitly implemented this way years ago. > The second one is windows dependent (maybe even TSVN specific): > > 'svn list' uses '/' whereas 'svn pg' uses '\' > > do all native windows clients behave this way or is this with the TSVN > client only? The standard 'svn' clients will all use the same formatting as they share the same code here. (TortoiseSVN compiles the standard 'svn' sourcecode for their svn binary) The formatting is really part of the client as internally Subversion always uses '/', so any other client than 'svn' may use different formatting, but I think you can expect 'svn' to keep using the existing formats. Bert > > > I'm on win7 using the command line client that ships with tortoise svn > (TSVN 1.9.4 linked against svn 1.9.4) > -- > > Lorenz
RE: Re: subversion issue: ignore server invaild certificate in linux
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: vrijdag 21 oktober 2016 14:14 > To: yuan lixin <woo...@126.com> > Cc: users@subversion.apache.org > Subject: Re: Re: subversion issue: ignore server invaild certificate in linux > > On Fri, Oct 21, 2016 at 07:41:18PM +0800, yuan lixin wrote: > > but in the interface "svn_auth_ssl_server_trust_prompt_func_t", > > the actual parameter is "failures", not "*failures". so it can not change > > the svn's failures in linux, then can not ignore certificate. > > could you look at my code for a solution. > > > > Thank you > > --woodsp > > libsvn_subr gets 'failures' from the 'parameters' hash: Code shouldn't touch the failures value; they should change the accepted_failures in the credentials value. /** @c SVN_AUTH_CRED_SSL_SERVER_TRUST credentials. */ typedef struct svn_auth_cred_ssl_server_trust_t { /** Indicates if the credentials may be saved (to disk). For example, a * GUI prompt implementation with a checkbox to accept the certificate * permanently shall set @a may_save to TRUE if the checkbox is checked. */ svn_boolean_t may_save; /** Bit mask of the accepted failures */ apr_uint32_t accepted_failures; } svn_auth_cred_ssl_server_trust_t; If svn uses a different way to change a value in the caller that is a bug that should be fixed there. Bert
RE: svn switch, touches files with svn:keywords
> -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: zaterdag 24 september 2016 09:11 > To: FEDERICO PRADES ILLANES <federico.pra...@bbva.com> > Cc: users@subversion.apache.org > Subject: Re: svn switch, touches files with svn:keywords > > FEDERICO PRADES ILLANES wrote on Fri, Sep 23, 2016 at 12:36:24 +0200: > > Steps to reproduce: > > > >1. Create a branch b1. > >2. Create an dummy file in b1, with svn:keywords. > >3. Don't use the svn:keywords on the file. > >4. Commit the changes to b1. > >5. Create a branch b2, from b1. > >6. Perform a switch to b2. > > > > Expected results: > > > >- Dummy file modification time hasn't change > > > > Actual results > > > >- Dummy file modification time has change > > I can reproduce this with current trunk and I agree it's a (minor) bug. See also issue #1975, which documented the opposite behavior as a bug, which was fixed in 1.9.0 http://subversion.apache.org/issue1975 Bert
RE: Can't compile Subversion against Serf-1.3.9.
> -Original Message- > From: Andreas Stieger [mailto:andreas.stie...@gmx.de] > Sent: woensdag 7 september 2016 10:32 > To: "Alexandre C. Guimarães" <alexandre.guimar...@campus.ul.pt> > Cc: users@subversion.apache.org > Subject: Aw: Can't compile Subversion against Serf-1.3.9. > > Hi, > > Alexandre C. Guimarães wrote: > > I am getting trouble to rebuild subversion-1.9.4 on my > > FreeBSD-10.3 box after Serf be updated to 1.3.9: > [...] > > /usr/local/lib/libserf-1.so: undefined reference to `BIO_meth_set_gets' > > Looks like an OpenSSL linking problem. Ensure Apache Serf and Apache > Subversion are built against the same OpenSSL version. It looks like your Serf is compiled against OpenSSL 1.1.0, while some dependency of Subversion that is loaded before serf uses an older version. On FreeBSD OpenSSL 1.1.0 is only part of the 'openssl-devel' port. The normal openssl package is 1.0.2, while the base system is still at 1.0.1. My guess would be that you have an apr-util or cyrus sasl port that is linked to the base system version. (On FreeBSD apr and apr-util are a single package) Bert
RE: SVN Feature Request: Selecting the revision for pinning externals
A single argument specifying a revision may only work for very specific scenarios. The --pin-externals feature also works when you have dozens of externals, all pointing towards different repositories. When adding the feature we determined that we can't handle all these additional cases using the generic copy api. This function really 'pins' what a checkout would do at the time of the pinning. going any further would require much manual work from the user, which he/she could already do before we added this. (Update working copy manually, and commit by using svn cp PATH URL. Perhaps revert the local copy after this) Bert From: Israel Sadeh [mailto:israel.sa...@rtc-vision.com] Sent: donderdag 1 september 2016 18:47 To: users@subversion.apache.org Subject: SVN Feature Request: Selecting the revision for pinning externals Hi, The new '-pin-externals' switch of the 'svn copy' command pins the externals to their latest version. This makes sense when copying the latest revision, but in case the copied branch is from an older revision, it also makes sense to pin the externals to the old revision. This way in case it will be possible to create a tag from an old revision, and not only from the latest one. My suggestion: Add an optional pinning-revision parameter to the '-pin-externals' switch. By default (if the pinning-revision' parameter isn't set) - the externals will be pinned to the latest version. If the parameter is set - the externals will be pinned to the parameter revision. Best regards, Israel Sadeh Israel Sadeh Software Engineer RTC Vision Ltd. <http://www.rtc-vision.com/> www.rtc-vision.com
RE: svnserve takes too much memory for "svn blame"
> -Original Message- > From: Vincent Lefevre [mailto:vincent-...@vinc17.net] > Sent: woensdag 27 juli 2016 02:36 > To: users@subversion.apache.org > Subject: svnserve takes too much memory for "svn blame" > > When I do "svn blame" on some file (36972 lines), svnserve takes > more than 800 MB on the server (and is killed due to lack of > memory). So, it seems that svnserve is inefficient in terms of > memory usage (that's at least 22 KB per line!). > > svnserve, version 1.8.8 (r1568071) >compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu 'svn blame' downloads all versions of the file (via binary diffs between the revisions that contain actual changes), so the number of lines in the file is not a number that really relates to what the server has to do. The number of relevant revisions is far more interesting... as is how much really changed in the file. Bert
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 Exception! - on cleanup after uncomplete checkout
> -Original Message- > From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] > Sent: maandag 2 mei 2016 09:57 > To: Tomáš Bartek <tomas.bart...@gmail.com> > Cc: Subversion Users <users@subversion.apache.org> > Subject: Re: Subversion Exception! - on cleanup after uncomplete checkout > > > > On Apr 29, 2016, at 2:17 AM, Tomáš Bartek <tomas.bart...@gmail.com> > wrote: > > > > --- > > Subversion Exception! > > --- > > Subversion encountered a serious problem. > > Please take the time to report this on the Subversion mailing list > > with as much information as possible about what > > you were trying to do. > > But please first search the mailing list archives for the error message > > to avoid reporting the same problem repeatedly. > > You can find the mailing list archives at > > http://subversion.apache.org/mailing-lists.html > > > > Subversion reported the following > > (you can copy the content of this dialog > > to the clipboard using Ctrl-C): > > > > In file > > 'D:\Development\SVN\Releases\TortoiseSVN- > 1.9.3\ext\subversion\subversion\libsvn_client\cleanup.c' > > line 227: assertion failed (svn_dirent_is_absolute(dir_abspath)) This is an assertion on the very first line of svn_client_cleanup2(), asserting that the passed argument is an absolute path (required, as documented). Please report this issue at TortoiseSVN, as they somehow call this function with an invalid path. Bert
RE: A verbose option to "svn update"?
This may work for a system like CVS that does everything per file, but in case of Subversion this doesn’t really work. We check all files locally at the start of the update, then send a report to the server to what exactly we have locally… and then the server only sends a binary-tree-diff of what has changed between revisions. So changing a really large file, could be a very tiny operation… or changing a small one a huge operation. The client would only know when the file is done (=the moment you see the notification now). The verbose information you want is not available on either the client or the server… just on the combination. And redesigning the protocol to expose it would only slow things down. What might help is looking at how much data is transferred, which some of our common GUI clients do. Exposing this on the console is hard. (We made some early prototypes some time ago, but non that we liked enough to release in ‘svn’) Bert Sent from Mail for Windows 10 From: Doug Robinson Sent: woensdag 27 april 2016 22:57 To: users@subversion.apache.org Subject: A verbose option to "svn update"? Folks: A suggestion from one of our customers: I see that "svn update" does not have a -v (verbose) option either. That would be helpful, because verbose output of what svn update is doing file by file would help narrow in on what is going on much faster. Something like this: > svn -v update Updating '.': checking file1 ... checking bin/file2 ... U bin/file2 fetching file3 ... A file3 checking lib/file4 ... If something like the above was available, then users would see what svn was update while getting updates. I could have, for example, quickly seen it was stuck "checking file galaxy_ms_wroute_pg.v ..." the file the ended up being the issue in this case. In this case they found a problem with a large file by watching "ps" output. But such a verbose option would enable much easier diagnostics. Even better, on slow links this could definitely help delay the end-user SIGINT because they thought something was "hung". Thoughts? Is there already a better way? Thank you. Doug -- DOUGLAS B. ROBINSON SENIOR PRODUCT MANAGER T 925-396-1125 E doug.robin...@wandisco.com www.wandisco.com Learn how WANdisco Fusion solves Hadoop data protection and scalability challenges Listed on the London Stock Exchange: WAND THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
RE: Error---After upgrading from subversion 1.6 to 1.8.
> -Original Message- > From: Reyaz [mailto:skreyazaha...@gmail.com] > Sent: maandag 28 maart 2016 11:45 > To: users@subversion.apache.org > Subject: Error---After upgrading from subversion 1.6 to 1.8. > > Hi Team, > > We have recently upgraded subversion from 1.6 version to 1.8 version on > RHEL > 5.8. After upgrade we are getting below error in error_log file. Before > upgrade everything working fine.Now we are unable to access the projects > with below given error. > > > "[Tue Mar 15 03:06:57 2016] [error] [client 10.191.212.115] Failed to load > the mod_authz_svn config: Section name 'Ents_0590_EA:2113:ELA Amd #5 - > 340 > BCDs:/' contains non-canonical fspath '2113:ELA Amd #5 - 340 BCDs:/''" It looks like there is some invalid path in the authz file. This should be the file that you configured in [[ AuthzSVNAccessFile /u10//svnauthfile ]] in your configuration. Bert
RE: Upgrade Subversion from 1.5 to 1.9
I'm not sure where you read that, but subversion can upgrade working copies all the way up from 1.0. (See our compatibility guarantee) There is one exception: If a working copy operation was stopped halfway. in this case you need to run 'svn cleanup' with your older Subversion version (or 1.6.x) prior to upgrading to Subversion 1.7 or newer. You would have seen an error at the end of the operation and/or explicitly cancelled the operation as a user in all cases where you need this. Bert From: Safarulla Meerasahib [mailto:safarulla.meerasa...@oracle.com] Sent: maandag 21 maart 2016 18:34 To: users@subversion.apache.org Subject: Upgrade Subversion from 1.5 to 1.9 Hi, We have recently taken over a production application from other team, which uses the SVN 1.5.0 as one of the component. Now we have a requirement to upgrade this to latest version of the subversion. While going through the Apache subversion link we have noticed that Subversion 1.9 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7. Is there any workaround to upgrade 1.5.0 to 1.9? Thanks & Regards, Safarulla M.
RE: Modifying svn:log property: good or bad?
> -Original Message- > From: Alfred von Campe [mailto:alf...@von-campe.com] > Sent: maandag 29 februari 2016 16:56 > To: webster.br...@rogers.com > Cc: Eric Johnson <e...@tibco.com>; Subversion Users > <users@subversion.apache.org> > Subject: Re: Modifying svn:log property: good or bad? > > Thanks to all who have shared their respective policies. I’d be very > interested to hear from the Subversion contributors themselves as to what > the policy is for the Subversion repo. Subversion is now hosted in the ASF wide repository of the Apache foundation, so we don't declare the policy ourselves. (Although I think the original Subversion developers were involved when this repository was created) This repository allows changing the log message of revisions that apply to projects you are privileged to commit to. (I'm guessing it uses some custom scripting for this... not sure) Before that we used a similar 'allow edit svn:log' policy for committers on the now disabled svn.collab.net server. I think propedits to other properties are denied. All repository changes go through a commit mailer script, which sends out mails to the mailinglists of projects touched. For ^/subversion in the ASF repository that would be commits@subversion.a.o. Bert
RE: (unknown)
[Moving thread to dev@s.a.o from users@] > -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: maandag 22 februari 2016 13:21 > To: 'Daniel Shahaf' <d...@daniel.shahaf.name>; 'Michal Matyl' > <michal.ma...@zf.com> > Cc: users@subversion.apache.org > Subject: RE: (unknown) > > I just reviewed most of the code that is responsible for this behavior... and > I > have to conclude it works 'as designed'. > > 1) We determine the changes on both sides. > * On one side we see a replacement of line 'C', by a different set of tokens. > * And on the other side we see an insertion of a set of tokens after 'C'. > (This code is in subversion/diff/lcs.c) > > 2) Then we combine the changes of both sides. > * We can apply the first change as there are no overlapping regions > * We can apply the second change as there no overlapping regions > (This code is in subversion/diff/diff3.c) > > In our very abstract implementation things work as intended... so now we > have to determine how we want to fix things. -> back to design phase. > > > I have a working patch that determines that these changes touch each other > and then marks them as conflict, but that still doesn't produce the kind of > conflict that you would really want here. And I'm not sure > > In the optimal case we would flag one conflict containing both changes *as > one*, but that will take more work. > > > > Note that the 'whitespace' (noted in original report) is completely unrelated > to this issue. Our diff code works with tokens, while the whitespace is > handled in the tokenizer. I can easily reproduce this issue without any > whitespace changes. I completed the patch to a form, where I like the result. [[ Index: subversion/libsvn_diff/diff3.c === --- subversion/libsvn_diff/diff3.c (revision 1731660) +++ subversion/libsvn_diff/diff3.c (working copy) @@ -320,16 +320,17 @@ svn_diff_diff3_2(svn_diff_t **diff, suffix_lines, subpool); lcs_ol = svn_diff__lcs(position_list[0], position_list[2], token_counts[0], token_counts[2], num_tokens, prefix_lines, suffix_lines, subpool); /* Produce a merged diff */ { svn_diff_t **diff_ref = diff; +svn_diff_t *diff_last = NULL; apr_off_t original_start = 1; apr_off_t modified_start = 1; apr_off_t latest_start = 1; apr_off_t original_sync; apr_off_t modified_sync; apr_off_t latest_sync; apr_off_t common_length; @@ -429,16 +430,17 @@ svn_diff_diff3_2(svn_diff_t **diff, is_modified = lcs_om->position[0]->offset - original_start > 0 || lcs_om->position[1]->offset - modified_start > 0; is_latest = lcs_ol->position[0]->offset - original_start > 0 || lcs_ol->position[1]->offset - latest_start > 0; if (is_modified || is_latest) { +svn_boolean_t add_diff = TRUE; modified_length = modified_sync - modified_start; latest_length = latest_sync - latest_start; (*diff_ref) = apr_palloc(pool, sizeof(**diff_ref)); (*diff_ref)->original_start = original_start - 1; (*diff_ref)->original_length = original_sync - original_start; (*diff_ref)->modified_start = modified_start - 1; @@ -450,26 +452,47 @@ svn_diff_diff3_2(svn_diff_t **diff, if (is_modified && is_latest) { svn_diff__resolve_conflict(*diff_ref, _list[1], _list[2], num_tokens, pool); } -else if (is_modified) +else if (is_modified + && (!diff_last + || diff_last->type != svn_diff__type_diff_latest)) { (*diff_ref)->type = svn_diff__type_diff_modified; } -else +else if (is_latest + && (!diff_last + || diff_last->type != svn_diff__type_diff_modified)) { (*diff_ref)->type = svn_diff__type_diff_latest; } +else + { +/* We have a latest and a modified region that touch each other, + but not directly change the same location. Create a single + conflict region to properly mark a conflict, and to ease + resolving. */ +diff_last->type = svn_diff__type_conflict; +diff_last->ori
RE: (unknown)
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: zondag 14 februari 2016 15:35 > To: Michal Matyl <michal.ma...@zf.com> > Cc: users@subversion.apache.org > Subject: Re: (unknown) > > Michal Matyl wrote on Thu, Feb 11, 2016 at 10:19:02 +: > > The example is about a simple branch merging with default settings and > > a classic conflict situation, no fancy features or complex > > trunk-to-branch back merging, so I belive simple prose description of > > the problem is enough. > > The prose did not suffice: I would not have understood the problem > without the attachment. The preferred way to describe a bug is by > a script that reproduces it. > > For future reference, we provide template scripts at: > https://subversion.apache.org/docs/community- > guide/issues.html#reporting-bugs > (fourth paragraph) > > > First developer creates branch-01 and inserts few lines into existing > > file. Another developer creates branch-02 and makes exactly the same > > changes as first developer, i.e. inserts the same lines with the same > > content. The only difference in the second's developer branch is > > whitespace change (space/tab doesn't matter) in a line preceding > > inserted lines. > > > > You are describing a merge where > > * The difference between the OLD and MINE is: > > Index: branches/branch-01/test_file.txt > > == > = > --- branches/branch-01/test_file.txt(revision 3) > +++ branches/branch-01/test_file.txt(revision 4) > @@ -1,6 +1,9 @@ > A > B > C > +D > +E > +F > J > K > L > \ No newline at end of file > > * The difference between OLD and THEIRS is: > > Index: branches/branch-02/test_file.txt > > == > = > --- branches/branch-02/test_file.txt(revision 6) > +++ branches/branch-02/test_file.txt(revision 7) > @@ -1,6 +1,9 @@ > A > B > -C > + C > +D > +E > +F > J > K > L > \ No newline at end of file > > * There are no local mods. > > That merge results in: > > Index: trunk/test_file.txt > > == > = > --- trunk/test_file.txt (revision 7) > +++ trunk/test_file.txt (revision 8) > @@ -1,9 +1,12 @@ > A > B > -C > + C > D > E > F > +D > +E > +F > J > K > L > \ No newline at end of file > > Yes, I also think that is a bug: a text conflict should have been > flagged. I just reviewed most of the code that is responsible for this behavior... and I have to conclude it works 'as designed'. 1) We determine the changes on both sides. * On one side we see a replacement of line 'C', by a different set of tokens. * And on the other side we see an insertion of a set of tokens after 'C'. (This code is in subversion/diff/lcs.c) 2) Then we combine the changes of both sides. * We can apply the first change as there are no overlapping regions * We can apply the second change as there no overlapping regions (This code is in subversion/diff/diff3.c) In our very abstract implementation things work as intended... so now we have to determine how we want to fix things. -> back to design phase. I have a working patch that determines that these changes touch each other and then marks them as conflict, but that still doesn't produce the kind of conflict that you would really want here. And I'm not sure In the optimal case we would flag one conflict containing both changes *as one*, but that will take more work. Note that the 'whitespace' (noted in original report) is completely unrelated to this issue. Our diff code works with tokens, while the whitespace is handled in the tokenizer. I can easily reproduce this issue without any whitespace changes. Bert
RE: svn_fs for rename file and folder
Currently not. We still express moves as copies+delete. (There is some experimental support hidden in the implementations, but that isn’t used yet) Bert Sent from Mail for Windows 10 From: Ren Wang Sent: zondag 21 februari 2016 16:44 To: users@subversion.apache.org Subject: svn_fs for rename file and folder Are there APIs for renaming file/folder in the svn_fs layer? Regards, Ren
RE: upgrade Subversion from version 1.6 to svn, version 1.8.15 (r1718365)
Are you sure the directory you tried to upgrade is a 'working copy'? The way you describe it, it looks like it is a repository. Subversion 1.9 and 1.8 can just use 1.6 repositories without upgrade. or you can run 'svnadmin upgrade' on them to enable new features. Bert From: Hom, Margaret [mailto:margaret@ucsf.edu] Sent: zaterdag 20 februari 2016 02:30 To: users@subversion.apache.org Cc: Hom, Margaret <margaret@ucsf.edu> Subject: upgrade Subversion from version 1.6 to svn, version 1.8.15 (r1718365) Hi, I installed version 1.8.15, copied the working directory from an existing 1.6 version server to this new server. I su logged in as subvadm, cd to working directory, cd to one of the working directory ais_repos. I issued the command 'svn upgrade', but I got the error not a working copy root, file not found error. (please see the following copy and paste). I am new to the Subversion. Please advise. Thanks, Margaret Hom UCSF [sfaismh@vx63 ~]$ su - subvadm Password: [subvadm@vx63 ~]$ cd /subv_repos [subvadm@vx63 subv_repos]$ cd ais_repos [subvadm@vx63 ais_repos]$ svn upgrade svn: E155019: Can't upgrade '/subv_repos/ais_repos' as it is not a working copy root svn: E02: Working copy database '/subv_repos/ais_repos/.svn/wc.db' not found svn: E02: Additional errors: svn: E02: Can't open file '/subv_repos/ais_repos/.svn/entries': No such file or directory
RE: Subversion exception report
> -Original Message- > From: Andreas Stieger [mailto:andreas.stie...@gmx.de] > Sent: vrijdag 19 februari 2016 10:58 > To: Carlos Hernandez Alaniz <carlos.hernan...@gameloft.com> > Cc: users@subversion.apache.org > Subject: Re: Subversion exception report > > Hello, > > Carlos Hernandez Alaniz wrote: > > In file > > 'D:\Development\SVN\Releases\TortoiseSVN- > 1.9.1\ext\subversion\subversion\libsvn_client\commit_util.c' > > line 1197: assertion failed (svn_dirent_is_absolute(base_dir_abspath)) > > Please update to the compatible TortoiseSVN 1.9.3 (with svn 1.9.3) and try > again. > > > I had two copies of a repository and didn't notice I was > > trying to commit two files from one, and one file from the other. > > Could you describe this in more detail please? By checking the sourcecode, I think this issue is reproducable by committing files from two different drives on Windows. $ F:\>svn ci f:\svn-dev\dev g:\brk svn: E235000: In file '..\..\..\subversion\libsvn_client\commit_util.c' line 1197: assertion failed (svn_dirent_is_absolute(base_dir_abspath)) Confirmed with 1.9.3. Bert
RE: files always reported as reverted for different owner
> -Original Message- > From: Oleksiy Zagorskyi [mailto:zalex...@i.ua] > Sent: zondag 14 februari 2016 13:31 > To: users@subversion.apache.org > Subject: files always reported as reverted for different owner > > Is that ok? > > When I do "svn revert" using for example "root" account, but files in > the folder are owned by different user, then every file is reported as > reverted but actually there is nothing to be reverted? > Such wrong messages mislead a lot! > > An example: > root@it0:/zab/www-dev/trunk# whoami > root > > root@it0:/zab/www-dev/trunk# ls -l users.php > -rw-r--r-- 1 zalex zalex 13689 Jan 18 16:00 users.php > > root@it0:/zab/www-dev/trunk# svn st > > root@it0:/zab/www-dev/trunk# svn revert users.php > Reverted 'users.php' > > root@it0:/zab/www-dev/trunk# svn revert users.php > Reverted 'users.php' > > root@it0:/zab/www-dev/trunk# svn revert users.php > Reverted 'users.php' > > > In short to reproduce: a file owner and "svn revert" command issuer are > different users. Subversion doesn't check file ownership (as there is no platform independent way to do this), so there must be some different reason why you see that you can revert multiple times. (I'm unable to reproduce your issue with just your script) Which Subversion version did you try this with? Does the file have any specific 'svn:' properties set on it? I'm guessing that it has a 'svn:eol-style' set on it. The only known reproducible case of this issue involves getting a non-standard encoded EOL in your repository, with an eol-style defined that should convert it to another style. Bert
RE: Commit Error using ms onedrive repo
> -Original Message- > From: dennisj2 [mailto:djorge...@gmail.com] > Sent: zondag 14 februari 2016 01:22 > To: users@subversion.apache.org > Subject: Commit Error using ms onedrive repo > > I have a basic cloud setup, primary windows 10 client with onedrive > installed, and a remote server pointing to the onedrive url - I have full > access to the repository and can update, export, et.al., but cannot commit > changes made on the remote server. I get the following errors: > > <http://subversion.1072662.n5.nabble.com/file/n196123/svn-error.png> > > Thought this was going to be easy, thought wrong. Help? file:/// access to a repository really needs a real filesystem behind the local path you use. Onedrive (when mapped as a drive letter) doesn't provide the proper filesystem semantics needed to directy store a Subversion filesystem. I wouldn't recommend storing a Subversion repository in a local directory shadowed to onedrive/dropbox/other-store via its app either, as that doesn't provide the necessary guarantees either. Subversion really needs full read, write, lock, move, etc. access to the repository to guarantee stable behavior. If you want to run Subversion against some cloud you should install some server (Apache Httpd, svnserve) in the cloud and use a proper network layer to access it. File based repository access isn't designed for that scenario, and will most likely cause problems if you somehow get it running... The documentation even documents that you shouldn't run repositories on network drives that don't provide the necessary ACID behavior. Bert
RE: svnversion output changed when redirecting the output. Why?
This is a known issue with some slightly older builds of TortoiseSVN. Please upgrade and otherwise (re-)report the issue at the TortoiseSVN project as this is (was) caused by their specific build scripts. This issue is (was) caused by linking and using multiple CRT instances inside the same program, causing undefined behavior inside Visual C++ code. Bert From: Steenveld, Andre [mailto:a.h.m.steenv...@marin.nl] Sent: woensdag 10 februari 2016 16:09 To: users@subversion.apache.org Subject: svnversion output changed when redirecting the output. Why? Hi, I’m working with svn (via TortoiseSVN) versions 1.7, 1.8 and 1.9 and due to external factors I cannot bring it up to the same version. Also, I’m using svn via the TortoiseSVN package but I believe that my question is related to svn and not to TortoseSVN, please correct me it this is not the case. I use the svnversion command to keep track of versions in my sandboxes. For this I redirect the output from svnversion to a file and use that file in other parts. For versions 1.7 and 1.8 the command line output from svnversion is identical to the redirected output. But for version 1.9 it is not and there is no command line option to get it to the `old style’ output. Here is an example for 1.8 C:\…> svnversion . 22923:22924M C:\...>svnversion . > output.txt C:\...>type output.txt 22923:22924M And here is the same example but now for 1.9 C:\…> svnversion . 22923:22924M C:\...>svnversion . > output.txt C:\...>type output.txt M 22923:22924 Note that if the sandbox is not modified the first line is an empty one. Question: Why is the M (sandbox modified) on a separate line? How do I get ‘1.8’ behavior back for this 1.9 version of svnversion? Kind regards. André Steenveld | Software Engineer | Production Onderhoud, Ontwikkeling & Support MARIN | T +31 317 49 34 30 | a.h.m.steenv...@marin.nl <mailto:a.h.m.steenv...@marin.nl> | www.marin.nl <http://www.marin.nl> <https://www.linkedin.com/company/marin> <http://www.youtube.com/marinmultimedia> <https://twitter.com/MARIN_nieuws> <https://www.facebook.com/marin.wageningen> MARIN news: Viscous free-surface power predictions for self-propulsion using a hybrid RANS-BEM coupling procedure <http://www.marin.nl/web/News/News-items/Viscous-freesurface-power-predictions-for-selfpropulsion-using-a-hybrid-RANSBEM-coupling-procedure.htm>
RE: Question to svn merge (merge just parts of a diff)
> -Original Message- > From: Kai Behncke [mailto:kai.behn...@uni-osnabrueck.de] > Sent: dinsdag 9 februari 2016 07:49 > To: users@subversion.apache.org > Subject: Question to svn merge (merge just parts of a diff) > > Dear users, > > I`m quite new to svn. I would like to know it the following in svn is > possible: > > > > I have in (let`s say Revision 2) a file, that I have changed onetime (I > deleted "B"), with the following content now: > A > C > D > > Then, in Revision 3 an automatic update occurs. The new file has the > content: > A > B > E > > ...that means that some changes, that I made, are overwritten now. But > that should not be. If all these versions were just committed and updated via the repository, this is the intended behavior and there is nothing you can do about it. If on update the local file is unmodified, the file is replaced by the new version. I can't think of a version management system that does this differently. No merging happens in this situation If you have local changes, and then an update comes in with changes, you have a different situation. In that case we start a merge operation, that may or may not complete automatically depending on the combination of local and remote changes. You can even configure your own 3-way-merge tool to handle this merge step by your own tool in the config file. > > > A diff between 2 and 3 would show someting like: > A > -C > -D > +B > +E If everything is committed, then this is unrelated information. It is local modified vs unmodified that handles the first step. Otherwise updates that skip revisions aren't possible, etc. etc. I think you need a more complete sample, perhaps even as a pseudo-script to describe what you really want to ask. Bert > > Is there a possibility to do (for Revision 4) a "svn merge" to get a new > file, that: > > * "knows" that B has been deleted before, so it will not be reintegrated > * does not delete C and D (I would like to declare s.th. like: Don`t > delete anything that has been added in a former revision) > * integrates E (as a new entry, that has not been in any former version) > > so that a result like: > A > C > D > E > > ...comes out? > What I mean is: Is it possible to "have a look to a diff" and then > analyze automatically by the system the single-diff parts > to set some rules if the single diff-parts should be integrated or not? > > Thank you very much, Kai > -- > > Dr. Kai Behncke > Zentrum für Informationsmanagement und virtuelle Lehre > Raum 42/06, Heger-Tor-Wall 12, 49074 Osnabrück > Telefon: +49 (0)541/969-6505 > http://www.virtuos.uni-osnabrueck.de
RE: Subversion crashes on list with an empty format 3 repo
> -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: zondag 7 februari 2016 01:22 > To: Michael Osipov <micha...@apache.org> > Cc: Ivan Zhakov <i...@visualsvn.com>; users@subversion.apache.org > Subject: Re: Subversion crashes on list with an empty format 3 repo > > Michael Osipov wrote on Fri, Feb 05, 2016 at 23:34:16 +0100: > > Am 2016-02-05 um 22:10 schrieb Ivan Zhakov: > > >'vn: E160033: Invalid name for FS type 'fsfs > > >]]] > > We know now that the repo is mangled. The output of the last line is > broken > > btw. It should read "svn:... 'fsfs'" but it reads "'vn:...'fsfs". Shall a I > > create a JIRA issue for that? > > Yes, please. We should be escaping the \r character rather than > printing it literally. > > The root problem is that we just use the equivalent of apr_psprintf("The > value is '%s'", value) to enter replaceables into error messages; we > don't escape the argument to %s, nor do we use a format code (like > the %r and {!r} of Python's string formatting or the %q of the printf(1) > builtin of bash and zsh) that implements single-quoting-and-escaping itself. > > >>> print("The value is '%s'." % ('fsfs\x0D',)) > '.e value is 'fsfs > >>> print("The value is %r." % ('fsfs\x0D',)) > The value is 'fsfs\r'. > > > I have unzipped the repo on: > > FreeBSD bsd10 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28: Wed Aug > 12 > > 15:26:37 UTC 2015 > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC > > amd64 > > > > and I receive the very same error as you do. > > That's not surprising: the fs-type file has a CRLF line ending, and on > FreeBSD the CR wouldn't be removed. > > Does 'svnadmin create' use CRLF for the fs-type file on windows? It > should probably use LF to make the format entirely platform-independent. No, it uses a LF only, like on other platforms. (I think that should be clear about this bug report... We fail when we have a file with that byte sequence we never create ourselves). We open most text files as binary in the libsvn_* code on Windows. (Note that we use the other default in our python testsuite) It is probably nice to fix this specific case as it is above the FS layer, but I don't think we should really start to look at fsfs as EOL agnostic. Bert
RE: Svn 1.9 repository 20% bigger than svn 1.8 repository
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: maandag 1 februari 2016 11:11 > To: Philip Martin <philip.mar...@wandisco.com> > Cc: Stefan Fuhrmann <stef...@apache.org>; Gert Kello > <gert.ke...@gmail.com>; users@subversion.apache.org > Subject: Re: Svn 1.9 repository 20% bigger than svn 1.8 repository > > On Mon, Feb 01, 2016 at 10:06:19AM +, Philip Martin wrote: > > Stefan Fuhrmann <stef...@apache.org> writes: > > > > > So, all user content is there and merely the deduplication failed > > > (as already being investigated elsewhere in this thread). > > > > I suppose format 7 might allow us to implement a system that fixes > > missing deduplication during packing. > > And perhaps get rid of sqlite in the repository while at it? I think at least that last part will require a format 8. Optimizing pack should (theoretically) be possible without a format bump. We could even backport changes that allow this, but I'm still waiting on real world test experience with format 7. There are still far too many users delaying their upgrades to 1.9 waiting for others to switch :( Waiting for the ASF to perform a major upgrade is on reason I hear quite often... Bert
RE: Svn 1.9 repository 20% bigger than svn 1.8 repository
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: donderdag 28 januari 2016 13:38 > To: Gert Kello <gert.ke...@gmail.com> > Cc: users@subversion.apache.org > Subject: Re: Svn 1.9 repository 20% bigger than svn 1.8 repository > > Gert Kello <gert.ke...@gmail.com> writes: > > > I have a svn 1.9 repository, created with svnsync, that has ~15 > > revisions and size about 45 GB. Due to some issues in svn-all-fast-export I > > wanted to have svn 1.8 version repository so I downgraded it by doing > > svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle. I was surprised that > > the size of v 1.8 repository is "only" 37.5 GB > > I tried to compare content of db\revs folder: some files are bigger in 1.8 > > repo, some in 1.9 repo. Just to be sure: that 1.9 repository was recently created with 1.9 and then loaded via svnsync? Or was it upgraded from previous versions? Did you try to svnadmin load the same repository into a new 1.9 repository? (I would be interested in that result). 1.9 should also be able to create repositories compatible with older versions. You might have a very interesting testcase at hand :-) But with such a size repository it might be hard to test different variants. Bert
RE: Compiling ZLIB for svn 1.9.3 on Windows 7 using MSVC 2008
> -Original Message- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: maandag 4 januari 2016 11:41 > To: users@subversion.apache.org > Subject: Re: Compiling ZLIB for svn 1.9.3 on Windows 7 using MSVC 2008 > > On 12/31/2015 10:31 AM, Cooke, Mark wrote: > >> -Original Message- > >> From: Ivan Zhakov [mailto:i...@visualsvn.com] > >> Sent: 30 December 2015 18:59 > >> > >> On 30 December 2015 at 19:06, Cooke, Mark > <mark.co...@siemens.com> wrote: > >>> [Updates below] > >>> > >>>> -Original Message- > >>>> From: Cooke, Mark [mailto:mark.co...@siemens.com] > >>>> Sent: 30 December 2015 15:56 > >>>> > >>>> Folks, > >>>> > >>>> I was having issues compiling httpd and svn for use with Trac (via the > >>>> python 2.7 bindings). I have compiled httpd 2.4.18 (with apr 1.5.1, > >>>> apr-util 1.5.4, apr-iconv 1.2.1, openssl 1.0.2e, pcre 1.3.8 and > >>>> mod_wsgi 4.4.21) and am now trying to compile svn. > >>>> > >>>> I noted the comments about zlibstat and ZLIB_WINAPI [1][2], so I > edited: > >>>> - zconf.h (added #define ZLIB_WINAPI) > >>>> - bld_ml32.bat (added the /safeseh switch to both lines) > >>>> ...and ran: > >>>> - vcbuild /rebuild contrib\vstudio\vc9\zlibvc.sln "Release|Win32" > >>>> > >>>> This seems to compile OK so I copied the zlibstat.lib up to the zlib > >>>> root. > >>>> > >>>> [1] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL > (section E4 > >>>> ZLib) > >>>> [2] http://www.tannerhelland.com/5076/compile-zlib-winapi-wapi- > stdcall/ > >>>> > >>>> Next I built SERF 1.3.8: > >>>> > >>>> [...] > >>>> > >>>> In the end I got it running by _removing_ all the ZLIB_WINAPI > >>>> defines in the Visual Studio project files and _not_ defining > >>>> ZLIB_WINAPI in the main config file: this is the opposite of the > >>>> advice in [1]! Does this sound correct? If so I think the INSTALL > >>>> file needs updating. > >>> I get one test failure but it looks bad:- > >>> > >>> START: checksum-test.exe > >>> PASS: checksum-test 1: checksum parse > >>> PASS: checksum-test 2: checksum emptiness > >>> PASS: checksum-test 3: zero checksum matching > >>> svn_tests: E26: Decompressed data doesn't match expected size or > crc > >>> with blocksize 17: Found crc32=0x3a74e3ee, size=241883. > >>> Verify your ZLib installation, as this should never happen > >>> FAIL: checksum-test 4: zlib expansion test (zlib regression) > >> Zlib has known bug in assembly optimized code. Just disable assembly > >> optimized code in zlib and everything should be fine. > > Thanks, Ivan, that makes sense. For the record this is how I got ZLib > working for me: > > > > Unpack archive to \svn\zlib > > Search/Remove all instances of ZLIB_WINAPI from *.vcproj > Are you sure this is required? My current build environment suggests > it's just building/working fine and as intended by adding the > ZLIB_WINAPI define. That's how it should also work. > I've to admit that I didn't test it using VS 2008 (but rather 2010 and > 2015), but I would not expect that having an impact on the reported > linker error you got. > Might it be that you compiled another lib which pulled in zlib without > defining ZLIB_WINAPI? Then that would explain the linker error you are > reporting. The ZLIB_WINAPI patch changes the calling convention of the library. That is not necessary for Subversion's usage, but it might be necessary if you use the same ZLIB dll file from something else. Just make sure both the headers and the actual libraries use the same convention or you see huge problems in edge scenarios. In general I would recommend using a normal static compilation of ZLIB for Subversion or otherwise one with LTCG enabled, to allow completely inlining things in the linker step. That allows even further optimizations than just changing the calling convention. Bert
RE: Unexpected HTTP status 400 'Bad request'.
Usually you wouldn’t get ‘bad request’ errors from httpd unless Subversion sends a bad request. Server side errors as disk io are usually reported by other error codes, such as 500. Most bad cases of status 400 are caused by firewall and antivirus products that somehow alter requests in unexpected ways. Another ‘expected’ case of this error is when Subversion sends too many headers to the server; we see this in some commits of subtrees with hundreds of locks. The investigation for this error code should start in the server log. Except for that too much header data, the Subversion client should never generate a request that the server thinks is ‘bad’. That is what it tells with status 400. But as noted before: more details should be in the server log (and often in the response body itself… but if there was usable data there Subversion should have noted that) Bert From: Yves Martin [mailto:ymartin1...@gmail.com] Sent: dinsdag 8 december 2015 11:06 To: users@subversion.apache.org Subject: Re: Unexpected HTTP status 400 'Bad request'. Hello Is your repository served read-write by other services like svnserve or eventually through SSH in addition to Apache HTTPS access ? If so you have to check your repository file permissions: owner, group and modes (for instance g+w or g+s...) I guess your repository has been created long ago with a previous version of Subversion. What is your repository format version ? Are some revisions packed ? Use svnadmin info. Maybe you should use "svnadmin upgrade" to get some new features properly enabled with Subversion 1.9, or even use dump/load procedure (or svnsync) to get your repository ready (and optimized) for Subversion 1.9. Regards -- Yves Martin
RE: Unexpected HTTP status 400 'Bad request'.
These are both about bodies… The headers causing that lock problem are not part of the body. There is probably another configuration knob for them. Bert From: Yves Martin [mailto:ymartin1...@gmail.com] Sent: dinsdag 8 december 2015 12:10 To: Subversion <users@subversion.apache.org> Subject: Re: Unexpected HTTP status 400 'Bad request'. Hello, In my Apache2 configuration, I have added "LimitRequestBody 0" and "LimitXMLRequestBody 0" to avoid such troubles with a 12-year-old-really-large repository... Hope this helps Regards -- Yves Martin
RE: Unexpected HTTP status 400 'Bad request'.
This is just the Subversion operational log generated by mod_dav_svn. The interesting things would be in the apache access and/or error logs. (Depending on the configuration of your apache these could be the same logfile) The operational log just shows successful Subversion operations, so that doesn’t tell us much why a request failed. Bert From: Chris Capon [mailto:ttab...@gmail.com] Sent: dinsdag 8 december 2015 15:29 To: users@subversion.apache.org Subject: Re: Unexpected HTTP status 400 'Bad request'. Hi Bert. The only log I know of is under /var/log/apache2/subversion.log, and when I issue a checkout, I get only two lines in it: [08/Dec/2015:09:24:53 -500] myself get-inherited-props /dev/trunk r3066 [08/Dec/2015:09:24:53 -500] myself checkout-or-export /dev/trunk r3066 If the error were caused by a firewall or antivirus software, would it still make sense that the checkout begins and gets several files in before failing? Also, to try and eliminate that possibility, I've been performing the checkout tests on the subversion server machine. On 2015-12-08 05:37, Bert Huijben wrote: Usually you wouldn’t get ‘bad request’ errors from httpd unless Subversion sends a bad request. Server side errors as disk io are usually reported by other error codes, such as 500. Most bad cases of status 400 are caused by firewall and antivirus products that somehow alter requests in unexpected ways. Another ‘expected’ case of this error is when Subversion sends too many headers to the server; we see this in some commits of subtrees with hundreds of locks. The investigation for this error code should start in the server log. Except for that too much header data, the Subversion client should never generate a request that the server thinks is ‘bad’. That is what it tells with status 400. But as noted before: more details should be in the server log (and often in the response body itself… but if there was usable data there Subversion should have noted that) Bert From: Yves Martin [ <mailto:ymartin1...@gmail.com> mailto:ymartin1...@gmail.com] Sent: dinsdag 8 december 2015 11:06 To: <mailto:users@subversion.apache.org> users@subversion.apache.org Subject: Re: Unexpected HTTP status 400 'Bad request'. Hello Is your repository served read-write by other services like svnserve or eventually through SSH in addition to Apache HTTPS access ? If so you have to check your repository file permissions: owner, group and modes (for instance g+w or g+s...) I guess your repository has been created long ago with a previous version of Subversion. What is your repository format version ? Are some revisions packed ? Use svnadmin info. Maybe you should use "svnadmin upgrade" to get some new features properly enabled with Subversion 1.9, or even use dump/load procedure (or svnsync) to get your repository ready (and optimized) for Subversion 1.9. Regards -- Yves Martin
RE: Unexpected HTTP status 400 'Bad request'.
> -Original Message- > From: Chris Capon [mailto:ttab...@gmail.com] > Sent: dinsdag 8 december 2015 14:47 > To: users@subversion.apache.org > Subject: Re: Unexpected HTTP status 400 'Bad request'. > > On 2015-12-08 05:06, Yves Martin wrote: > > Hello > > > > Is your repository served read-write by other services like svnserve > > or eventually through SSH in addition to Apache HTTPS access ? > I'm sorry. I don't understand what this asks. Permissions are > controlled by a .apache_auth and .apache_htpasswd file (in addition to > client certificates). The .apache_auth file has the folder defined as > 'rw' for my user id. > > > > If so you have to check your repository file permissions: owner, group > > and modes (for instance g+w or g+s...) > All the file level permissions are set to rwxr-xr-x (755) and both owner > and group are www-data, the user id under which the Apache2 service runs. > > > > I guess your repository has been created long ago with a previous > > version of Subversion. > > What is your repository format version ? Are some revisions packed ? > > Use svnadmin info. > Repository Format: 5 > Compatible With Version: 1.9.0 > Repository Capability: mergeinfo > Filesystem Type: fsfs > Filesystem Format: 7 > FSFS Sharded: yes > FSFS Shard Size: 1000 > FSFS Shards Packed: 0/3 > FSFS Logical Addressing: no > Configuration File: /root/subversion/root/repository/db/fsfs.conf > > > > > Maybe you should use "svnadmin upgrade" to get some new features > > properly enabled with Subversion 1.9, > After running > svn upgrade /root/subversion/root/repository > > The response was "Upgrade completed." But an svn checkout gives the > same error: > > svn: E175002: Unexpected HTTP status 4000 'Bad request' on > '/svn/repository/!svn/rvr/1903/dev...' > > Again, at a random file about 5 or 6 files in. > > or even use dump/load procedure (or svnsync) to get your repository > > ready (and optimized) for Subversion 1.9. > We tried this in a previous e-mail (see for details). Are you using some kind of (caching) proxy server when you connect to the server? You are focusing your search to a disk problem (probably caused by hints on this list), while you are trying to determine what causes a 'bad HTTP request' error. Bad requests on these urls may be caused by sending bad header values... I've seen those before when using nginx as proxy with a too strict caching policy. Bert
RE: API for creating file and revision
In this context we use the word 'text' for the body/content/whatever is in the file, so you don't have to use separate functions. On the fs and repos layers we don't handle binary and textual files in different ways. Where we do at the client level we usually use a few properties if we want to make the behavior explicit. Bert From: Ren Wang [mailto:renwang...@gmail.com] Sent: woensdag 25 november 2015 13:27 To: users@subversion.apache.org Subject: API for creating file and revision First of all, I would like to express my appreciation for the support from the community in the past few days. Here are some more another questions: The API svn_fs_make_file() will create an empty file, and the svn_fs_apply_text() will fill the text content to the repository. Is there a similar API for setting binary content? If the file already created in the repository, what's the API to create a revision of it? Regards, Ren
RE: svn_repos_fs_commit_txn error
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: dinsdag 24 november 2015 06:13 > To: users@subversion.apache.org > Subject: Re: svn_repos_fs_commit_txn error > > On 23.11.2015 21:01, Ren Wang wrote: > > I got an error for creating a new directory to the repository. Strange to me > > is that enve the code failed at the svn_repos_fs_commit_txn, but the > > directory got created: > > > > > > > > > > > > 1) Open repository, repos > > > > 2) Get the latest revision, youngest > > > > 3) Do the following: > > > > svn_fs_txn_t *txn; > > > > svn_fs_root_t *txn_root; > > > > apr_pool_t *subpool = svn_pool_create(pool); > > > > SVN_ERR(svn_repos_fs_begin_txn_for_commit(, , > youngest_rev, > > "UncleYinan", "log msg", subpool)); > > > > SVN_ERR(svn_fs_txn_root(_root, txn, subpool)); > > > > SVN_ERR(svn_fs_make_dir(txn_root, directoryPath, subpool)); > > > > SVN_ERR(svn_repos_fs_commit_txn(NULL, c->repos, _rev, txn, > > subpool));-- failed here This may be 100% expected... see the documentation of this function. Especially the part [[ * A successful commit is indicated by a valid revision value in @a * *new_rev, not if svn_fs_commit_txn() returns an error, which can * occur during its post commit FS processing. If the transaction was * not committed, then return the associated error and do not execute * the post-commit hook. ]] For completeness I copied the documentation from svn_repos.h here: /** Like svn_fs_commit_txn(), but invoke the @a repos' pre- and * post-commit hooks around the commit. Use @a pool for any necessary * allocations. * * If the pre-commit hook fails, do not attempt to commit the * transaction and throw the original error to the caller. * * A successful commit is indicated by a valid revision value in @a * *new_rev, not if svn_fs_commit_txn() returns an error, which can * occur during its post commit FS processing. If the transaction was * not committed, then return the associated error and do not execute * the post-commit hook. * * If the commit succeeds the post-commit hook is executed. If the * post-commit hook returns an error, always wrap it with * SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED; this allows the caller to * find the post-commit hook error in the returned error chain. If * both svn_fs_commit_txn() and the post-commit hook return errors, * then svn_fs_commit_txn()'s error is the parent error and the * SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED wrapped error is the child * error. * * @a conflict_p, @a new_rev, and @a txn are as in svn_fs_commit_txn(). */ svn_error_t * svn_repos_fs_commit_txn(const char **conflict_p, svn_repos_t *repos, svn_revnum_t *new_rev, svn_fs_txn_t *txn, apr_pool_t *pool); -- Bert
RE: svnlook changed doesn't include all of the files that are part of the commit
Diff reports copies of directories as adds of the individual files, while svnlook changed reports a copy on the root and only interesting changes below that. Just like how 'svn status' would have reported it before the commit. Bert From: Hartleroad, James [IT] [mailto:james.hartler...@sprint.com] Sent: maandag 23 november 2015 15:30 To: users@subversion.apache.org Subject: svnlook changed doesn't include all of the files that are part of the commit Why doesn't svnlook changed show all of the files that are part of the commit? A developer created a new directory with two files in a branch and the branch was merged into another branch. When running svnlook it shows the directory was added, but not the included files. If I run a svn diff with the summarize option it does list the files, so shouldn't svnlook include them too? svnlook changed -r5596 /data/ans/repos/r4BN _U 4BN/cmblds/1551-MID16.1.2.0/ A 4BN/cmblds/1551-MID16.1.2.0/4BN_Envs/dev/ReleaseChanges/MID16.1.2_Release_Ch anges.txt _U 4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_Scripts/ A 4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_Scripts/MID16.1.2/ _U 4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP_Scripts/ A 4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP_Scripts/MID16.1.2/ svn diff -r5595:5596 --summarize file:///data/ans/repos/r4BN A file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_Envs/dev/Release Changes/MID16.1.2_Release_Changes.txt A file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP _Scripts/MID16.1.2/MID16.1.2_PJ019964_Epic363_Add_New_Programs.ldif A file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP _Scripts/MID16.1.2 M file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/LDAP _Scripts A file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S cripts/MID16.1.2/MID16.1.2_PJ019964_Epic363_AUTO_ACTIVITY_WRKFLW_TASK_DML_Ch anges.sql A file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S cripts/MID16.1.2/MID16.1.2_PJ019964_Epic363_ADD_New_Programs_DML_Changes.sql A file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S cripts/MID16.1.2 M file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0/4BN_FAST_source/DB_S cripts M file:///data/ans/repos/r4BN/4BN/cmblds/1551-MID16.1.2.0 _ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
RE: how to get node property by using C API
There should be an api for the size. Author, creation info, etc. are attached to the revision in which the file was created. Bert From: Ren Wang [mailto:renwang...@gmail.com] Sent: vrijdag 20 november 2015 16:19 To: users@subversion.apache.org Subject: how to get node property by using C API I would like to know how to get a directory or file property with Subversion C API, if I already have the node ID and path, what's the API to get file size and author, creation time etc.? Regards, Ren
RE: Subversion C API
Mod_dav mostly uses the repository layer api. In a few specific cases it goes into the fs layer directly. sometimes because something isn't mapped, but in other cases because mod_dav was developed very early in the development process and the repository layer wasn't as complete as it is today. But is the client layer really that expensive for you that you can't use it? Did you measure it? I can't imagine usecases where the performance is that critical that you really can't afford the thin layer that the file:/// repository api has, but don't want a specialized datastore 100% optimized for your usecase. I can think of a few cases where you might want to avoid the overhead of having a working copy, but even there the costs aren't usually that high that it makes sense to spend a lot of time to develop something else. (And in many cases the still private API behind svnmucc can already help you there) Bert From: Ren Wang [mailto:renwang...@gmail.com] Sent: vrijdag 6 november 2015 19:44 To: users@subversion.apache.org Subject: Subversion C API I have posted the same question to the stackoverflow, here it is. Looking forward to hear from you: We are considering to use Subversion as the file system layer to store version enabled documents. Since the security function will be handled by other code, I am considering to directly use the Subversion FS C API layer. I wonder if there any good sample code for using Subversion FS APIs? Someone answered back: Subversion's FSFS store is meant to be used by the subversion server. While it might be useable in other scenarios, whatever sits on top of it will likely have to act much like a subversion server when interacting with it. Subversion differentiates between client workspaces and the server storage space. If you are going to leverage subversion components, your application needs to realize that these two spaces are not the same within a subversion architecture, and therefore should not be the same within your solution that uses their components. Why not just embed a subversion client into the place you desire and then go from there? The user workspace will still be "the subversion user workspace" and the server side will be the server side. In fact, check out tortise SVN (or other desktop integrations of subversion). You might not even need to write anything. I asked again with more context for the project: SVN Client API will have performance penalty since it will go through other layers such as user authentications, authorizations, transport etc. which are not needed for us. Subversion server side API will bypass those calls. I wonder which API mod_dav_svn used. Regards, Ren
RE: subversion 1.9.2 could not be built "all-static" on FreeBSD 10+
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: maandag 19 oktober 2015 13:22 > To: 'Philip Martin' <philip.mar...@wandisco.com>; 'Lev Serebryakov' > <l...@freebsd.org> > Cc: 'Daniel Shahaf' <d...@daniel.shahaf.name>; > users@subversion.apache.org > Subject: RE: subversion 1.9.2 could not be built "all-static" on FreeBSD 10+ > > > > > -Original Message- > > From: Philip Martin [mailto:philip.mar...@wandisco.com] > > Sent: maandag 19 oktober 2015 11:19 > > To: Lev Serebryakov <l...@freebsd.org> > > Cc: Daniel Shahaf <d...@daniel.shahaf.name>; > users@subversion.apache.org > > Subject: Re: subversion 1.9.2 could not be built "all-static" on FreeBSD > 10+ > > > > Lev Serebryakov <l...@freebsd.org> writes: > > > > > Hello Daniel, > > > > > > Sunday, October 18, 2015, 11:08:45 AM, you wrote: > > > > > >>> I could not build subversion 1.9.2 with "--enable-all-static" on > FreeBSD. > > >>> "configure" script forms wron arguments to ${CC} in this case and > fails to > > >>> find any library. > > >>> > > >>> Here is couple of lines from config.log for 1.9.2: > > >>> > > >>> configure:6130: checking for sqlite3_close in -lsqlite3 > > >>> configure:6155: cc -o conftest -Werror=unknown-warning-option -O2 > > >>> -pipe -fpic -DPIC -fstack-protector -fno-strict-aliasing > > >>> -I/usr/local/include -fstack-protector -L/usr/local/lib > > >>> -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib > > >>> -R/usr/local/lib -L/usr/local/lib conftest.c -lsqlite3 >&5 > > >>> cc: error: unknown argument: '-R/usr/local/lib' > > >>> cc: error: unknown argument: '-R/usr/local/lib' > > >>> configure:6155: $? = 1 > > > > > >> I assume you're building the 1.9.2 tarball, correct? Does the problem > > > Yep. > > > > > >> also occur if you build from a checkout of the 1.9.2 tag? (You'll need > > >> to run autogen.sh before configure.) > > > Yes. Here is version of tools used by autogen.sh: > > > > > > buildcheck: autoconf version 2.69 (ok) > > > buildcheck: autoheader version 2.69 (ok) > > > buildcheck: libtool version 2.4.6 (ok) > > > > > > And after that same error if "--enable-all-static" is passed. > > > > On my FreeBSD 10.1 install I get further than that when I try to build > > the 1.9.x branch, but linking svn fails due unresolved SSL symbols. I > > can fix it by changing LIBS in Makefile to add -lssl -lcrypto. > > > > Subversion configure script does not add the -R so I suppose on of the > > dependencies must be telling Subversion to add it. What does your > > configure line look like? Have you build any of the dependencies > > yourself? > > I think I found these flags in /usr/local/libdata/pkgconfig/serf-1.pc > > [[ > SERF_MAJOR_VERSION=1 > prefix=/usr/local > exec_prefix=${prefix} > libdir=/usr/local/lib > includedir=${prefix}/include/serf-1 > > Name: serf > Description: HTTP client library > Version: 1.3.8 > Requires.private: > Libs: -L${libdir} -lserf-${SERF_MAJOR_VERSION} > Libs.private: -L/usr/local/lib -R/usr/local/lib -laprutil-1 -ldb-5.3 -lgdbm > -lexpat -L/usr/local/lib -R/usr/local/lib -lapr-1 -lcrypt -lpthread -lz > -L/usr/lib -lssl -lcrypto > Cflags: -I${includedir} > ]] And now including dev@serf, as I think this should be fixed there: It looks like serf gets these flags from: $ apr-1-config --link-libtool Which is invoked from SConstruct [[ ### there is probably a better way to run/capture output. ### env.ParseConfig() may be handy for getting this stuff into the build apr_libs = os.popen(env.subst('$APR --link-libtool --libs')).read().strip() if apr_major < 2: apu_libs = os.popen(env.subst('$APU --link-libtool --libs')).read().strip() else: apu_libs = '' ]] And at this point I don't know what this is supposed to do. Bert
RE: subversion 1.9.2 could not be built "all-static" on FreeBSD 10+
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: maandag 19 oktober 2015 11:19 > To: Lev Serebryakov <l...@freebsd.org> > Cc: Daniel Shahaf <d...@daniel.shahaf.name>; users@subversion.apache.org > Subject: Re: subversion 1.9.2 could not be built "all-static" on FreeBSD 10+ > > Lev Serebryakov <l...@freebsd.org> writes: > > > Hello Daniel, > > > > Sunday, October 18, 2015, 11:08:45 AM, you wrote: > > > >>> I could not build subversion 1.9.2 with "--enable-all-static" on FreeBSD. > >>> "configure" script forms wron arguments to ${CC} in this case and fails to > >>> find any library. > >>> > >>> Here is couple of lines from config.log for 1.9.2: > >>> > >>> configure:6130: checking for sqlite3_close in -lsqlite3 > >>> configure:6155: cc -o conftest -Werror=unknown-warning-option -O2 > >>> -pipe -fpic -DPIC -fstack-protector -fno-strict-aliasing > >>> -I/usr/local/include -fstack-protector -L/usr/local/lib > >>> -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib > >>> -R/usr/local/lib -L/usr/local/lib conftest.c -lsqlite3 >&5 > >>> cc: error: unknown argument: '-R/usr/local/lib' > >>> cc: error: unknown argument: '-R/usr/local/lib' > >>> configure:6155: $? = 1 > > > >> I assume you're building the 1.9.2 tarball, correct? Does the problem > > Yep. > > > >> also occur if you build from a checkout of the 1.9.2 tag? (You'll need > >> to run autogen.sh before configure.) > > Yes. Here is version of tools used by autogen.sh: > > > > buildcheck: autoconf version 2.69 (ok) > > buildcheck: autoheader version 2.69 (ok) > > buildcheck: libtool version 2.4.6 (ok) > > > > And after that same error if "--enable-all-static" is passed. > > On my FreeBSD 10.1 install I get further than that when I try to build > the 1.9.x branch, but linking svn fails due unresolved SSL symbols. I > can fix it by changing LIBS in Makefile to add -lssl -lcrypto. > > Subversion configure script does not add the -R so I suppose on of the > dependencies must be telling Subversion to add it. What does your > configure line look like? Have you build any of the dependencies > yourself? I think I found these flags in /usr/local/libdata/pkgconfig/serf-1.pc [[ SERF_MAJOR_VERSION=1 prefix=/usr/local exec_prefix=${prefix} libdir=/usr/local/lib includedir=${prefix}/include/serf-1 Name: serf Description: HTTP client library Version: 1.3.8 Requires.private: Libs: -L${libdir} -lserf-${SERF_MAJOR_VERSION} Libs.private: -L/usr/local/lib -R/usr/local/lib -laprutil-1 -ldb-5.3 -lgdbm -lexpat -L/usr/local/lib -R/usr/local/lib -lapr-1 -lcrypt -lpthread -lz -L/usr/lib -lssl -lcrypto Cflags: -I${includedir} ]] Bert
RE: svn segfaults on relocate when having a not checked out external
Hi, It looks like this issue was already fixed since 1.9.0. Backporting the fix to 1.8 is not trivial (but not that hard either). The relevant revision is r1627338. The old code just assumes that svn:externals describes exactly what is in the working copy, while the new code checks what is really there. (Will even relocate working copies that are still there, but already removed from svn:externals) Bert From: Axel Kittenberger [mailto:axk...@gmail.com] Sent: dinsdag 6 oktober 2015 13:25 To: users@subversion.apache.org Subject: svn segfaults on relocate when having a not checked out external Hello, below is my shell script that raises the svn segfault for me. The issue is, doing a relocate while having an external that is not in the working copy. It raised for me, since I got one automated instance that automatically sets externals for a repository, but does not need to check it out itself, so it updates with "--ignore-externals", now I tried to relocate that daemons working copy, svn segfaulted. Its no big issue for me, since I can always revert to do a full checkout instead, or update without --ignore-externals, relocate and delete the externals in the working copy. Still I guess, a segfault never should be not a bug, so I report it. Operating System is Debian Jessie, if you no need any more info just ask. Kind regards, Axel ~ ~$ svn --version svn, version 1.8.10 (r1615264) compiled Aug 9 2015, 13:48:39 on x86_64-pc-linux-gnu Copyright (C) 2014 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.8 - handles 'http' scheme - handles 'https' scheme ~$ mkdir atest ~$ cd atest/ atest$ svnadmin create repository1 atest$ svnadmin create repository2 atest$ svn checkout file:///home/axel/atest/repository1 rep1 Checked out revision 0. atest$ svn checkout file:///home/axel/atest/repository2 rep2 Checked out revision 0. atest$ atest$ cd rep2/ rep2$ echo "bar" > foo rep2$ svn add foo A foo rep2$ svn commit -m foobar Adding foo Transmitting file data . Committed revision 1. rep2$ cd .. atest$ cd rep1/ rep1$ echo "^/../repository2 extrep2" > externals rep1$ svn propset svn:externals . -F externals property 'svn:externals' set on '.' rep1$ svn up Updating '.': Fetching external item into 'extrep2': Aextrep2/foo Updated external to revision 1. At revision 0. rep1$ cat extrep2/foo bar rep1$ ### everything working as expected so far ### rep1$ rm -rf extrep2/ rep1$ cd .. atest$ mv repository1/ namechange1 atest$ cd rep1/ rep1$ svn relocate file:///home/axel/atest/namechange1 Segmentation fault rep1$ This is easily tough circumvented with this. Which once again works as expected: rep1$ svn up Updating '.': Fetching external item into 'extrep2': Aextrep2/foo Updated external to revision 1. At revision 0. rep1$ svn relocate file:///home/axel/atest/namechange1
RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Subject: Re: Bug report: The auto-props setting of svn:mime-type is > impossible to avoid. > > > This whole discussion -in its many iterations- is one of the reasons why I > > never looked at enabling this feature on Windows. > > And nobody has been asking for it to be enabled? I don't remember anybody asking... I doubt many users explicitly enable it on other platforms either, but we do an autodetect there, which usually just works. Bert
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 <true.bug...@gmail.com> 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: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: zondag 4 oktober 2015 13:32 > To: Edward d'Auvergne <true.bug...@gmail.com> > Cc: Greg Stein <gst...@gmail.com>; users@subversion.apache.org > Subject: Re: Bug report: The auto-props setting of svn:mime-type is > impossible to avoid. > > On Sun, Oct 04, 2015 at 12:52:33PM +0200, Edward d'Auvergne wrote: > > I would maybe suggest introducing an option for disabling the entire > > automatic property subsystem, i.e. it combines both of these, and > > overrides them. This is an interesting thought experiment - devise > > any name for such a top level automatic property override - and this > > should convincingly demonstrate the confusion that the current setting > > names induces. > > I think that would just make the situation worse by adding to > the current mess. > > I agree the documentation needs to be improved. Would you have time > to update the documentation and send patches for it? > > > The problem with the svn:mime-type block is that for svn clients < > > 1.9, 'svn import' can never work. Specifically because the libmagic > > layer overwrites any user decision to disable automatic properties. > > There's another trick to disable libmagic which works with all > client versions. I just tested it with 1.8. > > Set the MAGIC environment variable to a file which does not exist. > > env MAGIC=/nonexistent svn import ... > > This effectively disabled libmagic support. For Windows I don't think you need any disabling, as our build doesn't even support building with libmagic there. (Perhaps somebody patched something in their own build... but I don't think that is really an interesting scenario). Note that the Cygwin version is an exception to most of this... It is a Windows build but tries to do everything the unix way. Bert
RE: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: zondag 4 oktober 2015 22:01 > To: Branko Čibej <br...@apache.org> > Cc: users@subversion.apache.org > Subject: Re: Bug report: The auto-props setting of svn:mime-type is > impossible to avoid. > > On Sun, Oct 04, 2015 at 09:16:04PM +0200, Branko Čibej wrote: > > On the other hand, I am surprised that the logic that uses libmagic > > isn't turned off with 'enable-auto-props=no'. After all, using libmagic > > is just a convenient extension to the definitions in the [auto-props] > > section. > > Recall that the idea was to make setting svn:mime-type convenient. > > Before we added this feature, people had to fiddle with their client > config, know what MIME-types are about, what useful values to set > them to, and keep their config consistent across all systems they > used since libmagic support pre-dates the svn:autoprops feature. > In a sane universe, almost nobody would ever bother setting it up that way. > > I am not opposed to the idea, though. But not because of the fairly > minor configurability issues raised in this thread. Rather, because > the more I learn about how libmagic actually works, the more potentially > dangerous, from the security point of view, it seems to be. > The libmagic parser could potentially cause security problems whenever > people are adding untrusted files to SVN. Which is a good reason to make > this feature opt-in. I would support changing Subversion to -by default- disable this feature, unless it is enabled in the configuration (or some flag passed to 'svn add' in 1.10+). I'm not sure if I would call it a security problem when a user adds a file of their choosing to Subversion though :-) This whole discussion -in its many iterations- is one of the reasons why I never looked at enabling this feature on Windows. Bert
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, <b...@qqmail.nl> 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: Incomplete SVN dump files
> -Original Message- > From: Andreas Mohr [mailto:a...@lisas.de] > Sent: woensdag 16 september 2015 07:48 > To: Eric Johnson <e...@tibco.com> > Cc: b...@qqmail.nl; users@subversion.apache.org > Subject: Re: Incomplete SVN dump files > > Hi, > > On Tue, Sep 15, 2015 at 05:26:38PM -0700, Eric Johnson wrote: > >I just checked, and there aren't any open bugs about this. > >Interrupting svnrdump can result in a dump file with not all the files of > >the last commit in the dump record. Accidentally use that dump file to > >load into a new repository, and the resulting repository will not be a > >copy of the original. > >My particular use case, I was trying to suck down a large repository. > >Connection interrupted part way through. I resumed from part way through > >(using the --incremental option) into an additional dump file. Then did a > >load of those two dump files. Did not yield a copy of the original > >repository, though. > >This seems like a critical issue for possible data loss when copying > >repositories from machine to machine using svnrdump. > > AFAICS (not an svnrdump expert here) very well described and to the point. > You just managed to pinpoint a rather important serialization format > that seemingly isn't fully properly atomically transaction-safe... > (good catch!) In some ways a dumpfile is a stream and not a file... and when you use the commandline tools you always obtain it from stdout. I could argue that you in that case should check if the operation exited successfully or with an error. After an error you can't trust that the final portion is ok. The stream was also deliberately designed in a way that you can incrementally generate it... E.g. after each new revision or as a daily backup operation. Adding some 'this is the end' marker would break those use cases, that we have been using since the day subversion was self-hosted. (Long before 1.0) And when loading from a stream we can't continue reading to the end to see if there is a final marker, as at that point we aren't able to go back to the start and start the whole process. (I've used '$ svn dump | ssh svnadmin load ...' more than a few times for repository migrations) Bert
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: 1.9 - Can't resolve to 'mine full' option for binary file conflict
> -Original Message- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: maandag 14 september 2015 09:54 > To: users@subversion.apache.org > Subject: Re: 1.9 - Can't resolve to 'mine full' option for binary file > conflict > > On 9/14/2015 7:56 AM, Daniel Becroft wrote: > > Hi guys, > > > > > > I've just upgraded to SVN 1.9. One of the first things I noticed is > > that when a binary file conflict is raised during an SVN update, I can > > no longer use the 'mine-full' option to resolve. > > > > The only options I have are: (r) working and (tf) theirs-full. > > > > I can't use the 'r' (working) option, as I get a message of "Invalid > > option; use diff/edit/merge/launch before choosing 'mark resolved'. > > > > If I postpone, and try resolving afterwards, I get the following errors; > > > svn resolve file.binary --accept mine-full > > svn: warning: W155027: Conflict on 'file.binary' could not be resolved > > because the chosen version of the file is not available. > > svn: E155027: Failure occurred resolving one or more conflicts > > > > I can't find anything in the release notes about the removal of the > > 'mine-full' option on binary files. Was it intentional? If so, what's > > the intended workflow for resolution? > > > > Current version: > > svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0) > >compiled Aug 26 2015, 17:09:55 on x86/x86_64-microsoft-windows6.2.9200 > > > > Cheers, > > Daniel B. > Hi Daniel, > > just to second ur observation: > I think I ran into the same problem last Thursday/Friday using TSVN > 1.9.1. I didn't report it yet because I didn't check out whether it's a > TSVN or an SVN issue. > Using TSVN, it however also gives me the "file not found" error when I > try to resolve a binary conflict selecting "Use Repository version" > during the merge dialog. > > I'm sure u are already ware, but just in case: My workaround was to let > the file in conflict and afterwards resolve the conflict by reverting > the file (so it was in the repository's state which I intended). In case of a binary file the original working copy version is left as the working version, whereas for text conflict the working copy version is changed into a mine version and a best effort merge is performed to the a new working copy version potentially containing conflict markers. In this case you probably get the result you want by just choosing the working copy version. The Subversion developer responsible for choosing this UI determined that it didn't make much sense to offer two different resolve options with exactly the same result. Bert > > -- > Regards, > Stefan Hett
RE: win32svn for 1.9.1?
> -Original Message- > From: Olivier Sannier [mailto:oliv...@obones.com] > Sent: woensdag 9 september 2015 23:46 > To: users@subversion.apache.org > Subject: Re: win32svn for 1.9.1? > > On 08/09/2015 18:57, Win32Svn wrote: > > > > > > On 2015-09-08 13:00, Stefan Hett wrote: > >> On 9/7/2015 10:21 PM, Win32Svn wrote: > >>> On 2015-09-07 18:59, Barry Scott wrote: > >>>>> On 7 Sep 2015, at 11:43, Andreas Stieger <andreas.stie...@gmx.de> > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Barry Scott wrote: > >>>>>> I see that the recent 1.7 and 1.8 win32svn builds being > >>>>>> announced, thanks for > >>>>>> them. > >>>>>> > >>>>>> Do you know when the svn 1.9 win32svn build might be available? > >>>>> Available at other binary "vendors": > >>>>> https://subversion.apache.org/packages.html#windows > >>>> Sadly only win32svn packages the include files that are needed to > >>>> write > >>>> code against svn. In my case I use win32svn as the basis of the pysvn > >>>> win32 build. > >>>> > >>>> Barry > >>>> > >>> > >>> Hi Barry! > >>> > >>> I'm sorry to say there won't be any 1.9.x build of Win32SVN. > >>> You can read about it on http://alagazam.net (click the 1.9.x info > >>> link on the right) > >>> > >>> Regards, > >>> David Darj a.k.a. Alagazam > >>> Maintainer of Win32SVN > >>> http://alagazam.net > >>> > >>> ps. > >>> If you like my work, please support this project by donating at > >>> http://sourceforge.net/donate/index.php?group_id=357628 > >>> > >> > >> Hi David, > >> > >> I'm wondering which particular VS6 issue you are referring to in that > >> note. > >> I've been told the only known issues atm not working using VS6 would > >> be in the javahl code (due to the template code) which I assume is > >> not the issue you are talking about, or is it? > >> > > > > Hi Stefan > > > > I don't remember exactly now, but I gave one of the 1.9.0-alpha a shot > > with my build scripts (you can find them on sourceforge). > > There were a lot more compilation errors than in 1.8.x where I've > > already patched a lot, and the time to look deeper then didn't exist. > > Maybe there isn't any specific windows api issues or other features, > > but the old C standard (MS-standard) in VC6 makes the burden, right > > now at least, to much. > > > > Regards, > > David Darj a.k.a. Alagazam > > Maintainer of Win32SVN > > Hello David, > > Do you think it would be possible to migrate the scripts to VC2010? > I mean, I have it installed and am using it on a regular basis, so I > could help with building part if need be. If you try this as a group effort I would recommend directly going to VS 2013 or VS 2015, as those are now available for free for noncommercial usage via the new 'Community Edition'. With 2010 you are still limited to those who have access to these versions. Note that if you want to remain compatible with Windows XP and 2003 with those versions, you need special options which will mostly get you back at the VS 2010 tools. Bert
RE: chcp has no effect on output encoding for chcp
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: maandag 7 september 2015 23:26 > To: Matthias Ludwig <matthias-lud...@gmx.net> > Cc: users@subversion.apache.org > Subject: Re: chcp has no effect on output encoding for chcp > > Matthias Ludwig wrote on Mon, Sep 07, 2015 at 11:45:13 +0200: > > The use of the subversion language bindings is no alternative because there > > exists no language bindings for svnlook. > > svnlook just wraps the svn_fs/svn_repos APIs, which do have bindings: > > % python2 > >>> from svn.fs import * > >>> from svn.repos import * > >>> fs = svn_repos_fs(svn_repos_open("/tmp/r")) > >>> svn_fs_youngest_rev(fs) > 0L > > (The repository was empty, i.e., zero revisions.) You could also look at the SharpSvn library (.Net on Windows). This library has a higher level SvnLookClient class which has mostly the same functions as 'svnlook'. You can find some examples on StackOverflow via http://stackoverflow.com/search?q=SvnLookClient Bert
RE: Access denied error on checkout-commit after updating to 1.9.X
I have no problem using Subversion on 1.9.x on network drives, testing to Windows servers and to Samba 4.x, so clearly not everyone using Subversion on a network drive has this problem. Perhaps you tried to say that most users seeing this problem have it on a network drive? Are there other common similarities? Are you all using the same virus scanner on either the client or the server, or the same windows version on client and/or server? (Or not even using Windows at all on the server?) Bert From: Daniele Pedroni [mailto:pedroni.dani...@zapispa.it] Sent: vrijdag 4 september 2015 17:15 To: users@subversion.apache.org Subject: Access denied error on checkout-commit after updating to 1.9.X After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN as well as command line throw the following error after trying to checkout or commit a Working Directory on a network share: Commit failed (details follow): Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base': Access is denied. (full discussion on TSVN mailing list here: https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U ) It seems to be a Subversion issue, not a TortoiseSVN one, since command line acts exactly the same as TSVN: everything fine with local paths, issues with network drives. Sometimes, trying more and more, the checkout/commit succeeds also on network share, but it is a random occurrence. Any clue? As you can see in the suggested link, it seems that everyone who works on network drive has the same problem: something has been changed or broken in 1.9.X release about it? I didn’t find anything about it. Thank you in advance Daniele P. Zapi Spa - Società per Azioni con Unico Socio - Via Parma, 59, 42028 Poviglio (RE) - Tel. +39 0522 960050 - Fax +39 0522 960259 - E-mail: z...@zapispa.it <mailto:z...@zapispa.it> - web site: www.zapispa.it <http://www.zapispa.it> - Capitale Sociale € 2.582.500,00 - Iscrizione Registro Imprese di Reggio Emilia n. 00794070342 - C.F. 00794070342 - P. IVA 01184200358 AVVERTENZA: Ai sensi del Codice Privacy DLGS n.196/03 si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il messaggio Le fosse pervenuto per errore La preghiamo di eliminarlo senza copiarlo, di non inoltrarlo a terzi e di darcene tempestiva comunicazione. According to Privacy Code DLGS n.196/03 we state that the information contained in this message are contidential and for the exclusive use of the receveir. In case the message reached you by mistake, we kindly ask you to delete it without copying it, not to send it to others and to inform us about it immediately. Rispetta l'ambiente: non stampare questa e-mail se non ti è necessario. Please consider your environmental responsability before printing this e-mail.
RE: Can't dump a subtree using svnrdump
-Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: zondag 30 augustus 2015 20:30 To: users@subversion.apache.org Subject: Can't dump a subtree using svnrdump Hi all, I would like to dump one or maybe two subtrees of the ASF repo and whatever I feed to svnrdump I always get the contents of unrelated subtrees as well. If I don't provide a revision range I get thew complete repo, if I provide a range where my subtrees have changed, I get all the revisions of unrelated subtrees in between as well. In the documentation and such I can read that svnrdump does support subtrees, so there must be something wrong ho I call it. What I want is the following URL: https://svn.apache.org/repos/asf/incubator/log4cxx Which was originally added as the following: https://svn.apache.org/repos/asf/logging/log4cxx What I've tried so far: svnrdump.exe dump https://svn.apache.org/repos/asf/incubator/log4cxx svnrdump.exe dump https://svn.apache.org/repos/asf/logging/log4cxx svnrdump.exe dump https://svn.apache.org/repos/asf/logging/log4cxx -r 307452:1554780 svnrdump.exe dump https://svn.apache.org/repos/asf/incubator/log4cxx -r 1554780:HEAD But all of those always dump revisions not related to my subtrees. What am I doing wrong? Thanks! I don't think you are doing anything wrong. Any revision in a repository applies to each path that exists at that revision and the only way to ensure a 100% compatible dump with matching revision numbers is to produce empty revisions for revisions that don't have relevant paths. So yes, you will see many more revisions than just your own project... but if filtered correctly not the changes in those revisions. Once you have dumps you can use tools like 'svndumpfilter' to filter out dummy/stub revisions, fixing things like copies and merges. I just used this to import the Serf repository into https://svn.apache.org/repos/asf/serf, while filtering a thousand stub revisions. Bert
RE: How to pass a message file in UTF8 encoding to svn commit?
-Original Message- From: Hunger Tobias [mailto:tobias.hun...@theqtcompany.com] Sent: donderdag 27 augustus 2015 15:45 To: users@subversion.apache.org Subject: How to pass a message file in UTF8 encoding to svn commit? Hello SVN users list! I have a file in UTF8 encoding, containing a couple of non-ASCII characters (Cyrillic mostly, some äüß and such). I know that file to be in UTF8 encoding. Then I am trying to run: svn commit --encoding utf8 --file mymsg.txt somefile.cpp and I get the following error: svn: E22: Commit failed (details follow): svn: E22: Error normalizing log message to internal format svn: E22: Non-ASCII character (code 195) detected, and unable to convert to/from UTF-8 Did I set something wrong in --encoding? Or does that not effect --file? How can I force SVN to treat the file contents as UTF8? I think at least UTF-8 as passed value should work. That encoding name is hardcoded to avoid the entire conversion. The other values might depend on what iconv settings are used by your specific client. Bert
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: Is it safe to redirect from HTTP to HTTPS in case of svn:externals?
-Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: woensdag 19 augustus 2015 21:50 To: users@subversion.apache.org Subject: Is it safe to redirect from HTTP to HTTPS in case of svn:externals? Hi, I'm implementing publicly accessible mod_davn_svn in addition to some internally used svnserve. Some of my repos use svn:externals where we used to defined //internal.example.org/..., my publicly available entry point is https://external.example.org;. For the public internal.example.org is resolved as external.example.org, so checking out a repo from HTTPS with svn:externals used would result in a request to https://internal.example.org; and produce certificate verification failures in the client because of mismatching domain names and such. So I thought of simply changing the svn:externals definition to http://internal.example.org; which I can then redirect to https://external.example.org; on my public server. In my tests that seemed to work properly and the important part is that the locally created working copy for svn:externals only contained HTTPS-URLs. So am I correct that my approach is safe regarding that no user passwords or such are going unencrypted over the wire if only the first request doesn't contain such passwords and will always only be the redirect? Any other problems which I might overlook currently? The key Subversion uses to store passwords is different between http and https, so a password used for https won't be used for http. There are other options to specify your externals; see 'svn help propset' [[ The URL may be a full URL or a relative URL starting with one of: ../ to the parent directory of the extracted external ^/ to the repository root /to the server root // to the URL scheme ^/../ to a sibling repository beneath the same SVNParentPath location ]] Bert
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: Broken SVN revision paths encoding
What client (including version) did you use to commit… and against what kind of server? Subversion's clients properly encode characters to utf-8 as far as we know, but perhaps you used some not standard client for the commit. (Newer servers should perform more verifications; that is why that answer is also relevant) Bert Sent from Surface From: dpsen...@apache.org Sent: Tuesday, July 28, 2015 4:11 PM To: users@subversion.apache.org Hi there, Somehow I was able to commit a file with a broken filename encoding and now the svn client can no longer process the log messages from the server! For example I commited the file “fooä.bar” and when I then try to svn log I get this: svn: E130003: The REPORT response contains invalid XML (200 OK) However, in wireshark I can see this coming in (stripped to the interesting lines): S:log-item S:added-pathfoo\344.file/S:added-path /S:log-item The clients svn is not the latest, but a newer version does not work either: svn –version svn, version 1.8.10 (r1615264) compiled Aug 10 2014, 15:48:46 on x86-microsoft-windows Any good ideas how we can bring the repository back to be fully functional? Cheers
RE: Feature request: Save the old file when svn revert
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: woensdag 22 juli 2015 13:43 To: Markus Schaber m.scha...@codesys.com Cc: Grierson, David david.grier...@sky.uk; d...@subversion.apache.org; 牛 暁冬 neoedm...@gmail.com; users@subversion.apache.org Subject: Re: Feature request: Save the old file when svn revert Markus Schaber wrote on Tue, Jul 21, 2015 at 13:01:09 +: All other commands need a --force or other explicit user decision to override user changed data, but the whole purpose of the svn revert command is to undo local changes - putting a --force option or something similar seems like a bit of contradiction. Note that 'svn revert' without further arguments does nothing and errors out; you must name explicitly what will be reverted. (Even with '-R' you still need to specify a target directory.) How do the other RCSes handle this situation? Maybe we can learn some ideas for a nice(r) UI there... In Git, if you add a file to the index, you can generally 'cat-file blob' it out of there for a while later if you know its hash (eg, if you have the header of a diff of that file, as headers mention the hash). Ditto for local commits, you can get them from the reflog for a while later (until a garbage collection pass). Adding it to the index, is usually done by something like commit. In that case I don't think you really need to stash the actual file locally, as you can just get it with 'svn cat' (probably after finding some revision with svn log) The local version of the file might have local changes though... If you would store that one in the pristine store, it would have some sha-1 hash... But I doubt the user would know that hash, and without that he/she would be unable to retrieve it, unless we build some UI. In that case I would start by looking at the UI. Bert
RE: E175002
Hi Anup, This error is raised from SvnKit. A pure java reimplementation of the Subversion libraries. While it is possible that this error is caused by the/a Subversion server, the fact that you can fix it by restarting Jenkins points towards an issue in either SvnKit or Jenkins. I think you should ask at either of these project's support mailinglists. The 'Caused by: java.lang.NoClassDefFoundError: hudson/remoting/RemoteClassLoader$RemoteIClassLoader' would point towards a bit more towards Jenkins, than to SvnKit. Bert From: Somashekarappa, Anup (CWM-NR) [mailto:anup.somashekara...@rbc.com] Sent: maandag 13 juli 2015 15:26 To: 'users@subversion.apache.org' Subject: E175002 Hi, We are frequently getting the below error when trying to downloading svn data from jenkins. Issue will get resolved when we restart jenkins slave node.Any idea what is the root cause? org.tmatesoft.svn.core.SVNException http://stacktrace.jenkins-ci.org/search?query=org.tmatesoft.svn.core.SVNExc eption : svn: E175002: OPTIONS /svn/repo/trunk failed Caused by: java.io.IOException: Remote call on channel failed at hudson.remoting.Channel.call(Channel.java:760) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java: 173) ... 36 more Caused by: java.lang.NoClassDefFoundError: hudson/remoting/RemoteClassLoader$RemoteIClassLoader at hudson.remoting.RemoteClassLoader.export(RemoteClassLoader.java:657) at hudson.remoting.UserRequest.init(UserRequest.java:70) at hudson.remoting.Channel.call(Channel.java:750) ... 37 more Thanks Regards, Anup T S __ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Emails are monitored by supervisory personnel in jurisdictions where monitoring is permitted. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
RE: Subversion 1.8.13 on Cygwin: E170000 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL
Hi Marc, It has nothing to do with cross compilation. (I don’t know how Cygwin produces their binaries… doesn’t matter) But Cygwin is a fake unix environment for Windows. As such it expects unix style paths. And when you compile Subversion for Cygwin, Subversion assumes that it is not on Windows so the path processing combines multiple slashes to one. The APR library that Subversion uses provides full Windows compatibility and Subversion itself also adds many Windows specific features, but only if you compile Subversion for Windows… which is what the Cygwin developers explicitly don’t. They explicitly disable the Windows portions to make Subversion behave as on other platforms. This is the problem you see here. Subversion 1.6 was very sloppy in its path handling, which required a lot of unneeded path processing all through the code. With Subversion 1.7 the path processing was completely updated to fully work with canonical and in most cases absolute paths, to avoid all kinds of errors. In 1.6 we didn’t catch all kinds of user errors, including file: file:///\\ style paths, or even file:///\\\ file:///\\ , but for 1.7 we declared these non canonical and convert them to a supported format before we use them. But depending on the platform we use different rules. Things like ‘c:hi’ are a valid filename on platforms like linux, while they are a drive relative path on Windows. The unix/posix code in Subversion doesn’t support UNC paths, while the Windows code does. We support a Windows version of Subversion, to handle the Windows platform. And the Cygwin developers support their compilation… but when they decide not to use our platform support, we can’t help you. That’s why I recommended mapping the drive (to work around the problem) or to use a proper Windows subversion client. Bert From: MORGAN Marc [mailto:marc.mor...@csem.ch] Sent: vrijdag 26 juni 2015 11:41 To: Bert Huijben; users@subversion.apache.org Subject: RE: Subversion 1.8.13 on Cygwin: E17 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL Hi Bert, Thanks for your reply. 1) Are you suggesting that Cygwin executables are cross-compiled for Cygwin under Linux? Are you sure of this? I’ve never come across a Linux environment for cross-compiling code for Cygwin execution. Do you have more information about this? 2) Access to the same repository worked fine with the previous svn on Cygwin on the same Windows computer, same Linux server, same network. Are you suggesting that someone removed the path mapping capability from svn between versions 1.6 and 1.8? Marc From: Bert Huijben [mailto:b...@qqmail.nl] Sent: vendredi 26 juin 2015 05:17 To: MORGAN Marc; users@subversion.apache.org mailto:users@subversion.apache.org Subject: Re: Subversion 1.8.13 on Cygwin: E17 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL The cygwin version of Subversion is a unix compilation of subversion running on Windows, via the cygwin libraries. As such it doesn't understand special Windoes paths. If you would use a normal windows client (compiled for windows; not cygwin) it would understand that it should transform file://myserver/share/path file:///\\myserver\share\path to \\myserver\share\path file:///\\myserver\share\path . If you would like to use the cygwin version, you should probably map the network share and then relocate your working copy. Bert Sent from Surface From: MORGAN Marc mailto:marc.mor...@csem.ch Sent: Thursday, June 25, 2015 3:47 PM To: users@subversion.apache.org mailto:users@subversion.apache.org Cc: MORGAN Marc mailto:marc.mor...@csem.ch Hi, I’ve been using subversion on my Windows 7 PC with Cygwin with a repository on a Linux server accessed via file:// file:///\\ . I installed a brand new Cygwin version yesterday. My local workspace lost its connection to the repository. I can no longer access via svn the repository which I was previously using on the same PC. % svn status -u svn: E17: Unable to connect to a repository at URL 'file://server/path/repository/trunk' svn: E17: Unable to open an ra_local session to URL svn: E17: Local URL 'file://server/path/repository/trunk'contains unsupported hostname % svn ls file:server/path/repository file:///\\server\path\repository svn: E180001: Unable to connect to a repository at URL 'file:///server/path/repository' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository 'file:///server/path/repository' % ls //server/path/repository conf dav db format hooks locks README.txt The new svn version is 1.8.13 (r1667537) on i686-pc-cygwin. The previous svn version I was using is 1.6.17. With file:// I get the E17 error. With file
Re: Subversion 1.8.13 on Cygwin: E170000 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL
The cygwin version of Subversion is a unix compilation of subversion running on Windows, via the cygwin libraries. As such it doesn't understand special Windoes paths. If you would use a normal windows client (compiled for windows; not cygwin) it would understand that it should transform file://myserver/share/path to \\myserver\share\path. If you would like to use the cygwin version, you should probably map the network share and then relocate your working copy. Bert Sent from Surface From: MORGAN Marc Sent: Thursday, June 25, 2015 3:47 PM To: users@subversion.apache.org Cc: MORGAN Marc Hi, I’ve been using subversion on my Windows 7 PC with Cygwin with a repository on a Linux server accessed via file://. I installed a brand new Cygwin version yesterday. My local workspace lost its connection to the repository. I can no longer access via svn the repository which I was previously using on the same PC. % svn status -u svn: E17: Unable to connect to a repository at URL 'file://server/path/repository/trunk' svn: E17: Unable to open an ra_local session to URL svn: E17: Local URL 'file://server/path/repository/trunk'contains unsupported hostname % svn ls file:server/path/repository svn: E180001: Unable to connect to a repository at URL 'file:///server/path/repository' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository 'file:///server/path/repository' % ls //server/path/repository conf dav db format hooks locks README.txt The new svn version is 1.8.13 (r1667537) on i686-pc-cygwin. The previous svn version I was using is 1.6.17. With file:// I get the E17 error. With file:/// or file: I get the E180001 error. The repository directory is technically on another computer but is seen as local on my PC (I guess it’s NFS or SAMBA) when accessed with the // prefix from the shell. I tried touch-ing a new file in the repository’s directory and that worked, with correct owner, group and file permissions when checked from the Linux server. If I copy the repository folder to my local /tmp, I can access it correctly via svn. But that’s obviously not my goal. If I access the repository via the URL svn+ssh://somelinuxcomputer/nfspath/repository, that works. But my experience with the SSH tunnel is that it tends to slow down access. Has anyone experienced this problem before? Any suggestions? Thanks in advance
RE: building SVN trunk on Windows fails on python gen-make.py
-Original Message- From: Cooke, Mark [mailto:mark.co...@siemens.com] Sent: maandag 22 juni 2015 13:46 To: Stefan Hett; users@subversion.apache.org Subject: RE: building SVN trunk on Windows fails on python gen-make.py Sorry I cannot help with the current issue but I wanted to add a comment about the content of INSTALL (below)... While I agree in principle, I need to build httpd and subversion to work with Trac (trac.edgewall.org) which is currently limited to python 3.0 (I use 2.7 also). For this to work properly my understanding is that httpd and python (and svn) all need to use the same compiler libraries and Python 2.7 is built using Visual C++ 2008... So the 2008 stuff is not completely irrelevant (I got it compiling and making the python bindings). I have some notes but they are not really fit for publication and are for VC2008 but I can share them if you think they would be useful. To build AnkhSVN for Visual Studio 2005 and 2008 I continue to build Subversion using VS 2008 at least every week, so I would consider VS 2005 and 2008 as fully supported for Subversion. But I don't think anybody working on Subversion really uses VS 6.0 (released +- 18 years ago) or 2002 and 2003, so I don't consider our support for these versions as really supported. I'm guessing that the VS 6.0 support might still work with a minor tweak, while I think the 2002/2003 support would need at least some patches to make it work again. If nobody is going to comment on this after the release of 1.9.0, I think we will drop support for these 12+ year old versions with 1.10+. With VS 2013 Community Edition now free to use for everybody working on open source projects, there is no good reason to continue to support these very old versions, that target platforms that are no longer supported anyway. One interesting point for some usecases is that the VS 2010 tooling allows building with the VS2008 compiler by passing a few specific flags to msbuild. This is how the first version of XP compatibility in VS2012+ was implemented. (And this is also how VC 2010+'s C++/CLI can target .Net 2.0-3.5) Bert
RE: svn 1.8.13 test failures: wc-queries-test.exe and move_tests.py
-Original Message- From: Cooke, Mark [mailto:mark.co...@siemens.com] Sent: maandag 1 juni 2015 08:24 To: users@subversion.apache.org Cc: Bert Huijben Subject: RE: svn 1.8.13 test failures: wc-queries-test.exe and move_tests.py -Original Message- From: Cooke, Mark [mailto:mark.co...@siemens.com] Sent: vrijdag 29 mei 2015 15:21 Hello, I am trying to compile svn (and httpd) with VS2008 (for python 2.7 compatibility) on Win 7 Enterprise and am getting some test failures: {{{ win-tests.py --release --cleanup --parallel win-tests.py -r -c --httpd-dir=d:\Apache24 --httpd-daemon }}} [40/96] wc-queries-test.exe ... FAILED [72/96] move_tests.py . success For #40 I noticed that Andreas confirmed [1] that r1672295 fixes a (similar?) issue (which is more recent than the 1.8.13 tag), so can I safely ignore this? -Original Message- From: Bert Huijben [mailto:b...@qqmail.nl] Sent: 29 May 2015 16:15 What version of sqlite do you use, I made a mistake and took a nightly snapshot: - sqlite-amalgamation-201505290135.zip and what is the error that you see? Apologies for not being more precise earlier, I am still finding my way around the code trees. This is the summary:- At least one test FAILED, checking D:\svn\src\Release\dav-tests.log FAIL: wc-queries-test.exe 3: test query expectations Summary of test results: 1950 tests PASSED 55 tests SKIPPED 32 tests XFAILED (1 WORK-IN-PROGRESS) 1 test FAILED SUMMARY: Some tests failed. ...and from the test log:- START: wc-queries-test.exe DBG: Using Sqlite 3.8.11 PASS: wc-queries-test.exe 1: sqlite up-to-date PASS: wc-queries-test.exe 2: queries are parsable svn_tests: E26: STMT_SELECT_EXTERNALS_DEFINED: Uses externals with only 1 index component: (wc_id=? ) SELECT local_relpath, def_local_relpath FROM externals WHERE (wc_id = ?1 AND def_local_relpath = ?2)OR (wc_id = ?1 AND (((def_local_relpath) (CASE (?2) WHEN '' THEN '' ELSE (?2) || '/' END)) AND ((def_local_relpath) CASE (?2) WHEN '' THEN X'' ELSE (?2) || '0' END))) svn_tests: E200035: Additional errors: svn_tests: E200035: |SEARCH TABLE externals USING COVERING INDEX I_EXTERNALS_DEFINED (wc_id=?) FAIL: wc-queries-test.exe 3: test query expectations PASS: wc-queries-test.exe 4: test schema statistics END: wc-queries-test.exe ELAPSED: wc-queries-test.exe 0:00:00.125000 Ok, this confirms that it is a known failure that will be fixed when the 'r1672295, r1673691' group of ^/subversion/branches/1.8.x/STATUS is backported. I hope this will happen for the next 1.8.x version. The problem occurs with Sqlite 3.8.10 and later. It currently tells us that it is using the index in a less than optimal way, but unless you have hundreds of externals in a working copy you wouldn't be able to tell the difference. The query optimizer is expected to use two index components here, but currently only one... which makes it essentially a table scan. But with typically every external in a single database page there won't be real performance problems. For the `move_tests.py` crash success the log states: START: move_tests.py PASS: move_tests.py 1: lateral (rename) move of a file test PASS: move_tests.py 2: sibling move of a file test PASS: move_tests.py 3: shallower move of a file test PASS: move_tests.py 4: deeper move of a file test PASS: move_tests.py 5: test property merging on move-update PASS: move_tests.py 6: move a missing directory PASS: move_tests.py 7: move many and delete-on-update W: svn: E235000: In file '..\..\..\subversion\libsvn_wc\wc_db_update_move.c' line 809: assertion failed (move_dst_revision == expected_move_dst_revision || status == svn_wc__db_status_not_present) W: W: This application has requested the Runtime to terminate it in an unusual way. W: Please contact the application's support team for more information. W: CWD: D:\svn\src\Release\subversion\tests\cmdline W: EXCEPTION: Failure: Command failed: D:\svn\src\Release\subversion\svn\svn.exe up svn-test- work\working_copies\move_tests-8 --accept ...; exit code 3 Traceback (most recent call last): File d:\svn\src\subversion\tests\cmdline\svntest\main.py, line 1561, in run rc = self.pred.run(sandbox) File d:\svn\src\subversion\tests\cmdline\svntest\testcase.py, line 114, in run return self._delegate.run(sandbox) File d:\svn\src\subversion\tests\cmdline\svntest\testcase.py, line 176, in run return self.func(sandbox) File d:\svn\src\subversion\tests\cmdline\move_tests.py, line 1397, in move_many_update_add wc_dir, '--accept', 'mine-conflict') File d:\svn\src\subversion\tests\cmdline\svntest\actions.py, line 865, in run_and_verify_update exit_code, output, errput = main.run_svn(error_re_string, 'up', *args) File d:\svn\src\subversion\tests\cmdline\svntest\main.py, line 682, in run_svn *(_with_auth
RE: svn 1.8.13 test failures: wc-queries-test.exe and move_tests.py
-Original Message- From: Cooke, Mark [mailto:mark.co...@siemens.com] Sent: vrijdag 29 mei 2015 15:21 To: users@subversion.apache.org Subject: svn 1.8.13 test failures: wc-queries-test.exe and move_tests.py Hello, I am trying to compile svn (and httpd) with VS2008 (for python 2.7 compatibility) on Win 7 Enterprise and am getting some test failures: {{{ win-tests.py --release --cleanup --parallel win-tests.py -r -c --httpd-dir=d:\Apache24 --httpd-daemon }}} [40/96] wc-queries-test.exe ... FAILED [72/96] move_tests.py . success For #40 I noticed that Andreas confirmed [1] that r1672295 fixes a (similar?) issue (which is more recent than the 1.8.13 tag), so can I safely ignore this? What version of sqlite do you use, and what is the error that you see? In most cases you can ignore the wc-query-expectations error failure, which only signals some performance loss. But it is hard to tell what failure you see if you only post the name of the .exe where one (or more) of the tests failed. The summary at the bottom is more valuable, and the test log contains the real details. Bert
RE: Error with quick-start experiment
Hi, You could use %REPOS_DIR:\=/% instead of just %REPOS_DIR% to replace all ‘\’ characters with ‘/’ (In batch scripts you might have to enable cmd extensions, but on the commandline this is enabled by default) Bert From: Antti Simola [mailto:asimol...@gmail.com] Sent: donderdag 28 mei 2015 11:19 To: Antti Simola; users@subversion.apache.org Subject: Re: Error with quick-start experiment This is what I typed in my last attempt. I've made several attempts after the one that worked earlier. C:\set REPOS_DIR=h:\repos\my-repos C:\mkdir h:\repos C:\svnadmin create %REPOS_DIR% C:\svn mkdir -m Create directory structure. file:///%REPOS_DIR%/trunk file:///\\%25REPOS_DIR%25\trunk file:///%REPOS_DIR%/branches file:///\\%25REPOS_DIR%25\branches file:///%REPOS_DIR%/tags file:///\\%25REPOS_DIR%25\tags svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: assertion failed (svn_uri_is_canonical(url, pool)) C:\ On Thu, May 28, 2015 at 11:30 AM, Stefan Sperling s...@elego.de mailto:s...@elego.de wrote: On Thu, May 28, 2015 at 11:08:17AM +0300, Antti Simola wrote: Hello, I’m learning to use the command-line Subversion (1.8.13 64-bit Win, SLIKSVN) by reading the book online and doing some tests. I followed the quick-start guide for some experiments: https://subversion.apache.org/quick-start The first time around went spotless. But the second time when I wanted to create another repo for another project I get the following error message: svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: assertion failed (svn_uri_is_canonical(url, pool)) when I execute the part that makes trunk, branches and tags subdirectories. That opens a dialog window for the error as well. Does anyone have any idea what I’m doing wrong here? Can you please show exactly what you typed on the command line when this happened? Antti Simola PS: There’s a typo in quick-start guide as the first “ is missing from the tags subdirectory address. Fixed, thanks.
RE: Error with quick-start experiment
If you want to use URL operations, the whole url should use ‘/’ separators. It now tries to open the local directory file:\\something file:///\\something , which certainly won’t exist because file: is not a valid device specifier on Windows. You want to use something like $ svn mkdir -m Create directory structure. file:///\\%25REPOS_DIR:\=\%25\trunk file:///%REPOS_DIR:\=/%/trunk file:///\\%25REPOS_DIR:\=\%25\branches file:///%REPOS_DIR:\=/%\branches file:///\\%25REPOS_DIR:\=\%25\tags file:///%REPOS_DIR:\=/%\tags But it might be easier to just set the properly encoded path in REPOS_DIR From: Antti Simola [mailto:asimol...@gmail.com] Sent: donderdag 28 mei 2015 11:55 To: Bert Huijben Subject: Re: Error with quick-start experiment Thanks! There's another error now with replaced slashes: C:\svn mkdir -m Create directory structure. file:\\\%REPOS_DIR%\trunk file:///\\%25REPOS_DIR%25\trunk file:\\\%REPOS_DIR%\branches file:///\\%25REPOS_DIR%25\branches file:\\\%REPOS_DIR%\tags file:///\\%25REPOS_DIR%25\tags svn: E020024: Error resolving case of 'file:\\\h:\repos\my-repos\trunk' On Thu, May 28, 2015 at 12:51 PM, Bert Huijben b...@qqmail.nl mailto:b...@qqmail.nl wrote: Hi, You could use %REPOS_DIR:\=/% instead of just %REPOS_DIR% to replace all ‘\’ characters with ‘/’ (In batch scripts you might have to enable cmd extensions, but on the commandline this is enabled by default) Bert From: Antti Simola [mailto:asimol...@gmail.com mailto:asimol...@gmail.com ] Sent: donderdag 28 mei 2015 11:19 To: Antti Simola; users@subversion.apache.org mailto:users@subversion.apache.org Subject: Re: Error with quick-start experiment This is what I typed in my last attempt. I've made several attempts after the one that worked earlier. C:\set REPOS_DIR=h:\repos\my-repos C:\mkdir h:\repos C:\svnadmin create %REPOS_DIR% C:\svn mkdir -m Create directory structure. file:///%REPOS_DIR%/trunk file:///\\%25REPOS_DIR%25\trunk file:///%REPOS_DIR%/branches file:///\\%25REPOS_DIR%25\branches file:///%REPOS_DIR%/tags file:///\\%25REPOS_DIR%25\tags svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: assertion failed (svn_uri_is_canonical(url, pool)) C:\ On Thu, May 28, 2015 at 11:30 AM, Stefan Sperling s...@elego.de mailto:s...@elego.de wrote: On Thu, May 28, 2015 at 11:08:17AM +0300, Antti Simola wrote: Hello, I’m learning to use the command-line Subversion (1.8.13 64-bit Win, SLIKSVN) by reading the book online and doing some tests. I followed the quick-start guide for some experiments: https://subversion.apache.org/quick-start The first time around went spotless. But the second time when I wanted to create another repo for another project I get the following error message: svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: assertion failed (svn_uri_is_canonical(url, pool)) when I execute the part that makes trunk, branches and tags subdirectories. That opens a dialog window for the error as well. Does anyone have any idea what I’m doing wrong here? Can you please show exactly what you typed on the command line when this happened? Antti Simola PS: There’s a typo in quick-start guide as the first “ is missing from the tags subdirectory address. Fixed, thanks.
RE: Error with quick-start experiment
That is not strictly typo, but I already committed a change to that line before I wrote my previous mail (r1682198). The current form specifies a root relative path on Windows ( \repos ), which would work while your current drive is ‘C:’ but stops working when you switch the active drive. Bert From: Antti Simola [mailto:asimol...@gmail.com] Sent: donderdag 28 mei 2015 12:49 To: Bert Huijben Cc: users@subversion.apache.org Subject: Re: Error with quick-start experiment Thanks! I got it working now by following the updated quick-start. There's perhaps one typo remaining as the drive is missing from this address: svn checkout file:///repos/my-repos/trunk file:///\\repos\my-repos\trunk ./ On Thu, May 28, 2015 at 1:10 PM, Bert Huijben b...@qqmail.nl mailto:b...@qqmail.nl wrote: If you want to use URL operations, the whole url should use ‘/’ separators. It now tries to open the local directory file:\\something file:///\\something , which certainly won’t exist because file: is not a valid device specifier on Windows. You want to use something like $ svn mkdir -m Create directory structure. file:///%REPOS_DIR:\=/%/trunk file:///\\%25REPOS_DIR:\=\%25\trunk file:///%REPOS_DIR:\=/%\branches file:///\\%25REPOS_DIR:\=\%25\branches file:///%REPOS_DIR:\=/%\tags file:///\\%25REPOS_DIR:\=\%25\tags But it might be easier to just set the properly encoded path in REPOS_DIR From: Antti Simola [mailto:asimol...@gmail.com mailto:asimol...@gmail.com ] Sent: donderdag 28 mei 2015 11:55 To: Bert Huijben Subject: Re: Error with quick-start experiment Thanks! There's another error now with replaced slashes: C:\svn mkdir -m Create directory structure. file:\\\%REPOS_DIR%\trunk file:///\\%25REPOS_DIR%25\trunk file:\\\%REPOS_DIR%\branches file:///\\%25REPOS_DIR%25\branches file:\\\%REPOS_DIR%\tags file:///\\%25REPOS_DIR%25\tags svn: E020024: Error resolving case of 'file:\\\h:\repos\my-repos\trunk' On Thu, May 28, 2015 at 12:51 PM, Bert Huijben b...@qqmail.nl mailto:b...@qqmail.nl wrote: Hi, You could use %REPOS_DIR:\=/% instead of just %REPOS_DIR% to replace all ‘\’ characters with ‘/’ (In batch scripts you might have to enable cmd extensions, but on the commandline this is enabled by default) Bert From: Antti Simola [mailto:asimol...@gmail.com mailto:asimol...@gmail.com ] Sent: donderdag 28 mei 2015 11:19 To: Antti Simola; users@subversion.apache.org mailto:users@subversion.apache.org Subject: Re: Error with quick-start experiment This is what I typed in my last attempt. I've made several attempts after the one that worked earlier. C:\set REPOS_DIR=h:\repos\my-repos C:\mkdir h:\repos C:\svnadmin create %REPOS_DIR% C:\svn mkdir -m Create directory structure. file:///%REPOS_DIR%/trunk file:///\\%25REPOS_DIR%25\trunk file:///%REPOS_DIR%/branches file:///\\%25REPOS_DIR%25\branches file:///%REPOS_DIR%/tags file:///\\%25REPOS_DIR%25\tags svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: assertion failed (svn_uri_is_canonical(url, pool)) C:\ On Thu, May 28, 2015 at 11:30 AM, Stefan Sperling s...@elego.de mailto:s...@elego.de wrote: On Thu, May 28, 2015 at 11:08:17AM +0300, Antti Simola wrote: Hello, I’m learning to use the command-line Subversion (1.8.13 64-bit Win, SLIKSVN) by reading the book online and doing some tests. I followed the quick-start guide for some experiments: https://subversion.apache.org/quick-start The first time around went spotless. But the second time when I wanted to create another repo for another project I get the following error message: svn: E235000: In file '..\..\..\subversion\libsvn_subr\dirent_uri.c' line 2307: assertion failed (svn_uri_is_canonical(url, pool)) when I execute the part that makes trunk, branches and tags subdirectories. That opens a dialog window for the error as well. Does anyone have any idea what I’m doing wrong here? Can you please show exactly what you typed on the command line when this happened? Antti Simola PS: There’s a typo in quick-start guide as the first “ is missing from the tags subdirectory address. Fixed, thanks.
RE: API accessing property diff of svn:mergeinfo
-Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: woensdag 6 mei 2015 14:49 To: users@subversion.apache.org Subject: Re: API accessing property diff of svn:mergeinfo On 06.05.2015 14:20, Bernhard Haumacher wrote: Hi Branko, On 06.05.2015 08:24, Bernhard Haumacher wrote: ... I'd like to analyze the diff of the svn:mergeinfo property (what other revisions were merged into some branch in a commit). ... ISVNClient.getMergeinfoLog should give you that information. The upcoming 1.9 release will have http://s.apache.org/pVj which allows you to limit the revision range. I tried out your suggestion, but it seems that it cannot be used for my purpose: I'm not interested in the merged revisions limited to those revisions that were merged from a specific merge source (for using the getMergeinfoLog() API, I do not have the `mergeSourceUrl` info): {{{ getMergeinfoLog(Mergeinfo.LogKind kind, String pathOrUrl, Revision pegRevision, String mergeSourceUrl, Revision srcPegRevision, Revision srcStartRevision, Revision srcEndRevision, boolean discoverChangedPaths, Depth depth, SetString revProps, LogMessageCallback callback) }}} What I'm interested in is the combination of all merge sources plus merged revisions that were merged within a single commit. At the command line, this information can be retrieved with {{{ svn diff --depth empty -crev url of branch }}} resulting in e.g.: {{{ Eigenschaftsänderungen: . ___ Modified: svn:mergeinfo Zusammengeführt /trunk:r161790 Zusammengeführt /branches/x:r160492 Zusammengeführt /branches/y:r185821 }}} Unfortunately, I cannot access this information using javahl in a structured way?! You can call ISVNClient.getMergeinfo twice with the same path and different revisions and calculate the difference of the returned Mergeinfo structures. That's just a hash+list intersection. In AnkhSVN I usually skip the diff apis and just obtain the whole files ('svn cat FILE' 'svn cat FILE@BASE') and properties ('svn proplist FILE' 'svn proplist FILE@BASE) and do the calculations myself. That way I also have access to what is not changed. Specifically for svn:mergeinfo you might be better of using the dedicated apis (which in many cases contact the server), but for all other properties I would guess just obtaining the values and explicitly apply further processing yourself is most likely far more future proof. Bert
Re: Cannot checkout or clean up using 1.9 dev build
I’m not sure if the \\?\ format is supported in the new rename api(as this is an option in certain publi apis and not a low level supported format), but it should certainly be used in the fallback codepath where the normal rename is tried, like hiw it is in apr. But if the new api fails with the limit, it is quite likely that it supports the \\?\ format. Some more recent new in Windows 8+ apis just dropped the path length limit and therefore don’t support the \\?\ format… but that doesn’t apply here as this api was new in Vista. I hope somebody looks at this earlier, but I’ll will look into this early next week. Bert Sent from Windows Mail From: Ivan Zhakov Sent: Tuesday, April 28, 2015 9:07 AM To: Benjamin Fritz, Bert Huijben Cc: 'subversion' On 27 April 2015 at 21:35, Benjamin Fritz fritzophre...@gmail.com wrote: Apparently I'm not subscribed to get list emails; please CC me on future responses. I had to get this message from the archive :-) Branko Čibej wrote: On 27.04.2015 18:06, Benjamin Fritz wrote: I get the following error when I try to check out a working copy from my repository at work (exact path names obfuscated but length unchanged, in case it matters It probably does matter ... FWIW, I believe you did change the length of the file name, the workqueue record says 234 chars but the name in the record is 240; still, that shouldn't be an issue. Oops. You're right. My actual directory has only 3 characters where I replaced with Prog in the path string. Still, those 6 fewer characters are probably irrelevant. ), leaving a partially downloaded working copy: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. The full path of the file would be 281 characters long, which is more than Windows' limit of 260. But Subversion goes to a lot of trouble to avoid the path limit ... I wonder what's going on here. It seems Windows specific implementation of svn_stream__install_stream() doesn't prepend path with \\?\ for long names. Replacing svn_utf__win32_utf8_to_utf16() call with svn_io__utf8_to_unicode_longpath() should fix the problem, but I didn't try yet. Bert, is it intentional behavior or just small typo? -- Ivan Zhakov
RE: Dealing with very old repo format (version 1)
-Original Message- From: Andrew Reedick [mailto:jreed...@incomm.com] Sent: dinsdag 28 april 2015 23:03 To: users@subversion.apache.org Subject: Dealing with very old repo format (version 1) Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/re p os.h - Formats 0, 1 and 2 were pre-1.0. There are repository versions and database versions (format files are in repos/ and repos/db/). It looks like he is talking about the db format, which is documented in the filesystem backends. Bert
RE: building SVN trunk on Windows fails on python gen-make.py
-Original Message- From: Stefan Hett [mailto:ste...@egosoft.com] Sent: woensdag 22 april 2015 15:59 To: 'subversion' Subject: building SVN trunk on Windows fails on python gen-make.py Hi, I just tried to build https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo- normalizer on Windows following the INSTALL file documentation up to the point where the make file is being generated. Using this call: python gen-make.py -t vcproj --with-zlib=..\zlib --with-apr=..\apr --with-apr-util=..\apr-util --vsnet-version=2010 I'm now getting the following error: Traceback (most recent call last): File gen-make.py, line 325, in module main(conf, gentype, skip_depends=skip, other_options=rest.list) File gen-make.py, line 62, in main generator = gen_module.Generator(fname, verfname, other_options) File build\generator\gen_vcnet_vcproj.py, line 36, in __init__ 'vcnet-vcproj') File build\generator\gen_win.py, line 83, in __init__ self.find_libraries(True) File build\generator\gen_win_dependencies.py, line 286, in find_libraries self._find_apr() File build\generator\gen_win_dependencies.py, line 395, in _find_apr bin_files = os.listdir(dll_dir) FileNotFoundError: [WinError 3] The system cannot find the path specified: '..\\apr\\bin' Looking at the apr-directory I downloaded/extracted, there's no apr/bin-directory. I downloaded the following APR-source package (1.5.1): http://mirror.serversupportforum.de/apache//apr/apr-1.5.1-win32-src.zip Did I get the wrong one? Or did I miss some step? Subversion expects that you already build apr before using it as a source of binaries to link against. It is not going to build apr for you. Building APR would have created this bin directory. (A patch to produce a nicer error message would be welcome :)) There are other scripts that may help you building Subversion and all dependencies. I maintain one such script as part of SharpSvn (Repository: https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports ; username guest; no password). This script uses NAnt, and is used to produce the publicly available binaries for SharpSvn and SlikSvn. Somewhere in the Subversion repository there is a perl script that should also be able to help with building on Windows, but I don't have experience with that script. Bert
RE: The XML response contains invalid XML
-Original Message- From: OlePinto [mailto:olepinto+...@gmail.com] Sent: woensdag 22 april 2015 16:25 To: users@subversion.apache.org Subject: RE: The XML response contains invalid XML Bad news: it has happened again. I haven't installed anything, or changed any setting since yesterday. Right now I don't have the needed time to redo the TCP reset + restart and try again, just for the sake of knowing if it would work again for a while. If someone would like any information, traces or whatever, feel free to ask and I'll try to oblige. Just to be sure: you get this error during an update? Not during a commit? If it is during a commit: Are you committing to an xml file? Bert
RE: Tortoise Subversion Exception, Help Needed
Hi, This tells us that somehow your working copy has some invalid state stored. This specific error message was replaced with an error message that contains more data in December 2011 (backport to 1.7.x in r1213745), so I would recommend you to upgrade your Subversion client (read: TortoiseSVN). If possible I would recommend directly upgrading to 1.8.x as 1.7.x may be out of support within a few months. Most likely the actual problem has been fixed around that time as well as I haven't seen error reports for this specific error in years. Bert From: Shahbaz Akhter [mailto:shahbaz.akh...@spanservices.com] Sent: woensdag 22 april 2015 09:14 To: users@subversion.apache.org Subject: Tortoise Subversion Exception, Help Needed Hello Users, Please look into below issues I got during clean up ,Suddenly I ran into is this. I was doing clean up and I got below issue. Looking forward for your reply Regards, Shahbaz Akhter DISCLAIMER: This email message and all attachments are confidential and may contain information that is Privileged, Confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email to mailad...@spanservices.com mailto:mailad...@spanservices.com and destroy the original message. Opinions, conclusions and other information in this message that do not relate to the official of SPAN, shall be understood to be nether given nor endorsed by SPAN.
RE: The XML response contains invalid XML
-Original Message- From: OlePinto [mailto:olepinto+...@gmail.com] Sent: dinsdag 21 april 2015 12:20 To: users@subversion.apache.org Subject: Re: The XML response contains invalid XML We have finally fixed it, although we sadly do not really know what the problem was. The magic medicine has been: run /netsh int ip reset c:\filename.log/, reset, reconfigure the network, and done! So it seems it was a client problem, but I don't really know even what kind of problem it was. Did it help anyone else? What kind of virusscanner / firewall do/did you run on this machine? This command removes custom settings on the IP stack, which may include third party hooks. Adding this information to this thread may help resolve the problem in the future. There might be valuable information in the 'c:\filename.log' file created by running this command. Did you check that file? Bert
RE: Subversion Exception diff_editor.c 1626
This doesn't provide us enough information to reproduce your problem. (And 'large tree' is not well defined. For some users that could be thousand files, while for others that would be hundreds of thousands of files) To reproduce and fix your problem we need more information: In this case interesting information might include: Do you have externals in this working copy? Do you use a normal Subversion server? Or something that just simulates Subversion. E.g. GitHub, Codeplex, SvnBridge? Are there incomplete nodes in your working copy (See: svn status) But really we could use as much information as possible to reproduce your problem. Bert From: Tony Hailes [mailto:tony.hai...@ttp.com] Sent: vrijdag 17 april 2015 16:48 To: users@subversion.apache.org Subject: Subversion Exception diff_editor.c 1626 Whilst doing diff with url on a large tree with some files branched from the trunk: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.11\ext\subversion\subversion\li bsvn_wc\diff_editor.c' line 1626: internal malfunction --- OK ---