Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Johan Corveleyn]

On Fri, Sep 13, 2024 at 3:27 PM Jörg Dalkolmo  wrote:
>
> Hello Johan,
>
> Thanx a lot for your annotations.
> Unfortunately I am not allowed, and for us there is no colleague available to 
> check the configuration on the SVN server if there are any path-based 
> authorization settings, and if yes, if they affect our part of the repository.
>
> Are there any other scenarios thinkable than failed authorization, which 
> could lead to the ‚server-excluded‘ entry in the presence column? Perhaps 
> interrupted connection from client to server, or something else?

Well, in theory there could be other reasons (all the client knows for
sure is that the server excluded this node). But in practice, as far
as I know, failed path-based authorization is the only reason for
server-exclusion that has been implemented in the standard SVN server.

Specifically, an interrupted connection cannot cause 'server-excluded'
nodes. Those would get a 'not-present' (for files) or 'incomplete'
(for directories) status in the wc.db, as far as I remember.

-- 
Johan

Re: Incomplete checkout into empty directory, presence of nodes are 'server-excluded'

[Johan Corveleyn]

On Fri, Sep 13, 2024 at 9:40 AM Jörg Dalkolmo  wrote:
> Hello Nathan!
>
> Thank you very much for the quick and very valuable answer. I had searched 
> the internet for ‚server-excluded‘ before and often ended up somewhere in the 
> subversion source code, where ‚authz‘ is mentioned, so your hint encourages 
> me, that some kind of selective permissions for the omitted dirs and files in 
> the repository are the key for understanding the effect.
>
> Subversion in our environment is hosted on a Linux system with apache web 
> server; the clients are all TortoiseSVN on Windows servers, target 
> directories for the working copies are administrative shares on those servers.
> In one of our experiments we had the - for us - strange effect that for one 
> target directory on one server all files and dirs were checked out, for 
> another target directory on another server always the same files and dirs 
> were omitted. That is:
>
> //winserver1/adminshare1$/targetdir1/   gets all dirs and files.
> //winserver2/adminshare2$/targetdir2/ does NOT get all dirs and files.
>
> I have to mention that I am NOT the user that performs all the tortoiseSVN 
> actions in our trials and I have no relevant experience with SVN, I am just 
> part of the team that ponders about this problem that drives us crazy.
>
> To cut a long story short, thank you very much again, I will encourage our 
> team members to pursue this path.

Hi Jörg,

Nathan is referring to the built-in "path-based authorization" feature
of SVN (where one can configure certain paths to be only accessed by
certain (groups of) users). This is not managed inside the Apache
httpd config, but in the path-based authorization file of SVN. This
can be either a normal file on the server or a file in the repository
itself (referenced by the AuthzSVNAccessFile or
AuthzSVNReposRelativeAccessFile directives in the httpd config).

See these sections in the "SVN book" for more info:
https://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
https://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir

So probably, some of the files or dirs under
//winserver2/adminshare2$/targetdir2/ are not-authorized for your user
(as specified in the path-based authz file on the server).

-- 
Johan

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Johan Corveleyn]

On Sat, May 25, 2024 at 12:12 AM Williams, James P. {Jim}
(JSC-CD4)[KBR Wyle Services, LLC] via users
 wrote:
>
> > Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR 
> > Wyle Services, LLC] via users :
>
> > You previously mentioned Subversion 1.14.1, is that on the server or on the 
> > client?
>
> I'm using 1.14.1 on both the client and server.
>
> > Still it would be interesting to compare just to rule out a problem within 
> > the repository. You can use svnserve directly or tunneled over SSH, see the 
> > Subversion book:
>
> With svnserve 1.14.1, I see no problems.  Checkouts complete every time.  I'm 
> not sure what to conclude about that.  It's a different protocol, so it 
> doesn't necessarily exonerate the client or the network.
>
> > >   #0  epoll_wait   /usr/lib64/libc.so.6
>
> > Waiting for a reply from the server ... ?
>
> Yeah, that'd be my guess.  When the hang occurs, I've got about 90% of the 
> working copy checked out.  I expect the client is waiting for more bytes to 
> arrive on the socket.
>
> > Do you see any activity on the server (CPU / disk) during this time?
>
> The server is well-behaved throughout all of my tests.  It shows no CPU spike 
> or log messages hinting that it's noticed a problem.

That's why my bet is still on "something between client and server"
(proxy, reverse-proxy, security scanning soft, ...) that messes with
the network transfer (http or https). That would explain the symptoms
you're seeing (client hangs waiting for network (and sometimes
crashes), server has nothing to do and doesn't report anything
special).

-- 
Johan

Re: GUI interface to Subversion via web browser?

[Johan Corveleyn]

On Fri, May 24, 2024 at 3:18 PM Mark Phippard  wrote:
> On Fri, May 24, 2024 at 9:11 AM Johan Corveleyn  wrote:

> > What lots of people these days are looking for (myself included) is a
> > modern "Code Forge" ...
>
> Beanstalk has always seemed like a solid service:  https://beanstalkapp.com/
> And Assembla still exists: https://get.assembla.com/
>
>
> > Seriously, if we'd ever start such a sub-project under the Apache
> > Subversion umbrella one day, I'd be interested in joining the effort
> > :-).
>
> The Apache project for this is Allura: https://allura.apache.org/

Thanks for these suggestions Mark. Interesting to look around a bit.

Concerning Allura: I find it quite strange that this project is
completely disconnected from the Subversion project, being both Apache
projects. We don't know each other at all. This is the first time the
name "Allura" is mentioned on users@s.a.o ever since I was subscribed
(since 2010). On dev@s.a.o it was mentioned only once in 2013, during
a discussion on where to move the issue tracker. Sounds like marketing
/ making contact with potentially interested communities was not high
on the agenda.

-- 
Johan

Re: GUI interface to Subversion via web browser?

[Johan Corveleyn]

On Wed, May 22, 2024 at 10:06 AM Bo Berglund  wrote:
> I am running an SVN server on an Ubuntu 20.04 LTS system and I have the Apache
> connection so I can access it via its web interface.
>
> This works but is *very limited* in functionality, so I am looking for some 
> kind
> of GUI interface that can be added to my Ubuntu SVN installation and gives me
> functionality to view file revisions, logs etc and also diff revisions using 
> the
> web view.

What lots of people these days are looking for (myself included) is a
modern "Code Forge" [1][2][3], like GitHub/Lab/... or like the Forgejo
project [4] with its cloud-hosted platform Codeberg [5], but then for
Subversion.

I'd like a modern web interface (hostable on-premise or in the cloud)
that includes:
- Version control repositories (and management thereof)
- Online viewing, searching, diffing, ... (like ViewVC)
- Online editing, committing directly from the web interface
- Ability to manage patches aka pull requests
- Mailing lists and Forums
- Notification system (with ability to individually configure "watch" patterns)
- Issue tracker
- Code reviews
- Wiki
- General (plugable) "Actions" framework
- CI system with buildagents / bots
- Artifact repository
- Enterprise level user management
- ...
- Also accessible from mobile devices of course

Oh, and if possible it should flexibly integrate with external systems
that may already be present in your environment, like if you have a
JIRA issue tracker or wiki or ... you would want to integrate that one
instead of the "default / reference" implementation.

I'm dreaming of course, but wouldn't that be nice?

Seriously, if we'd ever start such a sub-project under the Apache
Subversion umbrella one day, I'd be interested in joining the effort
:-).

[1] https://www.wikidata.org/wiki/Wikidata:WikiProject_Informatics/Forges
[2] https://en.wikipedia.org/wiki/Forge_(software)
[3] https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities
[4] https://forgejo.org/
[5] https://codeberg.org/

-- 
Johan

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Johan Corveleyn]

On Wed, May 15, 2024 at 12:41 AM Williams, James P. {Jim}
(JSC-CD4)[KBR Wyle Services, LLC] via users
 wrote:
> > From: Nico Kadel-Garcia 
> > Sent: Saturday, May 11, 2024 10:47 AM
...
> > > I've tried with multiple repos of different sizes and ages.  The
> > smaller repo I mentioned has about 150 files in trunk, mostly 50 KB or
> > smaller, and about 500 revisions.  A larger repo with the same problems
> > has about 5000 files in trunk and 10,000 revisions.
> >
> > That *hints* at an httpd tuning issue, but I'm not sure. Check the httpd
> > logs?
>
> The httpd logs show no signs of a problem.  Success and failure cases look 
> the same in the logs.

In your initial post your mentioned:

>>> svn 1.10.2 was failing the same way before we upgraded to 1.14.1 as a 
>>> possible fix.

So the problem isn't new after the upgrade.
BTW: as Daniel asked: You previously mentioned Subversion 1.14.1, is
that on the server or on the client?

Regardless, since the issue manifests on the client-side by hangs and
crashes while waiting for / processing data from the server (hangs
inside libsvn_ra_serf), I'd suggest also to investigate whether there
is something in between your client and your server that might be
interfering. A proxy or reverse proxy perhaps? Or some security
software on the client that interferes with the network (as some
antivirus suites do on Windows)? If so, try to bypass it (or disable /
create an exclude rule), as a diagnostic step to see whether this
might be the cause.

-- 
Johan

Re: [EXTERNAL] Re: Moved file resolution fails

[Johan Corveleyn]

On Thu, Feb 15, 2024 at 7:32 PM Sands, Daniel N. via users
 wrote:
...
> On a further note, my real repo has 260 moves due to source tree
> restructuring.  There were 290 deletions.  The current move detection
> algorithm is an O(n^2) search to find all moves, where it ends up
> querying the SVN server 260*290 times for merge info, per file
> conflict.  Perhaps it would be a good cost savings to cache the merge
> info for each file during the search, so that there are O(n) trips to
> the server and everything else is resolved locally?

I don't know the tree conflict resolver code very well, so I'm not
sure if it works that way, with O(n^2) calls. But it's definitely a
good suggestion / idea to look closer into those calls and trying some
strategies to optimize things.

Would you have time / be able to dig deeper and try some things in the
code yourself, maybe come up with a patch [1], or a proposal / idea in
pseudo-code (best sent to d...@subversion.apache.org for discussion)?
These days the SVN community is completely volunteer-driven, so any
help is more than welcome :-).

[1] https://subversion.apache.org/docs/community-guide/general.html#patches

-- 
Johan

Re: Moved file resolution fails

[Johan Corveleyn]

On Wed, Feb 14, 2024 at 11:00 PM Sands, Daniel N. via users
 wrote:
>
> >
> Okay, I finally figured out how to trip up SVN:
>
>
>
>
> > > I built my own experiment which I'll try to reconstruct here:
> > > mkdir test
> > > mkdir test/foo
> > > mkdir test/foo/bar
> > > mkdir test/baz
> > > echo "a" > test/foo/bar/example.c
> > > svn import test svn+ssh://theserver/var/svn/playground/test
> > > rm -rf test
> > > svn co svn+ssh://theserver/var/svn/playground/test
> > > cd test
>
> Now I did something that SVN apparently doesn't like:
>
> svn mv foo/bar/example.c baz
> svn cp . ^/playground/test2

Hm, that's quite an atypical set of operations. The first command
makes a local move in the 'test' working copy (without committing that
move), and then creates a branch-from-WC with a local modification in
it. Creating a branch from a working copy is a bit special, precisely
because it may carry along local mods that are not committed to the
branch source. This is translated by SVN into copy of the branch
source, with the local modifications injected "on top". If you 'svn
log -v' the revision that created that branch I think you'll see
something like this:

A + /playground/test2 (from /playground/test:XXX)
D/playground/test2/foo/bar/example.c
A + /playground/test2/foo/baz/example.c (from
/playground/test/foo/bar/example.c:XXX)

As you can see, the Deleted file is different from the "copyfrom" of
the Added file (which is copied from the original pre-branch
location). So the simple logic in the tree conflict resolver cannot
detect that D-A pair as a move (it is not smart enough to see that you
created test2 from test in the exact same revision). In theory, this
should be a supportable scenario, but it'll take some special handling
I think.

When I create branches, I usually do so purely in the repository, by
copying URL's (either from TortoiseSVN's repo browser, or by 'svn cp
URL1 URL2' -- keep in mind that the caret for SVN is a shortcut for
the repo-root-URL). That way the branch is a "clean" copy from
something else in the repository. I prefer to keep other changes
separate from the branch-creation, so either I commit them before or
after creating the branch.

The only exception I make to this is when creating tags for release,
where I commit a "version-number" change in some file together with
creating the tag. That's how the Subversion project creates its
release tags too, see for example
http://svn.apache.org/viewvc?view=revision&revision=1914487

-- 
Johan

Re: Moved file resolution fails

[Johan Corveleyn]

On Mon, Feb 5, 2024 at 8:57 PM Sands, Daniel N. via users
 wrote:
> > Oh yes, a lot has changed since 1.8 (which is EOL for a long time
> > already). Actually, the major improvement came client-side in version
> > 1.10, with the interactive tree conflict resolver [1]. This uses a
> > lot
> > of information from both working copy and repository to figure out
> > what the sensible options are in case of a tree conflict, and
> > attempts
> > to resolve some of those automatically. You should upgrade your
> > clients to _at least_ 1.10 to have a reasonable experience with tree
> > conflict situations. After 1.10 lots of bugfixes and improvements
> > have
> > been made to the tree conflict resolver, so I would recommend to go
> > for 1.14 (which is actually the only supported version ATM [2]).
>
> Yeah I'm using RHEL8 which currently supports 1.10.  I also compiled
> the latest version of 1.14 to see if it had any improvement.
> Unfortunately they all fail the same way in attempting to resolve file
> moves.

Sorry for the late response, but I lack the time to dig deeper. It
should work as in the example (test) that Stanimir Stamenkov posted
earlier in this thread.

Is your case the same as in the DERBY issue that Stanimir referenced
[1]? Maybe you can narrow it down to a test with a repository from
scratch, or narrow down to a specific step that might have confused
the tree conflict resolver?

Perhaps someone else on this list has some more ideas / can zoom in on
the case in [1]?

[1] 
https://issues.apache.org/jira/browse/DERBY-7144?focusedCommentId=17582731&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17582731

-- 
Johan

Re: Moved file resolution fails

[Johan Corveleyn]

On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users
 wrote:
>
> Fri, 2 Feb 2024, /Sands, Daniel N./:
>
> >> As far as I'm aware this is all client-side behavior - nothing to do with 
> >> the server. Resource move/rename
> >> has always been recorded as a _Delete_ of the original path and a _Copy_ 
> >> (Add) from the previous path
> >> revision. It could be I'm missing something here, also.
> >
> > As of 1.8, it now knows if an add or delete was due to a move.  For 
> > example, on my RHEL8 system that has 1.10, a move will look like this in 
> > status:
> >
> > Dfoo/bar
> >> moved to baz/bar
> > Abaz/bar
> >> moved from foo/bar
> > [...]
>
> O.k.  I've now looked it up:
>
> "Working copy records moves as first-class operation"
> 
>
> Note the "working copy" (client-side):
>
> > Limitations:
> >
> >   * Moves are recorded as such only within the working copy. The link
> > between the copy and the delete is established only when a local move
> > operation is performed, and is lost upon commit. The committed revision
> > will show a copy and a delete, instead of a move.
>
> It is unclear to me whether the move info is retained in the source
> working copy after the commit, but is likely:
>
> > Known issues:
> >
> >   * Tree conflicts involving replacements are currently not detected
> > when updating a moved file or directory (see issue #4318).
> > 
>
> At the end:
>
> >   * Tree conflicts flagged by svn merge cannot be automatically resolved
> > yet. This will be addressed in a future release.
>
> If I understand correctly, not much has changed related to merging
> with/into moved files.

Oh yes, a lot has changed since 1.8 (which is EOL for a long time
already). Actually, the major improvement came client-side in version
1.10, with the interactive tree conflict resolver [1]. This uses a lot
of information from both working copy and repository to figure out
what the sensible options are in case of a tree conflict, and attempts
to resolve some of those automatically. You should upgrade your
clients to _at least_ 1.10 to have a reasonable experience with tree
conflict situations. After 1.10 lots of bugfixes and improvements have
been made to the tree conflict resolver, so I would recommend to go
for 1.14 (which is actually the only supported version ATM [2]).

You are of course free to discuss and seek help on this list for older
versions, but to me it makes no sense to complain about 1.8's
client-side tree conflict handling, when 1.10 and 1.14 perform so much
better in this regard.

Note also that:
- Even with 1.14, the information that you showed above about a move
in your working copy (with the "> moved to" and "> moved from"
details) is not transferred to the repository. After committing, the
repository (server) does not keep the same information (it does have
the "copyfrom" information in the Add, but that's it).
- So when looking at such a commit, or checking out and verifying
history, you cannot get the same ">moved to" and ">moved from"
information, because it is simply not there.
- Despite this, the tree conflict resolver in 1.10+ is in most cases
able to match deletes and adds-with-copyfrom to deduce they are
probably a move, and uses this kind of information to make a good
guess about what needs to go where. It seems to work out fine in
practice in most cases.

[1] https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver
[2] https://subversion.apache.org/docs/release-notes/#supported-versions

-- 
Johan

Re: Can't connect to github anymore

[Johan Corveleyn]

On Sat, Jan 13, 2024 at 8:28 PM roger21  wrote:
>
> hey there
>
> suddenly i can't connect to github anymore (svn update or svn checkout)
>
> i get the following error:
>
> svn checkout https://github.com/roger21/fract.git
> svn: E170013: Unable to connect to a repository at URL
> 'https://github.com/roger21/fract.git'
> svn: E160013: '/roger21/fract.git' path not found

Apparently, GitHub has removed its support for the Subversion protocol:

https://github.blog/changelog/2024-01-08-subversion-has-been-sunset/

-- 
Johan

Re: Adjust revision in new repository

[Johan Corveleyn]

On Fri, Sep 1, 2023 at 2:47 PM Magnus Lyrberg
 wrote:
>
> On Fri, Sep 1, 2023 at 2:05 PM Yasuhito FUTATSUKI
>  wrote:
> >
> > Although it makes a bunch of dummy empty commit, a dump file contains
> > empty revisions can increase youngest revision number keeping content
> > of the tree empty.
> >
> > e.g. A shell script to make a repositoy contains
> > 10 empty revisions:
> > [[[
> > #!/bin/sh
> >
> > repos_uuid='c68ffc52-e6c1-4053-9b3b-6e67a0e223f2'
> > rev0_date='2023-09-01T10:22:50.036256Z' # This should be just 27 letters.
> > number_of_commits=10
> >
> > produce_dump()
> > {
> > cat < > SVN-fs-dump-format-version: 2
> >
> > UUID: ${repos_uuid}
> >
> > Revision-number: 0
> > Prop-content-length: 56
> > Content-length: 56
> >
> > K 8
> > svn:date
> > V 27
> > ${rev0_date}
> > PROPS-END
> >
> > DUMP_HEAD_END
> >
> > rev=0
> > while [ $rev -lt $1 ]; do
> > rev=$(($rev+1))
> > cat < > Revision-number: $rev
> > Prop-content-length: 10
> > Content-length: 10
> >
> > PROPS-END
> >
> > REV_END
> > done
> > }
> >
> > svnadmin create new_repo
> > produce_dump "${number_of_commits}" | svnadmin load -q new_repo
> > svnadmin info new_repo
> > ]]]
>
> Thank you. This is very similar to our current solution. It would
> however be nice to avoid a lot of empty commits, hence my
> engagement in this list asking for alternative solutions.
>
> But perhaps there are none.

I'm not sure, but it sounds like that would be quite a hack, and I
don't think it will be possible.

The repository still has to give a sane reply if a user asks for "svn
update -r 2" or "svn ls https://server/svn@1";. If those revisions
really don't exist, what should the server answer? So I don't think
you can avoid creating those revisions, but you can leave them empty,
as suggested.

What is the problem in having those empty revisions anyway? I assume
they hardly take up any diskspace. If that's the only price you have
to pay for having this "old cruft removed but still original
rev-numbers repository", it sounds like a good deal to me (and it's
still a correctly working repository that behaves as designed).

-- 
Johan

Re: Adjust revision in new repository

[Johan Corveleyn]

On Fri, Sep 1, 2023 at 11:05 AM Magnus Lyrberg
 wrote:
> On Thu, Aug 31, 2023 at 4:51 PM Johan Corveleyn  wrote:
> > On Thu, Aug 31, 2023 at 2:21 PM Magnus Lyrberg
> >  wrote:
> > >
> > > Hello.
> > >
> > > I'm not subscribed so please CC me in any response.
> > >
> > > Is there some other way besides making a bunch of dummy commits
> > > to reach our current revision number in a new repository?
> >
> > Maybe you can give svndumpfilter [1] a try to filter out the "cruft"
> > (after creating a dump file from the original repository). It has
> > options like:
> >
> > --drop-empty-revs
> > If the current filtering invocation causes any revision to be
> > empty (i.e., the revision causes no change to the repository), removes
> > these revisions from the final dump file.
> >
> > --renumber-revs
> > Renumbers revisions that remain after filtering.
> >
> > which seems to indicate that by default (not using these options) it
> > will keep the original revision numbering (even if you filter out
> > entire revisions so they become empty).
> >
> > You'll have to create a dump file first, by using 'svnadmin dump' if
> > you have file access to the repo, or 'svnrdump dump' if you only have
> > remote access. Then svndumpfilter it, and 'svnadmin load' it into a
> > new repository. Maybe first try it with a small test sample to see if
> > it works as expected.
>
> Unfortunately 'svnadmin load' ignores the revision information in the dump
> file. If the new repository is empty it will start with revision 1
> regardless of
> what the dump file says.
>
> I made a quick test to verify this:
>
> svnadmin load /var/svn/repo2 < partial_dump.dump
> <<< Started new transaction, based on original revision 7
>  * adding path : test.txt ... done.
>
> --- Committed new rev 1 (loaded from original rev 7) >>>

But what is partial_dump.dump? Can you show us the exact commands you
used to create it?

Did you create this by dumping only revisions 7 and 8 from the
original repository, as in 'svnadmin dump /path/to/orig_repos -r7:8 >
partial_dump.dump'? In that case, it is expected to behave like you
described.

Or did you create it by dumping the entire repository, and then
svndumpfilter-ing out the unneeded stuff, as in 'svnadmin dump
/path/to/orig_repos | svndumpfilter exclude /path/to/unneededstuff >
partial_dump.dump'?

It is the last technique that I was suggesting, and I would expect
that to retain all the existing revision numbers (some revisions might
become empty revs because of the filtering, but they should still
"count").

-- 
Johan

Re: Adjust revision in new repository

[Johan Corveleyn]

On Thu, Aug 31, 2023 at 2:21 PM Magnus Lyrberg
 wrote:
>
> Hello.
>
> I'm not subscribed so please CC me in any response.
>
> We have, most unfortunately and for historical reasons,
> a very hard dependency on the revision number in subversion.
>
> Our current repository has become large and unwieldy, and we
> want to move to a fresh repository. The history is not very important,
> we are ok to start from scratch, but loosing the revision number
> would be incredibly costly.
>
> Is there some other way besides making a bunch of dummy commits
> to reach our current revision number in a new repository?

Maybe you can give svndumpfilter [1] a try to filter out the "cruft"
(after creating a dump file from the original repository). It has
options like:

--drop-empty-revs
If the current filtering invocation causes any revision to be
empty (i.e., the revision causes no change to the repository), removes
these revisions from the final dump file.

--renumber-revs
Renumbers revisions that remain after filtering.

which seems to indicate that by default (not using these options) it
will keep the original revision numbering (even if you filter out
entire revisions so they become empty).

You'll have to create a dump file first, by using 'svnadmin dump' if
you have file access to the repo, or 'svnrdump dump' if you only have
remote access. Then svndumpfilter it, and 'svnadmin load' it into a
new repository. Maybe first try it with a small test sample to see if
it works as expected.

[1] https://svnbook.red-bean.com/nightly/en/svn.ref.svndumpfilter.html
-- 
Johan

Re: Maintaining a SVN 1.7 mirror without network access

[Johan Corveleyn]

On Thu, Jun 8, 2023 at 2:54 AM Colcord, Scott via users
 wrote:
>
> Thanks to all for their insights.
>
> On Saturday, June 3, 2023 2:41 PM, Andreas Stieger wrote:
> > No you cannot do it in the way you described, and your approach is 
> > incorrect. Not for svn, but IT.
>
> Just to be clear, the status quo was not my idea; I'm just trying to work 
> with it.
>
> > For subversion: If you alter the history of the repository in any way, all 
> > working copies
> > will be invalidated. So even if you repeat the steps described, you will 
> > need to get new
> > working copies.
>
> Right; the need to re-fetch working copies after an update is understood. 
> It's been annoying but manageable because the mirror is read-only other than 
> the single adjustment commit - I don't need to worry about anyone having 
> pending changes in their working copy on that network.
>
> > Please separate immutable history from the location-specific configuration.
>
> I would love to, but...see below.
>
> On Sunday, June 4, 2023 4:06 AM, Nico Kadel-Garcia wrote:
> > Do you gain anything from running these distinct repos, instead of a
> > primary repo, a backup mirror, and a DNS or proxy managed name
> > for the URL or hostname mentioned in the svn:externals? Rather than
> > pointing so directly to one or the other repo?
>
> Everything is on a single server with the same name on each network, so I can 
> just use externals paths with no server name needed.  However some of the 
> externals required by my project are located at different paths on the 
> mirror's network. For example, /foo/tags/public_10 versus 
> /foo/tags/private_10, or /components/foo vs. /private/components/FOO. These 
> inconsistencies are unfortunately locked in; I do not have the ability to 
> relocate these projects on either network, and I'm not aware of any way to 
> embed more complex logic in the externals checkout process.
>
> My current process for mirror updates involves reloading the repository, 
> running a script that commits the adjustment to svn:externals, and then 
> having everyone re-fetch their working copies. If anyone has any suggestions 
> for how to better manage this situation within the limits I have to live 
> within, I would be happy to hear it.
>

I'd suggest moving towards separate scripts or other tools, outside of
SVN, instead of svn:externals, for stitching things together. For very
simple and straightforward "arrangements", svn:externals might be a
good fit, but if things start getting more complex you're often better
off building something outside of SVN. That way you can implement more
complex logic as much as you want for this.

An example from my own experience: for dependencies between our Java
modules we first started by using svn:externals in some top-level
applications (listing all necessary sub-modules), so you could create
a nice working-copy to have everything. A bit later we implemented a
script to adjust those svn:externals if dependencies changed. But
after a while it became more and more complex, and the svn:externals
started to become a hindrance. So at some point we created a python
script to stitch everything together with plain svn checkout and
update commands etc, and ditched the svn:externals. Things have been
much easier and simpler since then :-).

