On 19.02.2022 16:31, Daniel Shahaf wrote:
Stefan Kueng wrote on Sat, Feb 19, 2022 at 16:11:59 +0100:
I guess I'm a little late to this discussion, but I just upgraded today to
the svn trunk and saw the new APIs.
From what I understand is that new clients can choose which WC format to use
I guess I'm a little late to this discussion, but I just upgraded today
to the svn trunk and saw the new APIs.
From what I understand is that new clients can choose which WC format
to use during checkout/upgrade?
If that's correct, I'd like to propose a small enhancement:
* provide an env
Using svn 1.13.0 on Windows:
SUBST G:\ D:\Development\TestWC
G:
svn st .
! .
? Foo
? src\nonversioned
As you can see, the root folder doesn't show the correct status.
This showed the correct status with 1.12.x.
Stefan
Hi,
Crashreports for TSVN show a problem in the
svn_client_conflict_tree_get_details() API.
The data passed to the API is correct, already checked that.
Here's the stack trace:
libsvn_tsvn.dll!uri_escape(const char * path, const char * table,
apr_pool_t * pool) Line 920 C
On 14.01.2019 14:25, Branko Čibej wrote:
On 14.01.2019 13:36, Julian Foad wrote:
Stefan, thanks for taking account of the feedback and updating the doc string
in r1851197.
I took a look and thought to rewrite the part about encoding and line splitting
like this:
* Character Encoding
On 10.01.2019 23:46, Branko Čibej wrote:
On 10.01.2019 19:13, Stefan Kueng wrote:
On 10.01.2019 06:58, Branko Čibej wrote:
On 10.01.2019 04:58, Branko Čibej wrote:
On 07.01.2019 20:57, Stefan Kueng wrote:
@@ -758,6 +759,33 @@
* will be true if the reason there is no blame
On 10.01.2019 06:58, Branko Čibej wrote:
On 10.01.2019 04:58, Branko Čibej wrote:
On 07.01.2019 20:57, Stefan Kueng wrote:
@@ -758,6 +759,33 @@
* will be true if the reason there is no blame information is that the line
* was modified locally. In all other cases @a local_change
On 08.01.2019 20:30, Michael Pilato wrote:
On 08.01.2019 19:45, stevek...@apache.org wrote:
Author: steveking
Date: Tue Jan 8 18:45:45 2019
New Revision: 1850781
[...]
Modified: subversion/trunk/subversion/include/svn_client.h
URL:
On 08.01.2019 19:58, Branko Čibej wrote:
On 08.01.2019 19:45, stevek...@apache.org wrote:
Author: steveking
Date: Tue Jan 8 18:45:45 2019
New Revision: 1850781
URL: http://svn.apache.org/viewvc?rev=1850781=rev
Log:
Extend the blame callback with a string length parameter.
*
On 07.01.2019 19:58, Daniel Shahaf wrote:
Stefan Kueng wrote on Mon, 07 Jan 2019 19:30 +0100:
On 06.01.2019 21:09, Daniel Shahaf wrote:
Stefan Kueng wrote on Sun, Jan 06, 2019 at 20:40:28 +0100:
@@ -758,6 +759,33 @@
* will be true if the reason there is no blame information
On 07.01.2019 19:56, Branko Čibej wrote:
On Mon, 7 Jan 2019, 19:30 Stefan Kueng <mailto:tortoise...@gmail.com> wrote:
I think for proper C, all variables need to be declared at the start of
the function. Unless of course svn allows newer C versions?
Not "the start of t
the attached patch has some corrections to the doc strings.
If there are no objections, I'll commit this tomorrow.
Also see inline comments:
On 06.01.2019 21:09, Daniel Shahaf wrote:
Stefan Kueng wrote on Sun, Jan 06, 2019 at 20:40:28 +0100:
+++ subversion/include/svn_client.h (working
On 06.01.2019 19:54, Daniel Shahaf wrote:
The encoding may also be set explicitly via a svn:mime-type="text/foo;
charset=utf-16-le" property. (We even parse that in mod_dav_svn, I think?)
Setting the mime-type to text/.. with the utf16 charset helps only that
the --force flag doesn't need
On 06.01.2019 19:37, Branko Čibej wrote:
Windows default is UTF-16-LE, at least on x86(_64) and other
little-endian architectures. I'm not sure what they do on ARM but I'd be
surprised if Windows doesn't put it in little-endian mode, given that
decades of legacy software assume
On 06.01.2019 15:05, Branko Čibej wrote:
Sorry about getting into this late, but as Julian said:
* we already have a (char*, len) wrapper, called svn_string_t, so I would
expect it would be neatest to use that;
but the patch has:
@@ -758,6 +758,28 @@
On 06.01.2019 15:22, Julian Foad wrote:
Branko Čibej wrote:
+ const svn_string_t line = {sb->data, sb->len};
In plain old C, we can't write that, but we have a helper function:
svn_stringbuf__morph_into_string().
but that destroys the original stringbuf, but that one is
On 05.01.2019 22:35, Daniel Shahaf wrote:
Stefan Kueng wrote on Sat, 05 Jan 2019 21:15 +0100:
here's a patch using svn_stringbuf_t for review.
Change "Provided for backwards compatibility with the 1.6 API" to
"Provided for backwards compatibility with the 1.11 API" in
s
On 05.01.2019 17:53, Julian Foad wrote:
Stefan Kueng wrote:
When running blame on an utf16 text file, the lines can not be used
since the blame callback only passes a 'char *' parameter which means it
ends at the first zero char. But actually, svn knows if the line has
more content.
+1
On 05.01.2019 18:05, Mark Phippard wrote:
On Jan 5, 2019, at 10:58 AM, Stefan Kueng wrote:
So, with this patch I'm able to do a blame on utf16 files, so I'd like to
commit this if there are no objections.
I have no objections, just a question. I thought SVN treated utf16 files
On 05.01.2019 17:53, Julian Foad wrote:
Stefan Kueng wrote:
When running blame on an utf16 text file, the lines can not be used
since the blame callback only passes a 'char *' parameter which means it
ends at the first zero char. But actually, svn knows if the line has
more content.
+1
Hi,
When running blame on an utf16 text file, the lines can not be used
since the blame callback only passes a 'char *' parameter which means it
ends at the first zero char. But actually, svn knows if the line has
more content.
So I'd like to propose the following patch which extends the
On 12.12.2018 21:12, Branko Čibej wrote:
On 12.12.2018 19:07, Stefan Kueng wrote:
On 12.12.2018 13:55, TortoiseSVN-dev on behalf of Julian Foad wrote:
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
[…]
https
On 12.12.2018 13:55, TortoiseSVN-dev on behalf of Julian Foad wrote:
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
[…]
https://subversion.apache.org/mailing-lists.html
It is likely that this is a problem specific to
On 9/20/2018 5:17 PM, Julian Foad wrote:
A fresh perspective on the experimental-APIs issue just came to me: this should
not hold up the 1.11 release. We were falling into the old trap of thrashing
about debating how to do it, assuming we needed some solution for 1.11, but we
don't. One of
A few more thought, mostly for the next release:
* svn_client_shelf_save_new_version3 takes two callback functions, but
they both have the same type. So why not just change that API to take
one callback but provide a 'failed' flag instead?
* when a shelve operation fails, we have to remove
Hi,
I know I'm a little bit late, but now I'm implementing the new shelf
APIs in TSVN so it's now that I have some thoughts and suggestions:
* there are deprecated APIs already, even though they weren't there in
1.10.0, for example svn_client_shelf_save_new_version - since they're
all new
On 08.06.2018 00:30, Branko Čibej wrote:
Just FYI: in that case svn would have a requirement for NTFS. Because
both hard links (for files) and junctions (for directories) only work
on NTFS. So it wouldn't be possible anymore to use svn on e.g. a usb
stick formatted with FAT32.
Yes ... we'd
Hi,
It seems that svn doesn't handle reparse points properly in all
situations. Which causes big problems for TSVN when a working copy is on
a Onedrive folder.
See here for more details:
https://groups.google.com/d/msg/tortoisesvn/hlQj5OifhBg/RX_cw_sQCgAJ
While in this particular situation,
On 27.08.2017 02:09, Branko Čibej wrote:
On 27.08.2017 02:04, Daniel Shahaf wrote:
Julian Foad wrote on Fri, 25 Aug 2017 21:42 +0100:
Let's clarify. We can mean two possible things when we say 'a series of
patches':
1. "patch versions": a series of successively better patches, all
On 13.03.2017 11:52, Julian Foad wrote:
Stefan K, trying to help push this forward...
We have consensus to do something about automatically providing updates
to translatable strings. We need some help to fill in the details and
actually do it.
From my perspective, it looks like we should:
*
On 08.02.2017 15:03, Evgeny Kotkov wrote:
Stefan Sperling <s...@elego.de> writes:
Ah, indeed. Thank you very much for this patch!
Please commit it when you get a chance.
Thanks, I committed the fix in r1782169.
Stefan Kueng <tortoise...@gmail.com> writes:
But as I mentio
On 07.02.2017 21:34, Stefan Sperling wrote:
On Tue, Feb 07, 2017 at 08:17:41PM +0100, Stefan Kueng wrote:
I figured out the problem:
to get updated descriptions, I have to call
svn_client_conflict_tree_get_resolution_options() again to get new updated
options. I can't just get the description
On 07.02.2017 09:37, Stefan Sperling wrote:
On Mon, Feb 06, 2017 at 07:54:46PM +0100, Stefan Kueng wrote:
On 06.02.2017 13:19, Stefan Sperling wrote:
On Sun, Feb 05, 2017 at 03:23:33PM +0100, Stefan Küng wrote:
Still doesn't work for me
On 05.02.2017 20:55, Daniel Shahaf wrote:
Stefan Kueng wrote on Sun, Feb 05, 2017 at 15:28:25 +0100:
On 05.02.2017 12:21, Andreas Stieger wrote:
On 04/02/17 17:13, Stefan Kueng wrote:
[...]I'm wondering about the translations of those strings.
Several points on this:
#1 Working
On 06.02.2017 13:19, Stefan Sperling wrote:
On Sun, Feb 05, 2017 at 03:23:33PM +0100, Stefan Küng wrote:
Still doesn't work for me.
svn_client_conflict_option_set_moved_to_repos_relpath(opt, j, scratchpool);
label = svn_client_conflict_option_get_label(opt, scratchpool);
description =
On 05.02.2017 12:21, Andreas Stieger wrote:
On 04/02/17 17:13, Stefan Kueng wrote:
[...]I'm wondering about the translations of those strings.
Several points on this:
#1 Working with Pootle works well, both ways. There is just a bit of a
coordination effort. That coordination needs
On 04.02.2017 19:52, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 07:21:50PM +0100, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 04:57:45PM +0100, Stefan Küng wrote:
But the problem with the description not being updated still persists.
OK, I believe I see the problem.
The *option*
On 04.02.2017 18:16, Daniel Shahaf wrote:
Stefan Kueng wrote on Sat, Feb 04, 2017 at 17:13:06 +0100:
I remember there was a discussion about two years ago about using a web
based translation tool for Subversion (e.g. http://translationproject.org/),
but that discussion got to no real decision
Hi,
Since the new conflict resolver API offer a lot of strings to be used in
an UI, I'm wondering about the translations of those strings.
I remember there was a discussion about two years ago about using a web
based translation tool for Subversion (e.g.
http://translationproject.org/), but
On 04.02.2017 14:12, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 01:45:10PM +0100, Stefan Kueng wrote:
On 04.02.2017 11:16, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 09:23:06AM +0100, Stefan Kueng wrote:
Hi,
while trying out the new conflict resolver APIs I came upon a slight
On 04.02.2017 14:12, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 01:45:10PM +0100, Stefan Kueng wrote:
On 04.02.2017 11:16, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 09:23:06AM +0100, Stefan Kueng wrote:
Hi,
while trying out the new conflict resolver APIs I came upon a slight
On 04.02.2017 14:24, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 02:12:45PM +0100, Stefan Sperling wrote:
The idea is to just call it as many times as you want to.
It just sets an internal index that indicates which moved-to-path to use
for descriptions and resolution from now on.
See
On 04.02.2017 11:16, Stefan Sperling wrote:
On Sat, Feb 04, 2017 at 09:23:06AM +0100, Stefan Kueng wrote:
Hi,
while trying out the new conflict resolver APIs I came upon a slight
problem. The API svn_client_conflict_option_get_description() returns a
string that can be used to show
Hi,
while trying out the new conflict resolver APIs I came upon a slight
problem. The API svn_client_conflict_option_get_description() returns a
string that can be used to show to the user as a choice - in TSVN that
would be the text on a two-line button (the 'label' is the first line,
the
On 28.01.2017 15:38, Stefan Sperling wrote:
On Sat, Jan 28, 2017 at 01:47:03PM +0100, Stefan Sperling wrote:
On Sat, Jan 28, 2017 at 01:31:46PM +0100, Stefan Kueng wrote:
Hi,
trying out the new conflict resolver. Ran into a segfault on my first try:
Thank you! I will fix this ASAP
Hi,
trying out the new conflict resolver. Ran into a segfault on my first try:
libsvn_client\conflicts.c, function find_modified_rev():
if there is no author for a commit, then we get a segfault here:
/* No paths were changed in this revision. Nothing to do. */
if (!
On 09.10.2015 18:16, Branko Čibej wrote:
On 09.10.2015 17:16, Julian Foad wrote:
This FAQ seems rather out of date / lacking in correctness:
http://subversion.apache.org/faq#nfs
Since 1.7, the SQLite DB in the WC needs 'file locking' to work
properly, which (as I understand it)
On 10.06.2015 21:04, Bert Huijben wrote:
I don’t think we can really fix that url in the api by canonicalizing it
to something completely different/unrelated, but the assertion makes it
obvious that the caller can just see/check that the url is not going to
work… just like values such as the
On 10.06.2015 19:06, Bert Huijben wrote:
Hi Dean,
There is not much we can do about this. The Subversion apis require that
you pass canonical urls, while the client (TortoiseSVN) that you use
doesn’t canonicalize the url before passing it to this api.
And that's what the
On 09.04.2015 16:57, Bert Huijben wrote:
-Original Message-
From: Stefan Kueng [mailto:tortoise...@gmail.com]
Sent: woensdag 8 april 2015 19:46
To: Subversion Development
Subject: error committing to 1.7 servers
Hi,
While trying to commit a change to an xml file with the svn:mime
On 29.03.2015 17:50, Bert Huijben wrote:
-Original Message-
From: Stephen White [mailto:swh...@corefiling.com]
Sent: vrijdag 27 maart 2015 14:03
To: dev@subversion.apache.org
Subject: Subversion checkout issue with certain short names on Windows
If you pass a Windows short-name as
On 16.02.2015 20:22, Bert Huijben wrote:
-Original Message- From: Stefan Kueng
[mailto:tortoise...@gmail.com] Sent: maandag 16 februari 2015
20:01 To: Subversion Development Subject: pin externals when
creating a copy from specific revision
Hi,
I'm still doing some testing
On 16.02.2015 20:39, Stefan Sperling wrote:
On Mon, Feb 16, 2015 at 08:01:19PM +0100, Stefan Kueng wrote:
Hi,
I'm still doing some testing with the new --pin-externals feature, and I
found a situation which I'm not sure should be handled that way:
imagine the repo is at r100. Now if one
On 14.02.2015 10:35, Stefan Sperling wrote:
Can you please file issues for these problems, with a 1.9.0 milestone?
Thanks!
Done:
http://subversion.tigris.org/issues/show_bug.cgi?id=4558
http://subversion.tigris.org/issues/show_bug.cgi?id=4559
Hi,
While trying out the new 'pin externals' feature, I found a problem:
if the external definition has spaces in them for the local path,
something like this:
^/branches/test1 'ext with spaces'
then that will get changed to
^/branches/test1@1234 ext with spaces
which basically breaks the
On 04.02.2015 16:07, Stefan Sperling wrote:
On Fri, Jan 30, 2015 at 06:14:02PM +0100, Stefan Kueng wrote:
But can you maybe implement my other request about using an array of
externals to tag so the user can chose which externals to tag and which ones
to just leave as-is?
Does this API do
On 04.02.2015 19:08, Stefan Sperling wrote:
On Wed, Feb 04, 2015 at 06:42:08PM +0100, Stefan Kueng wrote:
Maybe one more improvement:
Add a new API to fetch the list of externals which would be pegged if NULL
is passed to the svn_client_copy7 API.
Suggested name
On 30.01.2015 01:10, Stefan Sperling wrote:
On Fri, Jan 30, 2015 at 12:43:47AM +0100, Johan Corveleyn wrote:
From the peanut gallery: I'm with Stefan Küng on this. I think
intra-repository externals are used *a lot*, especially in
companies. I'm not a big fan of this way of working myself,
On 29.01.2015 12:33, Stefan Sperling wrote:
On Thu, Jan 29, 2015 at 12:14:27PM +0100, Tom Ghyselinck wrote:
Hi everybody,
I am following this feature with a lot of interest!
One question pops up:
1. Suppose I have a branch B with external references to E
2. E has an external reference to F
On 29.01.2015 22:45, Stefan Sperling wrote:
On Thu, Jan 29, 2015 at 07:26:01PM +0100, Stefan Kueng wrote:
TortoiseSVN has such a feature. Of course, it doesn't work in an ideal way.
Here's what I do in TSVN:
The branch/tag dialog (the one that's shown for an 'svn copy') scans the
working
On 28.08.2014 20:33, Branko Čibej wrote:
On 27.08.2014 20:48, stevek...@apache.org wrote:
Author: steveking
Date: Wed Aug 27 18:48:05 2014
New Revision: 1620955
URL:http://svn.apache.org/r1620955
Log:
Make 'svn status' ignore the thumbs.db files by default, which are
created by the Windows
On 28.05.2014 12:28, Bert Huijben wrote:
-Original Message-
From: Stefan Kueng [mailto:tortoise...@gmail.com]
Sent: dinsdag 27 mei 2014 20:24
To: 'Subversion Development'
Subject: crash reports
Hi,
There are several crash reports sent for TortoiseSVN that I can't figure
out. I've
Hi,
There are several crash reports sent for TortoiseSVN that I can't figure
out. I've analyzed multiple dumps from those reports but I'm not
successful in finding the root cause.
I *think* it's because the crashes happen due to wrong pool handling,
i.e. pools are destroyed but then used
On 27.05.2014 20:56, Branko Čibej wrote:
On 27.05.2014 20:23, Stefan Kueng wrote:
Hi,
There are several crash reports sent for TortoiseSVN that I can't
figure out. I've analyzed multiple dumps from those reports but I'm
not successful in finding the root cause.
I *think* it's because
Hi,
When compiling svn with the latest Windows SDK I get compiler errors in
apr. This only happens if _WIN32_WINNT is = 0x0502, and only with the
SDK for Win8.1 (maybe for Win8 too, haven't tested that).
I have to patch apr to make the build work. I've attached the patch I'm
using.
Has
On 13.03.2014 14:14, Bert Huijben wrote:
-Original Message-
From: Ivan Zhakov [mailto:i...@visualsvn.com]
Sent: donderdag 13 maart 2014 13:56
To: Branko Čibej
Cc: Subversion Development
Subject: Re: Subversion checked-out files not indexed in Windows search
On 13 March 2014 16:46,
Hi,
Using a build from the svn trunk (built 30 minutes ago, r1574973):
svn list -v https://svn.apache.org/repos/asf/subversion/trunk
shows a lot of garbage in the author column.
Also linked with:
apr 1.5.0
apr-util 1.5.3
serf 1.3.3
OpenSSL 1.0.1f 6 Jan 2014
zlib 1.2.8
in case that's
On 06.03.2014 19:53, Branko Čibej wrote:
On 06.03.2014 19:32, Stefan Kueng wrote:
Hi,
Using a build from the svn trunk (built 30 minutes ago, r1574973):
svn list -v https://svn.apache.org/repos/asf/subversion/trunk
shows a lot of garbage in the author column.
Confirmed; in my case it's
On 06.03.2014 19:52, Ben Reser wrote:
On 3/6/14, 10:32 AM, Stefan Kueng wrote:
Using a build from the svn trunk (built 30 minutes ago, r1574973):
svn list -v https://svn.apache.org/repos/asf/subversion/trunk
shows a lot of garbage in the author column.
Also linked with:
apr 1.5.0
apr-util
On 06.03.2014 20:29, Bert Huijben wrote:
-Original Message-
From: Stefan Kueng [mailto:tortoise...@gmail.com]
Sent: donderdag 6 maart 2014 19:32
To: dev@subversion.apache.org
Subject: svn list broken
Hi,
Using a build from the svn trunk (built 30 minutes ago, r1574973):
svn list -v
Hi,
Running
$ svn diff folder --depth=empty
still produces the diff for all added children as well, even though the
depth was set to empty.
$ mkdir folder
$ echo test folder/file
$ svn add folder
$ svn diff folder --depth=empty patch.diff
now the file patch.diff also contains the diff for
71 matches
Mail list logo
