Re: Re: svn merge --reintegrate like diff

[Daniel Shahaf]

Johan Corveleyn wrote on Mon, Sep 26, 2016 at 13:04:04 +0200:
> 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'.

That command would also show changes made on trunk that have not yet been
merged to the branch.  (E.g., if you ran it in on subversion's trunk and
1.9.x branch, it would show -SVN_VER_MINOR 10\n +SVN_VER_MINOR 9\n.)

The OP asked for the changes merge would do, which is approximately
   --old=TRUNK@REV --new=BRANCH
where REV is the youngest revision of trunk merged to the branch.
("Approximately" because this is inaccurate when cherry-picks or subtree
merges hapepned.)

Cheers,

Daniel

[Linux] Hook hashbang hardships

[Dario Niedermann]

Hello! I've been having trouble getting my own pre-revprop-change
hook script to work. Svn was refusing any change to a revprop with
the following error:

svn: E165001: Revprop change blocked by pre-revprop-change hook
(exit code 1) with no output.


Until I found out that the issue was in the script's shebang:

#!/bin/bash -e

which wouldn't work. Had to remove ' -e'. Is this expected behaviour
or is there something wrong with svn (version 1.9.4 (r1740329) on
Linux/x86_64) ?

Thanks,
DN

Re: [Linux] Hook hashbang hardships

[Ralph Seichter]

On 27.09.2016 12:59, Dario Niedermann wrote:

> I found out that the issue was in the script's shebang:
>
> #!/bin/bash -e
>
> which wouldn't work. Had to remove ' -e'. Is this expected behaviour or
> is there something wrong with svn (version 1.9.4 (r1740329) on
> Linux/x86_64) ?

Why would anything be wrong with Subversion? Apparently something is not
going as expected in your own script, causing bash to exit.

Scripts always have to be adapted to local needs. On some systems, the
path for bash might be different, or bash might not be available at all.
That's each user's own responsibility.

-Ralph

Re: svn merge --reintegrate like diff

[Alexey Neyman]

On 09/27/2016 01:46 AM, Daniel Shahaf wrote:

Johan Corveleyn wrote on Mon, Sep 26, 2016 at 13:04:04 +0200:

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'.

That command would also show changes made on trunk that have not yet been
merged to the branch.  (E.g., if you ran it in on subversion's trunk and
1.9.x branch, it would show -SVN_VER_MINOR 10\n +SVN_VER_MINOR 9\n.)

The OP asked for the changes merge would do, which is approximately
--old=TRUNK@REV --new=BRANCH
where REV is the youngest revision of trunk merged to the branch.
("Approximately" because this is inaccurate when cherry-picks or subtree
merges hapepned.)
There's one more issue with these approaches. ReviewBoard can be smart 
about displaying the moved/copied files. However:


- If one does 'svn merge --reintegrate', Subversion will copy new files 
from the branch unchanged, and 'svn diff' will not show them (and hence, 
RB won't either) - or, with --show-copies-as-adds, it will show them as 
being added anew. For the review purposes, it would be better if instead 
of copying the file from the branch unchanged, Subversion would perform 
the same move on the trunk and apply the textual changes.
- If you do 'svn diff --old=... --new=...', I believe the copy-from 
information is lost from the diff completely - and ReviewBoard will show 
all the moved files as adds/deletes, not showing diffs either.


For now, I am using the attached script to perform this task. The 
workflow is:

1. Perform a merge to trunk.
2. Run the script (which attempts to find the original location in trunk 
for every copied file and replay the move on trunk).

3. 'rbt post'.

The script is not perfect; it only operates at file level - so if there 
are renamed directories, the files inside them end up in 'R +' status 
(replaced with history) and ReviewBoard shows a spurious deletion for 
this file, in addition to a move/copy with changes.


Regards,
Alexey.

#!/usr/bin/python3
# vim: set et sw=4 :

import os
import re
import subprocess
import sys

allowed_paths = [ "/vendor/" ]
debug = False

def get_svninfo_value(svnlog, lookfor):
for l in svnlog.splitlines():
if l.startswith(lookfor):
return l[len(lookfor):]

def get_common_part(f1, f2):
l1 = f1.split('/')
l2 = f2.split('/')
for i in range(0, min(len(l1), len(l2))):
if l1[i] != l2[i]:
break;
else:
i = min(len(l1), len(l2)) + 1
return '/'.join(l1[0:i])

def get_original_path(f):
copied_path = f
rest = ""
wcroot = None
while True:
if copied_path == wcroot:
return f
svnlog = subprocess.check_output(["svn", "info", copied_path], 
universal_newlines=True)
if wcroot is None:
wcroot = get_svninfo_value(svnlog, "Working Copy Root Path: ") # 
Path to WC
rel_path = get_svninfo_value(svnlog, "Relative URL: ^") # Relative URL
root_url = get_svninfo_value(svnlog, "Repository Root: ") # Repository 
root URL
copy_url = get_svninfo_value(svnlog, "Copied From URL: ") # Copy-from 
URL
if (rel_path is None or root_url is None):
raise ValueError
if (copy_url is not None):
if (not(copy_url.startswith(root_url + '/'))):
print("Invalid copy URL")
raise ValueError
break
last_slash = copied_path.rindex("/")
rest = copied_path[last_slash:] + rest
copied_path = copied_path[:last_slash]
rel_path += rest
copy_url += rest
svnlog = subprocess.check_output(["svn", "info", wcroot], 
universal_newlines=True)
rel_root_path = get_svninfo_value(svnlog, "Relative URL: ^") # Relative URL 
for root of WC
if rel_root_path is None:
print("No root path found")
raise ValueError
lookfor = copy_url[len(root_url):]
if debug:
print('wcroot %s' % wcroot)
print("root rel path {%s}" % rel_root_path)
print("look for {%s}" % lookfor)
try:
svnlog = subprocess.check_output(["svn", "log", "-qv", f], 
universal_newlines=True)
except subprocess.CalledProcessError:
return f # Ok, even though inside a copied path, this path does not 
seem to be copied
logrevs = 
svnlog.split("\n")[1:-1]
while True:
if lookfor.startswith(rel_root_path):
orig = wcroot + lookfor[len(rel_root_path):]
if debug:
print("found local copy source for `%s': `%s' (lookfor `%s')" % 
(f, orig, lookfor))
return orig
elif get_common_part(lookfor, rel_root_path):
if debug:
 

Re: svn switch, touches files with svn:keywords

[Nico Kadel-Garcia]

On Mon, Sep 26, 2016 at 3:36 AM, 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.

How can Subversion know that? Reprocessing the file, setting aside the
processed file, then doing a "diff" between them is a lot more pain
than it's worth. And the maintenance of supporting such a feature for
all releases, and backporting it to previous Subversion releases to
support such a contorted workflow as switching upstream midrepos or
branches midstream, is potentially quite fragile.

If you switch the upstream repo for a software source repo, recompile.
It's the best way to make sure you've not left some datestamped file
inconsistencies that could mess with the system.

> 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.

And how, exactly, are you going to verify this? Put in a locally
processed working file to check against? That's begging to leave
debris in the working repository./

> 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

[Branko Čibej]

On 28.09.2016 01:44, Nico Kadel-Garcia wrote:
>
>> 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.
> And how, exactly, are you going to verify this? Put in a locally
> processed working file to check against? That's begging to leave
> debris in the working repository.

Subversion already has both files available.

Files that arrive in the working copy (during checkout, update, etc.)
are preprocessed in a temporary to expand keywords, adjust newlines and
so on, then moved to the final location in the working copy.

-- Brane

Linux patch with Apache update changing permissions on SVN files

[Benson, Dave L.]

We are running Linux

Linux xx.xxx.com 2.6.32-504.12.2.el6.x86_64 #1 SMP Sun Feb 1 12:14:02 
EST 2015 x86_64 x86_64 x86_64 GNU/Linux

We are also using Collabnet - SubversionEdge:
Information
Software version

3.2.1-3360.104

Subversion version

1.7.7-3360.104


Over the weekend out techgroup rolled out a patch that apparently included an 
Apache update.

Many of our directories and files under
/svn/cnsvnedge
Were owned by apache , group apache
This was especially true under /svn/cnsvnedge/data  - where the repositories 
live, and /svn/cnsvnedge/conf where config files live.

During the patching the permissions to all of these were set back to a level 
where only apache could run them, but cnsvnedge runs as webadm on our box.  As 
a result we were not able to start SubversionEdge using  'csvn start'.

I was logging into the server with my private account and doing a
sudo to apache before trying to start the service.

This has worked numerous times in the past.

Here is how it goes:

cd /svn/cnsvnedge
sudo -u apache bash
export JAVA_HOME=/usr/java/default
bin/csvn start

I get this error and it quits

/sbin/runuser: cannot set groups: Operation not permitted

Our techgroup was able to reassign groups and permissions to directories and 
files to at least start Edge and eventually allow write access to our repos.  
But this runuser issues persists so our standard shutdown/startup procedures do 
not work anymore.

Any help would be appreciated on what Apache did to us and how to get things 
back to normal.

NOTE:  I am not a subscribed user (yet).
David L. Benson | Senior Application Developer
Donaldson Co., Inc | COMPASS - RICEW/Development Team
Phone: 952-887-3823
david.ben...@donaldson.com | 
www.donaldson.com
Thank you for considering the environmental impact of printing emails.


[cid:image001.jpg@01D149EB.28481590]
Click here to access IT Self Service 

How to open an IT support 
ticket