-- 
Johan

Re: Property svn:ignore reported as inherited by svn proplist

[Johan Corveleyn]

On Mon, Mar 20, 2023 at 11:56 PM Daniel Sahlberg
 wrote:
>
> Den mån 20 mars 2023 kl 21:09 skrev Xsawer xsawer :
>>
>> Both are correct in my eyes, just the information, that svn:ingore is listed 
>> by svn propget/proplist when using parameter --show-inherited-props, is 
>> missing. I would write something like:
>> ...the patterns found in the svn:ignore property apply only to the directory 
>> on which that property is set, and not to any of its subdirectories, however 
>> it will still be listed by svn propget/proplist commands on subdirectories 
>> when using parameter --show-inherited-props.
>
>
> As this is a change to the book, it should probably be discussed on the 
> svnbook-dev list (see 
> https://mailman.red-bean.com/mailman/listinfo/svnbook-dev).
>
> I'm not personally convinced since the inheritance (or rather 
> non-inheritance) is discussed in the section about inheritable properties 
> (https://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.inheritable),
>  that section is prior to the section about ignoring unversioned items. But 
> we can have that discussion on the correct mailing list.
>

For some background information about the how and why, you may also
want to take a look at:
https://cwiki.apache.org/confluence/display/SVN/InheritedProperties

And if you really want to do some archeology, dig into the mailinglist
archives from around 2011 / 2012 :-).

-- 
Johan

Re: Subversion 1.14.1 and serf 1.3.9

[Johan Corveleyn]

On Thu, Oct 21, 2021 at 2:00 PM Daniel Sahlberg
 wrote:
>
> Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski :
>>
>> I’m using Virtual SVN, server shows accepted connection with code 200.
>>
>>
>>
>> I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib 
>> 1.2.7 (that was used by me some time ago) and it seems that it works OK, now.
>>
>> Very strange problem with assembly code in zlib 1.2.11.
>>
>>
>>
>> Tomek L
>
>
> Thanks for reporting back! That is indeed a very strange problem, even more 
> so since TortoiseSVN seems to use zlib 1.2.11.
>
> Maybe you can check the same action using TortoiseSVN?
>
> Kind regards,
> Daniel

Indeed, zlib's assembly code seems to be unreliable on Windows. When I
build / test (for signing new releases) on Windows, I never use the
assembly build of zlib anymore (ever since I ran into problems with it
years ago).

I suppose TortoiseSVN also does not use the assembly build of zlib.

-- 
Johan

Re: SVN hook

[Johan Corveleyn]

On Wed, Aug 25, 2021 at 7:36 AM Philipp Mueller
 wrote:
> Hello,
>
> I´m new to this topic and I have quite a hard time getting into programming 
> hooks for my problem. I need a hook which can distinguish between three 
> different user groups:
> Group A: can do anything (delete tags and trunks, commit without comment)
> Group B: can commit to tags and delete tags/branches; CANNOT delete trunks 
> and CANNOT commit without comment
> Group C: can commit to tags; CANNOT change or delete anything
>
> Is there any way to do that?

I've used a predecessor of these pre-commit hook scripts for
implementing similar checks at my company:
https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook

They work really well and are quite easy to configure IMHO.

HTH,
-- 
Johan

Re: message "disk I/O error" when TurtoiseMerge is open (after update) and another updating by script/batch is done

[Johan Corveleyn]

On Mon, Jul 12, 2021 at 10:32 PM Daniel Sahlberg
 wrote:
> Den mån 12 juli 2021 kl 17:02 skrev Nathan Hartman :
>> On Mon, Jul 12, 2021 at 6:44 AM Arbeiter Ansgar 
>>  wrote:
>>>
>>> after update an repository, i normally check actual changes (with 
>>> TurtoiseMerge) so this tool and the update window are open.
>>> when i then update again (by batch file) then i very often get this message:
>>>
>>> svn: E200030: sqlite[S10]: disk I/O error
>>>
>>> when i close TurtoiseMerge (and update window) before update again, then i 
>>> never noticed it.
>>> (i also checked for actually disk problems, but there are none)
>>>
>>> batch file:
>>> @echo off
>>> svn --version > nul
>>> if %ErrorLevel% gtr 0 (
>>>   echo Sources can't be updated because the SVN-client not found. Please 
>>> install the console tools TortoiseSVN.
>>> ) else (
>>>   svn up ..\..\Axxx
>>>   svn up ..\..\Cxxx
>>>   svn up ..\..\Dxxx
>>>   svn up ..
>>> )
>>>
>>> used versions:
>>>
>>> TortoiseMerge 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02
>>> libsvn_diff 1.14.1,
>>> apr 1.6.5
>>> apr-util 1.6.1
>>>
>>>
>>> TortoiseSVN 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02
>>> ipv6 enabled
>>> Subversion 1.14.1, -release
>>> apr 1.6.5
>>> apr-util 1.6.1
>>> serf 1.3.9
>>> OpenSSL 1.1.1i  8 Dec 2020
>>> zlib 1.2.11
>>> SQLite 3.29.0
>>>
>>> Mit freundlichen Grüßen / With kind regards
>>> i.A. Ansgar Arbeiter
>>> Graduate Engineer - Development
>
>
> I've tried to reproduce your problem but I can't. However you state that you 
> get the error "very often" so maybe I'm just not lucky enough to catch it.
>
>  Hello,
>>
>>
>> It sounds like one of the tools may be holding the working copy
>> database open and/or locked in some way against access by other
>> programs (e.g., a file system based locking, a SQLite EXCLUSIVE_LOCK,
>> etc).
>>
>> The error message "disk I/O error" may be misleading in this case;
>> i.e., it may not be an actual *disk* error, but rather inability to
>> open or operate on the database file for other reasons. (This error is
>> reported when the working copy's SQLite database reports SQLITE_IOERR.
>> The [S10] means the same thing as SQLITE_IOERR; it doesn't give any
>> more information. That is a generic code for a multitude of different
>> conditions.)
>>
>> It's probably just best to close the Tortoise windows when you want to
>> use the command line client; however maybe someone else on this list
>> will know a better answer. You could also try asking at the
>> TortoiseSVN mailing list (see [1] below) whether the Tortoise client
>> is expected to prevent simultaneous access by other clients, and if
>> so, whether there is a way to avoid that.
>
>
> As far as I know, TortoiseSVN never touch the working copy by it self but 
> only through calling Subversion's API. (I even checked the sources but I 
> couldn't "findstr" ("grep" in Unix-speech) anything related to sqlite).
>
> I seem to remember a similar question last year (?) where TortoiseSVN kept 
> some resources open until the window was closed. I meant to look into it but 
> never found the time. I think it was related to a temp file being held open, 
> but I can't find the mail right now.
>
> The svn command line client is doing one thing at a time (per process) 
> whereas in TortoiseSVN you might start one thing (for example an update), 
> then with that process still "alive" start other things, either in the same 
> process or as separate processes. I think (hope) that there are some 
> Subversion APIs that TortoiseSVN could call to cleanup things when whatever 
> it does is finished instead of relying on cleaning up things
>
> If I find time, I'll try to look at it and submit patches to TortoiseSVN. As 
> Nathan already wrote, you can also ask in the TortoiseSVN mailing lists [1].
>
>  [1] https://groups.google.com/g/tortoisesvn
>
> Kind regards,
> Daniel Sahlberg

Note that there is a config setting in the client-side "config" file
that might have some impact here (setting "exclusive locking" for the
SQLite database):

http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking

Also, look for "exclusive-locking" in this svnbook section:
https://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.config

Perhaps you could test if that setting has any impact on the problem
you're seeing.

-- 
Johan

Re: What is happening with a long merge with internet reliability

[Johan Corveleyn]

On Fri, Jun 25, 2021 at 12:54 AM John Abraham  wrote:
>
> I have some internet reliability issues on some clients which seems to cause 
> a big problem with 'svn merge’.  'Svn checkout' seems to be ok, it will 
> either fail (and can be manually restarted) or it will continue.  But 'svn 
> merge’ often just sits there, with no internet traffic, no disk access, no 
> CPU usage. My hypothesis is that this happens after it had some problem 
> connecting to the server, and rather than retrying consistently, or giving up 
> and throwing an error message, it just sits there bored for maybe 45 minutes 
> not knowing what to do.
>
> What would be a good way to test my theory? Does anyone have another theory?
>
> It’s a pretty big repo, 26GB, biggest file is 3GB, but the internet traffic 
> monitor today showed it stalling out after only ~10MB of traffic came down…

First thing to check: what version is your SVN client and your SVN server?
If not the latest, can your re-check with at least the latest client
version, and see if the problem is still there?

Just to rule out the possibility that it's a bug that has been fixed already.

-- 
Johan

Re: Unexpected behavior of svn log -r BASE:HEAD

[Johan Corveleyn]

On Thu, Jun 3, 2021 at 6:28 AM Yasuhito FUTATSUKI
 wrote:
>
>
> In article 
> 
> guillaume.brune...@gmail.com writes:
> > Den ons 2 juni 2021 12:47Yasuhito FUTATSUKI  skrev:
> >
> > > Hello,
> > >
> > > In article  > > a-...@mail.gmail.com>
> > > guillaume.brune...@gmail.com writes:
> > >
> > > > Hello,
> > > >
> > > > The command  svn log -r BASE:HEAD .  doesn't behave as I expect it to.
> > > > According to svn help log:
> > > >
> > > > Show the log messages for any incoming changes to foo.c during the
> > > > next 'svn update':
> > > >   svn log -r BASE:HEAD foo.c
> > >
> > > This help message seems innacurate.  'svn log -r BASE:HEAD' shows log
> > > messages from "BASE" revision to "HEAD" revision on foo.c including
> > > both revisions, where "BASE" is the revision number of an item in working
> > > copy and "HEAD" is the latest(or "youngest") revision in the 
> > > repository[1].
> > >
> > > [1] Version Control with Subversion (Nightly Build)
> > >Chapter 3. Advanced Topics > Revision Specifiers > Revision Keywords
> > >
> > > http://svnbook.red-bean.com/nightly/en/svn.tour.revs.specifiers.html#svn.tour.revs.keywords
> >
> >
> > Ah, thank you, I guess the help message should be fixed then?
>
> I have no idea about how accurate it should be in example section, and
> I can't also propose how it should be because of my poor English
> writing ability. However if you have some idea how it should be, please
> make a draft (or patch against subversion/svn/svn.c).
>
> > > Yet on my machine I have the following behavior:
> > > >
> > > >
> > > > > svn up
> > > > Updating '.':
> > > > At revision 103730.
> > > > > svn log -r BASE:HEAD .
> > > > 
> > > > r103730 | guillaumeb | 2021-06-01 09:35:24 +0200 (Tue, 01 Jun 2021) | 1
> > > line
> > > > some commit message
> > > > 
> > > > > svn up
> > > > Updating '.':
> > > > At revision 103730.
> > > >
> > > >
> > > > So svn log -r BASE:HEAD reported a log message for a change that was
> > > > already taken into account.
> > > > Is that a bug in svn or am I misunderstanding something? I would have
> > > > expected an empty result, given that there was no incoming change
> > > > during the next svn up.
> > >
> > > In this case, both of "BASE" and "HEAD" revisions are 103730, so it
> > > is equivalent to 'svn log -r 103730:103730', and in r103730, there
> > > is some changes in '.'.  That is why it showed the log message.
> > >
> >
> > Is there another way to get what is described in the help message? To show
> > the log messages for any incoming changes to foo.c during the next 'svn
> > update'. This is exactly what I was trying to do.
>
> One of obvious way is something like this (although this can't take
> multiple target paths):
> [[[
> #!/bin/sh
>
> # if This is not in your command search paths, please change it.
> svn=svn
>
> revision_base=`${svn} info -r BASE --show-item revision "$1"` || exit $?
> revision_head=`${svn} info -r HEAD --show-item revision "$1"` || exit $?
>
> # This check is needed to avoid "No such revision error"
> if test "${revision_base}" = "${revision_head}" ; then exit 0; fi
>
> ${svn} log -r $((${revision_base}+1)):HEAD --incremental "$1"
> ]]]
>
> or if you allowe to be shown 'No such revision' error:
> [[[
> #!/bin/sh
>
> # if This is not in your command search paths, please change it.
> svn=svn
>
> ${svn} log -r $((`${svn} info -r BASE --show-item revision "$1"`+1)):HEAD \
> --incremental "$1"
> ]]]
>
> or check the BASE revision number in advance and filter out the log
> on its revision number from the result of 'svn log -r BASE:HEAD'.
>
> In addition, to get "exactly" what you want, you need forbidding
> everyone to commit change on the target path just after you examine
> the HEAD revision until you run 'svn update', and I think it is not
> good idea.

It just occurred to me, there is also this trick that might get you
what you want:

svn mergeinfo --show-revs eligible --log -v .@HEAD .

This lists the "revisions that are eligible for merging" between
'.@HEAD' (HEAD revision of the current working directory) and '.'. The
'--log' and '-v' options extend the output beyond merely listing the
revision numbers, to also include the verbose log info.

There is a slight possibility that this might be wonky, if someone
messed with merge tracking (i.e. manipulated the svn:mergeinfo
property) or if revisions from the own "natural history" have been
reverse merged by someone else between your BASE and the HEAD revision
(like in the "Undoing Changes" section in the svn book [1]). But if
you can live with that, I think it's quite elegant :-).

[1] 
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

-- 
Johan

Re: How to Prevent SVN commits if the Valid number is not entered

[Johan Corveleyn]

On Tue, Mar 9, 2021 at 2:57 AM Kenneth Porter  wrote:
>
> --On Monday, March 08, 2021 8:21 PM -0400 Phani Teja 
> wrote:
>
> > Hello i need help regarding SVN , how can i prevent if people do not enter
> > with Letter DE followed by 3 or 4 number (e.g DE123 or DE1234) in svn log
> > message while doing commit.below is the configurating i have in my
> > pre-commit bat file.Any help or lead would be highly appreciated.
>
> I suggest writing a small script in Perl, Python, Powershell, or whatever
> you're comfortable with, and invoking that from your batch file.
>

And if you want to do something more extensive (or foresee it growing
into that), there are some useful utilities / bundles floating around
on the net, such as this one:
https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook

Quite powerful (including functionality to validate commit messages
against a regex), though perhaps a bit too much if the only thing you
want to do is validate the commit message for the presence of a ticket
number.

In our environment we use an earlier version of that perl script (with
config file), that was once circulated on this very mailinglist.

-- 
Johan

Re: Error report: wc_db.c line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))

[Johan Corveleyn]

On Wed, Aug 19, 2020 at 10:38 AM Alessandro Garberi
 wrote:
>
> Hello,
> I received this error using TortoiseSVN Project Monitor (latest TortoiseSVN 
> version 1.14.0) on Windows 7 64-bit fully updated.
> I found a similar report, so I replied to it.
>
> Probably this is the condition:
> - using a VPN to connect to SVN repository
> - Project Monitor dialog was open
> - PC went to stand-by
> - when I turned on the PC, the VPN was disconnected (by the stand-by)
> - Project Monitor tried to update data
> - error appeared
> - if I click on the "Check Now" button, the same error appears again
>
> ---
> 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
> https://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.14.0\ext\subversion\subversion\libsvn_wc\wc_db.c'
>  line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
> ---
> OK
> ---

Hi Alessandro,

Interesting, and great that you found a (probable) reproduction recipe.

I think you should report this to the TortoiseSVN project first (it is
a separate project, see [1] for their mailinglists). It is likely that
they are best placed to investigate and fix this problem (and if it's
a problem with the core libraries, they might be able to provide some
more technical information for the "core project" to look at).

[1] https://tortoisesvn.net/community.html

Thanks,
-- 
Johan

Re: SVN 1.4 doesn't run on Windows 2019 core

[Johan Corveleyn]

On Mon, Jul 13, 2020 at 11:16 PM Neil Sleightholm  wrote:
> On 2020/07/13 15:17:07, Neil Sleightholm  wrote:
> > Your operating system>
> > Windows 2019 Core (Version 10.0.18363.900)>
> >
> > The release and/or revision of Subversion>
> > svn, version 1.14.0 (r1876290)>
> > compiled May 24 2020, 17:07:49 on x86-microsoft-windows>
> >
> > The compiler and configuration options you built Subversion with>
> > Downloaded as part of TortoiseSVN>
> >
> > Any private modifications you made to your Subversion>
> > N/A>
> >
> > The version of Berkeley DB you're running Subversion with, if any>
> > N/A>
> >
> > Anything else that could possibly be relevant. Err on the side of too much 
> > information, rather than too little.>
> > When you run SVN nothing happens, no error or any other output, same goes 
> > for SVN --version.>
> >
> > This only happens on Windows 2019 core (i.e. no UI) my guess would be that 
> > it is linked to an API that is not available in core. SVN versions 1.13 and 
> > earlier work ok.>
>
> This is not a problem with the build 2004 update (Version 10.0.19041.329).
>
> Neil

Thanks for mentioning this. But it's not clear to me whether this
means the problem is fixed (i.e. version 10.0.19041.329 is the newer
version, and the problem only occurred in some previous build) or not.

If it's not fixed: can you please post more details? Is there an error
message (please copy-paste it as plain text then)? Or is there a crash
or something else?

-- 
Johan

Re: maybe a bug

[Johan Corveleyn]

On Thu, May 14, 2020 at 10:30 AM lu chengwei  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
> https://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.13.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
> line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
>

Hi lu,

If you encountered this error after clicking "Edit" on a file from the
TortoiseSVN Repository browser, then you've probably hit a
TortoiseSVN-specific bug that was already reported on this list a
couple of times before.
Just to be clear: TortoiseSVN (Windows GUI for SVN) is a separate
project from the Subversion project, with its own mailinglists:
https://tortoisesvn.net/community.html).

The bug seems to be fixed already:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/tortoisesvn/_wyo1iQIc1c/HAybYPkjCQAJ

