On Wed, Oct 12, 2016 at 10:13 PM, wrote:
>
> Author: ivan
> Date: Wed Oct 12 20:13:24 2016
> New Revision: 1764536
>
> URL: http://svn.apache.org/viewvc?rev=1764536&view=rev
> Log:
> * STATUS: Veto r1759116 group.
>
> Modified:
> subversion/branches/1.9.x/STATUS
...
> @@ -135,6 +119,24 @@ Cand
Stefan Fuhrmann writes:
> There are a number of backport proposals that only need one more +1.
> Since the Berlin hackathon is going on and we feel like preparing the
> next patch release(s) soon-ish, please review and vote.
I plan to roll 1.9.5 after the hackathon. Any reason why we might also
Hi there,
There are a number of backport proposals that only need
one more +1. Since the Berlin hackathon is going on and
we feel like preparing the next patch release(s) soon-ish,
please review and vote.
-- Stefan^2.
On 12 October 2016 at 17:06, James McCoy wrote:
> On Wed, Oct 12, 2016 at 04:44:10PM +0200, Ivan Zhakov wrote:
>> On 12 October 2016 at 15:38, Patrick Steinhardt
>> wrote:
>> > Hi,
>> >
>> > please find attached a patch pulling out the short descriptions
>> > of conflict resolution options from t
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: Re: [PATCH] Reject checkouts to existing director
On Wed, Oct 12, 2016 at 04:44:10PM +0200, Ivan Zhakov wrote:
> On 12 October 2016 at 15:38, 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.
> >
> > [
On Wed, Oct 12, 2016 at 04:32:24PM +0200, Stefan Sperling wrote:
> On Wed, Oct 12, 2016 at 03:38:02PM +0200, Patrick Steinhardt wrote:
[snip]
> > + svn_client_conflict_option_t *option,
> > + apr_pool_t *result_pool,
> > +
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: Re: [PATCH] Reject checkouts to existing director
On Wed, Oct 12, 2016 at 04:44:10PM +0200, Ivan Zhakov wrote:
> On 12 October 2016 at 15:38, 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.
> >
> > [
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: woensdag 12 oktober 2016 16:37
> To: Patrick Steinhardt
> Cc: Subversion
> Subject: Re: [PATCH] Reject checkouts to existing directory
>
> On Wed, Oct 12, 2016 at 04:28:05PM +0200, Patrick Steinhardt wrote:
> >
On 12 October 2016 at 15:38, 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
>
> * include/sv
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
>
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/svn/checkout-cmd.c:
- (svn_cl__checkout): Reject checkout to existing directory
wit
On Wed, Oct 12, 2016 at 03:46:38PM +0200, Ivan Zhakov wrote:
> On 12 October 2016 at 15:05, Patrick Steinhardt
> wrote:
> > Hi,
> >
> > see the attached patch for fixes to some unused-variable
> > warnings.
> >
> > [[
> > Remove variables which are written but not used in any way.
> >
> > * subver
On 12 October 2016 at 15:05, Patrick Steinhardt
wrote:
> Hi,
>
> see the attached patch for fixes to some unused-variable
> warnings.
>
> [[
> Remove variables which are written but not used in any way.
>
> * subversion/libsvn_client/conflicts.c:
> Remove unused variables
> ]]
Hi, Patrick.
The
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
* include/svn_client.h:
- Provide function `svn_client_conflict_option_label`
* lib
Hi,
see the attached patch for fixes to some unused-variable
warnings.
[[
Remove variables which are written but not used in any way.
* subversion/libsvn_client/conflicts.c:
Remove unused variables
]]
--
Patrick Steinhardt, Entwickler
elego Software Solutions GmbH, http://www.elego.de
Gebäud
On 12 October 2016 at 14:03, Paul Hammant wrote:
> It's very exciting to hear that Subversion already calculates shas somewhere
> in the backend :)
I noted this multiple times on this thread: SHAs are optional at the
repository backend layer.
--
Ivan Zhakov
> -Original Message-
> From: Paul Hammant [mailto:p...@hammant.org]
> Sent: woensdag 12 oktober 2016 14:45
> To: Subversion Development
> Subject: Re: New SHA1 property for nodes returned 'svn ls --xml'
invocations.
>
> Svnsync looks to also leverage sha1s - I'll try to make a small exp
Hi Bert, thanks for your reply.
The problem that I've described is not about revision numbers, it's about copied
nodes.
Suppose we have an repository 'repo' containing nodes '/A' and '/B',
where '/B' (or some path under '/B') was create by copying of '/A' (or some
path under '/A').
Now, if we ru
Svnsync looks to also leverage sha1s - I'll try to make a small experiment
later, and report back.
I see that svnadmin-dump will add in sha1 hashes. But that is server side only
:-(
On 10/12/2016 1:22 PM, Daniel Shahaf wrote:
> Stefan wrote on Wed, Oct 12, 2016 at 13:17:50 +0200:
>> On 10/12/2016 12:58 PM, Ivan Zhakov wrote:
>>> PS: Please submit patches with text/plain mime type as recommended in
>>> Community Guide [1]
>>> [1]
>>> https://subversion.apache.org/docs/communit
It's very exciting to hear that Subversion already calculates shas somewhere in
the backend :)
I can't find the cadaver source repo, but a tar.gz for v0.23.3 is on the site.
Unarchiving that, and using ack to find 'sha' (case insensitive) yields no
matches.
Can you direct me to any reproduca
Stefan wrote on Wed, Oct 12, 2016 at 13:17:50 +0200:
> On 10/12/2016 12:58 PM, Ivan Zhakov wrote:
> > PS: Please submit patches with text/plain mime type as recommended in
> > Community Guide [1]
> > [1]
> > https://subversion.apache.org/docs/community-guide/general.html#patches-submission
> Didn'
On 10/12/2016 12:58 PM, Ivan Zhakov wrote:
> On 12 October 2016 at 12:48, Stefan wrote:
>> Hi,
>>
>> hope this patch is correct... As far as I see the number of elements is
>> off by one here:
>>
>> [[[
>> Allocate the correct number of element entries.
>>
>> * subversion/libsvn_client/conflicts.
On 12 October 2016 at 12:58, Ivan Zhakov wrote:
> On 12 October 2016 at 12:48, Stefan wrote:
>> Hi,
>>
>> hope this patch is correct... As far as I see the number of elements is
>> off by one here:
>>
>> [[[
>> Allocate the correct number of element entries.
>>
>> * subversion/libsvn_client/conf
This doesn’t look like some kind of update request (more like a commit). We use
many different propfind requests, which usually only return the requested
information as that is far more efficient than requesting all properties.
I don’t see why we would need it on commit, so I’m not surprised
> -Original Message-
> From: Sergey Raevskiy [mailto:sergey.raevs...@visualsvn.com]
> Sent: woensdag 12 oktober 2016 12:44
> To: Subversion Development
> Subject: [PATCH] Add '--include' and '--exclude' options to 'svnadmin dump'
>
> Hi!
>
> I've attached a patch that adds '--include/-
Dario Niedermann wrote on Wed, Oct 12, 2016 at 12:04:03 +0200:
> Returning to the original topic, and just to be even clearer: this is
> about Subversion NOT RUNNING a script because it has a FLAG FOR THE
> SHELL in its SHEBANG LINE. Not because I got the path to bash wrong or
> because there is so
On 12 October 2016 at 12:48, Stefan wrote:
> Hi,
>
> hope this patch is correct... As far as I see the number of elements is
> off by one here:
>
> [[[
> Allocate the correct number of element entries.
>
> * subversion/libsvn_client/conflicts.c
> (svn_client_conflict_text_get_resolution_options
You're right - and in the fullness of time, I'll replace all the Svn uses
with their wire equivalents. If Shas were implemented at some future date,
I'd be happy for them to be available via PROPFIND. I's be even more happy
for them to be passed back to me in the response of a PUT.
Or are you say
Hi,
hope this patch is correct... As far as I see the number of elements is
off by one here:
[[[
Allocate the correct number of element entries.
* subversion/libsvn_client/conflicts.c
(svn_client_conflict_text_get_resolution_options): Correct number of array
entires.
]]]
Regards,
Stefan
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
Hi!
I've attached a patch that adds '--include/--exclude' options to 'svnadmin
dump'. These options work similarly to 'svndumpfilter include/exclude'
but provide proper handling of 'copy from' paths.
Consider the following example with svndumpfilter:
[[
$ svnadmin create /repo
$ svn mkdir -m "" f
Il 12/10/2016 alle 12:18, Stefan Sperling ha scritto:
> I don't think it's a very important bug to fix though because there is
> an easy workaround. You should be able to work around this by adding:
>
> set -e
>
> on the first line of your script.
That is true. I was mostly wondering if Subve
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
Il 12/10/2016 alle 11:29, Stefan ha scritto:
> Forwarding messages to the dev list is not really considered good
> practice.
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 onl
Hi Dario,
On 10/12/2016 9:47 AM, Dario Niedermann wrote:
> Hi! Having received no relevant replies on users@ in 15 days, I'm
> forwarding my message here. Thanks for looking into the issue.
>
> - Forwarded message from Dario Niedermann -
>
> Hello! I've been having trouble getting my own p
Hi! Having received no relevant replies on users@ in 15 days, I'm
forwarding my message here. Thanks for looking into the issue.
- Forwarded message from Dario Niedermann -
Hello! I've been having trouble getting my own pre-revprop-change
hook script to work. Svn was refusing any change
If you are using dav autoversioning, then why do you want to obtain the sha
using 'svn’.
You should be able to obtain the sha using a PROPFIND request against the
server.
We use that checksum from there to avoid downloading the same file multiple
times in our streamlined v2 http protocol.
Ber
42 matches
Mail list logo
