Re: 1.9.4 on RHEL 7 (httpd version difficulties)

2016-09-26 Thread Zdenek Sedlak
On 2016-09-20 10:59, Zdenek Sedlak wrote:
> On 2016-09-17 09:49, Daniel Shahaf wrote:
>> Branko Čibej wrote on Sat, Sep 17, 2016 at 03:29:25 +0200:
>>> But be aware that if the RHEL 7 version of httpd is *not* patched, your
>>> SVN server will be broken in subtle ways.
>>>
>>> I really have no idea how to check that.
>> I believe the relevant change is this:
>>
>>   https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.7/CHANGES
>>   *) mod_dav: dav_resource->uri is treated as unencoded. This was an
>>  unnecessary ABI changed introduced in 2.4.6. PR 55397.
> Hi,
>
> I opened a support case @ Red Hat. Hopefully Red Hat will be willing
> to back-port this change back to 2.4.6, as this may affect more
> product relying on DAV.
>
> //Zdenek 

Hi,

could any one check if this fixed the problem?
https://bugzilla.redhat.com/show_bug.cgi?id=1235383

Or at least point me at something I can test by myself.

Should be fixed in httpd-2.4.6-39 or greater.

//Zdenek


RE: svn switch, touches files with svn:keywords

2016-09-26 Thread Bert Huijben


> -Original Message-
> From: Daniel Shahaf [mailto:danie...@apache.org]
> Sent: zaterdag 24 september 2016 09:11
> To: FEDERICO PRADES ILLANES 
> Cc: users@subversion.apache.org
> Subject: Re: svn switch, touches files with svn:keywords
> 
> FEDERICO PRADES ILLANES wrote on Fri, Sep 23, 2016 at 12:36:24 +0200:
> > Steps to reproduce:
> >
> >1. Create a branch b1.
> >2. Create an dummy file in b1, with svn:keywords.
> >3. Don't use the svn:keywords on the file.
> >4. Commit the changes to b1.
> >5. Create a branch b2, from b1.
> >6. Perform a switch to b2.
> >
> > Expected results:
> >
> >- Dummy file modification time hasn't change
> >
> > Actual results
> >
> >- Dummy file modification time has change
> 
> I can reproduce this with current trunk and I agree it's a (minor) bug.

See also issue #1975, which documented the opposite behavior as a bug, which 
was fixed in 1.9.0
http://subversion.apache.org/issue1975

Bert



Re: Re: svn merge --reintegrate like diff

2016-09-26 Thread Johan Corveleyn
On Mon, Sep 26, 2016 at 10:30 AM, Veit Guna  wrote:
>> Gesendet: Montag, 26. September 2016 um 09:59 Uhr
>> Von: "Johan Corveleyn" 
>> An: "Daniel Shahaf" 
>> Cc: "Veit Guna" , "users@subversion.apache.org" 
>> 
>> Betreff: Re: svn merge --reintegrate like diff
>>
>> On Sat, Sep 24, 2016 at 12:44 PM, Daniel Shahaf  
>> wrote:
>> > Veit Guna wrote on Sat, Sep 24, 2016 at 12:19:16 +0200:
>> >> So basically what I need is a diff that shows me the same changes that
>> >> would be made to trunk if the branch
>> >> would be merged to it (ignoring trunk changes merged to branch).
>> >>
>> >> Is this somehow possible?
>> >
>> > Checkout trunk@HEAD, run 'merge --reintegrate' (without committing the
>> > result), and run 'diff'?
>> >
>> > That'd give the most accurate answer possible, even if the branch has
>> > received cherry-picking or subtree merges.
>>
>> I would think that 'svn diff --old=$trunk --new=$branch' should also
>> work pretty well.
>>
>> Perhaps experiment with some of the options like --no-diff-added,
>> --no-diff-deleted, --ignore-properties, --show-copies-as-adds, --git,
>> --patch-compatible, ...
>>
>> --
>> Johan
>>
> Hi Johan.
>
> That's what I've used in the past. But that showed trunk merges as well. 
> Haven't tried the mentioned options though.
> Currently testing the suggested merge-to-trunk-and-diff approach. Looks 
> promising...

Hi Veit,

[ Please remember to include the mailinglist when replying. ]

Maybe I'm missing something, but I don't understand why 'svn diff
--old=TRUNK --new=BRANCH' would show you things that you previously
merged from TRUNK to BRANCH. It should show exactly the content-wise
difference between TRUNK and BRANCH, so if some content was merged
from TRUNK to BRANCH, both should be identical on that point, and it
shouldn't show up in 'diff'. Except if you're talking about ignoring
certain content in a merge e.g. by using --record-only merges, or by
modifying the merge result during conflict resolution or something
like that ...

-- 
Johan


Re: svn switch, touches files with svn:keywords

2016-09-26 Thread Lorenz
Daniel Shahaf wrote:

>Lorenz wrote on Mon, Sep 26, 2016 at 06:01:31 +:
>> are you sure about tha being a bug?
>> 
>> If for instance in the file the URL keyword is used to initialize a
>> string variable, wouldn't you want the file to be recompiled after the
>> switch?
>
>You are describing a different scenario than the OP.
>[...]