But unfortunately it's not yet part of a new TSVN release (1.13.1 is
currently the latest one). Perhaps you could use a nightly build of
TortoiseSVN if you need this fix (scroll to the bottom of
https://tortoisesvn.net/downloads.html).

In a couple of weeks SVN 1.14.0 will be released, and I'm sure
TortoiseSVN will then make a new release as well (which will have the
above bug fixed too).

HTH,
-- 
Johan

Re: SVN Server migration to a new server

[Johan Corveleyn]

On Tue, May 12, 2020 at 1:00 PM Dheeraj  wrote:
>
> Hi All
>
> I did SVN server migration from RHEL 6 to RHEL 7 and migrated the repos.
> Also DNS entry is changed so that alias points to the  news server. When I 
> did svn up from an existing setup, I got below error.
>
> svn: E175002: Unable to connect to a repository at URL 
> 'https://svn-hpc.americas.shell.com/svn/RnD'
> svn: E175002: Server sent unexpected return value (500 Internal Server Error) 
> in response to OPTIONS request for 
> 'https://svn-hpc.americas.shell.com/svn/RnD'
>
> Any solution to this.

A "500 Internal Server Error" always indicates that the server had
some error internally. You have to take a look at the (Apache httpd)
error log on the server to get more information about the nature of
the error. Perhaps there is something wrong on the server side with
your new installation.

-- 
Johan

Re: commit failed due to "backwards-sliding source views" - what do I do?

[Johan Corveleyn]

On Wed, Apr 29, 2020 at 12:11 PM Daniel Shahaf  wrote:
>
> Johan Corveleyn wrote on Wed, 29 Apr 2020 11:04 +0200:
> > On Wed, Apr 29, 2020 at 7:14 AM Chaya  wrote:
> > >
> > > 1. Unfortunately, it's not a public repository.
> > > 2. The SVN project repo is actually file based. So I had to convert it to
> > > svn protocol before cloning to git.
> > > 3. Using latest version of svn (version 1.13.0 (r1867053)) and git ( 
> > > version
> > > 1.13.0 (r1867053))
> > >
> > > --
> > > Sent from: 
> > > http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html
> >
> > You're using "git svn", which is part of git (sorry, I thought git-svn
> > was a separate project, but it seems to be simply part of git itself
> > now, as a subcommand):
> > https://git-scm.com/docs/git-svn
> >
> > From what I understand 2.26.2 is the latest release of git currently
> > (see https://git-scm.com/).
> >
> > IMHO you'll need to ask the git community for support on the "git svn"
> > command. I have no idea what kind of svn-like operations the "git svn"
> > tool really performs under the hood. Maybe there are certain
> > pre-conditions you need to make sure of, before running "git svn" on a
> > repository (those should be documented at
> > https://git-scm.com/docs/git-svn, or if not you should ask the git
> > community).
> >
> > Maybe one more suggestion: you say in (2) that you "had to convert it
> > to svn protocol before cloning to git". What do you mean with "convert
> > it to svn protocol"? Did you first use it as a file-based repository
> > (in SVN with a file:// URL), and before using "git svn" you had to set
> > up and "svnserve" process to serve it? Perhaps the (file-based)
> > repository you started from is in a very old format which isn't
> > supported well by "git svn". In that case, perhaps you should first
> > try to "svnadmin upgrade $REPO" with your svn tools, before trying to
> > run "git svn" on it. It's worth a try...
>
> Johan, what do you mean by 'a very old format which isn't supported well
> by "git svn"'?

For instance an svn repository that was created by svnadmin 1.0, with
BDB backend. Or a pretty old version of FSFS or something like that.

> How would you tell, over the svn:// protocol, whether
> a repository is of a 'very old format'?  I'd expect the server to hide
> these details from the client — assuming the version of svnserve is new
> enough, at least.  [Well, one thing the server won't hide is the
> "mergeinfo" capability, which depends on the backend format number, but
> that's probably not related to the case at hand.]

I assumed, because Chaya said the "SVN project repo is actually file
based", that she would have control over it as an admin, and perhaps
would know more about its history and / or exact version, setup, etc.
But maybe I was a bit too terse there, so thanks for chiming in and
adding some concrete commands which could give us some more
information :-).

> In any case, Chaya, could you run `svnserve --version -q` and `svnadmin
> info /path/to/repos` and post the output here?  In addition to Johan's
> direction, there's a svn_txdelta_parse_svndiff() call in BDB that I'd
> like to rule out.  In fact, I wish I had a backtrace of the error (it's
> generated by us: see subversion/libsvn_delta/svndiff.c:write_handler),
> but I don't even know whether to ask you to debug svnserve(8) on the
> server or svn(1) or git-svn(1) on the client… as Johan said, we really
> need the git-svn folks to look into this first and come back to us with
> a reproduction recipe in terms of our APIs.
>
> Also, could you try creating an svnsync mirror of the repository, and
> let us know whether that succeeded or errored?
>
> Cheers,
>
> Daniel



-- 
Johan

Re: commit failed due to "backwards-sliding source views" - what do I do?

[Johan Corveleyn]

On Wed, Apr 29, 2020 at 7:14 AM Chaya  wrote:
>
> 1. Unfortunately, it's not a public repository.
> 2. The SVN project repo is actually file based. So I had to convert it to
> svn protocol before cloning to git.
> 3. Using latest version of svn (version 1.13.0 (r1867053)) and git ( version
> 1.13.0 (r1867053))
>
> --
> Sent from: 
> http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html

You're using "git svn", which is part of git (sorry, I thought git-svn
was a separate project, but it seems to be simply part of git itself
now, as a subcommand):
https://git-scm.com/docs/git-svn

>From what I understand 2.26.2 is the latest release of git currently
(see https://git-scm.com/).

IMHO you'll need to ask the git community for support on the "git svn"
command. I have no idea what kind of svn-like operations the "git svn"
tool really performs under the hood. Maybe there are certain
pre-conditions you need to make sure of, before running "git svn" on a
repository (those should be documented at
https://git-scm.com/docs/git-svn, or if not you should ask the git
community).

Maybe one more suggestion: you say in (2) that you "had to convert it
to svn protocol before cloning to git". What do you mean with "convert
it to svn protocol"? Did you first use it as a file-based repository
(in SVN with a file:// URL), and before using "git svn" you had to set
up and "svnserve" process to serve it? Perhaps the (file-based)
repository you started from is in a very old format which isn't
supported well by "git svn". In that case, perhaps you should first
try to "svnadmin upgrade $REPO" with your svn tools, before trying to
run "git svn" on it. It's worth a try...

HTH,
-- 
Johan

Re: commit failed due to "backwards-sliding source views" - what do I do?

[Johan Corveleyn]

On Tue, Apr 28, 2020 at 8:16 AM Chaya  wrote:
>
> Has anyone found solution to this problem?
> I am getting this error while running git svn fetch command.
> Tried many things to solve this issue, but no luck.
> If anyone has found solution , it would be very helpful if you post it here.
> Thanks!
>
> --
> Sent from: 
> http://subversion.1072662.n5.nabble.com/Subversion-Users-f84423.html

I did not find much about this error. Just this SO question, without a
real answer:
https://stackoverflow.com/questions/24904329/git-svn-clone-failed-due-to-svndiff-backward-sliding-source-view

Seems to me the problem is specific to git-svn, so I'm thinking you
should contact people in the git-svn community. They might know more
or have experience with this kind of problem.

-- 
Johan

Re: Who else is using SVN for large-binary-asset storage?

[Johan Corveleyn]

On Sat, Apr 25, 2020 at 11:18 AM Daniel Shahaf  wrote:
>
> Karl Fogel wrote on Fri, 24 Apr 2020 13:43 -0500:
> > On 24 Apr 2020, Mark Phippard wrote:
> > >I think this would be a good idea in that it might be one of the last
> > >remaining niches where SVN is a better tool for the job than a DVCS.
> > >I do not think I could contribute though.
> > >
> > >I just wanted to throw another item on the pile. I recall an old
> > >thread (have not been able to find it) where it was shown that a
> > >massive performance win on large binary blobs would be if we could
> > >skip all of the xdelta stuff and just stream the binary.  If I recall
> > >correctly, you can even see and demo this today using WebDAV and just
> > >doing a PUT or whatever is right request with the entire file.  The
> > >server already knows how to handle it and store the file the same as
> > >it would if it had come via a SVN client.  I think there were some
> > >complications with how svndiff0/svndiff1 etc are expected by a
> > >client, but if there were some way to have a property on a file that
> > >caused us to skip all of this, including storing the extra pristine
> > >copy, it could be a big win for managing large binaries with SVN.
> > >
> > >It seems like we could make revert fetch the file from the server
> > >again to restore a binary.
> > >
> > >If I can find any of those old threads I will share them.  So far the
> > >only one I found was about how using a larger xdelta window size
> > >could give better compression, but the thread I recall was about not
> > >doing it at all.  It also assume that the xdelta is of no real value
> > >because it does not shrink the amount of bytes that have to be
> > >transferred.
> >
> > Ah, thanks for this reminder!  I also recall those results (and I guess 
> > they're not surprising).  I'll make sure we keep it in mind if this project 
> > happens.  If you happen to dig up any of the old threads, that'd be great, 
> > but even if you don't, the above information is enough for a developer to 
> > know the possibility exists.
>
> That one doesn't seem like it'd be terribly hard to implement.  The
> data format of svndiff0 enables "Produce the following bytes verbatim"
> to be represented.  There's nothing stopping whoever generates an
> svndiff stream from using that feature of the data format to produce a
> degenerate self-delta (that is, a self-delta that doesn't attempt to
> compress) where currently it would produce a self-delta or a delta
> against the BASE revision, as well as to produce an svndiff0 stream
> even when the other side accepts svndiff1 and/or svndiff2.  We don't
> even need a new wire capability for this.
>
> With this approach files would still be split into SVN_DELTA_WINDOW_SIZE
> bytes -sized windows, so we won't reach the performance of sendfile(2);
> however, I suspect the lion's share of the slowdown is due to the
> deltification and compression steps.
>
> Cheers,
>
> Daniel
>
> P.S. This being users@, clarification: "svndiff0" and "svndiff1" are
> internal binary delta formats that have nothing whatsoever to do with
> the «svn diff» command.

I think Mark was referring to this thread on dev@ from 2017, which was
started by Paul Hammant (I think he was working on a tool for
versioning big directory trees easily, with merkle trees etc ... might
be interesting to get in touch with him):

https://svn.haxx.se/dev/archive-2017-07/0034.shtml

Philip Martin made some interesting suggestions and provided some
numbers, first focusing on the deltification overhead (which he could
eliminate, on the client-side, by enabling SVNAutoversioning and
performing a PUT with curl -- IIUC it's not possible right now to
eliminate deltification on the server-side):

https://svn.haxx.se/dev/archive-2017-07/0040.shtml

and later he also eliminated compression on the server-side, which
yielded another factor 3 speed boost:

https://svn.haxx.se/dev/archive-2017-07/0043.shtml

-- 
Johan

Re: subversion exception on subversion repository viewer

[Johan Corveleyn]

On Wed, Apr 15, 2020 at 1:42 PM Brian Thomas 
wrote:

> We're long time svn users. We recently upgraded from
>
> C:\Windows\System32>svn --version
> svn, version 1.9.5-SlikSvn (SlikSvn/1.9.5)
>compiled Dec  2 2016, 22:16:15 on x86_64-microsoft-windows6.2.9200
>
> to this:
>
> C:\Program Files\TortoiseSVN>bin\svn --version
> svn, version 1.13.0 (r1867053)
>compiled Oct 31 2019, 20:41:49 on x86-microsoft-windows
>
> Now when I open the TortoiseSVN repository browser and select a project
> folder in the left-hand pane, then r-click a file in the right-hand pane
> and select Edit then the selected file opens in Notepad.
> But on the second attempt—if I r-click a *different* file in the same
> folder in the right-hand pane I get a dialog containing this text:
>
> Error: 'C:\Users\thomasb\AppData\Local\Temp' is already a working copy for
> a different
> Error:  URL
> Completed!:
>
>
> and then I get this Exception dialog:
>
> ---
> 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
> https://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.13.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
>  line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
> ---
> OK
> ---
>
>
> This defect has been reported already (in 2018!) but there's been no fix
> as far as I can tell.
>
>
> This is a regression since 1.9 where this error did not occur.
>


Hi Brian,

Heh, this error was just reported twice on this mailinglist two days ago
:-). As I replied already on those other posts:

This is a bug specific to TortoiseSVN (Windows GUI for SVN, a separate
project from the Subversion project, with its own mailinglists:
https://tortoisesvn.net/community.html).

The bug seems to be fixed already:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/tortoisesvn/_wyo1iQIc1c/HAybYPkjCQAJ

But unfortunately it's not yet part of a new TSVN release (1.13.1 is
currently the latest one). Perhaps you could use a nightly build of
TortoiseSVN if you need this fix (scroll to the bottom of
https://tortoisesvn.net/downloads.html).

-- 
Johan

Re: svn:ignore of checked in files and commit

[Johan Corveleyn]

On Wed, Apr 15, 2020 at 2:03 PM Attila Kinali  wrote:
>
> On Wed, 15 Apr 2020 13:53:07 +0200
> Branko Čibej  wrote:
>
> > I don't remember svn:ignore *ever* working the way you describe. Can you
> > tell us which version of Subversion you were using? Are you absolutely
> > sure it wasn't modified to behave as you describe?
>
> That was like 10-15 years ago. I don't remember which version we
> used back then.
>
> > Like I said, it did not change. Files that are already
> > version-controlled cannot be ignored. This was part of the original
> > svn:ignore design spec, and the behaviour is actually based on .cvsignore.
>
> Hmmm.. could it be that we were relying on a bug?
>
> > > Is there a workaround that we can use?
> >
> > Sure, don't commit the files that you don't want in the repository.
> > Instead, create a template that each user can rename to an (ignored)
> > local name.
>
> Yes, but mistakes happen. This is a project we are doing together with
> a bunch of computer scientists. These are not computer savy people!
> I'm glad we are using any SCM in the first place and not some Dropbox
> with zip files or something.
>
> Seem's like I have to think about changing our workflow..

FWIW, the behavior you want is a very old feature request that
unfortunately never got implemented:

https://issues.apache.org/jira/browse/SVN-2858 (Support file property
which indicates that commit must be manually forced)

Some of us know it as the "svn:hold" property.

I think this still could be implemented if someone stepped up to do it
(starting by dusting off the old design docs and discuss approaches on
dev@). But it won't be easy, because there is a lot of interaction
with other existing features.

-- 
Johan

Re: Preferred Subversion 1.13 MPM

[Johan Corveleyn]

On Tue, Apr 14, 2020 at 10:25 AM Carmen Alzzer  wrote:
>
> helo friends,
> while this is still hot on here - can you please tip in how your MPM are
> handled? also if you have thoughts upon reading my setup, i would be
> delighted to hear from you :)
>
> cheers
> Carmen

Hi Carmen,

[ Sidenote: we prefer "bottom-posting" or "inline replying" on this list. ]

I have never looked at tweaking the MPM myself, and I have not yet
seen much discussion about it here. We're using the defaults of our
distribution (we use a CollabNet package of SVN, which includes httpd
2.2.23), which is prefork (with default settings). We're running it on
a VM with 4 Intel Xeon CPU's and 8 GB RAM, running Ubuntu 16.04. I
think the MPM will not be a big performance factor in most cases. IMHO
the things with the most impact on performance are not MPM-related
(and some are more client related). So, following Stefan, I would
suggest first making sure the "known performance knobs" are in order.
I'll try to give you "my list" here below.

In my experience, the most important things for SVN performance are:

Server side:
- httpd config:
MaxKeepAliveRequests 1 (or higher, we use 2) [1]
SVNInMemoryCacheSize 131072 (=128 MB -- or higher if you have
enough RAM), or some suitable value [2]
Cache authentication results (LDAP caching) (though I believe
this is less important if KeepAlive works well)
- If you don't need path-based authorization, disable it
(SVNPathAuthz off). If you have to use path-based authz, try
"SVNPathAutzh short_circuit" [3].
- FSFS back-end must be on fast storage, accessible by the server
as a local disk (not NFS / SMB mounted -- that's way too slow)
- Use FSFS format 8 with lz4 compression, and do a full dump &
load to this format if you can. (see [4] for a step-by-step guide)
- 'svnadmin pack' your repositories regularly (we use a nighly
cron job for this)
- If you have problems with commit performance, check your hook
scripts (start-commit, pre-commit, post-commit) for any custom code
that could be slowing things down too much (be very careful if you
loop over all changes in a commit, and do $stuff for every modified /
added / deleted file ... this scales with the size of your commit, so
make sure $stuff is as fast as possible, and avoid unnecessary work
(early-exit wherever you can)). If you're not sure, try to inject some
measurement code in your hook scripts [5].

Client side:
- Make sure they use recent clients! At least 1.10, preferably
even the latest (1.13).
- If a working copy acts really slow, ask them to run "svn
cleanup" (cleaning up the pristine store, and most importantly fixing
the timestamps of the files in the svn metadata). This is especially
important if they have copied over their (large) working copy from one
disk to another (depending on how this is done, this gives all files a
new lastmod-time, which makes the working copy very slow because svn
cannot use its metadata anymore as a shortcut to see if a file was
modified ... it has to read + checksum every file on many operations).
- Avoid using working copies on networked drives (NFS, CIFS, ...).
This can be really slow.
- If you really must use a networked location for your working
copy, try if it helps if you put "exclusive-locking = true" in the
[working-copy] section of the ~/.subversion/config (*nix) or
%APPDATA%/Subversion/config (Windows). [6]

Client-Server network:
- Be very wary of proxies etc. If you're running a corporate
installation, try to arrange that your clients can connect directly to
the svn server.
- On a LAN, of course wired works best (1 Gbit, or even 100 Mbit).
But wireless (if enough capacity) works fine too. These days, most of
our users are working from home over VPN, and that works very well
too.

[1] https://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
[2] 
https://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning
[3] 
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.ref.mod_dav_svn
[4] https://subversion.apache.org/faq.html#dumpload
[5] I'm using this helper code in my pre-commit hook (in Bourne shell):

[[[
DEBUG=1
logStart()
{
if [ $DEBUG ]
then
START_DATE=`date +'%F %T'`
START=`/usr/local/perl/bin/perl -MTime::HiRes -e 'print
Time::HiRes::gettimeofday.""'`
AUTHOR=`$SVNLOOK author $REPOS -t $TXN`
CHANGED=`$SVNLOOK changed $REPOS -t $TXN`
export CHANGED # Export so it can be reused (other scripts
check for this variable)
NR_CHANGES=`echo "$CHANGED" | wc -l`
fi
}

# logEndAndExit $exitCode
# Logs the end of the script with timing information, and exits with $exitCode
logEndAndExit()
{
EXIT_CODE=$1
if [ $DEBUG ]
then
ELAPSED=`/usr/local/perl/bin/perl -MTime::HiRes -e 'printf
("%.3f", Time::HiRes::gettimeofday - $ARGV[0])' $START`
# start-datetime end-datetime author n

Re: SVN Server migration to a new server

[Johan Corveleyn]

On Tue, Apr 14, 2020 at 11:36 AM Dheeraj  wrote:
>
> Hi Johan
>
> Thanks for the update. I have taken care of the hooks and configuration, 
> probably I missed the locks part.
> I will have a look into it.
> I was thinking since the IP address is changing will it cause any issue 
> during Checkout or commit even though the alias will be the same.

I think that would be okay. If they have done the checkout from the
DNS name, then it should work out fine.

-- 
Johan

Re: Tortoize svn Error

[Johan Corveleyn]

On Tue, Apr 14, 2020 at 9:27 AM  wrote:
>
> Hello
>
> I use tortoise svn
>
> When I try to edit excel file
> I can't open file and this error massage
>
> Please tell me solution
>
> 
> ---
> Subversion Exception!
> ---
> Subversion は深刻な問題に遭遇しました。
> 下記のエラー情報と、何をしようとしたかをできるだけ詳しく
> 書いて、Subversionのメーリングリストに報告してください。
> 但し、同じ問題が繰り返し報告されることを避けるために、
> まずメーリングリストアーカイブから、このエラーメッセージを
> 探してみてください。メーリングリストのアーカイブは下記の
> アドレスにあります。
> https://subversion.apache.org/mailing-lists.html
>
> Subversion の報告内容（Ctrl+Cを使用すると、このダイアログの
> 内容をクリップボードにコピーできます。）:
>
> In file
>  
> 'D:\Development\SVN\Releases\TortoiseSVN-1.13.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
>  line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
> ---
> OK
> ---
>
>
> --
> Sincerely yours,
> Takayuki Nii

Hi Takayuki,

Thanks for your report.
I believe this is a bug specific to TortoiseSVN (Windows GUI for SVN,
a separate project from the Subversion project, with its own
mailinglists: https://tortoisesvn.net/community.html).

The bug seems to be fixed already:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/tortoisesvn/_wyo1iQIc1c/HAybYPkjCQAJ

But unfortunately it's not yet part of a new TSVN release (1.13.1 is
currently the latest one). Perhaps you could use a nightly build of
TortoiseSVN if you need this fix (scroll to the bottom of
https://tortoisesvn.net/downloads.html).

-- 
Johan

Re: SVN problem when trying to edit a file

[Johan Corveleyn]

On Mon, Apr 13, 2020 at 3:58 PM Levan Katsadze - EP
 wrote:
>
> Hello, I have a problem on using SVN. Previous version worked fine, but this 
> new version does not let me edit any file.
> I click on "edit" and the error window jumps up (screenshots attached).

Hi Levan,

I'm pasting the error here in textual form, for easier searchability.
Your error was:

 
'D:\Development\SVN\Releases\TortoiseSVN-1.13.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
 line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))

I believe this is a bug specific to TortoiseSVN (Windows GUI for SVN,
a separate project from the Subversion project, with its own
mailinglists: https://tortoisesvn.net/community.html).

The bug seems to be fixed already:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/tortoisesvn/_wyo1iQIc1c/HAybYPkjCQAJ

But unfortunately it's not yet part of a new TSVN release (1.13.1 is
currently the latest one). Perhaps you could use a nightly build of
TortoiseSVN if you need this fix (scroll to the bottom of
https://tortoisesvn.net/downloads.html).

-- 
Johan

Re: SVN Server migration to a new server

[Johan Corveleyn]

On Tue, Apr 14, 2020 at 9:28 AM Dheeraj  wrote:
>
> Hi
>
> I have upgraded my SVN from RHEL 6 to RHEL 7 to a new server.
> I still have RHEL 6 server in production and have an DNS alias named 
> svn-server poditing to the old server. My plan is to do a SVN dump of repos 
> from old server and load it on new server. Once I load all repos, I will make 
> the old server (RHEL 6) to read only and then make DNS change to point 
> svn-server alias to new server (RHEL 7) and make it production.
> Do I need to do any other thing apart from this.
> Will I get any error while doing commit/check out to the existing one, since 
> server is changed.
> Will I get "svn: E155000:" error?

Hi Dheeraj,

Dump & load will only transfer the versioned data (FSFS database).
Don't forget to also copy over:

  - hook scripts: OLDREPOS/hooks to NEWREPOS/hooks (it's best to
review them at this point, to make sure they'll work on the new
machine)

  - conf files: OLDREPOS/conf to NEWREPOS/conf (also, review them, and
check the new default conf files to see if there are any interesting
new options or comments)

  - locks: OLDREPOS/db/locks to NEWREPOS/db/locks (the locks that are
kept in working copies, for which a token is held on the server -- be
sure to do this during your maintenance window)

If you've done a full dump and load onto the new machine (in a freshly
created new repository), the repository UUID should be transferred as
well, so normally your old working copies will keep working, and you
won't get the E155000 error.

Perhaps also take a look at this FAQ entry for some more details of
the dump&load procedure:
http://subversion.apache.org/faq.html#dumpload

-- 
Johan

Re: Tab completing URL arguments in the shell (was: Re: Automatically supply the origin URL in svn merge)

[Johan Corveleyn]

On Thu, Mar 26, 2020 at 10:36 PM Daniel Shahaf  wrote:
>
> Stefan Sperling wrote on Thu, 26 Mar 2020 21:02 +00:00:
> > The ultimate goal here is to allow users to type less characters when
> > starting merges. Scripting tab-completion for SVN URL arguments into
> > your favourite shell would also be a usable and effective solution.
>
> What would the algorithm be?

This reminds me, I once saw a patch being posted about bash URL
completion. For some reason it wasn't picked up properly back in 2012.
I never looked into it in detail, but here's a pointer FWIW:

First on the users list:
https://svn.haxx.se/users/archive-2012-07/0194.shtml

The OP got redirected to the dev list:
https://svn.haxx.se/dev/archive-2012-07/0291.shtml

-- 
Johan

Re: "svn diff -c" behavior on file copy from an old revision

[Johan Corveleyn]

On Thu, Nov 21, 2019 at 3:09 PM Vincent Lefevre  wrote:
> On 2019-11-20 15:21:22 +0100, Johan Corveleyn wrote:
> > Vincent Lefevre also wrote:
> > >> Note: "svn cat -r... file2" or "svn cat -r... file2@3" also shows a
> > >> similar behavior:
> > >>   -r1: one gets file1@1
> > >>   -r2: "Unable to find repository location for..." error
> > >>   -r3: one gets file2@3
> >
> > Hm, it might be related, but I don't see this as exactly the same
> > problem. IMHO this is normal and correct behavior.
>
> I think that, as -c is documented, this is the same issue: "-c M" is a
> shorthand for "-r N:M" with N = M−1. Thus
>
>   svn diff -c3 file2
>
> is equivalent to
>
>   svn diff -r2:3 file2@BASE
>
> Here, BASE is assumed to be 3 (or equivalent). Thus one should get the
> difference between the contents corresponding to
>
>   svn cat -r2 file2@3
>
> and
>
>   svn cat -r3 file2@3
>
> > Indeed, in r2 there was no file2.
>
> This is not really what is described here:
>
>   http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html
>
> OPERATIVE-REV is older than PEG-REV. Thus
>
> 1. Locate item in the revision identified by PEG-REV. There can be
>only one such object.
>
> → This is file2.
>
> 2. Trace the object's history backwards (through any possible renames)
>to its ancestor in the revision OPERATIVE-REV.
>
> → As I understand it, the history is as followed.
>
> There is file2 at revision 3, which is a copy of file1 from revision 1.
> At revision 1, this is file1. The renamed (and modification) occurred
> at revision 3, thus I would say that revision 2 did not introduce a
> change of the file, i.e. this is like file1@1. If the file is assumed
> to be nonexistent, then this would mean that in the history line, it
> has been removed, then re-added; this does not make sense to me, as
> there was no such operation in the history.
>
> > In r1 there was a predecessor of file2@3, namely file1@1. You could
> > argue that in r2 it should show the contents of file1@1 (which were
> > incidentally unchanged in r2).
>
> Exactly, but the reason is not that file1 was unchanged in r2.
> It is because that file1@1 is the latest ancestor or file2@3.
>
> > But what if file1 would have been changed in r2 (yet file2@3 was a
> > copy of file1@1), what would you expect svn to show?
>
> Obviously file1@1, as file1@2 is *not* an ancestor of file2@3.
> Just like file1@3 will not affect file2@3.
>
> Remember, we are looking at the (backward) *history* of file2@3.
>
> > Or what if file1 was deleted in r2?
>
> Ditto, file1@1.
>
> > I guess the same questions can be asked for 'svn diff -c 3' (what if
> > file1 had a different content in r2, or was deleted in r2?). Yet in
> > that case I intuitively expect "diff -c3" to take the copy-source into
> > account, no matter if it has made a jump through history. As I argued
> > in [3] above, it seems 'svnlook' can do this with its --diff-copy-from
> > option ... (which I happen to like for generating diffs in post-commit
> > emails).
>
> My above interpretation of the history would have the advantage to
> make it consistent with the current specification of "diff -c".

Ah, okay. Thanks for explaining. I can follow that.
So I agree this is probably the same issue, in that there is a similar
"bug in semantics".

If both commands ('svn cat -r2 file2@3' and 'svn diff -c3 file2', with
file2='svn copy file1@1') would use the IMHO very reasonable semantics
that you explain above, that would make sense to me.

As I said before in this thread, 'svnlook --diff-copy-from' seems to
be able to do it, so I think there is no purely technical reason why
it can't be done either.

-- 
Johan

Re: "svn diff -c" behavior on file copy from an old revision

[Johan Corveleyn]

On Tue, Nov 19, 2019 at 4:53 PM Nathan Hartman  wrote:
>
> On Mon, Nov 18, 2019 at 4:44 AM Vincent Lefevre  
> wrote:
>>
>> I have the following issue with svn 1.10.6:
>>
>> Assume that I committed "file1" at revision 1, did some unrelated
>> change at revision 2, and for revision 3, copied "file1@1" to "file2"
>> with "svn copy"[*] and did some changes in file2 before the commit.
>>
>> [*] The revision older than the latest one is what happens when one
>> does a "svn copy" directly from the working copy without an update
>> first.
>>
>> If I do "svn diff -r 1:3 file2", then I get the changes that have been
>> introduced between file1 and file2. But if I do "svn diff -c 3 file2",
>> which is equivalent to "svn diff -r 2:3 file2", then I get the whole
>> file2 content, as if file2 were an entirely new file.
>>
>> I'm wondering whether this is the expected behavior. In any case,
>> this behavior is rather unintuitive and rather useless. I think there
>> should be an easy way to get the changes introduced by a commit.

[ snipped note ... not sure this is the same problem, see below. ]

>
>
> Hello Vincent,
>
> Thank you for reporting this.
>
> I think it is the expected behavior because file2 does not exist in revision 
> 2 and by using '-c 3' (equivalent to -r 2:3) you're restricting the revisions 
> that are included in the differencing; as it does not follow the copy source 
> farther back than revision 2, the file is considered a new file.
>
> In contrast, with -r 1:3, since the revisions are not restricted (or at least 
> not as restricted; revision 1 is now included in the differencing), it 
> follows the copy backwards to revision 1 and shows only the differences.
>
> I agree it would be nice if it could show only the changes in the copy, but 
> then a command like 'diff -r 2:3' would be ambiguous... How would it know if 
> you want it to trace history beyond the range specified, or if you want it to 
> respect the -r 2:3 limit?
>
> Thoughts?

This issue is _ancient_ :-).

FWIW: I agree with you, Vincent. I expect the same behavior as you do.
But this has been discussed at length before, and so far no one has
managed to (find consensus to) change this, or to even invent a new
option to get the behavior you and I find intuitive.

For some background, see this thread from dev@ in 2013 [1]:
1.6 vs. 1.8: strange behavior of 'svn diff -cN WC-FILE' if the
file was created in rev N by copying

In my last post in that thread I tried the "but this is inconsistent /
unpredictable" card, to no avail [2]:
"Maybe I gave the wrong impression, but I'm not trying to completely
 redefine the behavior of 'diff -c'. However the current behavior, when
 looking at a moved file, is unpredictable: it depends on whether or
 not the move source's revision was exactly 1 revision before the
 move-commit. That unpredictability is not good."

Somewhere in that thread I also dropped a pointer to an earlier thread
in which I observed (in passing) that this was a difference between
'svn' and 'svnlook' [3].
"So it seems that detecting copies with their sources is broken in
'svn diff'"

[1] https://svn.haxx.se/dev/archive-2013-06/0588.shtml
[2] https://svn.haxx.se/dev/archive-2013-06/0705.shtml
[3] https://svn.haxx.se/dev/archive-2012-11/0480.shtml


Vincent Lefevre also wrote:
>> Note: "svn cat -r... file2" or "svn cat -r... file2@3" also shows a
>> similar behavior:
>>   -r1: one gets file1@1
>>   -r2: "Unable to find repository location for..." error
>>   -r3: one gets file2@3

Hm, it might be related, but I don't see this as exactly the same
problem. IMHO this is normal and correct behavior.

Indeed, in r2 there was no file2. In r1 there was a predecessor of
file2@3, namely file1@1. You could argue that in r2 it should show the
contents of file1@1 (which were incidentally unchanged in r2). But
what if file1 would have been changed in r2 (yet file2@3 was a copy of
file1@1), what would you expect svn to show? Or what if file1 was
deleted in r2?

I guess the same questions can be asked for 'svn diff -c 3' (what if
file1 had a different content in r2, or was deleted in r2?). Yet in
that case I intuitively expect "diff -c3" to take the copy-source into
account, no matter if it has made a jump through history. As I argued
in [3] above, it seems 'svnlook' can do this with its --diff-copy-from
option ... (which I happen to like for generating diffs in post-commit
emails).

-- 
Johan

Re: Need help in importing Perforce dump in to SVN

[Johan Corveleyn]

On Wed, Sep 18, 2019 at 8:01 AM Shilp, Kumar  wrote:
> Hi,
>
> We are trying to import Perforce dump in to SVN but we are hitting ‘checksum 
> mismatch’ error. Can someone please let me know what could be the issue here 
> and how can we resolve it?
>
> Error snippet:
>
> C:\>svnadmin load --force-uuid repo < depot_build.dump
> <<<  Started new transaction, based on original revision 1
> editing path : trunk ... done.
> editing path : trunk/ReadMe.txt ... done.
> Committed revision 1 >>>
> <<< Started new transaction, based on original revision 2
> • editing path : trunk/Makefile ... done.
> • editing path : trunk/buildEnvironment ... done.
> • editing path : trunk/buildEnvironment/channel.src ... done.
> • editing path : trunk/buildEnvironment/channel.src/codepage-channel ... 
> done.
> editing path : trunk/buildEnvironment/channel.src/codepage-channel/.castanet 
> ... done.
> editing path : 
> trunk/buildEnvironment/channel.src/coclepage-channel/.castanet/properties.txt 
> ... done. '
> editing path : 
> trunk/buildEnvironment/channel.srt/codepage-channel/.castanet/publish.mrb 
> ...svnadmin: E200014: Checksum mismatch for 
> ‘/trunk/buildEnvironment/channel.srt/codepage-channel/.castanet/publish.mrb':
> expected: e8b415c62a9389736e70d82994612c5c
> actual: 1fcc3a2d7f40406c20301a6f52163429
>
> Any information would be very much helpful.

What version of svn (svnadmin) are you using (see svn --version or
svnadmin --version)? I'd suggest using 1.10.6 (latest LTS release) or
1.12.2 (latest regular release).

The problem could be with the tool that exported the dump from
Perforce of course (i.e. perhaps that tool created an incorrect dump
file). In that case there is not much the "Apache Subversion" project
can do to help (though perhaps others on this list might have
experience with the tool you're using).

-- 
Johan

Re: svn-crash-log20190911192859

[Johan Corveleyn]

On Thu, Sep 12, 2019 at 7:50 AM 明日 <421810...@qq.com> wrote:
>
> Hello: When I was restoring svn backup, the following error occurred
> svnadmin:E200014:Checksm mismatch for  
> excepted:d6a8b3bcfe071aa3431bd60189488082 
> actual:2dcf50751688e0e9648010f752129672
> Therefore, I would like to extract separately the part of the catalogue that 
> has no problems, and use the following command
> Svndumpfilter exclude Project Management Office/1.7 Server/< Operations > xm
> However, the problems in my attachment appear. Thank you very much for your 
> help.

Hi,

I'm copy-pasting here below a relevant excerpt from the svn-crash-log
that you attached:

[[[
Process info:
Cmd line: svndumpfilter  exclude 项目管理办公室/ 1.7服务器/
Working Dir: D:\cygwin64\home
Version:  1.10.6 (r1863367), compiled Aug 28 2019, 19:44:07
Platform: Windows OS version 6.1 build 7600

Exception: STATUS_NO_MEMORY

Registers:
Rax=597af153 Rcx=0030ec60 Rdx=0001
Rbx=000c
Rsp=0030f270 Rbp=07fef8b687d0 Rsi=004c2358
Rdi=002c
R8=  R9=  R10=
R11=0200
R12=07fef8b687d0 R13=0030f4e8 R14=004c23d0
R15=004bf7b0
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b

Stacktrace:
#1  0x7fefcfcaa7d in RaiseException()
#2  0x7feee6d9ece in svn_pool_create_ex_debug()
#3  0x7407b498 in apr_palloc()
#4  0x7feee69d649 in svn_stringbuf_ensure()
#5  0x7feee6e53f7 in svn_stream_readline()
#6  0x7fef8b659e0 in svn_repos_parse_dumpstream3()
#7  0x13f1d23e0 in (unknown function)
#8  0x13f1d1f45 in (unknown function)
#9  0x13f1d185d in (unknown function)
#10  0x13f1d1293 in (unknown function)
#11  0x76aff56d in BaseThreadInitThunk()
#12  0x76d33281 in RtlUserThreadStart()
]]]

I suppose "Exception: STATUS_NO_MEMORY" indicates that it crashed
because of a lack of memory. Somehow svndumpfilter must be using too
much memory when processing your dump file. You'll probably see its
memory usage rising very high when you observe the process in Task
Manager.

I'm not sure what the reason could be. Perhaps the dumpfile itself is
huge, or has something special ... Or maybe the memory footprint is
normal, but the machine you're running it on is low on available
memory.

Suggestion: maybe you can accomplish what you're trying to do by using
the new-since-1.10 "svnadmin dump --exclude" (i.e. exclude something
directly during the dump process, and not by using svndumpfilter).

See 
http://subversion.apache.org/docs/release-notes/1.10.html#dump-include-exclude.

-- 
Johan

Re: Breaking svnsync mirrors

[Johan Corveleyn]

On Fri, Sep 6, 2019 at 1:53 PM Branko Čibej  wrote:
>
> On 06.09.2019 13:23, Grierson, David (Lead Engineer) wrote:
> > Hi,
> >
> > We're in the process of migrating & upgrading our Subversion installation. 
> > In doing so we're encountering a handful of repos which were impacted by 
> > issue 4129 (https://subversion.apache.org/docs/issue4129).
> >
> > The fix for this (to dump & reload) has been successful with most of the 
> > repos, however to do this you need to have sufficient storage to duplicate 
> > the repos; and one of the repos in question is over 700GB in size!
> >
> > As an alternative, I'm looking to use svnsync to fix this repository; I'm 
> > just looking to clarify the process for completing this.
> >
> > On new host:
> >   1) svnadmin create /path/to/new-repo
> >   2) Create /path/to/new-repo/pre-revprop-change hook
> >   3) svnsync init file:///path/to/new-repo https://url/to/old-repo
> >   4) svnsync sync file:///path/to/new-repo
> >
> > Allow the data to copy across ... then ...
> >   5) svnsync copy-revprops --skip-unchanged file:///path/to/new-repo
> >
> > At this point there will be a copy of the existing repository. Periodically 
> > we'll then be able to run the 'svnsync sync' and 'svnsync copy-revprops' to 
> > copy across any new revisions.
> >
> > We'll then schedule the cutover weekend so would perform something like:
> >
> >   1) Disable access to repos on old host.
> >   2) Perform final 'svnsync sync ...' & 'svnsync copy-revprops ...' on new 
> > host.
> >   3) Shutdown Subversion on old host.
> >   4) Remove the following revision properties from revision 0 on 
> > /path/to/new-repo
> >svn:sync-from-url
> >svn:sync-from-uuid
> >svn:sync-last-merged-rev
> >svn:sync-lock
> >
> > I just want to confirm that my process seems sensible and that what I've 
> > described regarding breaking the svnsync mirror is correct.
> >
> > If anyone can see anything that I might have wrong or missed?
>
> Looks both sensible and correct to me, except that you seem to be
> missing one step:
>
> 5) Copy httpd and/or svnserve configuration and hooks from the old host.
>
> You don't want to keep hooks for the synced repository in the production
> repository.
>

