On Thu, Nov 17, 2016 at 12:58:48AM +0100, Stefan wrote:
> Is there something else I'd do to improve the patch, or does anybody
> feel like approving it for commit?
+1
On Thu, Nov 10, 2016 at 07:34:09PM +0300, Evgeny Kotkov wrote:
> Here is the patch. Not sure that I fully understand the point about the
> number of iterations, though ;)
Ah, yes. I see what you're doing. Unravelling the accept arg during
the conflict walk instead of before the walk is very nice.
On Fri, Oct 14, 2016 at 06:24:05PM +0200, Evgeny Kotkov wrote:
> As for the change itself, I don't think that silently transforming one
> conflict option id to another in svn_client_conflict_text_resolve_by_id()
> API is a proper thing to do, because we don't expose this option id as a
> viable res
On Wed, Nov 09, 2016 at 11:21:42PM +0100, Stefan wrote:
> Hi,
>
> attached is a patch to correct indentation in
> svn_client_conflict_text_resolve_by_id() which was spotted by Evgeny
> (related to the mail thread: "svn commit: r1764902 - in
> /subversion/trunk/subversion: libsvn_client/conflicts.c
On Wed, Nov 09, 2016 at 11:27:47AM +0100, Patrick Steinhardt wrote:
> Hi,
>
> while continuing my work on the obstructed checkout patch I just
> updated to the new `svn_client_list4` call, which introduced a
> new `patterns` parameter. I initially run into a `NULL` pointer
> derefeernce, as I expe
On Mon, Oct 31, 2016 at 10:51:28AM +0100, Patrick Steinhardt wrote:
> On Fri, Oct 14, 2016 at 06:23:09PM +0200, Patrick Steinhardt wrote:
> > Hi,
> >
> > currently, call library-provided resolve option labels have a
> > leading uppercase character, but all client-specific options are
> > lowercase
On Fri, Oct 28, 2016 at 02:49:04AM +0200, b...@qqmail.nl wrote:
> In the summary I don’t see the support for restartability of a broken
> checkout. See the documentation of svn checkout in the svn-book.
> (http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.checkout.html)
Yes, we'll need to mak
On Tue, Oct 18, 2016 at 02:22:25PM +0200, Patrick Steinhardt wrote:
> Hi,
>
> finally got around to update my patch regarding checkouts to
> existing directories. The semantics have been changed to accept
> checkouts iff
>
> - the target directory does not exist
> - the target directory is empty
On Mon, Oct 24, 2016 at 11:18:51AM +0200, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: Stefan Sperling [mailto:s...@apache.org]
> > Sent: maandag 24 oktober 2016 11:08
> > To: dev@subversion.apache.org
> > Subject: Re: svn commit: r17644
On Sun, Oct 23, 2016 at 03:31:22PM -0400, James McCoy wrote:
> On Wed, Oct 12, 2016 at 12:34:19PM -, s...@apache.org wrote:
> > Modified: subversion/trunk/subversion/libsvn_client/conflicts.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/conflicts.c?rev=17
On Tue, Oct 18, 2016 at 04:36:27PM -0700, Alexey Neyman wrote:
> On 10/18/2016 02:02 PM, Stefan Sperling wrote:
> > On Tue, Oct 18, 2016 at 01:42:40PM -0700, Alexey Neyman wrote:
> > > I just found what made it consider this directory different: it had build
> > > artifa
On Tue, Oct 18, 2016 at 01:42:40PM -0700, Alexey Neyman wrote:
> I just found what made it consider this directory different: it had build
> artifacts (*.o, *.d, etc) in that directory - once I ran 'make clean' prior
> to merge, the merge proceeded smoothly. Does the client consider unversioned
> f
On Mon, Oct 17, 2016 at 09:20:16PM +, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Sun, Oct 16, 2016 at 22:36:39 +:
> > Stefan Sperling wrote on Sun, Oct 16, 2016 at 23:22:22 +0200:
> > > Reading our openhub stats for fun I noticed that the stats
> > > are tot
Reading our openhub stats for fun I noticed that the stats
are totally screwed. It seems they stop scanning our history
at r1295006 (the infamous commit that changed our trunk's copy ID).
https://www.openhub.net/p/subversion/commits?sort=oldest
It seems openhub have a problem distinguishing branch
On Fri, Oct 14, 2016 at 03:35:48PM +0200, Stefan wrote:
> Thanks for taking the time to review the patch, Ivan (and also stsp).
> After talking to stsp, here's a different approach to solve the issue
> without the need for adding a new parameter to the public API.
>
> (all tests pass on Windows an
On Thu, Oct 13, 2016 at 05:59:01PM +0200, Stefan wrote:
> On 10/13/2016 5:26 PM, Patrick Steinhardt wrote:
> > sion re-adds the result pool to
> > `svn_client_conflict_option_get_lazel`.
>
> > diff --git a/subversion/include/svn_client.h
> > b/subversion/include/svn_client.h
> > index 9bbe62b..f45
On Thu, Oct 13, 2016 at 04:46:55PM +0200, Patrick Steinhardt wrote:
> Is there by any chance a tool which helps generating this tedious
> list?
There are some but I cannot tell which is best and how well these are working.
https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/vim/
On Thu, Oct 13, 2016 at 03:46:32PM +0200, Patrick Steinhardt wrote:
> * subversion/include/svn_client.h:
> - new function `svn_client_conflict_option_get_label`
> * subversion/libsvn_client/conflicts.c:
> - svn_client_conflict_option_t: add label
> - add_resolution_option: add label argument
On Thu, Oct 13, 2016 at 03:01:39PM +0200, Ivan Zhakov wrote:
> I suggest to change behavior to something like the following:
> [[[
> $ svn resolve
> Searching tree conflict details for
> 'D:\ivan\svn\test-wc\add-versus-add\foo' in repository:
> Checking r5... done
> Tree conflict on 'D:\ivan\svn\te
On Wed, Oct 12, 2016 at 04:49:55PM +0200, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: Stefan Sperling [mailto:s...@elego.de]
> > Sent: woensdag 12 oktober 2016 16:37
> > To: Patrick Steinhardt
> > Cc: Subversion
> > Subject
On Wed, Oct 12, 2016 at 04:28:05PM +0200, Patrick Steinhardt wrote:
> Hi,
>
> attached is a patch to reject checkouts to already existing
> directories when `--force` is not given. This is according to
> `svn co --help`.
>
> [[
> Reject checkout to existing paths without force
>
> * subversion/s
On Wed, Oct 12, 2016 at 03:38:02PM +0200, Patrick Steinhardt wrote:
> Hi,
>
> please find attached a patch pulling out the short descriptions
> of conflict resolution options from the client and puts them into
> libsvn_client.
>
> [[
> Move conflict resolution options' labels out of the client
>
On Wed, Oct 12, 2016 at 12:29:55PM +0200, Dario Niedermann wrote:
> That is true. I was mostly wondering if Subversion was (for example)
> running hook scripts via /usr/bin/env; so that it's expected for any
> flags on the shebang line to cause errors. Or if I'm onto something
> and opening a bug i
On Wed, Oct 12, 2016 at 12:04:03PM +0200, Dario Niedermann wrote:
> The community guide on Subversion's website says it's OK to ask on
> dev@ if a report on a possible issue with svn doesn't goes unanswered
> on users@. Considering that the only reply I got on users@ was from
> someone who complete
On Fri, Sep 30, 2016 at 07:09:15PM +0300, Evgeny Kotkov wrote:
> Hi,
>
> I was thinking about which options should be offered by the tree conflict
> resolver in a common case with a catch-up merge when a file is moved
> away in trunk and edited on the branch. (Limiting the scope to a case
> when
On Sat, Sep 24, 2016 at 08:34:05PM -0400, Paul Hammant wrote:
> Can I put the item in Jira and y'all mark it as a 2.0 feature.
Just filing a ticket in the issue tracker won't lead to any sort of progress.
You'll need to convince us why *we* want this feature and do the work,
or why we should spen
On Sat, Sep 17, 2016 at 06:52:44AM +, Daniel Shahaf wrote:
> I think end-users do care about the error code. We print it out in the
> command-line tools too and one of the reasons for that is so scripts can
> parse it.
>
> Moreover, as per the TODO's in the patch, this is groundwork for passi
On Fri, Sep 16, 2016 at 03:42:58AM +, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Fri, Sep 09, 2016 at 06:44:51 +:
> > 3. Add to svn_commit_info_t an svn_error_t representation of the error
> > chain that svn_commit_callback_t::post_commit_err summarizes,
>
> Patch attached.
>
> The new
On Mon, Aug 29, 2016 at 02:44:28PM +0200, Stefan Sperling wrote:
> If you have time to fix it, please do!
I got an opportunity to fix this myself: http://svn.apache.org/r1758269
On Mon, Aug 29, 2016 at 12:36:05PM +0300, Ivan Zhakov wrote:
> On 28 August 2016 at 00:02, wrote:
> > Author: stsp
> > Date: Sat Aug 27 21:02:27 2016
> > New Revision: 1758069
> >
> > URL: http://svn.apache.org/viewvc?rev=1758069&view=rev
> > Log:
> > Fix issue #4652 which shows how to trigger an
On Fri, Aug 26, 2016 at 01:15:16PM +0300, Ivan Zhakov wrote:
> Hi Stefan,
>
> Currently svn_client_conflict_t stores a pointer to svn_client_ctx_t
> inside and uses it for every operation like
> svn_client_conflict_tree_get_details() or
> svn_client_conflict_*_resolve(). It may be useful for simpl
On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
> > Hi,
> >
> > the attached patch is the outcome of talking with jcorval on IRC about a
> > test suite issue on Windows (release builds) in SVN 1.
On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
> Hi,
>
> the attached patch is the outcome of talking with jcorval on IRC about a
> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
> fact that the tests will be interrupted on Windows by a Windows popup
> upon an ab
On Wed, Jul 27, 2016 at 08:02:07AM +, Thomsen, Allan A B wrote:
> Hi,
>
> I encountered this issue on 1.9.3 and upgraded to 1.9.4 - no difference
>
> If I do a cleanup I get:
> Quote
> Subversion reported the following
> (you can copy the content of this dialog
> to the clipboard using Ctrl-C
On Wed, Jul 27, 2016 at 09:24:08AM +, Thomsen, Allan A B wrote:
> Is the general recommendation against using network drives all together or
> just when there is a risk of multiple instance access?
Altogether. Store working copies on local disk (or something which
*really* looks like a local d
On Wed, Jul 27, 2016 at 08:02:07AM +, Thomsen, Allan A B wrote:
> The place the files are stored is on a network drive.
We generally recommend against storing working copies on network
drives because sqlite has problems with this: http://sqlite.org/faq.html#q5
On Wed, Jun 22, 2016 at 01:20:21AM +0200, Johan Corveleyn wrote:
> 1) Move anything only relevant to old releases (anything < 1.9 or <
> 1.8 (?)) to a separate page (faq_old.html or something -- linked from
> the main faq with a link somewhere at the top "Questions about older
> releases").
Or mov
On Tue, Jun 21, 2016 at 12:51:42PM +0200, Branko Čibej wrote:
> On 21.06.2016 09:16, s...@apache.org wrote:
> > Author: stsp
> > Date: Tue Jun 21 07:16:34 2016
> > New Revision: 1749456
> >
> > URL: http://svn.apache.org/viewvc?rev=1749456&view=rev
> > Log:
> > * subversion/trunk: Add "gmock-fused"
On Mon, Jun 20, 2016 at 08:34:24AM +0200, Stefan Fuhrmann wrote:
> Can you say what the main limitations are and whether you
> plan to remove them? My guess would be: files only, one
> move per file & conflict resolution cycle, no cyclic renames.
>
> -- Stefan^2.
I expect to get directories worki
Re: new svn conflict resolver status update
> >
> > On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling wrote:
> > > On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
> > >> To be honest, being able to use the python test framework would be a
&g
On Mon, Jun 13, 2016 at 06:15:39PM +0300, Pavel Lyalyakin wrote:
> Hello,
>
> I've been checking the conflict resolution tool to make necessary
> adjustments to SVNBook 1.8 and noticed that text conflict resolution offers
> to press (s) key to show the full list of available commands (e.g. like on
On Mon, Jun 13, 2016 at 01:51:49PM -, s...@apache.org wrote:
> Author: stsp
> Date: Mon Jun 13 13:51:49 2016
> New Revision: 1748236
>
> URL: http://svn.apache.org/viewvc?rev=1748236&view=rev
> Log:
> When merging an incoming file move, record this move in the working copy.
>
> This makes mer
On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
> To be honest, being able to use the python test framework would be a
> lot more productive for me. Maybe I can look into how to make it
> handle interactive prompting? Unless there's a reason why this would
> be notoriously difficul
I have been regularly working on the new conflict resolver since January.
This is a status update to present the results so far, and what remains
to be done before we can release this.
The code is on trunk, and not on a branch. We could still disable it
without much effort. However, at this point
On Wed, Jun 01, 2016 at 12:37:08PM +0200, Stefan Hett wrote:
> So with the change we are
> actually resolving problems for more standard compliant and also for older
> browsers working on that page.
Do you have any evidence of browsers not accepting that link?
Based on what Daniel Stenberg wrote
On Mon, May 16, 2016 at 03:44:58PM +0200, Stefan wrote:
> (issues): rename section id so it doesn't start with a number
Is breaking section links like the one below worth it?
It's not going to be a big problem for people to locate the right
section on the page even if this link changes. But on
On Mon, May 30, 2016 at 06:38:09AM +, Phil Crooker wrote:
> I posted this query to the users list but had no response. To me, this is not
> behaviour I would expect.
Hi Phil,
please do not use the dev@ list as an escalation path for users@.
Some people are subscribed to both lists. Replying
On Thu, May 26, 2016 at 11:15:11PM +0300, Pavel Lyalyakin wrote:
> Hello,
>
> I'm reading through the nightly SVNBook 1.8 and make more or less
> necessary changes to complete it and begin the work on SVNBook 1.9.
> I've just noticed that the output of `svn help` is slightly different
> in SVN 1.8
On Thu, May 26, 2016 at 02:51:23AM +0200, Stefan wrote:
> On 5/25/2016 18:11, astie...@apache.org wrote:
> > Author: astieger
> > Date: Wed May 25 16:11:01 2016
> > New Revision: 1745515
> >
> > URL: http://svn.apache.org/viewvc?rev=1745515&view=rev
> > Log:
> > * get-deps.sh: Update serf download
Hi Karl,
On IRC, you asked:
stsp: Is there anyone still in Patch Manager role in the project?
I just saw this, http://jk.ozlabs.org/projects/patchwork/, and thought it
might be helpful.
* kfogel asks the above question of Bert, Arfrever, or anyone else who
might know the answer
I
On Thu, Apr 21, 2016 at 07:43:15PM +0300, Evgeny Kotkov wrote:
> The 1.8.16 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on April 28th
> so pl
On Thu, Apr 21, 2016 at 07:43:37PM +0300, Evgeny Kotkov wrote:
> The 1.9.4 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on April 28th
> so ple
On Thu, Apr 21, 2016 at 10:57:34AM +0100, Philip Martin wrote:
> Stefan Sperling writes:
>
> > Funny. It works with 1.9.x indeed.
> >
> > Now try the same with a trunk client.
> > Is this a regression? Or a new feature?
>
> This is caused by the deliberate ch
On Thu, Apr 21, 2016 at 07:37:50PM +0300, Ivan Zhakov wrote:
> On 21 April 2016 at 17:34, Stefan Sperling wrote:
> > Implementation aside, I do think the option to merge the two directories
> > makes sense, even if they are ancestrally unrelated.
> May there are some implementa
On Thu, Apr 21, 2016 at 02:04:08PM -, s...@apache.org wrote:
> Author: stsp
> Date: Thu Apr 21 14:04:08 2016
> New Revision: 1740320
>
> URL: http://svn.apache.org/viewvc?rev=1740320&view=rev
> Log:
> Add a conflict resolution option for dir/dir "incoming add vs local
> obstruction upon merge"
On Thu, Apr 21, 2016 at 09:40:07AM +0200, Branko Čibej wrote:
> It is wrong to use conflict->local_abspath to construct the relative
> URL.
Yes, it is.
But where is the alleged code that does this? I don't see it.
And I don't think I've written it.
On Wed, Apr 20, 2016 at 10:19:56PM +0200, Bert Huijben wrote:
> The path calculation here 100% assumes that the working copy is always a
> clean check out from ^/. This might be the case in our test suite, but in
> almost every normal user scenario this isn’t the case.
>
> You can’t just calcula
On Tue, Apr 19, 2016 at 09:58:36AM -0700, Ryan J Ollos wrote:
> The SVK project hasn't been developed since 2010, so it seems appropriate
> to remove mention of it as an alternative to SVN. Patch is attached.
>
> [[[
> Remove mention of SVK project as alternative in svnsync.txt
> ]]]
>
> - Ryan
On Mon, Apr 18, 2016 at 10:40:53AM +0200, Stefan Sperling wrote:
> On Mon, Apr 18, 2016 at 10:33:43AM +0200, Branko Čibej wrote:
> > On 18.04.2016 10:28, Stefan Sperling wrote:
> > > On Sun, Apr 17, 2016 at 06:47:35PM +0200, Branko Čibej wrote:
> > >> I've bee
On Mon, Apr 18, 2016 at 10:33:43AM +0200, Branko Čibej wrote:
> On 18.04.2016 10:28, Stefan Sperling wrote:
> > On Sun, Apr 17, 2016 at 06:47:35PM +0200, Branko Čibej wrote:
> >> I've been looking at and fixing new compile-time warnings on trunk, and
> >> not
On Sun, Apr 17, 2016 at 06:47:35PM +0200, Branko Čibej wrote:
> I've been looking at and fixing new compile-time warnings on trunk, and
> noticed that the svn_client_resolve() function was deprecated in
> r1730495 in favour of three new functions that are specialised for text,
> property or tree co
On Sun, Apr 17, 2016 at 01:30:26PM +0200, Branko Čibej wrote:
> On 17.04.2016 18:54, Stefan Fuhrmann wrote:
> > stsp wrote:
> >
> >> * STATUS: r1721285 nomination needs a backport branch
> >
> > This is what I get:
> >
> > $ svn --version
> > svn, version 1.7.9 (r1462340)
> >compiled Oct 15 201
On Fri, Dec 18, 2015 at 01:49:08PM +, Philip Martin wrote:
> Julian Foad writes:
>
> > I (Julian Foad) wrote:
> >
> >> 4. Conversion of the element-based result to a series of WC edits. The
> >> code in branch_compat.c doesn't quite do this, as it assumes an Ev1
> >> output (with only a 'copy
On Mon, Apr 04, 2016 at 11:28:41PM +0200, Stefan wrote:
> Should this be also nominated for backporting to the 1.8 branch, since the
> issue has been reported in 1.8.11
> (https://issues.apache.org/jira/browse/SVN-4624)?
Officially, no. Because 1.8.x only receives fixes for security or data
corrup
On Fri, Apr 01, 2016 at 04:38:00AM -0500, Greg Stein wrote:
> no no no ... we've always said that OUT parameters are not dependable when
> an error occurs.
Do our API docs mention this anywhere?
Or was this information only passed around among SVN devs?
I don't disagree. But we should clearly com
On Mon, Mar 28, 2016 at 04:13:11PM +0300, Ivan Zhakov wrote:
> On 20 March 2016 at 01:18, wrote:
> > {
> >if (err->apr_err == SVN_ERR_CANCELLED)
> > {
> > - svn_error_clear(err);
> >*may_save_plaintext = FALSE;
> > - retu
On Mon, Mar 14, 2016 at 11:35:32AM +0100, Raphael Kubo da Costa wrote:
> [[[
> At the moment the kde4-config script is used only to determine KDE4's
> prefix, and then its header and library locations are derived manually.
>
> This is not optimal, as it assumes the libraries are always installed
>
On Mon, Feb 29, 2016 at 07:30:14PM +0100, Vincent Lefevre wrote:
> For "svn st", I do not try to access the file. A file with an invalid
> name cannot be a versioned file anyway. So, it could also just be
> ignored, and outputting a non-fatal warning would be sufficient, IMHO.
> Note that even "svn
On Sun, Feb 21, 2016 at 02:22:45PM +0100, Branko Čibej wrote:
> Personally I'd much prefer the svn_utf__casefold() you propose (i.e.,
> normalize plus casefold) as a separate API. Internally, it can be
> implemented with that extra flag, but even for a private API, I think
> it's better to make eac
On Wed, Feb 17, 2016 at 05:33:21PM +0300, Ivan Zhakov wrote:
> As we are adding more and more of such code, more and more users
> become faced with the significant performance regression (see [1] and
> other cases).
>
> Do you intend to resolve this problem in the future commits? I have
> some obv
On Wed, Feb 17, 2016 at 04:55:45PM +0100, Bert Huijben wrote:
> The new variable incoming_change is used uninitialized here, breaking the
> build on the Windows bots.
>
> See https://ci.apache.org/builders/svn-windows-local/builds/1046
Thanks for the heads up! Fixed in r1730943.
On Mon, Feb 15, 2016 at 05:30:55PM +0100, Bert Huijben wrote:
> Why would you need to wait for timestamps here?
>
> Can this change the working copy file?
>
> If it can the wc function should probably return a boolean to notify the case
> where it does, and only when it does we should wait for t
On Thu, Feb 04, 2016 at 01:00:38PM +0100, Vincenzo Reale wrote:
> Hi guys,
> I would share and submit a complete revision
> (spellchecked and with new strings) of the Italian
> translation for subversion.
>
> https://drive.google.com/file/d/
> 0B9FgaTlI6p0ybGFhWjk1X3E3SDA/view?usp=sharing
>
> B
On Thu, Feb 04, 2016 at 12:38:54PM +0100, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: phi...@apache.org [mailto:phi...@apache.org]
> > Sent: woensdag 3 februari 2016 15:27
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1728324 -
> > /subversion/trunk/subversi
On Tue, Feb 02, 2016 at 07:48:53PM -0600, Greg Stein wrote:
> On Tue, Feb 2, 2016 at 7:45 PM, Eric S. Raymond wrote:
> > Because of the difference between Subversion and DVCS branching models,
> > this kind of situation is better handled by using svncutter to extract
> > the components into separa
On Mon, Feb 01, 2016 at 12:44:38PM +0100, Andreas Scherer wrote:
> Am Montag, 1. Februar 2016, 10:51:39 schrieb Stefan Sperling:
> > So we could consider extending svn patch to run without a path argument
> > and read the patch from stdin.
> >
> > [...] this feature fa
On Sun, Jan 31, 2016 at 11:48:26AM +0100, Andreas Scherer wrote:
> I suggest to extend 'svn patch' so that it supports usage in a pipe like
>
> gzip -dc patch-0042.gz | svn patch -P patch-0042 -
>
> This would permit using 'svn patch' directly as a drop-in replacement for
>
>gzip -dc pat
On Thu, Jan 28, 2016 at 12:01:07PM +0100, Bert Huijben wrote:
> > + /* Add postpone option. */
> > + option = apr_pcalloc(result_pool, sizeof(*option));
> > + option->id = svn_client_conflict_option_postpone;
> > + option->description = N_("skip this conflict and leave it unresolved");
>
> I t
On Wed, Jan 27, 2016 at 10:40:06PM -0600, William A Rowe Jr wrote:
> If you are new to the conversation, include/apr_cstr.h has absorbed much of
> the efforts of svn_cstring_* API's into apr_cstr_* functions.
I'm very happy to see our strtol()-wrappers in APR. These wrap the POSIX
functions with s
On Thu, Jan 21, 2016 at 05:46:20PM +, Philip Martin wrote:
> Stefan Sperling writes:
>
> > Not objecting to this change, but I believe we do have a few
> > batons on the stack in several places and I don't think this
> > is a problem in general.
>
> It&#x
On Thu, Jan 21, 2016 at 02:18:43PM -, kot...@apache.org wrote:
> Author: kotkov
> Date: Thu Jan 21 14:18:43 2016
> New Revision: 1725957
>
> URL: http://svn.apache.org/viewvc?rev=1725957&view=rev
> Log:
> Allocate the baton for 'svn merge --accept' conflict callback in the pool,
> instead of u
On Thu, Jan 21, 2016 at 01:59:41PM +0100, Stefan Fuhrmann wrote:
> In real world applications this means people just
> hitting the old limit aren't likely to ever hit
> the new limit while those already far beyond it
> have fixed their config by now.
One would hope they'd fix their config. I would
On Thu, Jan 21, 2016 at 01:20:56PM +0100, Stefan Fuhrmann wrote:
> TL;DR: Change is effective as per attached test case.
> No crashes should ever result from it. Some 20% portion
> of cache memory is guaranteed to work as before which
> limits potential side effects.
Sounds like this is related t
On Fri, Jan 15, 2016 at 04:48:28PM -, s...@apache.org wrote:
> Author: stsp
> Date: Fri Jan 15 16:48:27 2016
> New Revision: 1724855
>
> URL: http://svn.apache.org/viewvc?rev=1724855&view=rev
> Log:
> * subversion/libsvn_wc/conflicts.c
> (svn_wc_create_conflict_result): Initialise 'merged_va
On Thu, Dec 17, 2015 at 02:28:44PM +, Julian Foad wrote:
> On 17 December 2015 at 14:14, Stefan Sperling wrote:
> > So I think we'll need some automated support for finding moves.
> > It doesn't need to be perfect, though.
>
> Yes, that's all correct: t
On Thu, Dec 17, 2015 at 12:34:46PM +, Julian Foad wrote:
> I mean that if the user doesn't explicitly specify any moves, then it
> will match by path only, which will result in behaviour similar to
> today. If the user specifies one or more 'moves', those will override
> the path matching for t
On Tue, Dec 08, 2015 at 11:47:46AM +0300, Evgeny Kotkov wrote:
> The 1.9.3 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on December 15th
> so
On Sat, Dec 12, 2015 at 08:59:33PM +0100, Fabien wrote:
>
> Hello Stefan.
>
> >Your script looks very nice! This definitely saves many people some
> >work in writing their own checks.
> >
> >We're trying to retire the contrib/ directory, since there are several
> >ways of hosting open source add-
On Sat, Dec 12, 2015 at 10:26:52AM +0100, Fabien wrote:
>
> Hello svn-dev,
>
> I've developped a while back a configurable pre-commit script which we have
> been using in production on several repositories for some years, see:
>
> http://www.coelho.net/svn-pre-commit.html
>
> I would be w
On Mon, Nov 30, 2015 at 02:02:26PM -, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Mon Nov 30 14:02:26 2015
> New Revision: 1717253
>
> URL: http://svn.apache.org/viewvc?rev=1717253&view=rev
> Log:
> On the ra-git branch: To avoid having to reimplement quite a bit of the repos
> layer
On Fri, Nov 13, 2015 at 11:30:59AM +, Philip Martin wrote:
> Johan Corveleyn writes:
>
> > I'm still very much wondering how this will fit in with the general
> > direction of Subversion ... but as you say, that's something we need
> > to work out together. That, for me, is currently the bigg
On Thu, Sep 24, 2015 at 05:40:45PM +0300, Ivan Zhakov wrote:
> On 24 September 2015 at 17:34, Bert Huijben wrote:
> >>
> >> +/* Parse a given URL_STR, fill in all supplied fields of URI
> >> + * structure.
> >> + *
> >> + * This function is a compatibility wrapper around apr_uri_parse().
> >> + *
On Mon, Sep 21, 2015 at 05:27:18PM -, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Mon Sep 21 17:27:11 2015
> New Revision: 1704374
>
> URL: http://svn.apache.org/viewvc?rev=1704374&view=rev
> Log:
> Complete the parsing routines for parsing git-like binary blobs. This patch
> complet
On Fri, Sep 18, 2015 at 06:43:52PM +0300, Evgeny Kotkov wrote:
> The 1.9.2 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on September 30th
> so
On Fri, Sep 18, 2015 at 10:53:07AM -0400, Mark Phippard wrote:
> I have unlocked the tigris project. Someone can ping me when it should be
> locked again.
BTW, every time the project is locked / unlocked I get multiple emails
from tigris. We should not be doing this very often, I would suggest,
t
On Fri, Sep 18, 2015 at 04:56:04PM +0200, Ivan Zhakov wrote:
> May be we can put issue tracker on tigris read-only: in this case I
> could prepare everything today to avoid potential surprises and the
> time of final migration. Any opinions?
I would prefer we migrate today and don't wait for repli
On Fri, Sep 18, 2015 at 04:25:45PM +0200, Branko Čibej wrote:
> I've begun sending the mails, from my ASF account. I decided to send
> separate mails to each address, to avoid triggering spam filters as much as
> possible. I'm allowing lots of time between the mails so that I don't get
> accidental
On Fri, Sep 18, 2015 at 04:16:22PM +0200, Ivan Zhakov wrote:
> Currently I'm waiting for tigris -> asf user mapping mails to @tigris
> addresses.
I would say we shouldn't wait for that if it means you can't finish the
migration before you're back home and bound up in $dayjob activities.
On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
> Attachments was successfully migrated after multiple attempts and help
> from ASF Infra team. This how Subversion issue tracker will look like:
> https://issues.apache.org/jira/browse/SVN
>
> I'm ready to perform final migration, but I
On Thu, Sep 17, 2015 at 05:41:41PM +0200, Ivan Zhakov wrote:
> That branch is complete and ready for merging, but I'm still not sure
> whether we should merge it or not.
I think we should merge it to trunk now.
I don't think this branch can improve much further unless we start
exercising the code
501 - 600 of 2849 matches
Mail list logo