ah yes, I overlooked "3. Don't use the svn:keywords on the file."
-- 

Lorenz



Re: svn switch, touches files with svn:keywords

2016-09-26 Thread FEDERICO PRADES ILLANES
Issue created: https://issues.apache.org/jira/browse/SVN-4656


*Federico Prades Illanes* - *ext. (2)75682 - Software Evangelist*
*Quantitative and Business Solutions (QBS) **- CIB - **BBVA*

On 26 September 2016 at 09:36, Daniel Shahaf  wrote:

> Lorenz wrote on Mon, Sep 26, 2016 at 06:01:31 +:
> > are you sure about tha being a bug?
> >
> > If for instance in the file the URL keyword is used to initialize a
> > string variable, wouldn't you want the file to be recompiled after the
> > switch?
>
> You are describing a different scenario than the OP.
>
> In the OP's scenario, the file content with keywords expanded was the
> same before and after the switch, yet the mtime differed.  I consider
> that a bug.
>
> If the file content with keywords expanded had been different before the
> switch to after to the switch, then yes, I would have expected the mtime
> to differ, too.
>
> Thanks for contributing this observation: the key question is whether
> the translated content was modified, not whether the repository-normal
> content was.
>
> Cheers
>
> Daniel
>

-- 


"Este mensaje está dirigido de manera exclusiva a su destinatario y puede 
contener información privada y confidencial. No lo reenvíe, copie o 
distribuya a terceros que no deban conocer su contenido. En caso de haberlo 
recibido por error,  rogamos lo notifique al remitente y proceda a su 
borrado, así como al de cualquier documento que pudiera adjuntarse.

 Por favor tenga en cuenta que los correos enviados vía Internet no 
permiten garantizar la confidencialidad de los mensajes ni su transmisión 
de forma íntegra.

 Las opiniones expresadas en el presente correo pertenecen únicamente al 
remitente y no representan necesariamente la opinión del Grupo BBVA."

 "This message is intended exclusively for the adressee and may contain 
privileged and confidential information. Please, do not disseminate, copy 
or distribute it to third parties who should not receive it. In case you 
have received it by mistake, please inform the sender and delete the 
message and attachments from your system.

 Please keep in mind that e-mails sent by Internet do not allow to 
guarantee neither the confidentiality or the integrity of the messages 
sent."


Re: svn merge --reintegrate like diff

2016-09-26 Thread Johan Corveleyn
On Sat, Sep 24, 2016 at 12:44 PM, Daniel Shahaf  wrote:
> Veit Guna wrote on Sat, Sep 24, 2016 at 12:19:16 +0200:
>> So basically what I need is a diff that shows me the same changes that
>> would be made to trunk if the branch
>> would be merged to it (ignoring trunk changes merged to branch).
>>
>> Is this somehow possible?
>
> Checkout trunk@HEAD, run 'merge --reintegrate' (without committing the
> result), and run 'diff'?
>
> That'd give the most accurate answer possible, even if the branch has
> received cherry-picking or subtree merges.

I would think that 'svn diff --old=$trunk --new=$branch' should also
work pretty well.

Perhaps experiment with some of the options like --no-diff-added,
--no-diff-deleted, --ignore-properties, --show-copies-as-adds, --git,
--patch-compatible, ...

-- 
Johan


Re: svn switch, touches files with svn:keywords

2016-09-26 Thread Daniel Shahaf
Lorenz wrote on Mon, Sep 26, 2016 at 06:01:31 +:
> are you sure about tha being a bug?
> 
> If for instance in the file the URL keyword is used to initialize a
> string variable, wouldn't you want the file to be recompiled after the
> switch?

You are describing a different scenario than the OP.

In the OP's scenario, the file content with keywords expanded was the
same before and after the switch, yet the mtime differed.  I consider
that a bug.

If the file content with keywords expanded had been different before the
switch to after to the switch, then yes, I would have expected the mtime
to differ, too.

Thanks for contributing this observation: the key question is whether
the translated content was modified, not whether the repository-normal
content was.

Cheers

Daniel


Re: svn switch, touches files with svn:keywords

2016-09-26 Thread Lorenz
Daniel Shahaf wrote:

>FEDERICO PRADES ILLANES wrote on Fri, Sep 23, 2016 at 12:36:24 +0200:
>> Steps to reproduce:
>> 
>>1. Create a branch b1.
>>2. Create an dummy file in b1, with svn:keywords.
>>3. Don't use the svn:keywords on the file.
>>4. Commit the changes to b1.
>>5. Create a branch b2, from b1.
>>6. Perform a switch to b2.
>> 
>> Expected results:
>> 
>>- Dummy file modification time hasn't change
>> 
>> Actual results
>> 
>>- Dummy file modification time has change
>
>I can reproduce this with current trunk and I agree it's a (minor) bug.
>[...]

are you sure about tha being a bug?

If for instance in the file the URL keyword is used to initialize a
string variable, wouldn't you want the file to be recompiled after the
switch?
-- 

Lorenz