And locks from $oldrepo/db/locks to $newrepo/db/locks (this can take a
couple of minutes ... lots of small files).

Those are the "working copy locks" (people running 'svn lock $file',
or their tool doing it for them), for which the server keeps the lock
tokens.

-- 
Johan

Re: svn x-shelve gives E200014: Checksum mismatch

[Johan Corveleyn]

On Fri, Aug 30, 2019 at 9:12 AM Mark P.  wrote:
>
> On 2019-08-30 06:11, Johan Corveleyn wrote:
> > On Wed, Jul 31, 2019 at 7:20 AM Mark P.  wrote:
> >>
> >>
> >>
> >> svn x-shelve shelf1
> >>
> >> I get the following output:
> >>
> >> Updating '.svn\experimental\shelves\v3\7368656c6631-001.wc':
> >> At revision 1.
> >> Sendingmain.cpp
> >> Transmitting file data .svn: E200014: Checksum mismatch for
> >> 'C:\Shared\Test\Test3\.svn\experimental\shelves\v3\7368656c6631-001.wc\main.cpp':
> >>expected:  b77dd03a6c3f68f496d874153363694e
> >>  actual:  7f081249d3e4e1383afb2798d46a58f5
> >>
> >
> > Hi Mark,
> >
> > Sorry for the late response.
> > This looks to me like a bug with the experimental shelving feature in 1.12.
> >
> > Is the file main.cpp "translated" into Windows end-of-line style in
> > the Windows working copy (vs. Unix eol-style on the FreeBSD machine),
> > i.e. does it carry the svn property "svn:eol-styl=native"? Perhaps
> > there is a bug when shelving, in that one side is eol-translated (and
> > checksummed) and the other is not.
> >
>
> Hi Johan,
>
> Thanks for the reply.  Yes, you're correct, svn:eol-style was set to
> 'native', and I think this is where the bug lies.
>
> I removed the property, ran:
>
> svn x-shelve shelf2
>
> and it seems to work as expected now, although ideally shelve should be
> able to work with eol-style=native.
>
> Mark

[ Re-adding the users@s.a.o list back to cc. Please use reply all to
keep the list in the loop. ]

Okay, thanks for checking this, and thanks for reporting this in the
first place.
So indeed this seems like a bug in x-shelve when working with
eol-style=native (and shelving it in a Windows working copy).

Could you please file an issue for that in our issue tracker?
https://issues.apache.org/jira/browse/SVN

If you would like to dig in further (going through the source code,
reading our community guide, possibly writing a patch etc. -- see
[1]), you're very welcome to do so. (no problem if you don't, your
report of the issue is already very useful)

Thanks,
-- 
Johan

[1] http://subversion.apache.org/contributing.html

Re: svn x-shelve gives E200014: Checksum mismatch

[Johan Corveleyn]

On Wed, Jul 31, 2019 at 7:20 AM Mark P.  wrote:
>
> Good day,
>
> I'm trying to use svn x-shelve on Windows, both via TortoiseSVN and via
> the command line client, and I'm getting the above error.  I'm using
> subversion version 1.12.2 everywhere.  I'm accessing the repositories
> using svn://
>
> After seeing this error on an existing repository, I:
> - created a fresh repository with nothing in it,
> - checked out the new repository to a working copy,
> - added a single file (main.cpp) with a few random lines of text in it,
> - committed the add,
> - altered the file,
> and then ran (from the command line):
>
> svn x-shelve shelf1
>
> I get the following output:
>
> Updating '.svn\experimental\shelves\v3\7368656c6631-001.wc':
> At revision 1.
> Sendingmain.cpp
> Transmitting file data .svn: E200014: Checksum mismatch for
> 'C:\Shared\Test\Test3\.svn\experimental\shelves\v3\7368656c6631-001.wc\main.cpp':
>expected:  b77dd03a6c3f68f496d874153363694e
>  actual:  7f081249d3e4e1383afb2798d46a58f5
>
> TortoiseSVN gives a similar, but less descriptive, error.
>
> This happens reliably, with any file I choose to add, when the
> repository and the working copy are on a FreeBSD machine and a Windows
> machine respectively.  Other repositories seem to do the same thing.
>
> When I try the same thing, with the same repository, but with the
> working copy on the FreeBSD machine (still accessed via svn://), it
> works as expected.
>
> When I try the same thing with a similar repository on the Windows
> machine (accessed via file://), and the working copy on the same Windows
> machine, it also works correctly.
>
> All other functionality seems to work fine (checkouts, commits, diffs,
> logs, etc.) with repositories on the same machines.  I've tried doing
> svn cleanup on the working copies, but I still have the same problem.
>
> Has anybody seen the same problem?  Is this something I'm doing wrong,
> or is it a bug?
>
> Thanks
> Mark

Hi Mark,

Sorry for the late response.
This looks to me like a bug with the experimental shelving feature in 1.12.

Is the file main.cpp "translated" into Windows end-of-line style in
the Windows working copy (vs. Unix eol-style on the FreeBSD machine),
i.e. does it carry the svn property "svn:eol-styl=native"? Perhaps
there is a bug when shelving, in that one side is eol-translated (and
checksummed) and the other is not.

-- 
Johan

Re: Remote renames create subtree mergeinfo

[Johan Corveleyn]

On Wed, Aug 21, 2019 at 6:55 PM Bryce Schober  wrote:
>
> I just noticed that whenever we do a remote rename (from URI to URI, as 
> opposed to in a working copy), svn add mergeinfo that didn't exist before. It 
> doesn't do this for renames in a working copy. Is this by design, or by 
> accident?

This is by design. See amongst others these mail threads:

https://svn.haxx.se/users/archive-2010-11/0357.shtml
https://svn.haxx.se/users/archive-2017-11/0017.shtml

-- 
Johan

Re: Questions about a script for regular backups

[Johan Corveleyn]

On Mon, Aug 26, 2019 at 9:01 PM Mark Phippard  wrote:
>
> On Mon, Aug 26, 2019 at 1:29 PM Anton Shepelev  wrote:
>>
>> I have now set up a post-commit hook that makes an
>> --incremental hotcopy.  With the destination on the same
>> machine's HDD, it takes about two seconds, but with a
>> network share it lasts 30 seconds.  Is it expected behavior
>> for committing a tiny change in a text file?  If not, then
>> where shall I look for the possible performance problems?  I
>> have svn 1.8.16.
>
>
> It is probably due to slowness of the IO across network to read what is in 
> the target repository and then copy over the files. Other than tuning NFS or 
> whatever you are using there is not much you can do.  This is why my first 
> recommendation was to use svnsync. You could have a second backup server 
> running and then use svnsync via https or svn protocol to that server.  This 
> basically replays the commit transaction so performs comparably to the 
> original commit. It also makes it a lot easier to send the backup around the 
> world or to another data center since it is using a protocol that is meant 
> for that sort of latency.
>

Does svnsync also copy locks and hook scripts?

Just to mention another option: Since 1.8 there is the command
'svnadmin freeze', which locks the repository for writing while you
run another command. That way, you can use regular backup / copy
commands (like rsync) to create a consistent copy. See the example
mentioned in the 1.8 release notes [1]:

svnadmin freeze /svn/my-repos -- rsync -av /svn/my-repos /backup/my-repos

Of course, in contrast with hotcopy, the original repository is locked
for a (hopefully short) while, so users might experience errors /
timeouts if this takes too long.

[1] http://subversion.apache.org/docs/release-notes/1.8.html#svnadmin-freeze

-- 
Johan

Re: svn status and info slowness when multiple files are passed as args

[Johan Corveleyn]

On Wed, Jun 26, 2019 at 9:33 AM Thuan Seah Tan  wrote:
>
> Apologies for the delay on this issue. I did more testing and the following 
> was my findings:
>
> svn info -r HEAD "svn://mysvnserver/1.10/test.txt" "svn:// name>/1.10/test2.txt" <-- slow
> svn info -r HEAD "svn://192.168.1.123/1.10/test.txt" "svn:// server>/1.10/test2.txt" <-- fast
>
> If I am not using the svn protocol and just passing in the file path on disk, 
> depending on how the files were checked out:
>
> if checked out using Tortoise SVN and specifying the repository server as 
> "svn://192.168.1.123":
> svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt" <-- fast
>
> if checked out using Tortoise SVN and specifying the address of the server as 
> "svn://mysvnserver":
> svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt" <-- slow
>
> Wondering if using the server name defaults to IPv6. I suppose that's up to 
> the router's configuration? When checking out files, is there something added 
> to the .svn folder that retains the knowledge of whether a file was checked 
> out using ipv4 or server name?
>

Ok, so it's clearly a problem with the client first trying the IPv6
address, to which svnserve doesn't respond in your case. Now, I don't
know a lot myself about how to deal with that situation (we don't use
svnserve, we're accessing our svn repository via https). Perhaps
someone else on this list has some experience, and can help a bit?

Just a couple of thoughts:
- The fact that svn://mysvnserver first defaults to the IPv6 address
is entirely up to network configuration, I guess. Not sure if it's the
router, local DNS server, Windows networking configuration, ... as I
said, I don't know much in that area. But perhaps that's the easiest
"fix" for you: fix the network configuration so clients get connected
to the IPv4 address by default.

- The .svn folder certainly retains knowledge of the exact URL it was
checked out from. It's visible when you run 'svn info' (showing the
working copy url). You can change that in an existing working copy by
running 'svn relocate' (see 'svn help relocate' for help), so you can
"connect" it with another URL pointing to the same repository.

- Perhaps that thread I pointed to earlier contains some more
interesting information about what else you can do.
https://svn.haxx.se/users/archive-2018-06/.shtml
(for instance, I see things about starting up a second instance of
svnserve with the -6 option for listening on the IPv6 address)

HTH,
-- 
Johan

Re: svn status and info slowness when multiple files are passed as args

[Johan Corveleyn]

On Thu, Jun 13, 2019 at 1:59 PM Thorsten Schöning  wrote:
>
> Guten Tag Thuan Seah Tan,
> am Donnerstag, 13. Juni 2019 um 09:25 schrieben Sie:
>
> > [...]I also tried running 'info -r HEAD' on files
> > that are checked out on the PC that the server was running, and it
> > is just as slow. Both the url and repository root fields started with 
> > "svn://localhost".
>
> As you are running Windows, disabling all kinds of AV-software at
> least for the directories belonging to your SVN-repos would be the
> first thing I'm trying. If that doesn't change a thing, use Process
> Monitor to see where the slowness comes from. That reports exactly
> which I/O happens where and how long it takes.
>
> https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
> https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning

Hm, I don't think the problem is "local IO slowdown" (like with
antivirus). That wouldn't explain "svn info -r HEAD -R directory"
taking 1-2 seconds (in the initial report by the OP).

@Thuan: has it always been that slow?
My intuition tells me to take a look at IPv4 vs. IPv6 problems. See
for example this thread on this mailinglist:
https://svn.haxx.se/users/archive-2018-06/.shtml

Also, in response to your question:
>> I am using Tortoise SVN 1.12.0 r1857323. When you say it could be optimized 
>> in the client, I take it that is up to the team maintaining the project 
>> (e.g. Tortoise SVN, Visual SVN, etc) and I should report the issue to them? 
>> Or is there some base client code used by these implementations?

Yes, there is "base client code" shared by all these implementations:
TortoiseSVN, Visual SVN, commandline SVN, ... they all share the same
underlying svn libraries that are maintained by this project, Apache
Subversion (of which you've reached the users mailinglist).

As for "reporting the issue to the team maintaining the project":
there is not really a dedicated "team" waiting to work on issues.
There are project members of the Apache Subversion project (some of
them are also reading this mailinglist -- I am one of them). Those
project members are just individuals like yourself, sometimes working
on things they care about (for themselves or for their employers) ...
such is the nature of FOSS. So reporting an issue or suggesting an
improvement will not magically make it happen. On the other hand, we
very much appreciate clear reports of issues or suggestions -- those
are definitely valuable contributions.

In other words: yes, it could be a good idea to officially write this
down into an issue in the issue tracker [1] (but we're still a bit
fuzzy on the details, I think we still need some further discussion /
troubleshooting), but to make expectations clear: reporting it does
not magically make it happen :-).

[1] http://subversion.apache.org/reporting-issues.html

Thanks,
-- 
Johan

Re: svn status and info slowness when multiple files are passed as args

[Johan Corveleyn]

On Wed, Jun 5, 2019 at 4:15 AM Thuan Seah Tan  wrote:
>
> Thanks for the response. I did more testing on the 1.12.0 server, and it 
> seems it's only those command options that I think would require querying the 
> server is experiencing the slow down:
>
> e.g.
> svn status --show-updates directory/file1.txt directory/file2.txt 
> directory/file3.txt <-- this took about 3 seconds  and seems to scale 
> according to the number of files as it outputs "Status against revision" for 
> each file.
> svn status --show-updates directory <-- this took about 1-2 seconds but only 
> output "Status against revision" once.
>
> svn info -r HEAD directory/file1.txt directory/file2.txt directory/file3.txt 
> <-- this took about 3 seconds and seems to scale according to the number of 
> files and display info for each file at the rate of 1 file per second
> svn info -r HEAD -R directory <-- this took about 1-2 seconds even though the 
> entire directory has 17 files and just outputs info for 17 files in one hit
>
> The server is on another machine in my local network and both running Windows 
> 10 Pro. Not entirely sure the filesystem you are referring to, but the drive 
> with the repository is running NTFS.

Is your client also version 1.12.0? Running 'svn --version' on the
client will tell.
It's just to eliminate that this was possibly optimized on the client
side in recent versions.

A couple of other things come to mind:

- It's possible that 'svn status --show-updates X Y Z' opens
(sequentially) 3 separate connections / sessions to the server,
instead of only 1. Same for your 'svn info -r HEAD' example. That's
something that could possibly be optimized in the client.

- How come it even takes 1-2 seconds for a single 'status
--show-updates' or 'info -r HEAD' request? That's extremely slow,
especially since you're saying it's all on a local network. Is it fast
if you create a working copy with a file:/// URL directly on the
server, and perform those commands there (it should be fast)? What
protocol are client and server using? Running 'svn info --show-item
url' on your working copy should tell. If it's https://, maybe there
is some problem / slowdown when opening a new SSL socket? Or
performing LDAP authentication on the server side. If it's svn://,
maybe there is a problem with IP v6 vs. IP v4.

-- 
Johan

Re: svn status and info slowness when multiple files are passed as args

[Johan Corveleyn]

On Tue, Jun 4, 2019 at 7:35 AM Thuan Seah Tan  wrote:
>
> Wondering if anyone has experienced slowness when running commandline svn if 
> multiple files are passed to svn status or svn info?
>
> For example:
> svn status directory/file1.txt directory/file2.txt directory/file3.txt
>
> In my tests, the output is generated at about the rate of 1 file per second 
> when doing so. Running svn status on the entire directory recursively turns 
> out to be much faster.

Doesn't ring a bell with me. Can you give some more context?
- Which OS?
- Which filesystem? Is it local or a network filesystem?
- Which version of SVN? If not the latest (1.12.0), can you try to
reproduce it with 1.12.0?

-- 
Johan

Fwd: V3 shelves slower than expected

[Johan Corveleyn]

Hi,

FYI: on the tortoisesvn users mailinglist some people reported
slowness of "shelves V3", compared to V1 and V2.

I thought this might be interesting to users@s.a.o in general, because
I'm guessing this problem is not specific to TortoiseSVN. I haven't
tried to reproduce it on the commandline myself, so my guess could be
wrong.

See below.

-- 
Johan

-- Forwarded message -
From: 

Date: Mon, May 13, 2019 at 4:50 PM
Subject: Re: V3 shelves slower than expected
To: TortoiseSVN 


On Wednesday, 8 May 2019 14:18:06 UTC+2, Tluigi003  wrote:
> I'm aware it's an experimental function, that's the reason I'm reporting this!
> Comparing to V1 and V2, V3 is slow on big projects.
>
>
> In my use case I've cloned an entire web project, including back, front, SQL 
> scripts... etc. However, as a front developer I only edit front files, 
> furthermore sometimes I have just edited a few items.
>
>
> The process of shelving will take some (from 2 to 5?) minutes until 
> completion. It's not a big deal, but I'm just curious about the reason behind 
> the change from V2 to V3
>
>
> Regards.

I can confirm this behavior. Shelving some tiny files with 1.12 showed
a dialog where it slowly transferred ~50MB before it completed,
whereas with 1.10 it was basically instant. This makes the whole
shelving feature rather unpleasant to use.

Re: SVN server ( (28)No space left on device: AH00023: Couldn't create the watchdog-callback mutex )

[Johan Corveleyn]

On Fri, May 10, 2019 at 9:14 AM Venkatakrishna Thumma
 wrote:
> Hi Team,
>
> Sometimes our SVN servers is going down and if we verify the logs we are 
> seeing below issue. But server has enough space.
>
> Can someone please help us in resolving the issue.
>
>
> [Mon Feb 18 03:36:05.063291 2019] [auth_digest:notice] [pid 31489] AH01757: 
> generating secret for digest authentication ...
> [Mon Feb 18 03:36:05.063627 2019] [ssl:warn] [pid 31489] AH01873: Init: 
> Session Cache is not configured [hint: SSLSessionCache]
> [Mon Feb 18 03:36:05.065530 2019] [ssl:warn] [pid 31489] AH01909: 
> 443:0 server certificate does NOT include an ID which matches the 
> server name
> [Mon Feb 18 03:36:05.067477 2019] [lbmethod_heartbeat:notice] [pid 31489] 
> AH02282: No slotmem from mod_heartmonitor
> [Mon Feb 18 03:36:05.067654 2019] [core:emerg] [pid 31489] (28)No space left 
> on device: AH00023: Couldn't create the watchdog-callback mutex
> [Mon Feb 18 03:36:05.067735 2019] [:emerg] [pid 31489] AH00020: Configuration 
> Failed, exiting
> [Mon Feb 18 04:20:12.619767 2019] [ssl:warn] [pid 22058] AH01909: 
> 443:0 server certificate does NOT include an ID which matches the 
> server name
> [Mon Feb 18 04:20:12.621528 2019] [suexec:notice] [pid 22058] AH01232: suEXEC 
> mechanism enabled (wrapper: /usr/sbin/suexec)

It seems to me that error is not specific to SVN, but to the Apache
httpd server in which the svn module runs. Searching for "(28)No space
left on device: AH00023: Couldn't create the watchdog-callback mutex"
results in a couple of hits that pertain to httpd in different
contexts than SVN. This one seems to give a possible cause and some
resolution options:

https://support.plesk.com/hc/en-us/articles/213368389-Unable-to-start-Apache-28-No-space-left-on-device-AH00023-Couldn-t-create-the-mutex

If that doesn't help, perhaps you should seek further help from the
Apache httpd community:
https://httpd.apache.org/support.html

-- 
Johan

Re: Same level externals not possible

[Johan Corveleyn]

On Tue, May 7, 2019 at 2:33 PM Osipov, Michael
 wrote:
>
>
>
> Am 2019-05-07 um 14:20 schrieb Branko Čibej:
> > On 07.05.2019 13:53, Osipov, Michael wrote:
> >> Hi folks,
> >>
> >> consider the following layout we need to solve for our legacy build:
> >>
> >> .
> >> |-- forms
> >> |-- src
> >> \-- inc
> >>
> >> inc shall point to forms as external. Wenn doing "svn ps" with "forms
> >> inc" or "./forms inc" I receive an error.
> >
> > Just to clarify, you want this:
> >
> > $ svn propset svn:externals './forms inc' .
>
> Correct. Expanded it is:
>
> /di1234/trunk
> |-- forms
> |-- src
> \-- inc

Can't you use the following?

$ svn propset svn:externals '../forms inc' .

or '../trunk/forms inc'
(not sure)

According to the book [1] '../' means "Relative to the URL of the
directory on which the svn:externals property is set"

[1] http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

-- 
Johan

Re: Subversion Exception svn_relpath_is_canonical in ra_loader.c

[Johan Corveleyn]

On Tue, Apr 30, 2019 at 9:28 PM Eliot, Christopher
 wrote:
> I am not subscribed to this mailing list.  If you need to reach me, please CC 
> me explicitly at christopher.el...@nagrastar.com

Hi Christopher,

> Running TortoiseSVN1.10 (r28148).
>
> Accessing SVN repository as https://ndev-svn01/svn/...
>
> TortoiseSVN had been running for a long time, I had done lots of things in it.
> I right-clicked on a tag and selected "Mark for comparison"
> I clicked on the trunk.
> Can't recall if I clicked "compare URLs" or not.
>
> Ooh.  This is repeatable.  I shut down TortoiseSVN complete and restarted it.
> Performed the same sequence of events; I get this same exception when I click 
> on
> "compare URLs".  I reproduced it a couple of times.
>
> I then selected the trunk and marked it for comparison, selected the tag, and
> was able to to compare them just fine.
>
> I then went back and repeated the original sequence of events and again got 
> the
> exception.

Thanks for taking the time to report this.

However, I'm afraid this community (the "core" subversion project)
can't help you directly. I think it's likely that this problem is
situated somewhere in the TortoiseSVN code (which is a separate
project, for the Windows GUI on top of the Subversion libraries). It
seems it is internally calling the Subversion libraries with a
"non-canonical path". Maybe there is something strange with the urls
that are constructed here?

If you report this to the TortoiseSVN community
(https://tortoisesvn.net/community.html), they might be able to
provide more help or to ask more specific questions to find out what's
going on.

> I'll look into updating TortoisSVN.
>
> When I update to 1.12, it’s unusable.  When I click on the directory for my 
> project, I get a popup that just says “TortoisesSVN client has stopped 
> working.  A problem caused the program to stop working correctly.  Please 
> close the program.”  It seems to be a problem with just this project; I can 
> click down into other projects in the same repository.  I’ll report that 
> separately.

Here again I think you should probably contact the TSVN community. It
might be related to the first problem (some non-canonical url being
passed to the libraries, specific to that one project). Or it might be
something else.

> ---
> 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
> https://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.10.0\ext\subversion\subversion\libsvn_ra\ra_loader.c'
> line 629: assertion failed (svn_relpath_is_canonical(path))
> ---
> OK
>
> Topher Eliot


-- 
Johan

Re: I need a decoder ring for the qacct output

[Johan Corveleyn]

On Thu, Apr 25, 2019 at 3:24 AM Mun Johl  wrote:
>
> Hi,
>
> I'm using 'qacct -P' in the hope of tracking metrics on a per project
> basis.  I am getting data out of qacct, however I don't fully comprehend
> what the data is trying to tell me.
>
> I've searched the man pages and web for definitions of the output of
> qacct, but I have not been able to find a complete reference (just bits
> and pieces here and there).
>
> Can anyone point me to a complete reference so that I can better
> understand the output of qacct?
>
> Thank you,
>
> --
> Mun

Hi Mun,

I think you have sent your question to the wrong mailing list. This
list is the users mailinglist of Apache Subversion, which has nothing
to do with qacct as far as I know.

-- 
Johan

Re: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network

[Johan Corveleyn]

On Wed, Apr 24, 2019 at 12:41 PM Marlow, Andrew
 wrote:
> -Original Message-
> From: Johan Corveleyn 
...
> > Where are you checking out your software? Is it on a local disk?
> Yes.

Okay, then there must be something strange with this local disk; or a
second process is interfering with 'svn' trying to lock its database.
In any case, no network is involved then, so "flaky network" can't be
the cause of your problem. The error you received specifically points
to a problem while locking the working copy database:

[[[
svn: E200033: Another process is blocking the working copy database,
or the underlying filesystem does not support file locking; if the
working copy is on a network filesystem, make sure file locking has
been enabled on the file server
svn: E200033: sqlite[S5]: database is locked
svn: E200042: Additional errors:
svn: E200033: sqlite[S5]: database is locked
svn: E200030: sqlite[S1]: cannot start a transaction within a transaction
svn: E200030: sqlite[S1]: cannot start a transaction within a transaction
]]]

To be clear: the "working copy database" is an sqlite database in the
"wc.db" file inside the .svn directory at the root of your working
copy.

I'm not sure what else to suggest, but "something" is preventing 'svn'
from locking its database; and since you're using a local disk, it
seems to me that "network" is not involved in this locking process.

BTW, what version of SVN are you using?

-- 
Johan

Re: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network

[Johan Corveleyn]

On Wed, Apr 24, 2019 at 11:51 AM Marlow, Andrew
 wrote:
>
> Sorry everyone, I mis-spoke below. While looking at this issue I was also 
> filing a bug report on the maven jar signing plugin, which also has a problem 
> when the network is flaky. That is the thing that was calling out to the 
> timestamp server, not svn. I got mixed up, sorry.
>
> Regarding the comment that was made, I don't know exactly how the svn repo is 
> hosted in the corporate environment I am in. It is accessed via an http URL 
> (not https, I know). The underlying filesystem is Windows because every now 
> and then we get aggro due to the case preserving behaviour of the Windows 
> filesystem. But is it on a network share? Not sure, but I don't think so. IMO 
> that would be an extremely bad setup.
>

The network share Stefan and I are referring to is not on the server
side (which is accessed via https, that's fine; and we're not
concerned with how that server is set up). We're talking about the
client-side location where you're putting your working copy. I'm not
sure you fully understand the difference between "repository"
(server-side, single source of truth of the entire history) and
"working copy" (client-side checkout, where you perform local work to
perform commits from, and "update" to get other's changes). See [1]
for some more explanation.

Where are you checking out your software? Is it on a local disk? Or on
a CIFS mounted filesystem (Windows) or on an NFS-mounted filesystem,
or SMB, ... if you're on Solaris?

For example, are you doing the following?

1) Log into your Windows pc.

2) cd \\some\network\share (or cd M:\subdir; where M: is a mapped
network drive)  <- this is where you're putting your working copy

3) svn checkout https://svnserver.example.com/path/to/repo  <- this is
the URL to the repository, which can be hosted on Windows, Solaris,
Linux, ... whatever


If in step 2 you're indeed using some network share as the location
for your working copy, that could be problematic. As Stefan said, this
is discouraged, and you should try to put working copies on local
disks. And if you really must work with networked filesystems for your
working copy, you should look at the configuration options in the
[working-copy] section of the client-side configuration file "config"
(see [2] for some general information about the client-side config
files). Maybe some tweaks there can help.

[1] http://svnbook.red-bean.com/nightly/en/svn.basic.version-control-basics.html
[2] http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html

-- 
Johan

Re: svn version 1.10 lack of robustness in presence of flaky network

[Johan Corveleyn]

On Mon, Apr 22, 2019 at 9:22 AM Marlow, Andrew
 wrote:
> Hello everyone,
>
> I got this error below during an svn co command. It left my workspace in a 
> bad state from which I had to do svn cleanup before trying again (the retry 
> worked):
>
> svn: E200033: Another process is blocking the working copy database, or the 
> underlying filesystem does not support file locking; if the working copy is 
> on a network filesystem, make sure file locking has been enabled on the file 
> server
> svn: E200033: sqlite[S5]: database is locked
> svn: E200042: Additional errors:
> svn: E200033: sqlite[S5]: database is locked
> svn: E200030: sqlite[S1]: cannot start a transaction within a transaction
> svn: E200030: sqlite[S1]: cannot start a transaction within a transaction
>
> I think this happens when the network is flaky. This error happened on 
> windows but I have also seen it happen on solaris 10.  Has anyone else seen 
> this? If it is due to network flakiness then perhaps svn should retry to work 
> around this transparently, and thus be more robust? Perhaps it could retry up 
> to 3 times with a sleep a 1 second between retries?
>

Is your working copy on a network filesystem (CIFS, NFS, ...)? And are
you talking about a flaky network between your machine and its
networked filesystem? If so, I think there is not much we can do about
it ... the filesystem you're checking out to should reliable. There is
already a retry loop in some places for putting checked out files into
place, to work around locks from antivirus software etc, ... (but the
sqlite database itself should be reliably available).

Or are you talking about flakiness of the network between your svn
client and the svn server? In that case, I would not expect this kind
of error.

-- 
Johan

Re: Getting a diff file from java svnkit

[Johan Corveleyn]

On Sun, Apr 21, 2019 at 12:22 PM Sharma,Deepank
 wrote:
>
> I’m stuck on the same thing for the past few days. Could you tell me how you 
> got the solution to this? It’ll be a great help.

Hi,

Svnkit is a separate project (a pure Java re-implementation SVN), and
is not maintained by the Apache Subversion community. You might have
more luck asking on one of their mailinglists:
https://svnkit.com/support.html#mailing-lists

-- 
Johan

Re: Understand call stack of subversion

[Johan Corveleyn]

On Tue, Apr 9, 2019 at 10:06 AM Ranade, Tanvi  wrote:
>
> Hi ,
>
> I am new to programming. I am asked to extend libsvn_fs to create new 
> implementation for sqlite. So far , I have read the code , checked out and 
> built subversion and went through schema of tables mentioned in berkeley DB 
> implementation. Can anyone please explain how to figure out which functions 
> to implement and how to proceed hereonwards.
>

Hi,

You might need to ask your question again on d...@subversion.apache.org
(see http://subversion.apache.org/mailing-lists.html#dev-ml). But I'm
not sure how many "volunteer resources" are available to help you with
this ... the dev community is pretty small these days. So self-study,
and asking concrete questions for things you don't understand, might
be the best approach.

One word of caution though: the BDB back-end has been deprecated since
SVN version 1.8 [1], which is already more than 5 years ago. That
doesn't mean it won't work, but bugs or feature requests for that API
might not get much attention from the community; and new features that
were (or will be) implemented for FSFS might not have an equivalent in
the BDB back-end anymore ...

[1] http://subversion.apache.org/docs/release-notes/1.8.html#bdb-deprecated

-- 
Johan

Re: E175012 and E175002 when trying to commit

[Johan Corveleyn]

On Tue, Apr 2, 2019 at 10:20 PM Daniel Shahaf  wrote:
>
> Christoph Vogtländer wrote on Tue, 02 Apr 2019 09:02 +00:00:
> > This is reproducible. Running with de_DE.UTF-8 (my default LANG), svn
> > will try to submit the change but runs into a time-out. Running with
> > en_GB.UTF-8, svn fails with error 413.
> >
> > Why is subversion acting differently with different language setting on
> > the client side?
> >
>
> I'm not sure, especially given that both locales are UTF-8 ones.

Perhaps the difference between your first and second attempt is not
caused by different language settings, but because the working copy
was in a different state? For instance, if the "base" of your working
copy is full of mixed revisions, and you're committing a lot of
changes on top of that, the "edit report" that's sent by the client to
the server can be much larger (thus hitting some limit on the server).
Maybe try to execute another 'svn update' on your entire working copy
so it gets a uniform revision.

> A few
> shots in the dark:
>
> - Try '-F /dev/null' instead of '-F svn-commit.tmp'.
> - Is there any non-ASCII in the output of `svn st -q`?  (`svn st -q | sed 
> 's/[ -~]//g' | grep .`; that's left bracket, space, minus, tilde, right 
> bracket)
> - Try LC_ALL=C and LC_ALL=C.UTF-8.
>
> > Any ideas what can be done to successfully commit the changes?
>
> Depends.  If you want to make the changes in one commit, you'll need to
> increase the timeouts in server and client sufficiently (that includes
> any proxies).  A workaround is to separate the changes to several
> commits: use 'svn commit -- ./foo ./bar' instead of 'svn commit -- ./'.

Just another hint to get you started: the client-side timeout can be
found in the file ~/.subversion/servers on your client machine. Look
for "http-timeout = ..." (the default is 60 (seconds) I believe).

Also, on the server-side, the httpd directive LimitXMLRequestBody
might be playing a role in that second error ("Request Entity Too
Large"). In our setup at work we have "LimitXMLRequestBody 0" in our
httpd config, to effectively have no limit (for a publicly exposed
repository you should always have some limit, to avoid malicious users
being able to crash your server, but if you only have internal users I
think it's OK to eliminate that limit).

Though I would seriously recommend splitting up your huge commit into
several commits. Perhaps find some logical blocks, or split by
subdirectories, or ... Huge commits can be a pain later on, for
instance because every time you query the 'svn log' for one of those
files later, this huge commit will be part of the result (part of its
history), and with the '-v' (verbose) option 'svn log' will show all
the affected paths, which will be huge ...

> I'm not sure why you'd get a 413 on the request to !svn/me, though.  (to
> the list) Are any requests made to !svn/me other than the initial POST?

Sorry, no idea.

-- 
Johan

Re: RE: svn log -r based on a start date suddenly no longer returns any revisions

[Johan Corveleyn]

On Mon, Apr 1, 2019 at 9:58 AM Andreas Stieger  wrote:
>
> Nate Kerkhofs wrote:
> > [...] this repo does not have monotonically increasing dates [...]
>
> > The appropriate way to fix this would most likely be to simply create a new 
> > svn repository from scratch
>
> Actually you could set the svn:date revision property on the existing 
> repository.

Another option (if you're considering rewriting the repository) is to
use svndumptool [1], with its 'merge' command.
(I haven't used it myself, just pointing it out, because I read the
readme of the tool)

[1] https://github.com/jwiegley/svndumptool

--
Johan

Re: Subversion Exception!

[Johan Corveleyn]

On Mon, Dec 10, 2018 at 9:47 AM Peta Miller  wrote:
>
> Hello,
>
>
>
> i got following exception at trying to start the tortoisesvn Project Monitor 
> with a doubleclick on the tray icon.
>
> System: WIN 10, Build 15063
>
> ---
> 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
> https://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.10.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
>  line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
> ---
> OK
> ---

[ Moved this thread to users@subversion.apache.org -- bcc'd dev@ so it
is dropped on further replies ]

Hi Peta,

It is likely that this is a problem specific to TortoiseSVN, and not
to core SVN. TortoiseSVN has its own mailinglists, so you should
report your problem there:

https://tortoisesvn.net/community.html

(Before doing so, you could perhaps upgrade to the latest version,
1.11.0, and see if the problem is already fixed)

-- 
Johan

Re: Subversion Exception!

[Johan Corveleyn]

On Mon, Dec 10, 2018 at 1:04 PM wuzhouhui  wrote:
>
> Let me translate it for English people.
>
> >
> >-Original Messages-
> >From:"为呐☆而狂"
> >Sent Time:2018-12-09 01:01:49 (Sunday)
> >To: users
> >Cc:
> >Subject: [CASS SPAM]Subversion Exception!
> >
> >Hello:
> >
> >   I installed Tortoise SVN in the C:\Program Files\TortoiseSVN directory, 
> > but it was not loaded into the D disk at all. How can I report this error?
> >
> >
> >  ---
> >  Subversion Exception!
> >  ---
> >  Subversion遇到了一个严重的问题。
> Subversion encountered a serious problem.
> >  麻烦您花点时间将这个问题报告给Subversion
> Please report this issue to Subversion
> >  请尽量详细的描述您之前尝试的操作。
> Please describe the steps that you did.
> >  不过希望您先在邮件存档中搜索一下同样的问题，避免重复提交。
> Before report this issue, please search archive for avoid reporting same 
> issue.
> >  您可以登录下面的地址搜索邮件存档：
> You can search archive in following location:
> >  http://subversion.apache.org/mailing-lists.html
> >
> >  Subversion产生的报告如下
> >  (您可以用Ctrl-C快捷键复制
> >  本对话框的内容到剪切板)：
> Following is outputs that Subversion generated:
> >
> >  文件
> >  
> > “D:\Development\SVN\Releases\TortoiseSVN-1.9.7\ext\subversion\subversion\libsvn_wc\wc_db.c”，行
> >  9210：断言失败(svn_dirent_is_absolute(local_abspath))
> “D:\Development\SVN\Releases\TortoiseSVN-1.9.7\ext\subversion\subversion\libsvn_wc\wc_db.c”，Line
> 9210：Assertion failed(svn_dirent_is_absolute(local_abspath))
> >  ---
> >  确定
> Confirm
> >  ---

First thing to do is to upgrade to the latest release of (Tortoise)SVN
and try again. Currently the latest version is 1.11.0.

-- 
Johan

Re: Check Path based authorization

[Johan Corveleyn]

On Wed, Dec 12, 2018 at 9:28 AM Stuempfig, Thomas
 wrote:
>
> Hi Brane,
>
> sorry i cannot post the contents of VisualSVN-WinAuthz.ini file since it is 
> company security related.
> I will take some time to setup a separate Demo LDAP, but this will take some 
> time.
>
> But basically my observation is
>
> 1) You have ldap group "GroupA"
> 2) Within that group you have users user_a and user_b (memberOf Attribute)
>
> now
> 3)  you setup your  repo authz file
> *
> [/]
> user_a  rw
> GroupA  rw
> *
>
> (I explicity do not include something like Group_A=user_a,user_b and set 
> @Group_A rw in authz file as this would duplicate ldap definition
> of Group membership)
>
> svnauthz gives "rw" for user_a and "Result no" for user_b
>
>
>
> my guess is that svnauthz does not evaluate the actual ldap info and ony 
> cares about groups defined in authz file whereas "svn --username .. ." does 
> authenticate with the ldap-group.  If I am thinking about the svnauthz 
> commandline, svnauthz has no information about the ldap connection which sits 
> in apache httpd.conf.
>

Okay, it seems there is some misunderstanding here. First of all,
"core" svn does not by itself have support for LDAP groups for
authorization. Indeed, it only looks at groups that are defined in the
authz file itself.

The VisualSVN-WinAuthz.ini file is an extra feature developed by
VisualSVN, on top of "core" svn. So indeed, the svnauthz commandline
tool does not know about those groups.

To get some help on using / validating the VisualSVN-WinAuthz.ini
file, you'll have to reach out to VisualSVN people (some of them are
reading this list too, so they might be able to comment further here).

-- 
Johan

Re: SVN crashing

[Johan Corveleyn]

On Tue, Nov 27, 2018 at 8:51 AM Ramesh Belli  wrote:
>
> Hi Sir,
>
> SVN is crashing when I try to download from the trunk.
>
> Can you please point me to the right solution.

Hi Ramesh,

I see that you're using version 1.8.9 of SVN, which is quite old, and
not supported anymore. So the first thing to try is to upgrade to the
most recent version (preferably 1.11.0 or 1.10.3) and try again.

You can find some links to binary packages for Windows here:
http://subversion.apache.org/packages.html#windows

-- 
Johan

Re: Filesystem corrupt issue in repo

[Johan Corveleyn]

On Wed, Nov 7, 2018 at 2:05 PM Dennis Jakobsen  wrote:
>
> Hi,
>
> I have a repo that returns no errors with 'svnadmin recover' or
> 'svnadmin verify', but dumping and loading into a new repo gives me:
> svnadmin: E160004: Filesystem is corrupt
> svnadmin: E200014: Checksum mismatch while reading representation:
> expected:  aa2f4b4990d8a287d104dd30ddf50ab0
>   actual:  9ba98374833678825028dcadcd521ece
>
> This is a simple svnadmin dump svnrepo > repo-backup and svnadmin load
> svnrepocopy < repo-backup.
>
> I tried filtering out the offending branch but it gives me a:
> svndumpfilter: E23: Invalid copy source path
> '/branches/bugfix-1_2/some-file-in-my-repo.txt'
>
> System info:
> svnadmin --version
> svnadmin, version 1.9.7 (r1800392)
> cat /proc/version
> Linux version 4.15.0-38-generic (buildd@lcy01-amd64-023) (gcc version
> 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018
>
> Hope i have a shot at fixing it, right now my dumps are not a viable
> backup solution :(

This might be due to this bug in the checksum verification:

https://issues.apache.org/jira/browse/SVN-4722 (checksum fail during
commit when delta is 16K)

The fix was released in 1.9.9.

Also note that 1.10.3 and 1.11.0 have been released already. Those
should not be affected by this bug, so it might also be a good
opportunity to upgrade to these more recent releases ...

-- 
Johan

Re: Re[2]: Subversion Exception on commit wirth pathfile

[Johan Corveleyn]

[ bcc: dev@subversion.a.o because that's where this thread started,
but it really belongs on users@ so redirecting it there ... ]
[ Rearranged reponses from top-posting to bottom-posting ... see below
for some new information. ]

On Thu, Oct 18, 2018 at 12:52 PM Yakov Maryanov  wrote:
> On 18 October 2018, 13:25:09 Bert Huijben  wrote:
>> On Thu, Oct 18, 2018 at 12:13 PM Johan Corveleyn  wrote:
>>> On Thu, Oct 18, 2018 at 11:34 AM Yakov Maryanov  wrote:
>>>>
>>>> Hello!
>>>>
>>>> I execute command:
>>>>
>>>> "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:commit 
>>>> /pathfile:"d:\SVN\Work\Source\Project\f2.txt"
>>>>
>>>> File f2.txt contains two strings:
>>>>
>>>> d:\SVN\Work\Source\Source\Project.Client
>>>> d:\SVN\Work\Source\Source\Project.Server
>>>>
>>>> And I received such result:
>>>>
>>>> ---
>>>> 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
>>>> https://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.10.2\ext\subversion\subversion\libsvn_wc\wc_db.c'
>>>>  line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
>>>> ---
>>>> OK
>>>> ---
>>>>
>>>> Am I doing something wrong, or is this a bug?
>>>
>>> Hi Yakov,
>>>
>>> This might be a problem specific to "TortoiseSVN", and not in "core
>>> svn". This mailinglist is for discussing the development of the core
>>> svn functionality (the Apache Subversion project), so we don't know
>>> anything about TortoiseProc.exe and how it handles its arguments etc
>>> (eventually calling the underlying SVN libraries). So I suggest you
>>> report this to one of the specific TortoiseSVN mailinglists. See
>>> https://tortoisesvn.net/community.html.
>>>
>>> Thanks,
>>> --
>>> Johan
>>
>> Could you try this same operation with the disk names capitalized?
>>
>> If this resolves the issue, please let us and the TortoiseSVN developers 
>> know, as in that case there is an issue in (their) path canonicalization api.
>>
>>Bert
>
> I have done "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" 
> /command:commit /pathfile:"D:\SVN\Work\Source\Project\f2.txt"
> and D:\SVN\Work\Source\Source\Project.Client in file f2.txt. Result is the 
> same.
>
> Thanks,
> Yakov

For the benefit of the subversion lists and their archives I'm adding
some extra information:

Yakov posted this problem to the tortoise users list [1], and it seems
the problem was identified. Stefan Küng answered the following:

>>> File f2.txt contains two strings:
>>>
>>> d:\SVN\Work\Source\Source\Project.Client
>>> d:\SVN\Work\Source\Source\Project.Server
>>
>> is the file encoded in utf-16? It has to be, ANSI or utf-8 won't work.
>>
>>> 'D:\Development\SVN\Releases\TortoiseSVN-1.10.2\ext\subversion\subversion\libsvn_wc\wc_db.c'
>>>
>>> line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
>>
>> this means the paths passed in the file are wrong. Either because the file 
>> f2.txt isn't encoded in utf16 or the paths are not correct/don't exist.
>>
>> Stefan
>
> In utf-16 encoding it's all right
>
> Thank you

[1] 
https://groups.google.com/d/msgid/tortoisesvn/fd22df25-c875-432d-a4dc-294139ba6935%40googlegroups.com

-- 
Johan

Re: a issue of --include' and '--exclude' options on 'svnadmin dump'

[Johan Corveleyn]

On Tue, Oct 16, 2018 at 11:56 AM 钱海远(Nathan) 
wrote:

> Dear Sir,
>
>
>
> During I am testing the -include' and '-exclude' options on 'svnadmin
> dump'  ,  I found that if I copy a non-include file, the  dump result is to
> add a file with file content; But if the copy is a non-include directory,
> the dump only adds this directory.
>
>
>
> I think, this may be wrong, it should be copy of the directory and all the
> files under the directory .
>
>
>
> [root@RD-230 subversion]# svnadmin dump /data1/svnroot/Dev --incremental
> -r 13386 --include "/CM Action/Tools" > /tmp/test.dmp
>
>
>
> 已转存版本 13386。
>
> [root@RD-230 subversion]# cat /tmp/test.dmp
>
> SVN-fs-dump-format-version: 2UUID: 313b818e-f7ce-944b-8d5d-4aca2895b6b9
>
>
>
> Revision-number: 13386
>
> Prop-content-length: 89
>
> Content-length: 89
>
>
>
> K 10
>
> svn:author
>
> V 11
>
> qianhaiyuan
>
> K 8
>
> svn:date
>
> V 27
>
> 2018-07-04T04:18:48.877124Z
>
> PROPS-END
>
>
>
> Node-path: CM Action/Tools/diffcount
>
> Node-kind: dir
>
> Node-action: add
>
> Prop-content-length: 10
>
> Content-length: 10
>
>
>
> PROPS-END
>
>
>
> In fact, the copy directory has many files. But the dump file is only add
> a new dir.
>
>
> --
>

Hi Nathan,

Thanks for reporting this.
I see you had previously filed an issue about this in our issue tracker:
https://issues.apache.org/jira/browse/SVN-4760 (a issue of --include' and
'--exclude' options on 'svnadmin dump')
(and added this in comment to the "feature request issue"
https://issues.apache.org/jira/browse/SVN-4729 (Add '--include' and
'--exclude' options to 'svnadmin dump'))

And you were directed here to discuss the issue.

This does indeed look like a bug / shortcoming of the current "dump with
include/exclude".

I hope someone with expertise in this area of funtionality might be able to
comment here.

-- 
Johan

Re: svndumpfilter and svnsync?

[Johan Corveleyn]

On Wed, Oct 10, 2018 at 11:18 AM Chris  wrote:
...
> >>> The syntax I used: svnadmin dump -q MYREPO | svndumpfilter exclude
> >>> --targets filterfile filterdump svnadmin load -q --no-flush-to-disk
> >>> --force-uuid -M 2048 --bypass- prop-validation ./NEWREPO < filterdump
> >>>
> >>> (I had to use the bypass-prop-validation due to some newline issues
> > in old log message, similar to this one
> > https://groups.google.com/forum/#!topic/subversion_users/P3ohZ-hKhCA,
> > don't know why they have wrong newlines, but the repo works as it is
> > now...)
> >>
> >> Instead of ignoring wrong newlines, you could fix them using
> >> svndumptool (using its eolfix-revprop command), originally at:
> >>
> >> http://svn.borg.ch/svndumptool/
> >>
> >> Newer fork at:
> >>
> >> https://github.com/jwiegley/svndumptool
> >
> > Also, as of version 1.10, svnadmin finally has an option to normalize
> > these on-the-fly during 'load':
> > http://subversion.apache.org/docs/release-notes/1.10.html#normalize-
> > props
> >
> > It's a lot better to normalize these (either with the
> > --normalize-props option for 'svnadmin load' or by using svndumptool)
> > than to "bypass" them. Otherwise you'll run into this again later (if
> > you would dump+load again sometime in the future).
>
> I tried --normalize-props and I still got the same error which is why I
> switched over to bypass. Maybe I've run into some bug with --normalize-props.
> Unfortunately, I don't think I'll be able to create a script for reproducing
> the error since it happens far into a monster dump load.
> So I'll stick with the bypass for now or try the tool that Ryan suggested.

In that case the culprit might be another property than svn:log (or it
might be something like "non UTF-8 encoded" but not EOL-related in
svn:log). Possibly a "versioned" property like svn:ignore or some
other property in the svn: namespace. This is more difficult to fix,
but still it might be best to get rid of it or you'll run into it
again in the future.

See the very last bullet in:
http://subversion.apache.org/faq.html#dumpload

If that's indeed the problem, then you'll have to use that svndumptool
that Ryan pointed you to.
Quoting from that last bullet in the FAQ entry above:

"This is more difficult to repair, because 'svn:ignore' is not a
revision property (unlike svn:log, which can be manipulated with
svnadmin setrevprop), but a versioned property (so it's part of
history). Again, you can ignore this with --bypass-prop-validation.
But since this is a corruption "in history", this can only be repaired
with a dump+load, so this might be a good time to try and fix this (or
you'll run into this again in the future). To repair it you can use a
tool like svndumptool. But it only works on dump files, not as part of
a pipe. So a possible way to go about it is: dump that single
(corrupt) revision to a file, repair it ('svndumptool.py eolfix-prop
svn:ignore svn.dump svn.dump.repaired'), load that single dumpfile,
and then continue with a new "piped" command (like step (6) above). "

I should note here that svnsync is more powerful in this regard: it
does have the ability to normalize all of these on the fly. It's a
real pity that 'svnadmin load' doesn't (except for the svn:log EOL
fixing). Doesn't *yet* that is, until a volunteer comes along that
submits a patch for it ;-).

Anyway, I hope you succeed in cleaning this up eventually :-).
-- 
Johan

Re: svndumpfilter and svnsync?

[Johan Corveleyn]

On Wed, Oct 10, 2018 at 9:16 AM Ryan Schmidt
 wrote:
>
>
>
> On Oct 10, 2018, at 02:04, Chris wrote:
>
> > I've trawled through bad commits of data files in our repo and added such 
> > paths to a filter file that I'm using for svndumpfilter to get a 
> > reasonably-looking dump. In most cases, the files in question existed in a 
> > single path(branch( and were no problem. But in some cases, the same files 
> > had been copied to a 2nd branch and then svndumpfilter gave me errors about 
> > missing source paths, so I added the same path on the 2nd branch to the 
> > filter expressions and tried again. After a few iterations of this process, 
> > I have a dump that should do what I want.
> > So I start "svnadmin load" and based on initial progress, that might take a 
> > couple of days to complete so I leave it overnight. I get back today and 
> > the load has crashed with a missing path. The error was:
> >
> > svnadmin: E160013: File not found: transaction '16289-ckh', path 
> > 'branches/second/dir/datafile'
> >
> > And looking up the history for that file, I see that "datafile" was added 
> > on branch "first" but the path "branches/first/dir" is already in my filter 
> > list. So why didn't svndumpfilter throw me an error on this like it did for 
> > a lot of other cases?
> > Since the load process it so much slower, the turnaround time for each 
> > error in that step is beyond painful, so if there's anything that I can do 
> > to assure that this gets caught by the filter would make my life a lot 
> > easier.
>
> I don't know the answer to that, but:

Hm, not really a clear answer here either. I don't know why
svndumpfilter did not detect these.

However, you might also give 'svnadmin dump --exclude' a try, if you
can use version 1.10 of svnadmin.
http://subversion.apache.org/docs/release-notes/1.10.html#dump-include-exclude

This feature works similarly to 'svnsync with an authz file that
denies the excluded files'. That means that, when the source of a copy
is excluded, the copy is transformed into an add (so to complete
eliminate a bad file and all its copies this might be more difficult
to get a hold of these copies ... you won't get any warnings or errors
I think -- not sure if it emits a notification for such a copy-to-add
conversion). OTOH, 'svnadmin dump --exclude' supports wildcards if you
add the --pattern option, so it might be easier to filter out all
appearances of a specific filename, as in 'svnadmin dump --pattern
--exclude /*/datafile'.


>
> > The syntax I used:
> > svnadmin dump -q MYREPO | svndumpfilter exclude --targets filterfile > 
> > filterdump
> > svnadmin load -q --no-flush-to-disk --force-uuid -M 2048 
> > --bypass-prop-validation ./NEWREPO < filterdump
> >
> > (I had to use the bypass-prop-validation due to some newline issues in old 
> > log message, similar to this one 
> > https://groups.google.com/forum/#!topic/subversion_users/P3ohZ-hKhCA, don't 
> > know why they have wrong newlines, but the repo works as it is now...)
>
> Instead of ignoring wrong newlines, you could fix them using svndumptool 
> (using its eolfix-revprop command), originally at:
>
> http://svn.borg.ch/svndumptool/
>
> Newer fork at:
>
> https://github.com/jwiegley/svndumptool

Also, as of version 1.10, svnadmin finally has an option to normalize
these on-the-fly during 'load':
http://subversion.apache.org/docs/release-notes/1.10.html#normalize-props

It's a lot better to normalize these (either with the
--normalize-props option for 'svnadmin load' or by using svndumptool)
than to "bypass" them. Otherwise you'll run into this again later (if
you would dump+load again sometime in the future).

And another tip: put the repo-to-be-loaded-into (NEWREPO) on as fast a
storage system as possible (SSD, ramdisk if feasible, ...). If you're
satisfied with the result, run 'svnadmin pack' on that fast storage,
and only then copy it over to the final location. Depending on the
final storage that technique might save you a lot of time (especially
if you have to redo it a couple of times).

> > An additional question about what Johan wrote below:
> >> - You can perfectly well use a 1.10 version of svnadmin or svnsync (or 
> >> svnrdump, to create
> >> a dumpfile from a remote server) to interact with a 1.8 server / 
> >> repository.
> >
> > Can I even do this with "svnadmin load"; I thought that would use an FSFS 
> > version 8 while 1.8 should have 6? I got that impression from my 
> > "research", but I'm probably off base.
>
> If you use a newer version of svnadmin (than the one that will be used to 
> serve the repo) to create the new repo and load the dump file, then make sure 
> you pass the right --compatible-version argument to svnadmin create.

Indeed. It's at 'svnadmin create' time that the FSFS version is
decided. 'svnadmin load' will just "commit" new revisions in the
repository that you first created, and it will follow / respect the
FSFS format that's already set. So it's perfectly doable to create an

Re: svndumpfilter and svnsync?

[Johan Corveleyn]

On Thu, Oct 4, 2018 at 3:03 PM Chris  wrote:
>
> (apologies for the top-posting, I really need to stop using this yahoo web 
> interface which is useless with quoting)
>
> Thanks for all the replies. I'll try out what you outlined. There are 
> unfortunately problems outside of my control that makes it worse and that is 
> that for company-internal policy reasons, I'm not allowed direct access to 
> the server, I'm only able to get a copy of the repo to work with and a 
> promise that they can replace the repo with my modified version when I'm 
> done. This might make some of the suggestions hard to work with, but I'll see 
> if seems possible. Also, the server runs 1.8, and I have no authority to get 
> it upgraded. I think I may have a chance to change the read permissions for 
> the sync user though, so there's a ray of light somewhere in there :)
>
> W.r.t. Johan's question about the time consumption for dumping, I haven't 
> been yet able to test it myself, I only got this as second-hand info from 
> someone who did a dump of the repo last year, so I hope that is completely 
> incorrect. Will try dumping as soon as I get my hands on a repo copy.
>
> Regarding why the repo is so large: my estimate from running some analysis on 
> old revisions is that 90-95% of the data consists of beginners doing 
> accidental commits of things that should not have been allowed to commit
>

Okay, good luck with those "operations". I wanted to add a couple more
bits of info:

- After dump+filter+load or svnsync-with-filtering (effectively
creating a new repository with an alternate history compared to the
original) your new repository will / should have a new UUID. This
effectively invalidates all existing working copies out there (which
keep track of the UUID they were a checkout from). So all users will
have to checkout new working copies.

- You can perfectly well use a 1.10 version of svnadmin or svnsync (or
svnrdump, to create a dumpfile from a remote server) to interact with
a 1.8 server / repository. So if using a more modern version of
svnadmin or svnsync is beneficial, you should use it :).

- A dump file can be (much) larger than the original repository
itself, depending on how the dump is created. That's because the
repository potentially uses deltification, compression and
"representation sharing". If you use the --deltas option for 'svnadmin
dump', it will be smaller, at the expense of cpu time for the
deltification. Usually people will not use the --deltas option when
sending it directly through a pipe (saving on the cpu cycles for
deltification), but when writing it to a file you should probably use
--deltas.

-- 
Johan

Re: svndumpfilter and svnsync?

[Johan Corveleyn]

On Thu, Oct 4, 2018 at 2:33 PM Daniel Shahaf  wrote:
>
> Ryan Schmidt wrote on Thu, 04 Oct 2018 06:04 -0500:
> > On Oct 4, 2018, at 02:32, Chris wrote:
> > > I figured using svnsync to get the "cleaned repo" up to date with the 
> > > changes on the "live repo", but a note in the svnsync documentation says 
> > > "The only commits and revision property modifications that ever occur on 
> > > that mirror repository should be those performed by the svnsync tool". 
> > > Does that also include this kind of cleanup operation where I remove 
> > > paths that don't exist on HEAD?
>
> Yes.  The precondition for running 'svnsync' is that every revision in
> the target repository is identical to the corresponding revision in the
> source repository.  "Correspondence", in this sense, simply means
> numeric equality: r5 must correspond to r5, not to r6 nor to r4.
>
> > > If I should't use svnsync for this, what should I do instead?
>
> You should use svnsync and set the source repository's URL to a URL
> that has authz restrictions denying read to the large binary blobs.
>
> That's it.

Indeed, like Daniel said, you can do this with svnsync by setting up
and authz configuration on the source repository, denying read access
to the problematic files to the svnsync user (see [1]).

Also, I'm quite surprised that dumping your repository takes 2 weeks.
What version of svn are you using? I'm used to 'load' taking a long
time (but that has been improved a lot in 1.10 by adding a
--no-flush-to-disk option for 'svnadmin load' [2]), but 'dump'
shouldn't take that long. Perhaps the problem is that the dump file is
getting way too large. You can also consider piping svnadmin dump |
svndumpfilter | svnadmin load.

I would also suggest you read this FAQ entry [3], where I documented a
procedure (which I've used myself) to perform a dump + load, while the
source repo is still fully online. The initial dump+load can take a
long time. Then you follow up with an incremental dump+load to catch
up with commits that happened in the meantime (you can repeat this
catch-up procedure as many times as you like, so you eventually have
minimal downtime for the "final catchup").

Another useful thing for you to look at is the new --include and
--exclude options for 'svnadmin dump' directly, which have been added
in svn 1.10 [4]. These work in a similar way as svnsync + (denying via
authz). If you go that route, you don't need to use svndumpfilter.

[1] http://subversion.apache.org/faq.html#removal
[2] http://subversion.apache.org/docs/release-notes/1.10.html#no-flush-to-disk
[3] http://subversion.apache.org/faq.html#dumpload
[4] 
http://subversion.apache.org/docs/release-notes/1.10.html#dump-include-exclude


-- 
Johan

Re: Svn-Checkout with externals

[Johan Corveleyn]

On Mon, Oct 1, 2018 at 6:19 PM von Schoenebeck, Florian
 wrote:
> Hi,
> we are using Apache Subversion 1.9.3 on our Ubuntu-16.04 – Server. (svn-repos 
> with format 5 (svn-1.7.3))
> With TeamCity and svnKit 1.9.2 we have problems to check out projects which 
> uses svn:externals.
> The checkout normally works but sometime we get the following error (apache: 
> error.log)
> The checkout is hanging, (normal checkout-time: 90s)
>
> [Mon Oct 01 17:44:38.737002 2018] [dav:error] [pid 12638] [client 
> 10.190.40.12:52380] A failure occurred while driving the update report editor 
>  [500, #160005]
> [Mon Oct 01 17:44:38.737026 2018] [dav:error] [pid 12638] [client 
> 10.190.40.12:52380] Cannot replace a directory from within  [500, #160005]
> [Mon Oct 01 17:44:38.740522 2018] [dav:error] [pid 12981] [client 
> 10.190.40.12:52384] A failure occurred while driving the update report editor 
>  [500, #160005]
> [Mon Oct 01 17:44:38.740560 2018] [dav:error] [pid 12981] [client 
> 10.190.40.12:52384] Cannot replace a directory from within  [500, #160005]
> [Mon Oct 01 17:45:02.296343 2018] [dav:error] [pid 10521] [client 
> 10.190.40.12:53914] A failure occurred while driving the update report editor 
>  [500, #160005]
> [Mon Oct 01 17:45:02.296360 2018] [dav:error] [pid 10521] [client 
> 10.190.40.12:53914] Cannot replace a directory from within  [500, #160005]
> [Mon Oct 01 17:45:02.298774 2018] [dav:error] [pid 12639] [client 
> 10.190.40.12:53924] A failure occurred while driving the update report editor 
>  [500, #160005]
> [Mon Oct 01 17:45:02.298803 2018] [dav:error] [pid 12639] [client 
> 10.190.40.12:53924] Cannot replace a directory from within  [500, #160005]
> [Mon Oct 01 17:45:21.677609 2018] [dav:error] [pid 12001] [client 
> 10.190.40.12:59448] A failure occurred while driving the update report editor 
>  [500, #160005]
> [Mon Oct 01 17:45:21.677628 2018] [dav:error] [pid 12001] [client 
> 10.190.40.12:59448] Cannot replace a directory from within  [500, #160005]
> [Mon Oct 01 17:45:21.680140 2018] [dav:error] [pid 7192] [client 
> 10.190.40.12:59458] A failure occurred while driving the update report editor 
>  [500, #160005]
>
> TeamCity- Build-Log:
>
> Failed to perform checkout on agent: Subversion: checkout failed: Subversion 
> update_external problem for D:\work\641f829b10ee37b7\src\: svn: E175002: 
> timed out waiting for server
>
> Has anyone an idea?

To me this looks like a problem specific to SVNKit, which is a
pure-Java reimplementation of the Subversion client. SVNKit is not
maintained by the Apache Subversion community. It has its own
mailinglists, see https://svnkit.com/support.html.

Also, a quick google search for "Cannot replace a directory from
within" turned up the following:
https://teamcity-support.jetbrains.com/hc/en-us/community/posts/206302499-Basic-Teamcity-and-SVN-question

Maybe this is the same problem, and you might be able to fix it like
the OP of that question, by following the hints of Alexander Kitaev
(SVNKit developer):

"I think this problem could appear when directory (your project root
directory) was "replaced" with another directory or deleted from
repository at some revision. I would recommend you to enable "clean
sources before build" option in build configuration and check whether
it will resolve the problem. Then you may disable this option."

-- 
Johan

Re: Jira Subversion Integration Using Fisheye

[Johan Corveleyn]

On Mon, Oct 1, 2018 at 10:43 AM Surbhi Kaushik
 wrote:
> Hi Team,
>
> This is regarding Jira Subversion integration using Fisheye application. 
> Below are the version details being used.
>
> Jira: 7.9.0
> Subversion: 1.8
> Fisheye: 4.5.3
>
> Issue: While indexing Subversion repositories through Fisheye we are facing 
> below error after initial few hours of indexing.
>
> Could you please help us with what configuration settings will be required 
> for Fisheye to index subversion repository at subversion side.
>
> Repository paused due to error 
> com.cenqua.fisheye.rep.RepositoryClientException: 
> java.lang.IllegalStateException: Can't overwrite cause with 
> org.tmatesoft.svn.core.SVNException: svn: E175002: Connection reset svn: 
> E175002: REPORT request failed on '/svn/sec-projects/!svn/vcc/default
>

Hi Surbhi,

First of all, your Subversion client is SVNKit, which is a pure Java
re-implementation of Subversion. SVNKit is not maintained by the
Apache Subversion project, and it has its own support channels:
https://svnkit.com/support.html. It's possible that your problem is
specific to SVNKit, in which case you should probably contact them (or
try if the problem gets resolved if you switch to "native
Subversion").

Second, you're using Subversion 1.8, which is no longer supported. You
should upgrade your client to 1.10.2 (= latest release) or at least
1.9.9 (the 1.9.x branch is the "old stable" branch which is still
supported).

At my company we use FishEye (version 4.6.0) and Subversion (1.9.x
client, 1.9.x server) too, and we have successfully changed the
FishEye configuration to make use of the native "javahl" Subversion
client. I suggest you try that first, to see if it resolves your
problem. Here are some links to Fisheye documentation about how to set
it up with JavaHL:

https://confluence.atlassian.com/fisheye/native-subversion-client-298976879.html
https://confluence.atlassian.com/fisheye/native-support-for-svn-389780391.html
https://confluence.atlassian.com/fishkb/getting-native-subversion-client-to-work-with-fisheye-on-a-windows-64-bit-machine-765594168.html

It's also possible that the problem is related to the Subversion
server. Perhaps there is some timeout happening. In that case it could
be interesting to take a look at the error logs on the Subversion
server, around the time of the "Connection reset svn: E175002: REPORT
request failed".

-- 
Johan

Re: Error report: wc_db.c line 1648: assertion failed (SVN_IS_VALID_REVNUM(changed_rev))

[Johan Corveleyn]

On Thu, Aug 23, 2018 at 8:53 PM Nathan Hartman  wrote:
> On Thu, Aug 23, 2018 at 9:46 AM Christoph Hannebauer 
>  wrote:
>> I have not subscribed to the users mailing list, so please CC me in this 
>> thread.
>>
>> My SVN crashed with this error message:
>> 'D:\Development\SVN\Releases\TortoiseSVN-1.10.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
>> line 1648: assertion failed (SVN_IS_VALID_REVNUM(changed_rev))
>>
>> What I did before the crash, was execute the following command:
>> svn checkout 
>> https://github.com/Microsoft/Windows-classic-samples/trunk/Samples/Win7Samples/security/certificateservices/exit/c++/WindowsServer2008R2
>>
>> I didn’t check whether other machines also show this behavior, but I did 
>> check that TortoiseSVN 1.9.7 is also affected.
>
> Interesting. There is another thread about an assertion failure, also in a 
> call to SVN_IS_VALID_REVNUM(), but in a different file. Could these be 
> related?

No, it seems not. I believe this is a bug in GitHub's emulation of the
subversion protocol.

First, when I try to checkout a parent directory higher up, it works fine:
svn checkout
https://github.com/Microsoft/Windows-classic-samples/trunk/Samples/Win7Samples/security/certificateservices/exit

As soon as you add the "c++" to the checkout path, it crashes:
[[[
svn checkout 
https://github.com/Microsoft/Windows-classic-samples/trunk/Samples/Win7Samples/security/certificateservices/exit/c++
svn: E235000: In file
'D:\Development\SVN\Releases\TortoiseSVN-1.10.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 1648: assertion failed (SVN_IS_VALID_REVNUM(changed_rev))
]]]

URL-encoding the '+' signs doesn't help by the way:
[[[
svn checkout 
https://github.com/Microsoft/Windows-classic-samples/trunk/Samples/Win7Samples/security/certificateservices/exit/c%2B%2B/
svn: E235000: In file
'D:\Development\SVN\Releases\TortoiseSVN-1.10.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 1648: assertion failed (SVN_IS_VALID_REVNUM(changed_rev))
]]]


But if I try the same with a regular SVN repository, there is no problem:
[[[
C:\Temp\svntest>svnadmin create repos

C:\Temp\svntest>svn mkdir -mm --parents
"file:///C:/Temp/svntest/repos/trunk/c++/WindowsServer2008R2"
Committing transaction...
Committed revision 1.

C:\Temp\svntest>svn ls file:///C:/Temp/svntest/repos/trunk
c++/

C:\Temp\svntest>svn ls file:///C:/Temp/svntest/repos/trunk/c++
WindowsServer2008R2/

C:\Temp\svntest>svn co file:///C:/Temp/svntest/repos/trunk/c++
Ac++\WindowsServer2008R2
Checked out revision 1.

C:\Temp\svntest>svn co
file:///C:/Temp/svntest/repos/trunk/c++/WindowsServer2008R2
Checked out revision 1.

C:\Temp\svntest>dir
...
05-09-2018  16:33  .
05-09-2018  16:33  ..
05-09-2018  16:33  c++
05-09-2018  15:12  repos
05-09-2018  16:33  WindowsServer2008R2
]]]


So I conclude that this is a bug in GitHub, sending it's data to the svn client.
Workaround: perform a checkout of a parent directory higher up the
tree, so the root path of your working copy does not contain those '+'
signs.

-- 
Johan

Re: Erroneous "diff --summarize" output?

[Johan Corveleyn]

On Wed, Aug 8, 2018 at 9:27 AM Chris  wrote:
>
> I just noticed some strange output from diff --summarize that to me looks 
> like a bug, but I'm not sure.
> What I'm doing is that I'm changing a file in a subdirectory, committing it 
> and then reverse-merging that change so I'm back to the same content of my 
> working copy as before. Running svn diff against the previous revision shows 
> no diffs as expected, but when I do the exact same command but add 
> --summarize, it says the file that I changed is modified and the directory it 
> is in has property changes.
> The attached reproduction script illustrates the difference. Is this a bug or 
> am I misunderstanding how summarize is supposed to work?

Hi Chris,

Thanks for reporting this. I think this is indeed a bug ... somehow
the 'diff --summarize' seems to do something wrong when determining
the working-copy revision (but regular 'diff' does it right). That's
if I'm correctly interpreting the second usage of 'diff'.

>From 'svn help diff':
[[[
  2. diff [-c M | -r N[:M]] [TARGET[@REV]...]
  ...
  2. Display the changes made to TARGETs as they are seen in REV between
 two revisions.  TARGETs may be all working copy paths or all URLs.
 If TARGETs are working copy paths, N defaults to BASE and M to the
 working copy; if URLs, N must be specified and M defaults to HEAD.
 The '-c M' option is equivalent to '-r N:M' where N = M-1.
 Using '-c -M' does the reverse: '-r M:N' where N = M-1.
]]]

So, "If TARGETs are working copy paths, N defaults to BASE and M to
the working copy".
But, if I'm following your test script, at the end the working copy is
at revision 3. And if not, it certainly is after I execute another
'svn update' at the working copy root.

If I do:
svn diff -r 1 A
indeed, it shows nothing.

If I do:
svn diff -r 1 --summarize A
it shows:
M   A\mu
 M  A

But if I do:
svn diff -r 1:3 --summarize A
it shows nothing.

So it seems, with the --summarize option, 'diff' doesn't seem to
determine correctly the "M" revision of the range (should be "3" in
this case, the working revision of the working copy).

This issue seems a bit similar:
https://issues.apache.org/jira/browse/SVN-4631 (svn --xml
--summarize -rBASE:n reports incorrect output)

But I'm not sure whether it's the same.

I think you should file a new issue, and attach your reproduction script to it.

-- 
Johan


summarize-bug.sh
Description: Bourne shell script

Re: Error report: wc_db.c line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))

[Johan Corveleyn]

On Fri, Aug 3, 2018 at 11:59 AM Lukner, Benjamin
 wrote:
>
> Hi,
>
> I couldn’t find an error report for that code line so I’d like to report it.
>
> I’m using TortoiseSVN-1.10.1.28295-x64-svn-1.10.2 on a german Win7 SP1 Pro 
> 64Bit with latest patches.
>
> I opened the log of a checked-out project and double-clicked a file to see 
> the differences to its previous version.
> I suspect the cause may be TortoiseSVN only passing the folder name without 
> file name to SVN but I can’t tell.
>
>
> Result:
>
> ---
> 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
> https://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.10.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
> line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))
> ---
> OK
> ---
>
> [Window Title]
> TortoiseSVN
>
> [Main Instruction]
> Subversion reported an error:
>
> [Content]
> 'C:\Users\blu\AppData\Local\Temp' is not a working copy
>
> [Schließen]

Hi Benjamin,

Thanks for reporting this.

I tried to reproduce it with TortoiseSVN 1.10.1 on a working copy of
my own, but I can't reproduce this error, no matter which file I
double-click in the log. Could it be that there is something special
about your working copy? For instance, are there any "svn:externals"?
Or is the working copy stored on some specific storage device? Any
other special conditions that might explain me not being able to
reproduce it?

I'm also wondering about the thing mentioned under "[Content]":
'C:\Users\blu\AppData\Local\Temp' is not a working copy.
Is the working copy perhaps located in some roaming profile, or
something like that?

-- 
Johan

Re: Checksum Mismatch error on check out or export

[Johan Corveleyn]

On Thu, Aug 16, 2018 at 8:25 AM Shakti Bansal
 wrote:
> Dear Team,
>
> I am facing the checksum mismatch error while performing check out or export 
> from SVN. Error is coming when we are checking out folders with large data.
>
> PFB the snapshot for your reference and provide support for the same issue on 
> urgent basis.

Hi Shakti,

I see that no-one has responded to your question yet.

To be clear: this list is not an actual "support venue". This is
merely the mailinglist of Apache Subversion users (also being followed
by several Subversion developers), where people try to help each other
by sharing knowledge and experience on using this open source
software. That said, there are professional consultants and service
companies out there that do provide paid support, if you would need
that.

Just as a fellow user and (volunteer) developer, I would ask you a
couple of followup questions:
- What version of TortoiseSVN were you using?
- Can you reproduce it when using the latest version of TortoiseSVN,
version 1.10.1 (linked against subversion 1.10.2)?
- Can you reproduce it when checking out from the command line ("svn co ...")?
- Does it always happen with the same (large) file? How about if you
reduce the size of the checkout to just the parent directory of that
large file?

-- 
Johan

Re: Wildcard bug? Or user error?

[Johan Corveleyn]

On Sun, Sep 2, 2018 at 11:10 PM Nathan Hartman  wrote:
>
> Has there been a recent change to how wildcards (the asterisk '*') is
> treated under Windows?
>
> I am using command line client 1.10.2 r1835932 as installed with
> TortoiseSVN 1.10.1, Build 28295 - 64 Bit , 2018/07/15 12:14:12, on
> Windows 10 Home 1803 build 17134.254.
>
> I've encountered weirdness with wildcards several times today, so I
> just tried in a clean freshly checked-out copy:
>
> E:\workspace\processor>svn rm *.hconfig
> svn: E25: Use --force to override this restriction (local modifications 
> may be lost)
> svn: E25: 'E:\workspace\processor\a' is not under version control
>
> There is no file or directory named 'a' here; however many files in
> this directory have names that begin with the letter 'a'.
> Furthermore, when working in the command line earlier today, it
> appeared that the names printed in the error messages were truncated
> versions of filenames. In this case the filename was truncated to
> just one character but I think I saw more characters in other
> filenames earlier (not 100% sure on this point).
>
> Other (possibly useful) information: There are no files whose names
> differ only in case. The filenames do not contain spaces (nor do any
> of the paths, whether in the repo or my working copy). There are no
> properties set on this directory or any of its files. Also, I tried
> similar operations on freshly checked out copies of other areas of
> the repo and the same phenomenon is manifesting. I don't recall ever
> seeing this before.
>
> Thoughts?

My first reaction is that this might be unrelated to svn, but merely
to Windows (or some Windows library). I wouldn't know what, but to
rule out that svn has anything to do with it, try something like 'dir
*.hconfig' in that directory.

-- 
Johan

Re: Problem report: low priority

[Johan Corveleyn]

On Thu, Aug 2, 2018 at 7:30 AM, Lulek.Branislav
 wrote:
> Hello,
>
> as dialog window directs me to post error window text to mailing list, I do 
> so:
>
> Best Regards,
> Branislav Lulek – Software developer

Hi Lulek,

Thank you for the report. Summarizing in plain text:

When opening the TortoiseSVN "SVN project monitor" (which shows a list
of working copies, with some info (?)), you always get this error:

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.10.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 10238: assertion failed (svn_dirent_is_absolute(local_abspath))

I'm not sure, but I believe this is possibly a problem in the
TortoiseSVN GUI, rather than in the underlying core svn libraries. So
I suggest you report this to one of the specific TortoiseSVN
mailinglists, see https://tortoisesvn.net/community.html.

Thanks,
-- 
Johan

Re: Subversion 1.10.x and svnkit compatibility?

[Johan Corveleyn]

On Fri, Jul 20, 2018 at 6:14 PM, Reuben Popp  wrote:
> Greetings to all,
>
> Can anyone tell me if svnkit is compatible with subversion 1.10.x?  Or if
> there's a particular svnkit dev branch that's in the works, so to speak?
> I've attempted mailing both the svnkit mailing lists themselves as well as
> the svnkit main email address, but all of them are bouncing as NDR.
>
> When responding, could you please reply to me directly as I am not a current
> subscriber to the list.

I have not seen a response on the list, so I'm not sure if anyone has
answered you directly. If not, I'm afraid most people on this list
don't know the current state of the svnkit project. It's a separate
project (with its own mailinglist, as you mentioned). If their list
doesn't work, and direct emails don't get a response either, I have no
idea how to contact them.

As far as I can see, their website doesn't mention a 1.10.x version
(latest seems to be 1.9.3). Their download page [1] does list a git
url, and their svn repository seems to be here:
https://svn.svnkit.com/repos/svnkit/ ... so perhaps you can find some
more recent work towards 1.10.x there.

[1] https://svnkit.com/download.php

-- 
Johan

Re: svn-win32.18.13_dev

[Johan Corveleyn]

On Thu, Jul 26, 2018 at 7:22 AM, Andreas Friedrich
 wrote:
>
> Hello,
>
> I use the lib files of svn-win32.18.13_dev. When I call the function 
> svn_client_version(), I get 1.7.5 as a result.
> Is it possible, that the lib files belong to an older version than 1.8?>
> When I checkout files with the API, I can’t use the compare function in my 
> TortoiseSVN. I have to upgrade my working copy to 1.8. My Tortoise uses 
> Subversion 1.8.9

Where did you get those lib files of svn-win32.18.13_dev? Maybe there
is a problem with that binary package? The Apache Subversion project
only release the source code, the binary packages are created /
maintained by various volunteers or organisations. Maybe you should
try another package from
http://subversion.apache.org/packages.html#windows. Or perhaps you can
simply use the dll's that come with your TortoiseSVN installation?

It's also possible that some old installation left some old dll's
somewhere on your PATH, which could cause them to be loaded in your
program that performs the API calls.

BTW: Version 1.8 is end-of-life now [1], while 1.9 is the "old stable"
release and 1.10 is the latest release branch. I recommend you upgrade
to 1.10.2 if possible. Also see
http://subversion.apache.org/roadmap.html if you want to know more
about our release planning.

[1] 
http://subversion.apache.org/docs/release-notes/1.10.html#svn-1.8-deprecation

-- 
Johan

Re: Http authentication

[Johan Corveleyn]

On Thu, Jul 19, 2018 at 12:15 PM, Felix E.  wrote:
>
>
> On 2018/07/18 14:45:38, Branko Čibej  wrote:
>> On 18.07.2018 15:38, Essig Felix wrote:>
>> >>
>> > Hi,>
>> >>
>> >  >
>> >>
>> > I have a question about the http authentication when using the>
>> > subversion api 1.8.13.>
>> >>
>> > For example using the ‚svn_client_list3‘ function:>
>> >>
>> > Everytime this function is called the first http request does not>
>> > contain any Authorization header which leads to a ‚401 Authorization>
>> > Required‘ response.>
>> >>
>> > In my opinion this leads to an unnecessary delay when the function is>
>> > called multiple times and the same credentials could be used.>
>> >>
>> >  >
>> >>
>> > When calling this function the svn_client_ctx_t contains an>
>> > svn_auth_baton_t with set default username and default password>
>> > parameters.>
>> >>
>> >  >
>> >>
>> > Now to my actual question:>
>> >>
>> > Can this behaviour somehow be changed or is it just designed to work>
>> > this way? I also know that the version I’m using is not the newest one>
>> > so if you think an upgrade to a newer version could lead to some>
>> > performance improvement please let me know.>
>> >>
>>
>> You can either modify the auth baton or create your own. See>
>> svn_cmdline_create_auth_baton2 in include/svn_cmdline.h and>
>> subversion/libsvn_subr/cmdline.c.>
>>
>> -- Brane>
>>
>>
>
> Thanks for your answer.
> But what exactly do you mean?
> As I said the default parameters are set.
> There is also no callback to any auth provider so the default values seem to
> work. But only after a auth required response.
> The http client should include the auth header already in the first request.

I think the client can not assume (without sending a first request)
that authentication will be required. Some servers offer anonymous
access, some require authentication for "write", but allow anonymous
reads, and some require authentication for both read and write
requests. It depends on the servers-side configuration.

-- 
Johan

Re: SSL handshake failed: SSL alert received

[Johan Corveleyn]

[ If possible, this list prefers bottom-posting / inline replies in
plain text. More below ... ]

On Wed, Jul 11, 2018 at 10:07 PM, Brandon L. Wisenburg
 wrote:
> Hi Johan,
> Yes, I edited out the actual domain. I can hit the URL via a browser and get 
> prompted for a password. The SSL Cert also checks out OK via SSLChecker. Any 
> other thoughts?

Hm, just a generic problem-solving thought: this worked before (since
you created a checkout from that url), so ... what changed? Something
must have changed to cause the error.

Is your pc the only one getting this error, and it works fine on
other's pc in your environment? That would help pinpointing the
problem to a either a central component or just your pc.

First suspects, IMHO, are:
- Something in the network infrastructure, or with the network
configuration of your pc. Perhaps your connection is now sent to /
manipulated by a proxy, whereas it wasn't before. Maybe you can
experiment a bit with the http-proxy-* options (for instance configure
http-proxy-exceptions for your domain) in the 'servers' configuration
file in your Subversion runtime configuration directory
(~/.subversion/servers on unix, or %APPDATA%/Subversion/servers on
Windows).
- A change in the server-side configuration (the httpd configuration).

-- 
Johan

Re: SSL handshake failed: SSL alert received

[Johan Corveleyn]

On Wed, Jul 11, 2018 at 5:32 PM, Brandon L. Wisenburg
 wrote:
> Greetings List,
> I am getting an error when attempting to svn update.
>
> svn update
> svn: OPTIONS of 'https://domain/src': SSL handshake failed: SSL alert
> received: Handshake failed (https://www.domain.com)
>
> Odd part is I am not sure why it is failing. Has anyone seen this issue
> before?

I suppose you hand-edited the error message to replace the actual
domain name with 'domain'. To double-check: the first url in the error
message is without the www.*.com, yes? So the actual repository url
does not have www.*.com, but the svn client seems to be forced to
perform its ssl handshake with www.domain.com. Perhaps a proxy that is
interfering?

Other than that: a quick thing to try is to access the repository url
from a web browser, and see if there is any connection problem or
anything strange with the ssl certificate / connection.

-- 
Johan

Re: Subversion Exception

[Johan Corveleyn]

On Wed, Jul 11, 2018 at 5:06 PM, Jeff Dege  wrote:

> I’m seeing a repeatable exception.
>
>
>
> If within TortoiseSVN Project Monitor, if I select “Show Range” and then
> pick a Date Start Revision a couple of weeks back and an End Revision of
> HEAD, I get an exception. (Picking an Date End Revision of today works
> without error.)
>
>
>
> ---
>
> 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.7\ext\
> subversion\subversion\libsvn_client\ra.c'
>
> line 681: assertion failed (SVN_IS_VALID_REVNUM(peg_revnum))
>
> ---
>
> OK
>
> ---
>
>
>

This could possibly be a bug in TortoiseSVN, rather than in core svn
itself. I suggest to first report this to one of the TortoiseSVN
mailinglists. See: https://tortoisesvn.net/community.html.

-- 
Johan

Re: Subversion server

[Johan Corveleyn]

On Thu, Jul 5, 2018 at 5:22 PM, Daniel Shahaf  wrote:
> Johan Corveleyn wrote on Thu, 05 Jul 2018 11:53 +0200:
>> I do think it would be a great feature though, to have --include and
>> --exclude options (with glob-like syntax, like our recent --search
>> option for 'svn ls') for certain svn commands. With server-side
>> support to only send the matching items (and falling back to pure
>> client-side filtering when talking to older servers). Then one could
>> do these as an efficient operation (if there is server-side support):
>>
>
> Even without any new server-side support, if the client can be assumed
> to have `svn ls -R` output, then it can simply drive the reporter in the
> right way for the server to return exactly the right data.

Ah yes, indeed. That'll surely be more efficient than downloading all
files and filtering client-side.

On top of that, the client can use the new-in-1.10 'svn ls -R --search
$glob-pattern' to gather the already-filtered list of files (a 1.10
server will perform the filtering of the list of files on the
server-side then). This is beginning to sound like low-hanging fruit
:-). For the include case at least ... for the exclude case there is
no server-optimized ls operation (yet).

-- 
Johan

Re: Subversion server

[Johan Corveleyn]

On Tue, Jul 3, 2018 at 4:32 PM, Bellamy Baron  wrote:
> Does anyone know of a way to export a directory directly from a subversion
> server and exclude certain filetypes?

Not as far as I know. If you are using TortoiseSVN, maybe something
can be done with client-side hook scripts [1], for example delete
unwanted files after exporting. Though I don't think there are
client-side hooks for the "export" operation.

I do think it would be a great feature though, to have --include and
--exclude options (with glob-like syntax, like our recent --search
option for 'svn ls') for certain svn commands. With server-side
support to only send the matching items (and falling back to pure
client-side filtering when talking to older servers). Then one could
do these as an efficient operation (if there is server-side support):

* svn cat -R --include '*.txt' $URL
* svn export --include 'build.xml' $URL (<- creating sparse directory
structure with only the matching files)
* svn export --exclude '*.iso' $URL

[1] 
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-hooks

-- 
Johan

Re: svn password prompt hanging in PowerShell

[Johan Corveleyn]

Thanks! That's very useful information. Let's hope MS will fix this soon.

-- 
Johan

On Sun, Jul 1, 2018 at 1:11 AM, David Gardiner  wrote:
> Just circling back with an update. The Tortoise folks discovered this is a
> bug in a library that shipped in Windows 10 RS4, possibly related to VS2017.
>
> See
> https://developercommunity.visualstudio.com/content/problem/245451/unbuffered-console-io-is-broken-only-in-release-bu.html
>
> As such I suspect it will probably affect other distributions if they use a
> similar build tool chain.
>
> David
>
> Get Outlook for iOS
> 
> From: David Gardiner 
> Sent: Saturday, June 30, 2018 9:45:57 PM
> To: Johan Corveleyn
> Cc: Subversion
> Subject: Re: svn password prompt hanging in PowerShell
>
> Thanks for your help, I've raise it with TortoiseSVN
>
> David
>
> On 29 June 2018 at 17:19, Johan Corveleyn  wrote:
>>
>> On Fri, Jun 29, 2018 at 6:25 AM, David Gardiner 
>> wrote:
>> > A couple of observations:
>> >
>> > I downloaded the visualsvn build as suggested, and that appears to work
>> > without issue
>> > Using the tortoisesvn svn.exe, I also had a merge conflict while running
>> > 'svn update' and the prompt for resolve the conflict also hung (so looks
>> > like it's a general problem with user input, not just related to
>> > passwords)
>>
>> Okay. In that case, please report this problem to one of the
>> TortoiseSVN lists: https://tortoisesvn.net/community.html
>>
>> It appears to be something specific to their build.
>>
>> --
>> Johan
>
>

Re: SVN patch issue with property changes

[Johan Corveleyn]

On Fri, Jun 29, 2018 at 10:34 AM, Branko Čibej  wrote:
> On 28.06.2018 22:08, Julian Foad wrote:
>> Philip Martin wrote:
>>> Julian Foad  writes:
 Julian Foad wrote:
> The bug seems to be that 'svn patch' fails to apply any patch of
> this form, that tries to change a property value from empty to
> non-empty.
 I committed a test for this in http://svn.apache.org/r1834628
>>> I'm confused, you are treating as '' special?  Suppose an existing
>>> property P has value 'foo'.  Should a patch that adds P with value 'bar'
>> The issue is about a patch that *changes* the current value to another 
>> value, not a patch that *adds* a property.
>>
>> I am pointing out that a patch that changes the empty value '' to 'bar' 
>> should be (and isn't being) applied successfully to a property that already 
>> has the empty value ''.
>>
>> The patch format for modifying an empty value is mostly the same as the 
>> patch format for adding a new property:
>>
>> [[[
>> Property changes on: f
>> ___
>> Added: empty
>> ## -0,0 +1 ##
>> +foo
>> \ No newline at end of property
>> ]]]
>> vs.
>> [[[
>> Property changes on: f
>> ___
>> Modified: empty
>> ## -0,0 +1 ##
>> +foo
>> \ No newline at end of property
>> ]]]
>>
>> It's similar to the ambiguous patch representation of create a file or add 
>> text to an empty file. In that case, 'svn patch' first creates the file if 
>> it doesn't exist, and in both scenarios adds the patch text.
>>
>> For a property patch, a property-patch header line specifies whether it's a 
>> modify or an add, so there is no ambiguity. If the patch asks to 'modify' 
>> from empty to non-empty, when the target property already exists and has an 
>> empty value, this should certainly succeed.
>
> However, when libsvn_client creates the svn:executable property, it
> *always* sets its value to *. Applying a patch from empty to something
> else will then very likely result in a conflict; because the
> svn:executable property value cannot be empty (unless someone used a
> broken client). This has been true since at least version 0.14., some 15
> years ago.

I think the cvs2svn conversion tool makes it possible to have an empty
svn:executable property. I don't remember if it does this by default,
or you need to do something special. I just recall we had this with an
early attempt at converting years ago (we ended up throwing that
version away, and replaced it with *).

I remember thinking at the time: "Why do we need to set it to *? The
docs only say the property needs to be set, but it doesn't require it
to be *, it can be _any value_ ... it's not because the default svn
client does so that it's required ..."

-- 
Johan

Re: svn password prompt hanging in PowerShell

[Johan Corveleyn]

On Fri, Jun 29, 2018 at 6:25 AM, David Gardiner  wrote:
> A couple of observations:
>
> I downloaded the visualsvn build as suggested, and that appears to work
> without issue
> Using the tortoisesvn svn.exe, I also had a merge conflict while running
> 'svn update' and the prompt for resolve the conflict also hung (so looks
> like it's a general problem with user input, not just related to passwords)

Okay. In that case, please report this problem to one of the
TortoiseSVN lists: https://tortoisesvn.net/community.html

It appears to be something specific to their build.

-- 
Johan

Re: SVN patch issue with property changes

[Johan Corveleyn]

On Wed, Jun 27, 2018 at 1:07 PM, Dipu H  wrote:
> Hi Team,
>
> I have a patch with svn property changes as below:
>
> dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py
> Index: xpathleak.py
> ===
> --- xpathleak.py (revision 950359)
> +++ xpathleak.py (working copy)
> @@ -4,25 +4,15 @@
> libxml2.debugMemory(True)
>
> expect="""--> Invalid expression
> ---> xmlXPathEval: evaluation failed
> --> Invalid expression
> ---> xmlXPathEval: evaluation failed
> """
> err=""
> def callback(ctx, str):
>
> Property changes on: xpathleak.py
> ___
> Modified: svn:executable
> ## -0,0 +1 ##
> +* <<<- Yes, there is a change, value * added to property
> svn:executable
> \ No newline at end of property
> Added: svn:mime-type
> ## -0,0 +1 ##
> +text/plain
> \ No newline at end of property
>
> 
>
> Now I generated the patch and applied it on another copy of the same branch.
>
> dipuh@contrail-ubm-MADHUS:/tmp/tests$ svn diff xpathleak.py >/tmp/mypatch
>
> dipuh@contrail-ubm-MADHUS:/tmp/apply$ svn patch /tmp/mypatch
> UC xpathleak.py
>> rejected hunk ## -0,0 +1,1 ## (svn:executable)
> Summary of conflicts:
> Property conflicts: 1
>
> The patch is rejected without changing the property. The destination file
> already has svn:executable property present in it. But the value is empty.
> Ideally, if the patch was applied properly, the value should have been
> changed to "*".
>
>
> After little bit of googling, I found the below link which looks like a
> similar issue.
>
> https://jira.atlassian.com/browse/CRUC-6114?src=confmacro
>
> SVN Version : 1.8.11
>
>
>
> I understand that the latest svn clients add * as the value of
> svn:executable property. However, if we generate a patch out of this and
> apply on an existing file, `svn patch` is not able to identify that there is
> a property change from ‘null’ to ‘*’. Could you please check if this is a
> bug?

SVN 1.8.11 is very old (version 1.8.x is actually end-of-life now
[1]). Can you test with a 1.10 client to see if it shows the same
behaviour?

[1] 
http://subversion.apache.org/docs/release-notes/1.10.html#svn-1.8-deprecation

-- 
Johan

Re: svn password prompt hanging in PowerShell

[Johan Corveleyn]

On Wed, Jun 27, 2018 at 3:13 AM, David Gardiner  wrote:
> Sorry, just to clarify.. I just tried using cmd.exe and that had the same
> problem - so not just a PowerShell problem.
>
> Running Windows 10 1803 (17134.112)
>
> On 27 June 2018 at 10:39, David Gardiner  wrote:
>>
>> I downloaded the latest TortoiseSVN build along with debug symbols and got
>> the following stack trace after attaching to svn.exe and breaking:
>>
>>  ntdll.dll!NtDeviceIoControlFile ()Unknown
>>  KernelBase.dll!ConsoleCallServerGeneric()Unknown
>>  KernelBase.dll!GetConsoleInput()Unknown
>>  KernelBase.dll!ReadConsoleInputW ()Unknown
>>
>> ucrtbase.dll!console_input_reopen_and_retry<
>> >()Unknown
>>  ucrtbase.dll!_getch_nolock ()Unknown
>>  ucrtbase.dll!_getch ()Unknown
>> >libsvn_tsvn.dll!terminal_getc(int * code, terminal_handle_t *
>> > terminal, int can_erase, apr_pool_t *) Line 336C
>>  libsvn_tsvn.dll!prompt(const char * * result, const char *
>> prompt_msg, int hide, svn_cmdline_prompt_baton2_t * pb, apr_pool_t * pool)
>> Line 504C
>>  libsvn_tsvn.dll!svn_cmdline_auth_simple_prompt(svn_auth_cred_simple_t
>> * * cred_p, void * baton, const char * realm, const char * username, int
>> may_save, apr_pool_t * pool) Line 628C
>>  [Inline Frame]
>> libsvn_tsvn.dll!prompt_for_simple_creds(svn_auth_cred_simple_t * *) Line 640
>> C
>>  libsvn_tsvn.dll!simple_prompt_first_creds(void * * credentials_p,
>> void * * iter_baton, void * provider_baton, apr_hash_t * parameters, const
>> char * realmstring, apr_pool_t * pool) Line 663C
>>  libsvn_tsvn.dll!svn_auth_next_credentials(void * * credentials,
>> svn_auth_iterstate_t * state, apr_pool_t * pool) Line 354C
>>  libsvn_tsvn.dll!svn_ra_serf__credentials_callback(char * * username,
>> char * * password, serf_request_t * request, void * baton, int code, const
>> char * authn_type, const char * realm, apr_pool_t * pool) Line 1211C
>>  [Inline Frame]
>> libsvn_tsvn.dll!serf__provide_credentials(serf_context_t * authn_type, char
>> * * pool, char * *) Line 1022C
>>  libsvn_tsvn.dll!serf__handle_basic_auth(int code, serf_request_t *
>> request, serf_bucket_t * response, const char * auth_hdr, const char *
>> auth_attr, void * baton, apr_pool_t * pool) Line 97C
>>  [Inline Frame] libsvn_tsvn.dll!handle_auth_headers(int) Line 200C
>>  libsvn_tsvn.dll!dispatch_auth(int code, serf_request_t * request,
>> serf_bucket_t * response, void * baton, apr_pool_t * pool) Line 312C
>>  libsvn_tsvn.dll!serf__handle_auth_response(int * consumed_response,
>> serf_request_t * request, serf_bucket_t * response, void * baton, apr_pool_t
>> * pool) Line 370C
>>  [Inline Frame] libsvn_tsvn.dll!handle_response(serf_request_t * pool,
>> apr_pool_t *) Line 929C
>>  libsvn_tsvn.dll!read_from_connection(serf_connection_t * conn) Line
>> 1136C
>>  [Inline Frame]
>> libsvn_tsvn.dll!serf__process_connection(serf_connection_t * events, short)
>> Line 1257C
>>  libsvn_tsvn.dll!serf_event_trigger(serf_context_t * serf_baton, void
>> * desc, const apr_pollfd_t *) Line 232C
>>  [Inline Frame] libsvn_tsvn.dll!serf_context_run(serf_context_t * ctx,
>> int) Line 305C
>>  libsvn_tsvn.dll!svn_ra_serf__context_run(svn_ra_serf__session_t *
>> sess, __int64 * waittime_left, apr_pool_t *) Line 910C
>>  [Inline Frame] libsvn_tsvn.dll!svn_ra_serf__context_run_wait(int *
>> sess, svn_ra_serf__session_t *) Line 981C
>>  [Inline Frame]
>> libsvn_tsvn.dll!svn_ra_serf__context_run_one(svn_ra_serf__handler_t *
>> handler, apr_pool_t *) Line 1021C
>>
>> libsvn_tsvn.dll!svn_ra_serf__exchange_capabilities(svn_ra_serf__session_t *
>> serf_sess, const char * * corrected_url, apr_pool_t * result_pool,
>> apr_pool_t * scratch_pool) Line 544C
>>  libsvn_tsvn.dll!svn_ra_serf__open(svn_ra_session_t * session, const
>> char * * corrected_url, const char * session_URL, const svn_ra_callbacks2_t
>> * callbacks, void * callback_baton, svn_auth_baton_t * auth_baton,
>> apr_hash_t * config, apr_pool_t * result_pool, apr_pool_t * scratch_pool)
>> Line 601C
>>  libsvn_tsvn.dll!svn_ra_open4(svn_ra_session_t * * session_p, const
>> char * * corrected_url_p, const char * repos_URL, const char * uuid, const
>> svn_ra_callbacks2_t * callbacks, void * callback_baton, apr_hash_t * config,
>> apr_pool_t * pool) Line 384C
>>  libsvn_tsvn.dll!svn_client__open_ra_session_internal(svn_ra_session_t
>> * * ra_session, const char * * corrected_url, const char * base_url, const
>> char * base_dir_abspath, const apr_array_header_t * commit_items, int
>> write_dav_props, int read_dav_props, svn_client_ctx_t * ctx, apr_pool_t *
>> result_pool, apr_pool_t * scratch_pool) Line 421C
>>  libsvn_tsvn.dll!update_internal(long * result_rev, int *
>> timestamp_sleep, apr_hash_t * conflicted_paths, svn_ra_session_t * *
>> ra_session_p, const char * local_

Re: Change svn:mergeinfo property on an old revision of the repository (history) which has an invalid syntax

[Johan Corveleyn]

On Fri, Jun 22, 2018 at 12:43 PM, Torsten Krah  wrote:
> Hi,
>
> unfortunately trying to svnsync a repository i discovered that there is
> an invalid revision in the repository having a wrong svn:mergeinfo
> property, instead of
>
> 1280-1282 it has 1282-1280
>
> "Commit rejected because mergeinfo on '/branch' is syntactically
> invalid"
>
> The client we're using t sync is version 1.9.7. The source server is
> 1.6.17.
>
> What's the best way to fix only those broken revision? Is there some way
> to fix this property in the history? Or is there some way to fix that on
> the fly? Any suggestions welcome.

I'm not sure how this would have happened (perhaps by manually editing
/ setting the mergeinfo property by the person who made that commit?).

I don't have any experience with this kind of problem, but perhaps
this tool could help you:

https://github.com/jwiegley/svndumptool

It has several features for manipulating / fixing svn dump files.

-- 
Johan

Re: how to get the newly created branch/folder without extra .svn folder?

[Johan Corveleyn]

On Fri, Jun 15, 2018 at 2:58 PM, James Peng  wrote:
> Hello everybody,
>
> I have the following project structure:
>
> Project
> --.svn
> --branches
> --p1
> --p2
> --trunk
>
> Now my co-worker has added a ‘p3’ under the branches and also a
> ‘products/pp1’ under the Project folder:
>
> Project
> --.svn
> --branches
> --p1
> --p2
> --p3   --
> ne
> --trunk
> --products
> --pp1
> --ne
>
>
> How can I get the new p3 and pp1 without get extra .svn under other folders?
>
> It seems I have to use ‘co’, then I will get .svn folder extra .svn under
> other folders. These extra .svn folders should not be there? How to avoid
> them?

It depends a bit on how you have set up your working copy. I believe
you're looking to have a "sparse working copy" with several parts of
the repository (but all being part of one working copy / one working
copy root / one .svn folder). If so, I suggest you take a look at:

http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html

Basically 'co' will give you an entirely new working copy, with its
own root (it can be embedded in another working copy, but that's not a
great idea). If you want to change the "sparseness" / structure of
your existing working copy, you need to use 'svn up' in combination
with the --set-depth option to include or exclude extra parts.

-- 
Johan

Re: Abuout subversion use_ assertion failed

[Johan Corveleyn]

On Wed, Jun 13, 2018 at 4:56 AM, 金聪睿  wrote:
> About SVN
> 1\ WIN2008  VisualSVN Server  2.5.1(Subversion 1.7.1,Apache 2.2.21)
> 2\ TortoiseSVN 1.9.X（zh_CN）
>
> Problems：
> When updating working copies，TortoiseSVN showed an error as follows:
> file
> "D:\Development\SVN\Releases\TortoiseSVN-1.9.5\ext\subversion\subverion\libsvn_wc\update_editor.c"
> line 1446 ： assertion failed （action == svn_wc_conflict_action_delete  ）
>
> I have searched the archives，but can not find out effective solutions .

Can you try again with the latest version, 1.10.0? For TortoiseSVN you
should be able to download it from here:
https://tortoisesvn.net/downloads.html.

It's possible that this is already fixed (or fails in a different way
now ... hard to tell).

-- 
Johan

Re: Why can’t I create folder ??

[Johan Corveleyn]

On Mon, May 21, 2018 at 5:52 AM, Piyaporn Settabunjong
 wrote:
> Dear sir ,
>
> I already update to version 1.10.0 then can create my folder. This is success.
> But when I try to check out code to my folder. It error as below.
>
> ---
> 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
> https://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.10.0\ext\subversion\subversion\libsvn_subr\dirent_uri.c'
> line 1601: assertion failed (! svn_path_is_url(relative))
> ---
> OK
> ---

Okay, so that's basically the same error as with 1.8.6 that you
reported earlier.

I'm just guessing here, but one possible reason could be an
"svn:externals" definition [1] that contains some incorrect values.
I'd start with investigating those.

You should be able to find any "svn:externals" properties under the
URL you're trying to checkout by executing this:

svn propget -R svn:externals $URL

Also: just to double check you should probably try to repeat your
action with the commandline client, outside of TortoiseSVN (by
executing 'svn checkout $URL'), to see if you get the same error.

[1] http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

-- 
Johan

Re: Reference to non-existent node

[Johan Corveleyn]

On Tue, May 22, 2018 at 8:30 PM, Davor Josipovic  wrote:
>>  Now that is interesting. 40k doesn't seem to be such a large amount of
>> data for modern computers. Very slow and fragmented hard drive? Or perhaps
>> there's something else going on that is manifesting this way?
>
> The HDD is indeed on the slowside, and together with low memory...
>
> But I think this also show how I/O intensive SVN is. On the client side, for
> each committed file, one copy is placed in .svn folder, and an other copy in
> a temporary folder (which is deleted after file transfer in v1.9). So for
> each file committed, a double copy is made client-side. This temporary copy
> is really necessary?
>
> Server-side, I see similar disk bashing. For each committed file, max 2 (?)
> copies are made in the transaction directory.
>
> So any way to reduce the I/O?

A couple of improvements have been made in 1.10. It would be
interesting to test this same scenario with a 1.10 client (to verify
the client-side improvements) and if possible also with a 1.10 server,
with a dumped+loaded FSFS back-end (to get an idea of any server-side
improvements).

Client-side there were some changes to make the (http) client stream
svndiff deltas without creating temporary files (during 'commit' and
'import'):
https://svn.apache.org/r1803143
https://svn.apache.org/r1803144
https://svn.apache.org/r1804819

Server-side, LZ4 compression was added as the default compression
algorithm in the FSFS back-end, and on the wire (not sure if that
helps in your case ... it won't impact the number of files that are
created temporarily I suppose):
https://subversion.apache.org/docs/release-notes/1.10.html#lz4

Also, maybe a commit such as this one helps too (though it seems to
only talk about reads):
https://svn.apache.org/r1759399

As always, probably further improvements can be made I guess, but
someone will need to dig into it.

If you'd be able to test with 1.10 both client and server-side, that
would give some more data points about where we are with the latest
state of things ...

Finally, one last tip: this (rather old) performance tuning page
suggests putting the "transactions" folder on a separate (faster)
filesystem to speed up commits:

https://www.orcaware.com/svn/wiki/Server_performance_tuning_for_Linux_and_Unix#Reducing_the_number_of_writes

I don't know how realistic that is in your setup (plus you need to
make sure that transactions filesystem is large enough for your
commits).

-- 
Johan