Re: More questions

[Stefan Hett]

Hi,

More noob questions about svn...

1.  Is using externals a good idea?

I've been told that it's generally a bad idea, and it feels to me like 
a bad idea, since it obfuscates what's going on in the repo.  Is it 
often done for professional projects?

It depends on the use-case.
There are situations where using externals are beneficial, but there are 
also several caveats related to externals.


One real-life example we in our company had trouble with was with a 1.6 
repository where we wanted to replace externals with a real copy of the 
source (i.e. remove the external property and copy the real source to 
the folder). That lead to tree conflicts when merging/updating 
WCs/branches and took a lot more time than anticipated. That was 
especially a PITA since these externals weren't actually necessary in 
the first place.


You might wanna check-out the issues related to externals which might 
give you a rough feeling of known bugs (search for "external" in the 
summary and optionally limit the search to issues for 1.6.x)

http://subversion.tigris.org/issues/query.cgi

Several of the known issues with externals have been dealt with in the 
upcoming 1.7 release, so things will improve with the next version 
beyond what has already been solved in the 1.6-branch.


Another caveat of externals is that they are generally slower when doing 
an update, since each external has to be checked individually to verify 
wheter it's up-to-date in the WC.


I tend to live with a rule of thumb here:
Use externals where necessary, avoid them where possible.

Regards,
Stefan

E175009 upon merge with Subversion 1.8.1

[Stefan Hett]

Hi,

I'm having the following issue with Subversion 1.8.1:

Upon trying to merge a specific (rather large) revision from trunk into 
a branch I'm getting the following error after a few minutes:

"svn: E175009: Missing update-report close tag"

Environment:
TSVN 1.8.1 (also tried via svn-command: svn merge http://[])

Tortoise SVN shows it's build against Serf 1.3.0.

On the server side we use Visual SVN 2.5.10 (build against Subversion 
1.7.10).


The server is accessed via a VPN connection (effective transferrate is 
roughly 60-70 kb/s). The revision I'm trying to merge contains several 
larger binary files (a few MB in total size).


Searching on the web makes me suspicious that these reports ran into the 
same problem I did:

http://codeplex.codeplex.com/wikipage?title=Using%20TortoiseSVN%20with%20CodePlex
http://wiert.me/2013/07/25/svnsubversion-and-codeplex-for-now-stick-to-svntortoisesvn-1-7-x-or-lower/ 
(second issue)


Is there any workaround for the problem? Any further details I can 
provide you with to trace down the issue?


Regards,
Stefan

Re: svn: E155011 "out of date" error and svn: E160020 "already exists" error

[Stefan Hett]

Hi James,

the error sounds to me as if the file you wanted to add was already 
commited.

Did you try svn up before svn commit?

Regards,
Stefan


I renamed a package (folder name) and then renamed two files under it 
(the renamed folder). Then I use kdesvn to do commit which will add 
and then commit, I think. I got the attached error.  Then I tried the 
following command line commands but no luck: svn up --force theFolder, 
svn commit -m "messages"

.
Is there a way to fix it or I have to checkout a fresh copy and copy 
over the existing one?


I am using svn 1.8.10 under Fedora 20.

thanks,
James


$ svn commit -m "rename scmgmt package to exmgmt"
Adding com/uiapp/exmgmt/ExMgmtMgr.java
svn: E155011: Commit failed (details follow):
svn: E155011: File 
'/home//0-workspace/OC/trunk/latest/src/com/uiapp/exmgmt/ExMgmtMgr.java' 
is out of date

svn: E160020: File 'com/uiapp/exmgmt/ExMgmtMgr.java' already exists

Re: crash report

[Stefan Hett]

Hi Klaus,

the SVN developers don't provide Windows binaries themselves. Without 
telling which distribution you are working with (aka: where you got the 
files located under C:/opt/subversion_1.7) the given dmp-file is merely 
useless as most likely is the given stacktrace.


Regards,
Stefan


Freundliche Grüße / kind regards

i. A. Dipl.-Phys. Klaus Rezepka

Entwicklung Powertrain



Lauer & Weiss GmbH
Kompetenzzentrum für Modulentwicklung
Höhenstraße 21
70736 Fellbach
Tel: +49 711 520889 259
Fax: +49 711 520889 20
Mail: klaus.reze...@lauer-weiss.de 
www.lauer-weiss.de 

Geschäftsführer: Jochen Lauer
Bankverbindung: IBAN: DE25 6026 1329 0032 8800 06  BIC: GENODES1FBB
Umsatzregister: ID-Nr. DE 210208516
Registergericht: Amtsgericht Stuttgart
Registernummer: HRB Nr. 264166

Re: How to move folder from one path to another along with all revisions

[Stefan Hett]

http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.move.html

Hi,

Suppose I have one folder in Repo1 (http://abc.com/SVN/Repo1/folder1) and I
have moved that folder to some new path which is (http://abc.com/SVN/Repo1).
Point is I want to move that folder along with all its revisions to new path
when i check history of that folder there should be all revisions instead of
one revision. Can someone tell how can i move folder along with all its
revisions to new path ?



Regards
Mohsin Abbas




--
View this message in context: 
http://subversion.1072662.n5.nabble.com/How-to-move-folder-from-one-path-to-another-along-with-all-revisions-tp192143.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: How to move folder from one path to another along with all revisions

[Stefan Hett]

This is the whole purpose of the svn mv-command. The history is kept if 
you use that command. Or am I getting your question wrong?


Regards,
Stefan

Thanks but my second question was how do i move folder to new path with all
its revision history ? Is it possible or we can't do this ? Actually moving
folder to new path is easy but question is moving folder with all its
history revisions to new path too.


Mohsin



--
View this message in context: 
http://subversion.1072662.n5.nabble.com/How-to-move-folder-from-one-path-to-another-along-with-all-revisions-tp192143p192148.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: inconsistency between mergeinfo records

[Stefan Hett]

Looks like the batch-file got truncated by some clients/mail servers on 
the way --- here's the plain batch file content.

Anyone having an idea what's going on here?

REM create test repository
mkdir C:\test
cd /d C:\test
mkdir test2
svnadmin create test2

REM check-out test repository
mkdir test2checkout
svn co file:///C:/test/test2 ./test2checkout
cd test2checkout

REM add initial structure
mkdir A
echo > A\test.txt
svn add A
svn commit -m test

REM copy A to B
svn cp A B
svn commit -m test

REM modify A/test.txt
echo >> A\test.txt
svn commit -m test

REM cherry pick test.txt change and commit to B
svn up
svn merge -r 2:3 A/test.txt B/test.txt
svn commit -m test

REM modify A/test.txt again
echo >> A\test.txt
svn commit -m test

REM do an auto merge of B
svn up
svn merge file:///C:/test/test2/A B
REM This produces merge infos in B only

REM alternative
svn revert B -R
svn merge file:///C:/test/test2/A B --record-only
REM This produces merge infos in B AND B/test.txt

Regards,
Stefan

Hi,

I'm wondering why there is a difference in how mergeinfos are recorded 
based on whether the merge is done using --record-only or not.
To demonstrate the case, I've put together a repro-script (for Windows 
- see attachment).


My question is that why does the last step in the script produce 
different merge-info properties:


1. svn merge file:///C:/test/test2/A B
This will produce mergeinfo in B

2. svn merge file:///C:/test/test2/A B --record-only
This will produce mergeinfo in B and B/test.txt

Looking through the web, the docu and the SVN buglist I couldn't find 
any matching entry. Maybe someone can point me on where to look for an 
explanation?


I'm wondering especially because as an alternative to variation 2, one 
might also follow variation 1 and then revert all changes (except for 
the recorded mergeinfo B). Isn't the outcome then the same as 
variation 2?


Regards,
Stefan

Re: inconsistency between mergeinfo records

[Stefan Hett]

Another user (Sergey Azarkevich) actually pointed me to an interesting fact:
C:\test\test2checkout>svn merge file:///C:/test/test2/A B --record-only
--- Recording mergeinfo for merge of r2 through r5 into 'B':
...

C:\test\test2checkout>svn merge file:///C:/test/test2/A B
--- Merging r3 through r5 into 'B':
...

Using explicit range of revisions same as for --record-only lead to equal
modifications in wc:
C:\test\test2checkout>svn merge file:///C:/test/test2/A B -r 2:5
--- Merging r3 through r5 into 'B':

Note the different ranges (r2-r5 vs. r3-r5 in the first two calls).
Maybe this sheds some light here?

Regards,
Stefan
Looks like the batch-file got truncated by some clients/mail servers 
on the way --- here's the plain batch file content.

Anyone having an idea what's going on here?

REM create test repository
mkdir C:\test
cd /d C:\test
mkdir test2
svnadmin create test2

REM check-out test repository
mkdir test2checkout
svn co file:///C:/test/test2 ./test2checkout
cd test2checkout

REM add initial structure
mkdir A
echo > A\test.txt
svn add A
svn commit -m test

REM copy A to B
svn cp A B
svn commit -m test

REM modify A/test.txt
echo >> A\test.txt
svn commit -m test

REM cherry pick test.txt change and commit to B
svn up
svn merge -r 2:3 A/test.txt B/test.txt
svn commit -m test

REM modify A/test.txt again
echo >> A\test.txt
svn commit -m test

REM do an auto merge of B
svn up
svn merge file:///C:/test/test2/A B
REM This produces merge infos in B only

REM alternative
svn revert B -R
svn merge file:///C:/test/test2/A B --record-only
REM This produces merge infos in B AND B/test.txt

Regards,
Stefan

Hi,

I'm wondering why there is a difference in how mergeinfos are 
recorded based on whether the merge is done using --record-only or not.
To demonstrate the case, I've put together a repro-script (for 
Windows - see attachment).


My question is that why does the last step in the script produce 
different merge-info properties:


1. svn merge file:///C:/test/test2/A B
This will produce mergeinfo in B

2. svn merge file:///C:/test/test2/A B --record-only
This will produce mergeinfo in B and B/test.txt

Looking through the web, the docu and the SVN buglist I couldn't find 
any matching entry. Maybe someone can point me on where to look for 
an explanation?


I'm wondering especially because as an alternative to variation 2, 
one might also follow variation 1 and then revert all changes (except 
for the recorded mergeinfo B). Isn't the outcome then the same as 
variation 2?


Regards,
Stefan

Re: inconsistency between mergeinfo records

[Stefan Hett]

committing changes is unnecessarily slowed-down because all mergeinfo 
changes are transferred one-by-one
- I guess other SVN-operations are slowed-down as well, because the 
mergeinfos are not stored only in one single mergeinfo-property...


Do u have any suggestion for us to improve our workflow? Wouldn't it be 
reasonable to change the behavior of the --record-only merge, so that it 
does not store these "redundant" mergeinfos in the first place?


Regards,
Stefan
I haven’t looked at the full details, but actual merges only store 
mergeinfo of what is actually merged (includes unaffected tree 
filtering, filtering what is already merged, etc.). A record only 
merge is a tool to just register as merged the affected target without 
further processing. It is primarily used to block further merges, or 
unblock something that wasn’t really merged.


So totally different mergeinfo is fully expected.

Does this answer your question, or did either of your operations 
record wrong mergeinfo?


Bert

Sent from Windows Mail

*From:* Stefan Hett <mailto:ste...@egosoft.com>
*Sent:* ‎Monday‎, ‎February‎ ‎23‎, ‎2015 ‎8‎:‎30‎ ‎AM
*To:* 'subversion' <mailto:users@subversion.apache.org>

Another user (Sergey Azarkevich) actually pointed me to an interesting 
fact:

C:\test\test2checkout>svn merge file:///C:/test/test2/A B --record-only
--- Recording mergeinfo for merge of r2 through r5 into 'B':
...

C:\test\test2checkout>svn merge file:///C:/test/test2/A B
--- Merging r3 through r5 into 'B':
...

Using explicit range of revisions same as for --record-only lead to equal
modifications in wc:
C:\test\test2checkout>svn merge file:///C:/test/test2/A B -r 2:5
--- Merging r3 through r5 into 'B':

Note the different ranges (r2-r5 vs. r3-r5 in the first two calls).
Maybe this sheds some light here?

Regards,
Stefan
> Looks like the batch-file got truncated by some clients/mail servers
> on the way --- here's the plain batch file content.
> Anyone having an idea what's going on here?
>
> REM create test repository
> mkdir C:\test
> cd /d C:\test
> mkdir test2
> svnadmin create test2
>
> REM check-out test repository
> mkdir test2checkout
> svn co file:///C:/test/test2 ./test2checkout
> cd test2checkout
>
> REM add initial structure
> mkdir A
> echo > A\test.txt
> svn add A
> svn commit -m test
>
> REM copy A to B
> svn cp A B
> svn commit -m test
>
> REM modify A/test.txt
> echo >> A\test.txt
> svn commit -m test
>
> REM cherry pick test.txt change and commit to B
> svn up
> svn merge -r 2:3 A/test.txt B/test.txt
> svn commit -m test
>
> REM modify A/test.txt again
> echo >> A\test.txt
> svn commit -m test
>
> REM do an auto merge of B
> svn up
> svn merge file:///C:/test/test2/A B
> REM This produces merge infos in B only
>
> REM alternative
> svn revert B -R
> svn merge file:///C:/test/test2/A B --record-only
> REM This produces merge infos in B AND B/test.txt
>



> Regards,
> Stefan
>> Hi,
>>
>> I'm wondering why there is a difference in how mergeinfos are
>> recorded based on whether the merge is done using --record-only or not.
>> To demonstrate the case, I've put together a repro-script (for
>> Windows - see attachment).
>>
>> My question is that why does the last step in the script produce
>> different merge-info properties:
>>
>> 1. svn merge file:///C:/test/test2/A B
>> This will produce mergeinfo in B
>>
>> 2. svn merge file:///C:/test/test2/A B --record-only
>> This will produce mergeinfo in B and B/test.txt
>>
>> Looking through the web, the docu and the SVN buglist I couldn't find
>> any matching entry. Maybe someone can point me on where to look for
>> an explanation?
>>
>> I'm wondering especially because as an alternative to variation 2,
>> one might also follow variation 1 and then revert all changes (except
>> for the recorded mergeinfo B). Isn't the outcome then the same as
>> variation 2?
>>
>> Regards,
>> Stefan
>

Re: PVCS to SUBVERSION

[Stefan Hett]

http://lmgtfy.com/?q=pvcs+to+svn+migration


Hi,

We want to migrate Pvcs to Subversion.

Could you please provide the steps, how to migrate the pvcs to svn.

It would be great full for us.

Regards

Suresh.



::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as 
information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any 
liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of 
the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior 
written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error 
please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for 
viruses and other defects.

Re: error

[Stefan Hett]

Hi,

you are on the subversion mailing list here, but the error you are 
getting suggests you are running TortoiseSVN. Maybe better report the 
issue there first.
Furthermore, the latest TortoiseSVN version atm is 1.8.11. You might 
wanna try updating first to see whether the issue was resolved meanwhile.


It might also help to state what you did before you got the assertion.

Regards,
Stefan

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_ra_serf\util.c'
 line 2543: assertion failed (*rel_path != NULL)
---
OK
---

consolidating mergeinfos

[Stefan Hett]

Hi,

I've been checking on if it's somehow reasonable for us to consolidate 
mergeinfos which have been built-up over the past 3-4 years in our 
repository. After checking on several papers/scripts/posts on the net, 
I've found this script which seemed to be a promising candidate at first:

https://github.com/ymartin59/svn-clean-mergeinfo

After reviewing the code I however see that (despite the really slow 
performance of the script --- in our case running the script on the 
entire repository would take approximately 2-3 years), I think the 
script is not handling a few special cases correctly. Especially 
non-inheritable mergeinfos seem to be not taken into account correctly, 
but completely ignored.


Can someone confirm that? Does anybody know of a better way to 
consolidate mergeinfos? Wouldn't it be useful to add support to SVN 
directly to consolidate mergeinfos?


Regards,
Stefan

Re: Getting Subversion Exception while SVN Upgrade working copy

[Stefan Hett]

Hi,

maybe better to start this of on the TortoiseSVN mailing list (since 
that's the client you seem to be using).


Regards,
Stefan


---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

with as much information as possible about what

you were trying to do.

But please first search the mailing list archives for the error message

to avoid reporting the same problem repeatedly.

You can find the mailing list archives at

http://subversion.apache.org/mailing-lists.html

Subversion reported the following

(you can copy the content of this dialog

to the clipboard using Ctrl-C):

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.8.10\ext\subversion\subversion\libsvn_wc\upgrade.c'

line 2231: assertion failed (result_format == SVN_WC__VERSION)

---

OK

---

Regards,

Sivasankar

Re: SVN 1.8.5 - Problems setting LC_CTYPE

[Stefan Hett]

Hi,

1.8.5 is really old. Maybe you wanna give the latest one a try (1.8.13) 
to see whether the issue is resolved with that already (I don't suggest 
it does, but maybe worth a try)?


Regards,
Stefan

Hi folks,

Recently started coming across problems when running svn commands on 
Linux RHEL 6+, for example svn --version returns the following


svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct
svn, version 1.8.5 (r1542147)

Only way so far to stop the warnings it is setting LC_CTYPE=C, but 
this is not a solution for us as there are files names with foreign 
characters so we need the UTF-8 encoding.


Oddly, there are no warnings on RHEL 5, but this maybe because the 
binary was built on this platform which I am looking into now. 
Otherwise, would something like a hook script to set the environment 
variables be a viable workaround for this, I haven't worked with them 
before so I'm just trying to avoid running into a dead end.


Many thanks,

Eoin

building SVN trunk on Windows fails on python gen-make.py

[Stefan Hett]

Hi,

I just tried to build 
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer 
on Windows following the INSTALL file documentation up to the point 
where the make file is being generated.


Using this call: python gen-make.py -t vcproj --with-zlib=..\zlib 
--with-apr=..\apr --with-apr-util=..\apr-util --vsnet-version=2010

I'm now getting the following error:

Traceback (most recent call last):
  File "gen-make.py", line 325, in  main(conf, gentype, 
skip_depends=skip, other_options=rest.list)
  File "gen-make.py", line 62, in main generator = 
gen_module.Generator(fname, verfname, other_options)
  File "build\generator\gen_vcnet_vcproj.py", line 36, in __init__ 
'vcnet-vcproj')
  File "build\generator\gen_win.py", line 83, in __init__ 
self.find_libraries(True)
  File "build\generator\gen_win_dependencies.py", line 286, in 
find_libraries self._find_apr()
  File "build\generator\gen_win_dependencies.py", line 395, in 
_find_apr bin_files = os.listdir(dll_dir)
FileNotFoundError: [WinError 3] The system cannot find the path 
specified: '..\\apr\\bin'


Looking at the apr-directory I downloaded/extracted, there's no 
apr/bin-directory.
I downloaded the following APR-source package (1.5.1): 
http://mirror.serversupportforum.de/apache//apr/apr-1.5.1-win32-src.zip


Did I get the wrong one? Or did I miss some step?

Regards,
Stefan

Re: building SVN trunk on Windows fails on python gen-make.py

[Stefan Hett]

The branch is based on the latest trunk. The only difference in 
gen_win.py is in line 70, where on trunk there's the call to 
generator.write_config_keys() which is missing on the branch-version.
I didn't try adding this call tough, since I found it kinda unlikely 
that this is the cause of the problem (I rather suspect some set-up 
issue on my side, which I can't just see atm).

Hi,

I just tried to build 
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer 
on Windows following the INSTALL file documentation up to the point 
where the make file is being generated.


Using this call: python gen-make.py -t vcproj --with-zlib=..\zlib 
--with-apr=..\apr --with-apr-util=..\apr-util --vsnet-version=2010

I'm now getting the following error:

Traceback (most recent call last):
  File "gen-make.py", line 325, in  main(conf, gentype, 
skip_depends=skip, other_options=rest.list)
  File "gen-make.py", line 62, in main generator = 
gen_module.Generator(fname, verfname, other_options)
  File "build\generator\gen_vcnet_vcproj.py", line 36, in __init__ 
'vcnet-vcproj')
  File "build\generator\gen_win.py", line 83, in __init__ 
self.find_libraries(True)
  File "build\generator\gen_win_dependencies.py", line 286, in 
find_libraries self._find_apr()
  File "build\generator\gen_win_dependencies.py", line 395, in 
_find_apr bin_files = os.listdir(dll_dir)
FileNotFoundError: [WinError 3] The system cannot find the path 
specified: '..\\apr\\bin'


Looking at the apr-directory I downloaded/extracted, there's no 
apr/bin-directory.
I downloaded the following APR-source package (1.5.1): 
http://mirror.serversupportforum.de/apache//apr/apr-1.5.1-win32-src.zip


Did I get the wrong one? Or did I miss some step?

Regards,
Stefan

Re: Subversion exception : diff_editor.c internal malfunction

[Stefan Hett]

Maybe not applicable, but if you don't get a more specific reply from 
s/o else I'd first try to update your TortoiseSVN version. 1.8.7 is 
quite old. 1.8.11 is the latest build available (in between 1.8.7 and 
1.8.11 there are quire a few fixes so maybe one applies to ur issue as 
well).


To whom it mat concern;

I am sending this EMAIL to report a Subversion exception as 
requested.  I was using Tortoise SVN, 1.8.7 Build 25475 – 64 bit 
2014/05/05 to perfom a “show log” functionality.  While viewing the 
log  I right clicked on the current revision of code (which was 3 
revisions newer than mine) and requested “Show changes as unified 
diff”.  The execution of this operation was taking a very long time 
(10 minutes?) and I still saw no result, so I decided to select 
“cancel” from the progress window.  The following error resulted:


---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

with as much information as possible about what

you were trying to do.

But please first search the mailing list archives for the error message

to avoid reporting the same problem repeatedly.

You can find the mailing list archives at

http://subversion.apache.org/mailing-lists.html

Subversion reported the following

(you can copy the content of this dialog

to the clipboard using Ctrl-C):

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\diff_editor.c'

line 1623: internal malfunction

---

OK

Re: SVN error 403 accedd denied while deleting files

[Stefan Hett]

Hi,

if u were to send a screenshot in some image format instead of attaching 
a docx format, people might be more likely to read it. Me for instance 
won't open a docx-file from any untrusted source on the web.


From the problem description I'd start looking into checking out the 
permissions related to deleting files in the appropriate directory with 
the appropriate user/group.


Regards,
Stefan

Hi,
Users have access to the repo and are able to check out and commit 
changes to the repo.
But when trying to remove an existing file from the repo we are 
getting a permission denied error as shown in the screenshot

Could you please help?
Shaiju

Re: building SVN trunk on Windows fails on python gen-make.py

[Stefan Hett]

Sorry for the late response. Had to shift priorities the last month 
here, before I could get back to this issue.


Thanks for the additional information on ways to build SVN. I quickly 
skimmed through the scripts/steps and might use them later when I can't 
get the current steps to run...


After build APR myself, it got passed the previous error. However I'm 
now stuck with another one and can't make-up what's wrong now... Any 
hint (couldn't find any reference on google or in the mail archive):

swig not found; skipping SWIG file generation...
Traceback (most recent call last):
  File "gen-make.py", line 325, in main(conf, gentype, 
skip_depends=skip, other_options=rest.list)

  File "gen-make.py", line 65, in main generator.compute_hdr_deps()
  File "build\generator\gen_base.py", line 212, in compute_hdr_deps
for include_file in include_deps.query(native_path(source.filename)):
  File "build\generator\gen_base.py", line 1167, in query c_includes, 
swig_includes = self.query_swig(fname)
  File "build\generator\gen_base.py", line 1150, in query_swig hdrs = 
self._scan_for_includes(fname)
  File "build\generator\gen_base.py", line 1203, in 
_scan_for_includesfor line in fileinput.input(fname):
  File "E:\Python34\lib\fileinput.py", line 263, in __next__ line = 
self.readline()
  File "E:\Python34\lib\fileinput.py", line 363, in readline 
self._buffer = self._file.readlines(self._bufsize)
  File "E:\Python34\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 
2116: character maps to 


Regards,
Stefan


On Wed, Apr 22, 2015 at 6:13 PM, Bert Huijben  wrote:



-Original Message-
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: woensdag 22 april 2015 15:59
To: 'subversion'
Subject: building SVN trunk on Windows fails on python gen-make.py

Hi,

I just tried to build
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-
normalizer
on Windows following the INSTALL file documentation up to the point
where the make file is being generated.

Using this call: python gen-make.py -t vcproj --with-zlib=..\zlib
--with-apr=..\apr --with-apr-util=..\apr-util --vsnet-version=2010
I'm now getting the following error:

Traceback (most recent call last):
File "gen-make.py", line 325, in  main(conf, gentype,
skip_depends=skip, other_options=rest.list)
File "gen-make.py", line 62, in main generator =
gen_module.Generator(fname, verfname, other_options)
File "build\generator\gen_vcnet_vcproj.py", line 36, in __init__
'vcnet-vcproj')
File "build\generator\gen_win.py", line 83, in __init__
self.find_libraries(True)
File "build\generator\gen_win_dependencies.py", line 286, in
find_libraries self._find_apr()
File "build\generator\gen_win_dependencies.py", line 395, in
_find_apr bin_files = os.listdir(dll_dir)
FileNotFoundError: [WinError 3] The system cannot find the path
specified: '..\\apr\\bin'

Looking at the apr-directory I downloaded/extracted, there's no
apr/bin-directory.
I downloaded the following APR-source package (1.5.1):
http://mirror.serversupportforum.de/apache//apr/apr-1.5.1-win32-src.zip

Did I get the wrong one? Or did I miss some step?

Subversion expects that you already build apr before using it as a source of 
binaries to link against. It is not going to build apr for you.

Building APR would have created this bin directory. (A patch to produce a nicer 
error message would be welcome :))


There are other scripts that may help you building Subversion and all 
dependencies. I maintain one such script as part of SharpSvn (Repository: 
https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports ; username guest; 
no password). This script uses NAnt, and is used to produce the publicly 
available binaries for SharpSvn and SlikSvn.

Somewhere in the Subversion repository there is a perl script that should also 
be able to help with building on Windows, but I don't have experience with that 
script.


Indeed, that script is tools/dev/build-svn-deps-win.pl. But it's a bit
outdated now. I recently used bits and pieces of it to get myself a
new working build environment for svn on Windows. In general our tools
and documentation for building svn on Windows are quite outdated and
could really use some love. For instance, INSTALL still contains a lot
of old irrelevant information, it should primarily focus on current
tools that people install these days (e.g. focusing on VS 2012, 2013
and 2015).

With my last build-setup attempt, I kept a short log of what I did
(based on things from build-svn-deps-win.pl, and further trial and
error). Perhaps this is useful:

[[[
download awk95.exe a

Re: building SVN trunk on Windows fails on python gen-make.py

[Stefan Hett]

Hi Johan,

thanks for the hint. That indeed seemed to have been the problem. Passes 
through the python script now when using Python 2.7.10.


Regards,
Stefan

On Mon, Jun 22, 2015 at 12:45 PM, Stefan Hett  wrote:

Sorry for the late response. Had to shift priorities the last month here,
before I could get back to this issue.

Thanks for the additional information on ways to build SVN. I quickly
skimmed through the scripts/steps and might use them later when I can't get
the current steps to run...

After build APR myself, it got passed the previous error. However I'm now
stuck with another one and can't make-up what's wrong now... Any hint
(couldn't find any reference on google or in the mail archive):
swig not found; skipping SWIG file generation...
Traceback (most recent call last):
   File "gen-make.py", line 325, in main(conf, gentype,
skip_depends=skip, other_options=rest.list)
   File "gen-make.py", line 65, in main generator.compute_hdr_deps()
   File "build\generator\gen_base.py", line 212, in compute_hdr_depsfor
include_file in include_deps.query(native_path(source.filename)):
   File "build\generator\gen_base.py", line 1167, in query c_includes,
swig_includes = self.query_swig(fname)
   File "build\generator\gen_base.py", line 1150, in query_swig hdrs =
self._scan_for_includes(fname)
   File "build\generator\gen_base.py", line 1203, in _scan_for_includes
for line in fileinput.input(fname):
   File "E:\Python34\lib\fileinput.py", line 263, in __next__ line =
self.readline()
   File "E:\Python34\lib\fileinput.py", line 363, in readline self._buffer =
self._file.readlines(self._bufsize)
   File "E:\Python34\lib\encodings\cp1252.py", line 23, in decodereturn
codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 2116:
character maps to 

Quick shot: perhaps it's related to the Python version. I'm using
Python 2.7. Can you try that?

is this mergeinfo redundant?

[Stefan Hett]

Hi,

I'm currently consolidating the mergeinfo records on our main 
development branch and am looking at some weird record here...


Reduced the case to the following example -

Repository root/
Project1
trunk
src
SDKs
libxml2
branches
Project1variant1
src
SDKs
libxml2

the Project1variant1 branch was created from Project1/trunk at revision 
184222.
Now I'm looking at the mergeinfo records on 
Project1/branches/Project1variant1/src/SDKs/libxml2 and see revisions 
which are < 184222:

/Project1/trunk/src/SDKs/libxml2:171866-172245,172247-172328,172330-172459,172461-172530,172532-172595,172597-172674,172676-172942,[...]

Am I right in assuming that these mergeinfo ranges could be removed, 
because there's really no point in how they could be valid entries, no?
I mean the branch didn't exist in either of these revisions yet and 
before the construction of the branch they would simply note that the 
revisions were merged into themselves... Doesn't make much sense to me 
at all.


Regards,
Stefan

Re: svn:mergeinfo is acting strange

[Stefan Hett]

Hi Chris,

Hi,

we've been using SVN for a large in-house project for a number of years and the longer 
time goes by, the more strange the svn:mergeinfo properties behave. I don't know if the 
"issues" are completely expected, if our repository somehow has ended up in a 
state that is unwanted or if there's something bug somewhere.

What happens:
Whenever someone merges a branch onto the trunk, there are approximately 100 
files/directories that get added mergeinfo despite these files (or files under 
them) not being affected by the commit. That the root directory of the trunk 
should be modified makes perfect sense to me, but if my merge only affects 
src/foo/bar.txt, why does it then have to set mergeinfo on e.g. 
test/some/untelated/thing.txt?
It seems to be the same set or files/dirs that always get tagged with 
additional information, so I suspect that some previous merge has made these 
specific files add all future mergeinfos into them, while other files that 
didn't get this strangeness stay unaffected. E.g. I have two source files in 
the same directory: File1 has 367 lines of mergeinfo (367 different branch 
merges, that is), file File2 has 0. And both these files are equally old, so it 
makes no sense that they should differ that way.

Is this expected or has our repository become overzealous?
If the latter: can I "fix" this situation by manually deleting the mergeinfo from files 
"further down in the tree"? And if I do that, how badly will upcoming branch merges be 
affected?

This isn't a major issue, but there have been cases where we've had conflicts inside the mergeinfo 
in these "special files" which has been sort of difficult to resolve for some committers. 
It is also quite annoying that every time we do "svn update" after a merge, we get 100+ 
lines of updates even if just one file has been modified (especially annoying in tools like 
subclipse).

TIA,
   Chris


We are facing exactly the same issue. I just got through dealing with 
this on our case using a tool written by the SVN developer Stefan 
Fuhrmann to get rid of redundant/unnecessary mergeinfo entries. It can 
be downloaded from the svn-mergeinfo-normalizer branch in the SVN 
repository. The tool is located under 
tools/client-side/svn-mergeinfo-normalizer. The branch readme provides 
some basic information about what the tool does and how it can be utilized.


In principle it provides the following functionality (all done on a WC):
- analyzing the mergeinfo and reporting whether certain nodes can be 
combined (and if not, what presents it from being combined)
- normalize the mergeinfo (basically removing redundant mergeinfo 
entries on nodes)
- combine-ranges to combine the recorded revisions to a shorter but 
semantically equal representation
- clear-obsoletes to drop mergeinfos for branches which no-longer exist 
on HEAD


Since you asked: I guess in most cases the reason for recording 
additional mergeinfos is because (for some other reason) you ended up 
with adding mergeinfos on a subnode (for instance 
test/some/unrelated/thing.txt.
As per definition of mergeinfos once a node (like thing.txt in ur case) 
contains mergeinfo, it needs to contain all the relevant mergeinfo in 
its own node. This is due to performance reasons as far as I understand 
it, so that if u want to determine which revisions got merged into a 
node, SVN only has to check out this one mergeinfo entry, rather than 
going up the tree to determine which things got merged into this one.


The good question here is why does it even keep record for revisions the 
node is not impacted by. I asked the same question in February already 
on this list (see: inconsistency between mergeinfo records). As far as I 
understand this is done atm to keep the application design simple. There 
are cases where the additional mergeinfo is required on nodes (for 
instance when adding a new file in a directory, the record needs to be 
kept on the directory node so the mergeinfo is correct). Effectively 
things could be improved (and as far as I've read here, it's on the 
radar for a later version), but the current behavior is as it stands 
right now.


If u're running under Windows and want to give the 
svn-mergeinfo-normalizer tool a try, I could send u the executable I've 
compiled and am using myself here.


Regards,
Stefan

Re: Subversion encountered a serious problem.

[Stefan Hett]

Hi Mark,

can't help you too much atm other than suggesting u update ur 
TortoiseSVN-version to the latest (which is 1.8.11). 1.8.7 is already 
several monthes old and based on SVN 1.8.9 (while the latest being 1.8.13).
Looking at the changelog in SVN 1.8.13 brings up a few candidates which 
might relate to the issue u're seeing (but yet again I didn't check in 
detail to be sure). Hence suggesting u simply try out the latest 
tortoise version.


Regads,
Stefan

I was trying to resolve conflict, didn’t find a solution in mailing 
archives, and got an error. This behavior was reproduced several times 
and conflict was not resolved.


---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

with as much information as possible about what

you were trying to do.

But please first search the mailing list archives for the error message

to avoid reporting the same problem repeatedly.

You can find the mailing list archives at

http://subversion.apache.org/mailing-lists.html

Subversion reported the following

(you can copy the content of this dialog

to the clipboard using Ctrl-C):

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.8.7\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c'

line 2462: assertion failed (move_src_op_root_relpath != NULL &&

move_dst_op_root_relpath != NULL)

---

OK

Thanks,

*Mark Sudakov*

*Database and Net Developer*

Atlas General Insurance Services, LLC

atlas_logo_cmyk.jpg

Direct: 858-529-6725

www.atlas.us.com 

[PATCH] APR install/configuration issue error handling (was: building SVN trunk on Windows fails on python gen-make.py)

[Stefan Hett]

-Original Message-
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: woensdag 22 april 2015 15:59
To: 'subversion'
Subject: building SVN trunk on Windows fails on python gen-make.py

Hi,

I just tried to build
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-
normalizer
on Windows following the INSTALL file documentation up to the point
where the make file is being generated.

Using this call: python gen-make.py -t vcproj --with-zlib=..\zlib
--with-apr=..\apr --with-apr-util=..\apr-util --vsnet-version=2010
I'm now getting the following error:

Traceback (most recent call last):
File "gen-make.py", line 325, in  main(conf, gentype,
skip_depends=skip, other_options=rest.list)
File "gen-make.py", line 62, in main generator =
gen_module.Generator(fname, verfname, other_options)
File "build\generator\gen_vcnet_vcproj.py", line 36, in __init__
'vcnet-vcproj')
File "build\generator\gen_win.py", line 83, in __init__
self.find_libraries(True)
File "build\generator\gen_win_dependencies.py", line 286, in
find_libraries self._find_apr()
File "build\generator\gen_win_dependencies.py", line 395, in
_find_apr bin_files = os.listdir(dll_dir)
FileNotFoundError: [WinError 3] The system cannot find the path
specified: '..\\apr\\bin'

Looking at the apr-directory I downloaded/extracted, there's no
apr/bin-directory.
I downloaded the following APR-source package (1.5.1):
http://mirror.serversupportforum.de/apache//apr/apr-1.5.1-win32-src.zip

Did I get the wrong one? Or did I miss some step?

Subversion expects that you already build apr before using it as a source of 
binaries to link against. It is not going to build apr for you.

Building APR would have created this bin directory. (A patch to produce a nicer 
error message would be welcome :))


There are other scripts that may help you building Subversion and all 
dependencies. I maintain one such script as part of SharpSvn (Repository: 
https://ctf.open.collab.net/svn/repos/sharpsvn/trunk/imports ; username guest; 
no password). This script uses NAnt, and is used to produce the publicly 
available binaries for SharpSvn and SlikSvn.

Somewhere in the Subversion repository there is a perl script that should also 
be able to help with building on Windows, but I don't have experience with that 
script.

Bert
As the saying goes "better later than never", as per ur suggestion, 
here's a patch which adds some better handling to detect user-errors 
when putting just the downloaded source of apr (and/or apr-util) into 
the specified folder. Suggested patch for trunk and nomination for 1.9 I 
guess.


[[[
   Produce human readable error when APR/APR-util wasn't 
installed/configured correctly.


* build/generator/gen_win_dependencies.py
  (_find_apr,
   _find_apr_util): Add detection for missing lib/dll directories, 
pointing to

an unconfigured/uninstalled source directory.
]]]

Regards,
Stefan
Index: gen_win_dependencies.py
===
--- gen_win_dependencies.py (revision 1691913)
+++ gen_win_dependencies.py (working copy)
@@ -401,6 +401,12 @@
 dll_dir = os.path.join(self.apr_path, 'bin')
 debug_dll_dir = None
 
+if not lib_dir or not os.path.isdir(lib_dir) or \
+   dll_dir and not os.path.isdir(dll_dir):
+  sys.stderr.write("ERROR: 'apr biniares' not found.\n")
+  sys.stderr.write("Use '--with-apr' option to configure APR location and 
make sure to have APR properly configured/installed.\n")
+  sys.exit(1)
+
 extra_bin = []
 
 if dll_dir:
@@ -502,6 +508,12 @@
 dll_dir = os.path.join(self.apr_util_path, 'bin')
 debug_dll_dir = None
 
+if not lib_dir or not os.path.isdir(lib_dir) or \
+   dll_dir and not os.path.isdir(dll_dir):
+  sys.stderr.write("ERROR: ' apr-util biniares' not found.\n")
+  sys.stderr.write("Use '--with-apr-util' option to configure APR-Util 
location and make sure to have APR-Util properly configured/installed.\n")
+  sys.exit(1)
+
 extra_bin = []
 
 if dll_dir:

Re: Crashes whilst importing from a repository dump

[Stefan Hett]

Looks like the dumps are from a VisualSVN Server compiled version. Did 
you try contacting their support? Without the PDBs from their compiled 
version it's a bit difficult for other users like me to check the crash 
out...


Kind Regards,

Simon Rowe

Senior Manager Engineering
Siemens plc

Healthcare Sector

Molecular Imaging/MR Magnet Technology
Beaver House
23/38 Hythe Bridge Street
OXFORD OX1 2EP
United Kingdom
Direct Line +44 (0)1865 265566 
Fax +44 (0)1865 265501 
Mobile +44 (0) 7921243214 


E-Mail simon.r...@siemens.com 

Siemens plc. Registered office: Faraday House, Sir William Siemens 
Square, Frimley,Camberley, GU16 8QD. Registered no: 727817, England.


This communication contains information which is confidential and may 
also be privileged. It is for the exclusive use of the addressee. If 
you are not the addressee please note that any distribution, 
reproduction, copying, publication or use of this communication or the 
information is prohibited. If you have received this communication in 
error, please contact us immediately and also delete the communication 
from your computer.

Re: is this mergeinfo redundant?

[Stefan Hett]

Hi,

Hi,

I'm currently consolidating the mergeinfo records on our main 
development branch and am looking at some weird record here...


Reduced the case to the following example -

Repository root/
Project1
trunk
src
SDKs
libxml2
branches
Project1variant1
src
SDKs
libxml2

the Project1variant1 branch was created from Project1/trunk at 
revision 184222.
Now I'm looking at the mergeinfo records on 
Project1/branches/Project1variant1/src/SDKs/libxml2 and see revisions 
which are < 184222:
/Project1/trunk/src/SDKs/libxml2:171866-172245,172247-172328,172330-172459,172461-172530,172532-172595,172597-172674,172676-172942,[...] 



Am I right in assuming that these mergeinfo ranges could be removed, 
because there's really no point in how they could be valid entries, no?
I mean the branch didn't exist in either of these revisions yet and 
before the construction of the branch they would simply note that the 
revisions were merged into themselves... Doesn't make much sense to me 
at all.
For the record: Got the answer from stefan2 on this and yes, the 
mergeinfo is actually redundant.


--
Regards,
Stefan Hett

preventing recording misaligned mergeinfos

[Stefan Hett]

Hi,

I'm currently checking-out ways to prevent the creation of misaligned 
mergeinfos in SVN. My current solution would be to add a pre-commit hook 
to prevent any mergeinfo records on any but the top-most node (aka: 
trunk or a branch). While this would prevent most cases which let to 
misaligned mergeinfos, it's certainly not exactly what I want/need.


Does anybody have an idea for a better/more precise solution/approach?

--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473

Re: preventing recording misaligned mergeinfos

[Stefan Hett]

It does and that's not quite the problem for me. However what's possible 
to do with SVN are merges like these:


merge A/B/somefile into A

absolutely valid operation, but nothing we use here. In cases this is 
done here in our company it's always an incorrect merge (because someone 
chose the wrong destination folder.
So we want to prevent issues like these, because they can easily result 
in polluting the mergeinfo records.



I was under the impression that subversion now automatically takes subtree 
mergeinfo into account:  
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.stayinsync.subtree


-Original Message-----
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: Friday, August 28, 2015 9:19 AM
To: 'subversion'
Subject: preventing recording misaligned mergeinfos

Hi,

I'm currently checking-out ways to prevent the creation of misaligned 
mergeinfos in SVN. My current solution would be to add a pre-commit hook to 
prevent any mergeinfo records on any but the top-most node (aka:
trunk or a branch). While this would prevent most cases which let to misaligned 
mergeinfos, it's certainly not exactly what I want/need.

Does anybody have an idea for a better/more precise solution/approach?

--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473





--
Regards,
Stefan Hett

Re: win32svn for 1.9.1?

[Stefan Hett]

On 9/7/2015 10:21 PM, Win32Svn wrote:

On 2015-09-07 18:59, Barry Scott wrote:
On 7 Sep 2015, at 11:43, Andreas Stieger  
wrote:


Hi,

Barry Scott wrote:
I see that the recent 1.7 and 1.8 win32svn builds being announced, 
thanks for

them.

Do you know when the svn 1.9 win32svn build might be available?

Available at other binary "vendors":
https://subversion.apache.org/packages.html#windows

Sadly only win32svn packages the include files that are needed to write
code against svn. In my case I use win32svn as the basis of the pysvn
win32 build.

Barry



Hi Barry!

I'm sorry to say there won't be any 1.9.x build of Win32SVN.
You can read about it on http://alagazam.net   (click the 1.9.x info 
link on the right)


Regards,
David Darj  a.k.a. Alagazam
Maintainer of Win32SVN
http://alagazam.net

ps.
If you like my work, please support this project by donating at
http://sourceforge.net/donate/index.php?group_id=357628



Hi David,

I'm wondering which particular VS6 issue you are referring to in that note.
I've been told the only known issues atm not working using VS6 would be 
in the javahl code (due to the template code) which I assume is not the 
issue you are talking about, or is it?


--
Regards,
Stefan Hett

Re: 1.9 - Can't resolve to 'mine full' option for binary file conflict

[Stefan Hett]

On 9/14/2015 7:56 AM, Daniel Becroft wrote:

Hi guys,


I've just upgraded to SVN 1.9. One of the first things I noticed is 
that when a binary file conflict is raised during an SVN update, I can 
no longer use the 'mine-full' option to resolve.


The only options I have are: (r) working and (tf) theirs-full.

I can't use the 'r' (working) option, as I get a message of "Invalid 
option; use diff/edit/merge/launch before choosing 'mark resolved'.


If I postpone, and try resolving afterwards, I get the following errors;
> svn resolve file.binary --accept mine-full
svn: warning: W155027: Conflict on 'file.binary' could not be resolved 
because the chosen version of the file is not available.

svn: E155027: Failure occurred resolving one or more conflicts

I can't find anything in the release notes about the removal of the 
'mine-full' option on binary files. Was it intentional? If so, what's 
the intended workflow for resolution?


Current version:
svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0)
   compiled Aug 26 2015, 17:09:55 on x86/x86_64-microsoft-windows6.2.9200

Cheers,
Daniel B.

Hi Daniel,

just to second ur observation:
I think I ran into the same problem last Thursday/Friday using TSVN 
1.9.1. I didn't report it yet because I didn't check out whether it's a 
TSVN or an SVN issue.
Using TSVN, it however also gives me the "file not found" error when I 
try to resolve a binary conflict selecting "Use Repository version" 
during the merge dialog.


I'm sure u are already ware, but just in case: My workaround was to let 
the file in conflict and afterwards resolve the conflict by reverting 
the file (so it was in the repository's state which I intended).


--
Regards,
Stefan Hett

Re: svnsync: Authorization failed

[Stefan Hett]

Normally running a clean-up would solve these lock issues (svn cleanup).

Sorry, no idea with ur actual authorization issue. If things worked 
before, I'd assume it's something with outdated/invalid credentials or 
problems due to some server-side upgrades of the authorization 
methods/set-up.


I got the new error messages below:

[root@zch124svn01 tmp]# svnsync info 
svn://zch124svn01.ap.mot-mobility.com/miracle3


subversion/libsvn_subr/sqlite.c:192: (apr_err=200030)

svnsync: database is locked

subversion/libsvn_subr/sqlite.c:362: (apr_err=200030)

svnsync: database is locked

Thanks,

Hubert Li

ARRIS

*From:*Li, Hubert
*Sent:* Monday, September 14, 2015 3:00 PM
*To:* 'Eric Johnson' 
*Cc:* users@subversion.apache.org
*Subject:* RE: svnsync: Authorization failed

Thanks, Eric. I tried to add –username and –password in svnsync, and 
got the same error messages. Yes, 1.6.6 is old, but we have to use it 
for some reasons.


Thanks,

Hubert Li

ARRIS

*From:*Eric Johnson [mailto:e...@tibco.com]
*Sent:* Monday, September 14, 2015 2:43 PM
*To:* Li, Hubert mailto:hubert...@arris.com>>
*Cc:* users@subversion.apache.org <mailto:users@subversion.apache.org>
*Subject:* Re: svnsync: Authorization failed

Two quick thoughts (I'm not a developer, just a user of Subversion):

1) 1.6.6 is old. If you can upgrade, you might get easier to 
understand error messages.


2) The sync operation is trying to sync /from/ some other place. Given 
that your credentials to access the zch124... repository may be fine, 
the likely culprit is the credentials to access the source of the sync 
request data. In any case, "svnsync help sync" will give you the 
command line options you can pass to set the creds.


Eric.

On Sun, Sep 13, 2015 at 8:02 PM, Li, Hubert <mailto:hubert...@arris.com>> wrote:


Hi,

I got the following error when I ran svnsync:

[root@zch124svn01 conf]# svnsync sync
svn://zch124svn01.ap.mot-mobility.com/miracle3
<http://zch124svn01.ap.mot-mobility.com/miracle3>

…

subversion/svnserve/serve.c:167: (apr_err=170001)

svnsync: Authorization failed

but I can co or export it with the same user, e.g.

[/dept/stb/...67/svn/test]$ svn export
svn://zch124svn01.ap.mot-mobility.com/miracle3
<http://zch124svn01.ap.mot-mobility.com/miracle3>

Amiracle3

…

Below is my system info:

[root@zch124svn01 conf]# cat /etc/issue

CentOS release 6.4 (Final)

Kernel \r on an \m

[root@zch124svn01 conf]# svnsync --version

svnsync, version 1.6.6 (r40053)

   compiled Oct 24 2013, 13:59:58

…

BTW, we can sync it before rebooting the system, but after reboot
it, we got this error. I start the service with this command:

svnserve -d -r /svn_files/svn/

Thanks,

Hubert Li

ARRIS




--
Regards,
Stefan Hett

Re: Subversion API

[Stefan Hett]

Hi Andreas,

Hello,

I want to write a client application that uses the Subversion API. I 
downloaded svn-win32-1.8.13_dev.
I tried to compile and link some code from the example 
minimal_client.c with Embarcadero RadStudio XE 6. The code compiles 
but fails to link because the file SVN.lib cannot be found.
I searched that file on my computer but cannot find it. Where can I 
get that file?


Mit freundlichen Grüßen

Andreas Friedrich

If you are refering here to the win32svn distribution, then pls note 
that this is built using VC6. I'm not sure whether this will be 
compatible with ur build environment or whether u have to rebuild SVN on 
ur environment urself.
If the later, please refer to the INSTALL doc in the subversion source 
as a starter on how to build the SVN libs.


I'm also not sure why ur build environment is looking for an SVN.lib 
file. You need to check that urself I guess. The Win32SVN distribution 
contains all its prebuilt libraries in the lib folder. libsvn libraries 
are split in different separate libraries there. You might have to link 
against all of these or a subset, depending on what u are actually 
compiling.


--
Regards,
Stefan Hett

Re: SVN crash on commit

[Stefan Hett]

On 9/29/2015 3:49 PM, Petr Janata wrote:

Hi,

I have experienced a crash during svn commit operation. It does not 
help to cleanup or update the working copy. Commit always fails with 
the same problem.


I use 1.8.0-SlikSvn-1.8.0-X64 command line client.
I have executed successful cleanup and update in the root of the 
working copy. Then I have tried to commit a subtree but it has failed.


The subtree modifications consist of moves, edits and deletes. All 
moves are within the subtree.
Some files were first moved and then deleted, could this cause the 
problem?


Please see attached the exact steps I have performed and log + dmp files.

Petr Janata


Hi Petr,

is there a particular reason you are stuck with 1.8.0? I see that 
there's already 1.8.14 out of SilkSVN. I strongly suggest you update and 
then rerun the test. IMO there's a very high probability that issue has 
been resolved already, given u are using a version which is over 2 years 
old.


--
Regards,
Stefan Hett

Re: Error:This application has halted due to an unexpected error.

[Stefan Hett]

Hi Mark,

the log suggests you are running SVN 1.8.8. Maybe there's a chance you 
could upgrade to SVN 1.8.14.


And btw: some text/description would be appropriate when you send a mail 
to a public mailing list (I hope you intended it to be sent here, and no 
confidential information was included in your log which you didn't want 
to share with the rest of the world).


This email and any attached files are confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this 
email by anyone else is unauthorised. If you are not the addressee, 
any disclosure, reproduction, copying, distribution, or other 
dissemination or use of this communication is strictly prohibited. If 
you have received this transmission in error please notify the sender 
immediately (you can send an email to emailad...@kbc.ie) and then 
delete the email. Alternatively in emergencies you can telephone our 
email processing centre at ++353 1 6646600. This centre will only 
process calls relating to email delivery/non delivery.
Email transmission cannot be guaranteed to be secure or error free as 
information could be intercepted, corrupted, lost, destroyed, arrive 
late or incomplete, or contain viruses. The sender therefore does not 
accept liability for any errors or omissions in the contents of this 
message, and shall have no liability for any loss or damage suffered 
by the user, which arise as a result of email transmission. If 
verification is required please request a hard copy version.
KBC Bank Ireland plc is regulated by the Central Bank of Ireland. KBC 
Bank Ireland plc is a company registered in the Republic of Ireland, 
Company Number 40537. Registered Office: Sandwith Street, Dublin 2, 
Ireland





--
Regards,
Stefan Hett

Re: Searching for compatible binary

[Stefan Hett]

On 12/4/2015 10:55 AM, Johan Wallström wrote:

Hello,

I'm searching for a binary release that can meet the following 
requirements:

* Windows 64bit
* Supports file system format 7 (svn 1.9)
* Includes module-files for Apache 2.4 (latest wamp)

I have found some binaries including svn 1.9, but supporting only 
AP2.2, while other would support svn 1.8 with AP2.4


best regards
Johan

Hi Johan,

for testing purposes I think MaxSVN would meet these needs:
http://www.luke1410.de/typo3/index.php?id=97

However, this would only be for testing, not for setting up some 
production environments.
I take it you checked out the list of Windows packages here already? 
https://subversion.apache.org/packages.html


--
Regards,
Stefan Hett

Re: Searching for compatible binary

[Stefan Hett]

On 12/4/2015 4:42 PM, Stefan Hett wrote:

On 12/4/2015 10:55 AM, Johan Wallström wrote:

Hello,

I'm searching for a binary release that can meet the following 
requirements:

* Windows 64bit
* Supports file system format 7 (svn 1.9)
* Includes module-files for Apache 2.4 (latest wamp)

I have found some binaries including svn 1.9, but supporting only 
AP2.2, while other would support svn 1.8 with AP2.4


best regards
Johan

Hi Johan,

for testing purposes I think MaxSVN would meet these needs:
http://www.luke1410.de/typo3/index.php?id=97
I just realized the Apache 2.4 modules are not packed alongside the 
archive. If that would be helpful for you I could repackage them so you 
can use that for testing.


--
Regards,
Stefan Hett

Re: Searching for compatible binary

[Stefan Hett]

On 12/4/2015 6:02 PM, Ivan Zhakov wrote:

On 4 December 2015 at 18:53, Stefan Hett  wrote:

On 12/4/2015 4:42 PM, Stefan Hett wrote:

On 12/4/2015 10:55 AM, Johan Wallström wrote:

Hello,

I'm searching for a binary release that can meet the following
requirements:
* Windows 64bit
* Supports file system format 7 (svn 1.9)
* Includes module-files for Apache 2.4 (latest wamp)

I have found some binaries including svn 1.9, but supporting only AP2.2,
while other would support svn 1.8 with AP2.4

best regards
Johan

Hi Johan,

for testing purposes I think MaxSVN would meet these needs:
http://www.luke1410.de/typo3/index.php?id=97

I just realized the Apache 2.4 modules are not packed alongside the archive.
If that would be helpful for you I could repackage them so you can use that
for testing.


I wouldn't recommend to use Apache HTTP Server and Subversion modules
obtained from different source: different version of compile settings
like Visual Studio runtime, used OpenSSL and APR version could produce
different kind of errors.
Absolutely right Ivan, and now that you mention that this is exactly why 
I left that out intentionally (just didn't remember that point when I 
sent the reply :) ).


--
Regards,
Stefan Hett

Re: Searching for compatible binary

[Stefan Hett]

On 12/4/2015 6:02 PM, Ivan Zhakov wrote:

On 4 December 2015 at 18:53, Stefan Hett  wrote:

On 12/4/2015 4:42 PM, Stefan Hett wrote:

On 12/4/2015 10:55 AM, Johan Wallström wrote:

Hello,

I'm searching for a binary release that can meet the following
requirements:
* Windows 64bit
* Supports file system format 7 (svn 1.9)
* Includes module-files for Apache 2.4 (latest wamp)

I have found some binaries including svn 1.9, but supporting only AP2.2,
while other would support svn 1.8 with AP2.4

best regards
Johan

Hi Johan,

for testing purposes I think MaxSVN would meet these needs:
http://www.luke1410.de/typo3/index.php?id=97

I just realized the Apache 2.4 modules are not packed alongside the archive.
If that would be helpful for you I could repackage them so you can use that
for testing.


I wouldn't recommend to use Apache HTTP Server and Subversion modules
obtained from different source: different version of compile settings
like Visual Studio runtime, used OpenSSL and APR version could produce
different kind of errors.
Absolutely right Ivan, and now that you mention that this is exactly why 
I left that out intentionally (just didn't remember that point when I 
sent the reply ).


--
Regards,
Stefan Hett

Re: TSVN Error message

[Stefan Hett]

Hi Paul,

I was doing a 'clean up' with Tortoise when this error message came up:

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
  
'D:\Development\SVN\Releases\TortoiseSVN-1.9.2\ext\subversion\subversion\libsvn_client\cleanup.c'
  line 227: assertion failed (svn_dirent_is_absolute(dir_abspath))
---
OK
---
Just a quick blindshot. TSVN 1.9.3 was released last night. So you might 
wanna give that one a try.


--
Regards,
Stefan Hett

Re: Commit not working with multiple .svn directories in single working copy

[Stefan Hett]

Dear SVN experts,

I need to have multiple .svn directories inside woking copy.
I need to have svn working copy for /home directory  for students
and at least each user needs to have own repository on same machine
It blocks me to commit changes form working copy at home by different 
repository id

Is it possible for svn to force not to look for inner .svn directories for 
data, or I need find out each
.svn rename it make commit and return inner .svn directories back,please? Use 
of externals is not suitable for me

I look forward hearing from you

Yours faithfully

Peter Fodrelk

Hi Peter,

I assume your requirement is rather about the intended folder/check-out 
structure on your local machine rather than the requirement to have 
multiple .svn-directories in your working copy.
If I'm not mistaken here, then you might wanna rethink your folder 
structure.

Wouldn't something like this work for you?

/Project
/- myOwnWorkingCopy
/- here's your own checkout
/- student1WorkingCopy
/- here's the checkout for the 1st student
/- student2WorkingCopy
/- another checkout for the 2nd student
/- 

In other words: you have separate checkouts and separate working copies 
for yourself and all your students.


--
Regards,
Stefan Hett

Re: what's the cause of error 120108 and checksum mismatch

[Stefan Hett]

On 12/31/2015 8:35 AM, 黄章梁 wrote:


Developers of subversion:

 Hello!

 I encountered two problems.

 Question 1: When update the work-copy failed atfter that 
update some files success , and tips:


   ‍svn: E120108: Unable to connect to a 
repository at URL 'https://…. '‍


   ‍svn: E120108: Error running context: The 
server unexpectedly closed the connection. ‍


   What’s the cause of this promble? Network error?

That would be one possibility. But honestly, your question sounds like 
you want us to guess what particular problem is rather than what kind of 
causes could cause such an error. That we certainly can't, since there 
is a multitude of possible explanations. Network error being just one of 
that.


  Question 2: When update the work-copy, tips:

   ‍Error: Checksum mismatch while updating 
'D:\xx\xx.h':‍


‍Error:expected: 
e14ae03a45fcfb4d754531bb5b38d1fe ‍


‍Error:  actual: 
d67898a0aae70499c71819a747b18a0a ‍


‍Error: Try a 'Cleanup'. If that doesn't 
work you need to do a fresh checkout.‍


   “Cleanup” is not effective,  how to solve the 
problem except as do a fresh checkout?


Did you try out the google resources already? For instance: 
http://stackoverflow.com/questions/10352934/svn-checksum-mismatch-while-updating


   And what is the cause or operation leads to this 
problem?


Same situation as the question 1. Sorry, but I left my crystal ball at 
home. One possible explanation for that would be disk corruption. 
Whether that was the cause in ur case or whether there was some other 
underlying issue, I can't tell of cause.


--
Regards,
Stefan Hett

Re: Compiling ZLIB for svn 1.9.3 on Windows 7 using MSVC 2008

[Stefan Hett]

On 12/31/2015 10:31 AM, Cooke, Mark wrote:

-Original Message-
From: Ivan Zhakov [mailto:i...@visualsvn.com]
Sent: 30 December 2015 18:59

On 30 December 2015 at 19:06, Cooke, Mark  wrote:

[Updates below]


-Original Message-
From: Cooke, Mark [mailto:mark.co...@siemens.com]
Sent: 30 December 2015 15:56

Folks,

I was having issues compiling httpd and svn for use with Trac (via the
python 2.7 bindings).  I have compiled httpd 2.4.18 (with apr 1.5.1,
apr-util 1.5.4, apr-iconv 1.2.1, openssl 1.0.2e, pcre 1.3.8 and
mod_wsgi 4.4.21) and am now trying to compile svn.

I noted the comments about zlibstat and ZLIB_WINAPI [1][2], so I edited:
- zconf.h (added #define ZLIB_WINAPI)
- bld_ml32.bat (added the /safeseh switch to both lines)
...and ran:
- vcbuild /rebuild contrib\vstudio\vc9\zlibvc.sln "Release|Win32"

This seems to compile OK so I copied the zlibstat.lib up to the zlib root.

[1] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL (section E4
ZLib)
[2] http://www.tannerhelland.com/5076/compile-zlib-winapi-wapi-stdcall/

Next I built SERF 1.3.8:

[...]

In the end I got it running by _removing_ all the ZLIB_WINAPI 
defines in the Visual Studio project files and _not_ defining 
ZLIB_WINAPI in the main config file: this is the opposite of the 
advice in [1]! Does this sound correct? If so I think the INSTALL 
file needs updating. 

I get one test failure but it looks bad:-

START: checksum-test.exe
PASS:  checksum-test 1: checksum parse
PASS:  checksum-test 2: checksum emptiness
PASS:  checksum-test 3: zero checksum matching
svn_tests: E26: Decompressed data doesn't match expected size or crc
with blocksize 17: Found crc32=0x3a74e3ee, size=241883.
Verify your ZLib installation, as this should never happen
FAIL:  checksum-test 4: zlib expansion test (zlib regression)

Zlib has known bug in assembly optimized code. Just disable assembly
optimized code in zlib and everything should be fine.

Thanks, Ivan, that makes sense.  For the record this is how I got ZLib working 
for me:

Unpack archive to \svn\zlib
Search/Remove all instances of ZLIB_WINAPI from *.vcproj
Are you sure this is required? My current build environment suggests 
it's just building/working fine and as intended by adding the 
ZLIB_WINAPI define. That's how it should also work.
I've to admit that I didn't test it using VS 2008 (but rather 2010 and 
2015), but I would not expect that having an impact on the reported 
linker error you got.
Might it be that you compiled another lib which pulled in zlib without 
defining ZLIB_WINAPI? Then that would explain the linker error you are 
reporting.


--
Regards,
Stefan Hett

Re: This application has halted due to an unexpected error.

[Stefan Hett]

Hi,

you might be better off contacting CollabNet on this. According to your 
attached log you are using their distributed client.


Also you might wanna try updating ur CollabNet client to 1.9.3 (assuming 
there is already an update available from them).


--
Regards,
Stefan Hett

Re: This application has halted due to an unexpected error.

[Stefan Hett]

You got a convincing point here Mark (not wanting to drive people away 
from the Forum), so pardon me rushing in too quickly here.


Let's see if the OP does provide some further details then --- for the 
record: The log states the following command was issued:
svn.exe  commit 
"D:\AutoBuild\CleanSVN\toolbar\kits-history\Toolbar-SetDefaultSearch\v24.0_kb240\20160107_build4_WT_24.0_C240\SMSetup999.exe" 
--message "Autobuild commit."


Regards,
Stefan


I generally do not want to drive people away from this forum.  I 
usually send people here if anything.  I would say the OP has not had 
a response because:


a) their post is only 4 hours old
b) it is the sort of post that rarely gets a response

No one wants an email with just crash dumps.  If the OP cannot be 
bothered to describe the problem from their perspective, what command 
they were doing etc..  Then it is not likely to go anywhere.


Mark



On Thu, Jan 7, 2016 at 8:46 AM, Stefan Hett <mailto:ste...@egosoft.com>> wrote:


The thought was that
a) I'm not familiar with the build process or any potential
customizations which might have been applied to the CollabNet builds
b) looking at a dmp-file without the corresponding PDBs is quite
time consuming

Of cause given that it's the CollabNet client I take it that it
doesn't quite apply that much here (even though I'm aware that
CollabNet has their own set up support channels (Forum and
professional support).

I just replied due to the lack of anybody else jumping in here, so
I thought the OP might have a better chance to get a helping hand
on the CollabNet Forum.



Why does it matter where the binaries come from?  It is not like
they are customized from one place to the next.

    Mark

On Thu, Jan 7, 2016 at 8:24 AM, Stefan Hett mailto:ste...@egosoft.com>> wrote:

Hi,

you might be better off contacting CollabNet on this.
According to your attached log you are using their
distributed client.

Also you might wanna try updating ur CollabNet client to
1.9.3 (assuming there is already an update available from them).

-- 
Regards,

Stefan Hett




-- 
Thanks


Mark Phippard
    http://markphip.blogspot.com/



-- 
Regards,

Stefan Hett




--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Bug Report: Subversion 1.7 segfaults when using gnome-keyring authentication (Linux x64)

[Stefan Hett]

Hi Vikram,

Hi,

I'm also stuck with this same issue,
"svn up" makes svn segfaults and coring.
This started happening when I give
my new password set in my svn server.

Can some one please help on this?
Any help is highly appreciated.

Thanks
Vikram
Unfortunately the 1.7 branch is no longer supported. Said that, 1.7.19 
contained a fix for a crash related to gnome keyrings. Since the OP 
stated he had the crash with 1.7.20 as well as with 1.7.19 that fixed 
issue cannot be the one he was reporting, but maybe it applies in your 
case (if you are running an older 1.7 version)?


Otherwise the OP stated that he didn't get crashes when using SVN 1.8 
and that's what I suggest you'd try as well, if possible.


--
Regards,
Stefan Hett

Re: Bug Report: Subversion 1.7 segfaults when using gnome-keyring authentication (Linux x64)

[Stefan Hett]

Hi Vikram,


Hi Stefan,

Thank you for the response and clarification.
Yes, I'm using 1.7.19 and I'm with that issue.

And, I have tried installing CollabNet Subverion client 1.8.15 and I 
get a different issue (svn: E175013:) as below. I don't think its a 
credentials issue because it still fails with the same error even with 
explicit credential specification.


Any idea, you can help on this.

Thanks
Vikram
this is a bit confusing. In your first reply you stated that you "are 
also stuck with this same issue[..]". Now you suggest running into a 
completely different problem which has nothing to do with the one the OP 
posted.


So assuming you have a different issue which is E175013 being returned 
by svn when doing an svn up, I take it that most likely there's some 
permission issue at hand (or you are trying to connect to the wrong URL?)?
Given that the issue started when you entered your new password, I'd 
tripple check whether the password really is correct and works with 
authenticating with the server. If that is, then I'd double check that 
the server (incl. repository) permissions are correct and didn't change 
for your account.


Looking quickly on google, it suggests a couple of trouble shooting 
steps in different links. Did you have a look at these?


--
Regards,
Stefan Hett

Re: Subversion crash report

[Stefan Hett]

Hi James,

without knowing which client you are using it's a bit difficult to dig 
into this problem.
From the logs I can only get your command line, working directory, 
version number (1.9.2) and see that you are using a 32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge 
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS 
--accept tc

Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3 version.


Hello,

Attached please find a crash report during an attempt to merge 
something to a trunk.


James C Patten

Senior Programmer/Analyst, OIT OCFS/DLRS

State of Maine, Office of Information Technology

james.pat...@maine.gov <mailto:james.pat...@maine.gov>

207-557-0349 (Desk/Cell)




--
Regards,
Stefan Hett

Re: Subversion crash report

[Stefan Hett]

Hi James,


Stefan,

Windows client, using a Powershell script running the svn command 
line.  I am running 64-bit Windows 7, running it in Powershell 4.  I 
use the 32-bit build because only developers have 64-bit windows.


James

*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* Monday, January 25, 2016 5:25 AM
*To:* Patten, James; users@subversion.apache.org
*Subject:* Re: Subversion crash report

Hi James,

without knowing which client you are using it's a bit difficult to dig 
into this problem.
>From the logs I can only get your command line, working directory, 
version number (1.9.2) and see that you are using a 32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge 
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS --accept 
tc

Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3 
version.


Hello,

Attached please find a crash report during an attempt to merge
something to a trunk.

James C Patten

Senior Programmer/Analyst, OIT OCFS/DLRS

State of Maine, Office of Information Technology

james.pat...@maine.gov <mailto:james.pat...@maine.gov>

207-557-0349 (Desk/Cell)

please always reply to the list as well, since while I might provide the 
first ideas/info, others might be better with helping with the actual 
problem at hand.


By "which client" I rather meant which distribution you are using. 
Apache Subversion does not provide any binaries itself, so you must be 
using either some distribution or use your own compiled binaries.


I'm asking because if the symbols would be available for the dump you 
provided, it could be easier to debug the problem.


--
Regards,
Stefan Hett

Re: Subversion crash report

[Stefan Hett]

Sorry.  I’m using the distribution from Collabnet.

*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* Monday, January 25, 2016 7:30 AM
*To:* Patten, James
*Cc:* 'subversion'
*Subject:* Re: Subversion crash report

Hi James,

Stefan,

Windows client, using a Powershell script running the svn command
line.  I am running 64-bit Windows 7, running it in Powershell 4. 
I use the 32-bit build because only developers have 64-bit windows.


James

    *From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* Monday, January 25, 2016 5:25 AM
*To:* Patten, James; users@subversion.apache.org
<mailto:users@subversion.apache.org>
*Subject:* Re: Subversion crash report

Hi James,

without knowing which client you are using it's a bit difficult to
dig into this problem.
>From the logs I can only get your command line, working
directory, version number (1.9.2) and see that you are using a
32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS
--accept tc
Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3
version.

Hello,

Attached please find a crash report during an attempt to merge
something to a trunk.

James C Patten

Senior Programmer/Analyst, OIT OCFS/DLRS

State of Maine, Office of Information Technology

james.pat...@maine.gov <mailto:james.pat...@maine.gov>

207-557-0349 (Desk/Cell)

please always reply to the list as well, since while I might provide 
the first ideas/info, others might be better with helping with the 
actual problem at hand.


By "which client" I rather meant which distribution you are using. 
Apache Subversion does not provide any binaries itself, so you must be 
using either some distribution or use your own compiled binaries.


I'm asking because if the symbols would be available for the dump you 
provided, it could be easier to debug the problem.


Unfortunately I'm a bit stuck here, since I don't have access to the 
CollabNet symbol files. Maybe you can try to reproduce the issue with 
SilkSVN: https://sliksvn.com/download/ and attach the dmp file of the 
crash when testing with their version?


--
Regards,
Stefan Hett

Re: Subversion crash report

[Stefan Hett]

Hi James,


I downloaded SlikSVN and installed it, using the Typical 
installation.  I then copied the DLLs and EXEs from C:\Program Files 
(x86)\SlikSvn\bin to C:\MyScripts\SVN2 so that it was easier to type 
the address, and ran the merge again.  It crashed. I have included the 
log files as you requested.


Thanks for the dump. Looking at the corresponding code sections suggest 
that the crash might not occur with the 64-bit binaries. Any chance you 
could try such a build? I'd expect you'd get some error in this case 
which should be a useful lead to the underlying problem.


--
Regards,
Stefan Hett

Re: rollback to previous revision

[Stefan Hett]

Hi,

Hello,
  

How to rollback of a file or folder to previous revision?

svn merge -rHEAD:PREV TARGET

Andreas
Or svn up -r [file/folder] if by "rollback" you mean to get an older 
revision of a file/folder instead of reverting changes done to the file.


--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473

Re: rollback to previous revision

[Stefan Hett]

Hi,

Maybe I didn't describe it clearly.

I mean to rollback on the repository instead of the working copy. If a user checked in a 
"wrong" file, system administrator/project manager needs to rollback the file 
to the previous revision on the repository.
Then go with Andreas' suggestion and do a commit of the revert 
afterwards (aka: svn ci [...]). Afterwards the revision (or just the 
changes in one of the files/folders done in that revision) is reverted.


P.S. pls don't top post.

Regards,
Stefan

Re: svn: E175002: Unexpected HTTP status 418 ' Not Found'

[Stefan Hett]

Hi Jordi,


Dear svn users

We are trying to perform a commit of an added file to a folder already 
in the repository server. A changed file works fine, however when we 
try to commit an added file the following error is reported:


svn: E175002: Commit failed (details follow):

svn: E175002: Unexpected HTTP status 418 ' Not Found' on 
'/svn/reposthe_path_of_the_file '


Has anyone found something similar?

Well, I take it you discovered a teapot (hint: check HTTP status code 
418). ;-)
I'd assume some server side issue here. Without knowing more details 
about your environment it's hard to tell.



--
Regards,
Stefan Hett

Re: SVN Checkout failed

[Stefan Hett]

Hi Inder,


HI,

Got error while checking out:

CheckOut:

 [echo] Checking Out Project from SVN = TRAX_FCS

  [svn]  started ...

  [svn] This application has halted due to an unexpected error.

  [svn] A crash report and minidump file were saved to disk, you 
can find them here:


  [svn] C:\Windows\svn-crash-log20160302143040.log

  [svn] C:\Windows\svn-crash-log20160302143040.dmp

  [svn] Please send the log file to users@subversion.apache.org to 
help us analyze


  [svn] and solve this problem.

  [svn] NOTE: The crash report and minidump files can contain some 
sensitive information


  [svn] (filenames, partial file content, usernames and passwords 
etc.)


  [svn]  failed !

Attached is the DMP and the LOG files.

Turtoise SVN Version Info:



TortoiseSVN 1.8.11, Build 26392 - 64 Bit , 2015/03/19 18:50:20

Subversion 1.8.13, -release

apr 1.5.1

apr-util 1.5.4

serf 1.3.8

OpenSSL 1.0.2a 19 Mar 2015

zlib 1.2.8



*Regards,*

*Inder*

While you provide the TSVN details here, your log states you were using 
SilkSVN 1.8.9. Since that version is quite old, I suggest you upgrade to 
the latest 1.8 version (SilkSVN 1.8.15) and test whether that resolved 
the crash you have.



--
Regards,
Stefan Hett

Re: Can I combine 'complete' and 'cherry-pick' merges?

[Stefan Hett]

Hi Eric,

Eric Dramstad  gmail.com> writes:

I'm thinking of doing this (while standing inside a trunk workarea):

  svn merge ^/feature
 svn merge -c -100 ./file.c
 svn merge -c -101 ./file.h
 svn commit -m 'reintegrated feature'

That should have been:

 svn merge ^/feature
 svn merge -c -100 ^/feature/file.c ./file.c
 svn merge -c -101 ^/feature/file.h ./file.h
 svn commit -m 'reintegrated feature'

I also should have mentioned that I'm using subversion 1.9.3.
Yes, this should be fine. We are using that approach quite regularly 
here (though in our case the other way around --- aka: cherry picking 
selective changes first and in the end do a complete merge of the rest).


--
Regards,
Stefan Hett

Re: wc_db.c line 10235: assertion failed

[Stefan Hett]

Hi,

I want to set an external reference to a relative project path, which does not 
contain spaces (googling the assertion gave a hint that spaces can be involved 
into creating this assertion).
I can enter the path but once I press the context menu entry "Fetch HEAD revision 
and adjust to it",
I get the assertion with the hint (svn_dirent_is_absolute(local_abspath)).
The local path is 'XXX', the referenced project is located at 
'../../../reference_project/trunk/my_src/XXX' and should exist,
as a second parallel project which is setup in similar fashion and directory 
structure can actually reference the same sub-directory.

My Tortoise svn is
TortoiseSVN 1.9.3, Build 27166 - 64 Bit -dev, 2016/02/08 07:58:04
on Windows 7.
Can you reproduce the issue using the svn command line tools? Otherwise 
maybe you would better be off on the TSVN users mailing list.


--
Regards,
Stefan Hett

Re: SVN v(+) database versioning question

[Stefan Hett]

Hi Vit,

Hello,

may I ask a question: what would be the best way to achieve this with 
SVN:


Database versioning scripts shall be (1) numbered (due to DBmaintain)  
and (2) incremental.


ad 1) When a developer commits a script, I should get the next higher 
number
than the last committed script. E.g. 045_customers.SQL, 046_orders.SQL 
etc


ad 2) Scripts, which are once committed, should be immutable -- 
developers

should not be able to change them. They can only add new scripts.

Many thanks in advance,
V. Prochazka
Both should be achievable using pre-commit hooks. You can add a check to 
ensure consecutive numbering of your SQL-script files as well as 
preventing any modifications to committed files.


--
Regards,
Stefan Hett

Re: Installation of svn 1.9.3 on windows 2008

[Stefan Hett]

Hi Subhadarsan,

Hi Team,

We are installing subversion 1.9.3 on windows 2008.
After the installation when i am trying to open the svnadmin/svnserve 
its giving me error,saying that libsvn_delta-1.dll is missing.

When i checked the dll is very much there,yet its giving this error.
Could anyone please help us on this.

Regards,
Subhadarsan

Which client are we talking here? Did you build the client from source 
yourself? If so, is libsvn_delta-1.dll located in the same directory as 
svnadmin.exe? Are you running svnadmin.exe from a local disk or some 
network/WebDAV drive?


--
Regards,
Stefan Hett

Re: svndumpfilter exclude folder with deleted folders

[Stefan Hett]

Hi Yael,

Hello

I would like to know if the subject situation is normal.

Moment 1 (folder structure)
Etudes
>tags
>>copytrunk
>>>src
>>>example

svndumpfilter exclude /Etudes/tags/copytrunk < dump > filter

The log shows 3 dropped nodes: copytrunk, copytrunk/src and 
copytrunk/example

Moment 2 (I deleted example)
Etudes
>tags
>>copytrunk
>>>src

svndumpfilter exclude /Etudes/tags/copytrunk < dump > filter

The log shows that copy trunk is still there
Of cause it does - you said that you deleted "example". Why do you 
expect that the parent folder (copytrunk) would not be there anymore? Or 
do you have a typo here?


Conclusion: if you have a deleted subfolder it is not possible to 
exclude the folder?
Maybe you could attach a repro script presenting the exact commands you 
perform to illustrate your question/issue?


--
Regards,
Stefan Hett

Re: Apache 2.4/SVN 1.8.15 - cannot see top level directories

[Stefan Hett]

On 4/25/2016 10:53 PM, Tom Kielty wrote:


We currently run SVN 1.8.8 on Windows 2008 R2 with Apache 2.2 and LDAP 
SSPI authentication.


We have 2 repositories. After authenticating you can see the top two 
directories in a browser.


URL: http:///Repo1 <http://%3cip%3e/Repo1>

Shows:

Directory1/

Directory2/

I am upgrading to SVN 1.8.15 with Apache 2.4 on Windows 2012 R2 with 
LDAP SSPI authentication.


When I go to the same url after upgrading I am not asked for 
authentication when going to http:///Repo1 <http://%3cip%3e/Repo1> 
but I see “Revision ”. I do not see Directory 1 or Directory2.


However if I go to http:///Repo1/Directory1 
<http://%3cip%3e/Repo1/Directory1> I am prompted to authenticate and I 
can see everything under Directory1.


Here is my httpd.conf information:



  DAV svn

  SVNPath D:/Repo/Repo1

  SVNListParentPath on

  AuthName "SVN Server"

  AuthType SSPI

  SSPIAuth On

  SSPIAuthoritative On

  AuthzForceUsernameCase lower

  SSPIDomain 

  SSPIOfferBasic on #let non-IE clients authenticate

  SSPIOmitDomain On

  AuthzSVNAccessFile "D:/Repo/Repo1/svnaccess.conf"

  Satisfy any

  Require valid-user



I also have WebSVN which does show everything just fine.

Any ideas?

Could it be that you have some additional path-based authorization set 
up? See 
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
If so, I think to remember there was some security issue with that at 
some point (aka: information disclosure of the directory names at some 
specific scenario). Since 1.8.15 no longer displays the directories for 
you, I'd take it that some version in between 1.8.8 and 1.8.15 contain 
that fix and therefore result in the different behavior you see.


Looking at the changelog for 1.8:
1.8.14:
[...]

 - Server-side bugfixes:
* mod_authz_svn: do not leak information in mixed anonymous/authenticated
  httpd (dav) configurations (CVE-2015-3184)
* do not leak paths that were hidden by path-based authz (CVE-2015-3187)

[...]

I take it these are the ones I happen to remember.

--
Regards,
Stefan Hett

Re: SVN Commit & Update Issue

[Stefan Hett]

Hi Aghil,

Dear Team,

I can able to commit files to our repository through Eclipse and 
terminal. In other system, when i check synchronize with repository, 
my committed changes are not showing.


Please help me to resolve this issue.

Regards,
Aghil T U
Please provide some more information about your environment. With this 
limited information nobody can give you any reasonable support I fear.



--
Regards,
Stefan Hett

Re: Blank lines

[Stefan Hett]

Hi Darek,

How can I force
svn status
not to indicate files with added/removed blank lines as modified?

I'm fighting with this all day today and I cannot find any help.
I've already changed diff-cmd and diff3-cmd to ignore blank lines, but
I still see these files as modified which gives me a jungle of changes
that I don't want to see.
As far as I know that's not directly possible with the command line 
client. You could however write a script/batch file to compile the 
results you expect.
One reference which might help to get started: 
http://stackoverflow.com/questions/19307464/svn-list-of-changed-files-ignoring-whitespaces
That contains a script which uses svn status and svn diff -- it does 
things slightly different from what your needs would require, but it 
should still be a useful starting point.



--
Regards,
Stefan Hett

Re: svnsync error : Error while replaying commit

[Stefan Hett]

Hi,

you might wanna repost your question in English. I'm not sure whether 
anybody here can read Chinese (if it is Chinese, that is).
All I can make out of this report is that you seem to get some error 
running svnsync which seems to be a rather old version (1.7.4). If you 
want/need to stick with 1.7, I suggest you at least upgrade to the 
latest 1.7-version (which is 1.7.22 at the time of writing this) or even 
a later (and still supported) version like 1.8/1.9.



我也遇到了该问题Error while replaying
commit，有些库用下面同样的步骤操作是没问题的，但是有些库就报这个错，不知道为什么，麻烦大家遇到过解决了的回答下，谢谢
我的操作步骤是
1、将脚本aapost-commit.bat放置到SVN主服务器相对应项目的hooks文件里，
例如：\\192.168.27.1\d$\SVN\c3m-video\hooks
"C:\Program Files (x86)\Subversion\bin\svnsync.exe" sync --non-interactive
svn://192.168.27.88/c3m-video --username admin --password cmadmin
修改下面一行中的备份服务器IP和项目名
2、将脚本Svn Start Server.bat放置在备份服务器SVN文件的同目录下
svnserve -d -r e:\SVN 修改对应的存储盘符
3、将脚本pre-revprop-change.bat放置在备份服务器相应项目的hooks文件夹下。例如：
\\192.168.27.1\d$\SVN\c3m-video\hooks
二、操作命令  (在备份服务器上操作)
1、连接 svnsync init svn://192.168.27.88/C3M-EMS svn://192.168.27.1/C3M-EMS
2、同步 svnsync sync svn://192.168.27.88/MVSS --username admin --password
cmadmin

主服务是Windows sever 2008 R2，备份服务器是Windows sever 2008 R2
SVN服务版本为Setup-Subversion-1.7.4



--
View this message in context: 
http://subversion.1072662.n5.nabble.com/svnsync-error-Error-while-replaying-commit-tp156531p196592.html
Sent from the Subversion Users mailing list archive at Nabble.com.




--
Regards,
Stefan Hett

Re: Migrate svn, version 1.6.11 (r934486) to svn verion 1.9.3

[Stefan Hett]

Hi Brandon,

you can load older dumps into newer versions. So there should be no 
reason to upgrade prior to the migration.


The only thing I'd consider is to upgrade the server to 1.6.23, since 
1.6.11 is rather outdated on the 1.6 branch and therefore there might be 
bugs in the dump logic which would have been fixed in a later 1.6 build 
(I'm not particularly aware of any specific issue here --- just 
suggesting a general I normally follow myself).


Obviously if there is no easy way to upgrade SVN to 1.6.23 on CentOS 
5.8, I'd also skip that. Worst case, you will still have the original 
repository backed-up so you can always replay the migration procedure.



Is an upgrade needed prior to migrating a repo if going to another 
version of svn? I wonder if 1.9.3 is supported on CentOS 5.8



*From: *"Gronde, Christopher (Contractor)" 
*To: *"Brandon L. Wisenburg" 
*Sent: *Thursday, May 5, 2016 7:40:38 AM
*Subject: *RE: Migrate svn, version 1.6.11 (r934486) to svn verion 1.9.3

I am actually doing the same exact thing and this is the first time 
I’ve upgraded SVN. The installer I got from WanDISCO and It seems 
pretty self-explanatory. Our intention is to do an in-place upgrade 
and then focus on transferring from RHEL6 to RHEL7 later and probably 
move from authenticating from FreeIPA to Active Directory. If you have 
any tips on upgrading I’d appreciate that as well!





From: Brandon L. Wisenburg [mailto:bran...@wisenburg.com]
Sent: Wednesday, May 04, 2016 10:27 PM
To: users@subversion.apache.org
Subject: Migrate svn, version 1.6.11 (r934486) to svn verion 1.9.3





Hello All.


I am working on a project to migrate a repo to a new server that is 
more up-to-date and runs a newer OS and newer version of subversion. 
I've done this before, between similar versions of subversion. I was 
wondering, are there any got ya's that I should be aware of regarding 
migration a 1.6.11 svn to 1.9.3? Does it matter much the different 
versions? Does anyone have any insight and experience they'd like to 
share?






Many Thanks.



--
Regards,
Stefan Hett

Problem with locking multiple files.

[Stefan Hett]

Hi,

this is in reference to a user reported problem on the TSVN mailing list [1]

The user is having an issue with using TSVN 1.9.4 over a Java-SSL-Tunnel 
when trying to lock hundreds or thousands of files. The same operation 
works without problems when:

- using TSVN 1.8.12 or
- using the SVN command line client (1.8 or 1.9)
- disabling the Java-SSL-Tunnel

I've been pointed to issue #4557 [2] by stsp. I'm not 100% certain 
whether this really is the particular problem the user runs into but 
even if it wouldn't be the case here, the underlying issue of #4557 
might be worth changing/fixing in 1.9 as well.


The reasoning from a users / downstream-developer's point of view would 
be that the new way could fail in a particular environment which the old 
(aka: 1.8) way would work just fine. So if I as a developer make use of 
the new functionality, it would look like a regression to my userbase of 
my tool.


Does that make sense to you? Should I create a new JIRA issue for that 
case (in contrast to SVN-4557 that would differ in that the effected 
version would be 1.9.x - not 1.8.x - aka: no regression)?



[1] 
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171337

[2] https://issues.apache.org/jira/browse/SVN-4557

--
Regards,
Stefan Hett

Re: Subversion checkout behavior at non-existent revision

[Stefan Hett]

Hi Aslesh,


Hi,

I have a question about the behavior of svn checkout. Here is the 
scenario:


I have a standard trunk, branches, tags structure for one of my apps 
in a repo and I created a branch, say at revision 500 of trunk.


Later, I delete the branch and the recreate another branch with the 
same name and at the same revision 500 of trunk.


Now I’m trying to check out the branch at revision 500. I know that 
the branch doesn’t exist at r500 (it will be some higher revision), 
only trunk does and it probably doesn’t make sense to check out a 
branch at that revision; but I’m interested in knowing why this 
behavior occurs and if it is expected.


svn co /branches/@500 à svn info on that gives the 
URL as expected i.e. /branches/


svn co -r 500 /branches/ à svn info on that gives an 
unexpected result i.e. /trunk


Shouldn’t subversion complain that the branch doesn’t exist at 
revision 500?


If it has checked out without complaining, why does svn info using the 
second way of checkout show the unexpected result?



Which version of SVN are you using?
I just tried to reproduce the behavior you are describing here using SVN 
1.9.4.


For the first test (aka: co with a peg-revision prior to the creation of 
the branch) I'm getting the expected svn error: "svn: E17: URL 
'/branches/' doesn't exist".
Could it be possible that you somehow mistook the revisions in your case 
and the branch in fact already existed in revision 500?



The second case brings up some different behavior on my test run too - 
and I can't quite make out much sense here (even after refreshing my 
memories re-reading the peg revision algorithm):


(note: r1 was the initial creation of trunk/branches/tags folders in my 
test repository --- 'a' was the name of the test branch I created)

Running in E:\test:
svn co -r 1 /branches/a resulted in:
Checked out revision 1.

However, that then working directory in a subdirectory E:\test\a 
(instead of one in E:\test).
If I change the svn co-command and explicitly specify the wc-path, I get 
the same result you are describing (aka: co of trunk instead of the branch):

svn co -r 1 /branches/a .

TBH I would have expected the same outcome as you are describing (aka: 
some error, since the branch to be checked-out is not present in the 
given operative revision).
I've attached a repro case (Windows batch file) for this. Maybe some of 
the SVN developers can catch that up and make some sense out of that?


I take it there are two separate questions at hand here:
1) Why does the svn co command not error out, if specifying a path which 
doesn't exist in the operative revision?
2) Why does the svn co command create a subdirectory 'a' instead of 
taking the specified URL as the path to checkout entirely?


--
Regards,
Stefan Hett

@echo off

rem 
##
rem ##  
##
rem ##  This is a template for writing Subversion bug reproduction scripts. 
##
rem ##  
##
rem ##  It creates a repository containing the standard Greek Tree (see 
##
rem ##  
http://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/greek-tree.txt)
 ##
rem ##  and checks out a working copy containing that tree.  Please adjust  
##
rem ##  this script however you need to to demonstrate your bug.  When it's 
##
rem ##  ready, post the bug report to d...@subversion.apache.org -- after   
 ##
rem ##  
http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs, ##
rem ##  of course.  
##
rem ##  
##
rem 
##

:defineCommands
rem You might need to adjust these lines to point to your
rem compiled-from-source Subversion binaries, if using those:
for %%i in (svn.exe) do set SVN="%%~$PATH:i"
for %%i in (svnadmin.exe) do set SVNADMIN="%%~$PATH:i"

:defineUrls
rem Only supported access method: file://. If http:// or svn://, then
rem you'll have to configure it yourself first.
set URL=file:///%CD%/repos
set URL=%URL:\=/%
echo Base url for repo: %URL%

:cleanAllDirsAndCreateRepo
if exist repos rmdir /s /q repos
if exist import-me rmdir /s /q import-me
if exist wc rmdir /s /q wc
%SVNADMIN% create repos

:prepareGreekTree
echo Making a Greek Tree for import...
mkdir import-me
mkdir import-me\trunk
mkdir import-me\tags
mkdir import-me\branches
mkdir import-me\trunk\A
mkdir import-me\trunk\A\B\
mkdir import-me\trunk\A\C\
mkdir import-me\trunk\A\D\
mkdir import-me\trunk\A\B\E\
mkdir import-me\trunk\A\B\F\
mkdir import-me\trunk\A\D\G\
mkdir import-me\trunk\A\D\H\
echo This is the file &#

Re: Problem with locking multiple files.

[Stefan Hett]

On 5/9/2016 10:09 AM, Ivan Zhakov wrote:

On 6 May 2016 at 14:37, Stefan Hett  wrote:

Hi,

this is in reference to a user reported problem on the TSVN mailing list [1]

The user is having an issue with using TSVN 1.9.4 over a Java-SSL-Tunnel
when trying to lock hundreds or thousands of files. The same operation works
without problems when:
- using TSVN 1.8.12 or
- using the SVN command line client (1.8 or 1.9)
- disabling the Java-SSL-Tunnel

I've been pointed to issue #4557 [2] by stsp. I'm not 100% certain whether
this really is the particular problem the user runs into but even if it
wouldn't be the case here, the underlying issue of #4557 might be worth
changing/fixing in 1.9 as well.

The reasoning from a users / downstream-developer's point of view would be
that the new way could fail in a particular environment which the old (aka:
1.8) way would work just fine. So if I as a developer make use of the new
functionality, it would look like a regression to my userbase of my tool.

Does that make sense to you? Should I create a new JIRA issue for that case
(in contrast to SVN-4557 that would differ in that the effected version
would be 1.9.x - not 1.8.x - aka: no regression)?


Could you please provide reproduction script using command line
client? As far I understand the problem in 'Java-SSL-Tunnel', not in
Subversion itself.
I'll forward that to the user on the TSVN list, since I don't have any 
environment at hand here to reproduce the described issue.


--
Regards,
Stefan Hett

Re: Problem with locking multiple files.

[Stefan Hett]

On 5/9/2016 10:55 AM, Stefan Hett wrote:

On 5/9/2016 10:09 AM, Ivan Zhakov wrote:

On 6 May 2016 at 14:37, Stefan Hett  wrote:

Hi,

this is in reference to a user reported problem on the TSVN mailing list [1]

The user is having an issue with using TSVN 1.9.4 over a Java-SSL-Tunnel
when trying to lock hundreds or thousands of files. The same operation works
without problems when:
- using TSVN 1.8.12 or
- using the SVN command line client (1.8 or 1.9)
- disabling the Java-SSL-Tunnel

I've been pointed to issue #4557 [2] by stsp. I'm not 100% certain whether
this really is the particular problem the user runs into but even if it
wouldn't be the case here, the underlying issue of #4557 might be worth
changing/fixing in 1.9 as well.

The reasoning from a users / downstream-developer's point of view would be
that the new way could fail in a particular environment which the old (aka:
1.8) way would work just fine. So if I as a developer make use of the new
functionality, it would look like a regression to my userbase of my tool.

Does that make sense to you? Should I create a new JIRA issue for that case
(in contrast to SVN-4557 that would differ in that the effected version
would be 1.9.x - not 1.8.x - aka: no regression)?


Could you please provide reproduction script using command line
client? As far I understand the problem in 'Java-SSL-Tunnel', not in
Subversion itself.
I'll forward that to the user on the TSVN list, since I don't have any 
environment at hand here to reproduce the described issue.
Seems like I'm not fully awake yet... As far as I understood the issue, 
there's no way to reproduce the scenario just using the command line 
client, since that doesn't allow to lock multiple files over different 
paths (aka: there's no recursive-flag for svn lock).


The only way to reproduce the problem atm seems to be using some other 
client. In this particular case the issue is reported to be reproducible 
using TSVN 1.9.4 (which according to Stefan Küng uses the SVN API 
directly for the lock/unlock feature --- aka: I assume he's calling 
svn_ra_lock() by passing multiple path_revs - didn't check that, so take 
it with care).


Do you have a lead for me how to get any further information from the 
user which would help to investigate the issue? Since I don't have an 
environment at hand here, I can't try to reproduce the described 
scenario myself.


--
Regards,
Stefan Hett

Re: Problem with locking multiple files.

[Stefan Hett]

On 5/9/2016 12:31 PM, Ivan Zhakov wrote:

[please use plain-text formatting as documented in Community Guide [1]]
https://subversion.apache.org/docs/community-guide/mailing-lists.html#encodings

On 9 May 2016 at 12:05, Stefan Hett  wrote:

On 5/9/2016 10:55 AM, Stefan Hett wrote:

On 5/9/2016 10:09 AM, Ivan Zhakov wrote:

[...]

Could you please provide reproduction script using command line
client? As far I understand the problem in 'Java-SSL-Tunnel', not in
Subversion itself.

I'll forward that to the user on the TSVN list, since I don't have any 
environment
at hand here to reproduce the described issue.

Seems like I'm not fully awake yet... As far as I understood the issue, there's
no way to reproduce the scenario just using the command line client, since
that doesn't allow to lock multiple files over different paths (aka: there's no
recursive-flag for svn lock).


'svn lock' accepts multiple targets:
$ svn lock a b c
'a' locked by user 'ivan'.
'b' locked by user 'ivan'.
'c' locked by user 'ivan'.


The only way to reproduce the problem atm seems to be using some other
client. In this particular case the issue is reported to be reproducible using
TSVN 1.9.4 (which according to Stefan Küng uses the SVN API directly
for the lock/unlock feature --- aka: I assume he's calling svn_ra_lock() by
passing multiple path_revs - didn't check that, so take it with care).

Do you have a lead for me how to get any further information from the user
which would help to investigate the issue?

- RA layer is being used?
- Server-side Subversion version?

But most likely 'Java-SSL-Tunnel' acts as a 'busted proxy' and doesn't
handle HTTP pipelining properly. I assume users uses http:// protocol
to access the server. Switching to https:// may help in this case.
Thanks for picking that up on the TSVN users list yourself, Ivan. Looks 
like it's indeed an issue with HTTP pipelining and the Java-SSL-Tunnel 
as you suspected.
For those interested in the outcome of the thread: TSVN users list 
topic: "TortoiseSVN "Get lock" of multiple files fails via 
Java-SSL-tunnel since v1.9.0 (bug?)".


--
Regards,
Stefan Hett

Re: tag individual files vs whole repo?

[Stefan Hett]

On 5/10/2016 4:09 PM, Matt Garman wrote:

Consider this scenario: our project has concurrent releases, R8 and
R9.  These releases have been indicated in the repo by some means,
either a tag or a branch.
Now, we need to bugfix R8 only.  Specifically, we want to do a release
R8.1 that does not include R9 features.

Through some means, e.g. mis-communication, developer error, whatever,
the developer does the bugfix on R9, instead of R8.  And he tags his
fix "bug_xyz_fix".  Now, the release manager will update his build to
the "bug_xyz_fix" label, and inadvertently release the bugfix plus the
R9 changes, which we wanted to avoid.

This is one potential problem with tagging a whole repo, rather than
individual files.  In this particular case, it may be possible that
the one file that changed for the R8 bugfix is also perfectly valid
for R9.  So in this case, it arguably makes sense to tag only the one
changed file, rather than the whole repo.

I've seen this asked before ("how to tag only individual files").  I
know it's possible to force svn into doing it, but it's going against
the design intent of the tool.  And I feel that whole-repo tagging is
generally better, but the above example is one case where that may not
hold.  So what I'm really asking is:
 - What are the rational reasons to prefer whole-repo tagging
versus individual file tagging?  I'm having trouble coming up with
example cases to support whole-repo tagging even though my gut says
it's better.
The case you are describing is certainly something where revision/file 
labels/tags would be beneficial.
However, tbh this is a case/situation I never came across yet in my 
entire time I've been developing software. Certainly the fact that I do 
not have much experience with Git contributes to that.


I take it that the reason for that is that I never thought about tagging 
just "bugfixes". I've used tags only ever to tag completed versions. 
Bugfixes for past versions, I've always worked on a separate branch. Aka:

- proj/trunk is the latest version we are developing on
- proj/branches/1.x is created from trunk when version 1.0 is released
- proj/tags/1.0 is created from proj/branches/1.x at the same time

Following work goes into proj/trunk - bugfixes are done in 
proj/branches/1.x.
At one point 1.1 is released from proj/branches/1.x and a tag is created 
(proj/tags/1.1).


There are also occasions where we release directly from trunk skipping 
the creation of proj/branches/xxx.


Hence the process is very much like the one the SVN project is using.

To simplify our workload we are utilizing CruiseControl and set-up a 
task there which runs daily and automatically merges any changes from 
proj/branches/1.x back to trunk. That way we have to fix issues which 
exist in 1.x only once (in the 1.x branch) rather than twice (1.x + trunk).


That said, for us tags are always representing the 
source-/resource-state of a whole version and never of a separate 
fixes/change - these things are always done using branches. The release 
manager works with the branch he explicitly switched to (aka: 
branches/1.x) and is pulling in other branches which contain fixes, so 
mistakes as you are describing are almost impossible to happen here in 
practice.


The one big obvious advantage of that process and the point of always 
tagging a whole repository (or better said: a whole project state) is 
that everything with that tag is in it's fixed state. There are never 
combinations of multiple tags, which are likely to occur in cases you 
would end up if you tag files/revisions. So the code and resource state 
is straight forward when you tag an entire repository. That's the main 
advantage I see here, but it's on the other side also the main limiting 
factor which reduces flexibility of what you can do.


To be more precise: If you would use a system/procesdure where you 
create your own release from a combination of separate tags, you could 
easily compose any kind of project variation. In practice however this 
would come to its limit sooner or later where the different tags deviate 
so much from one another that any kind of attempt to merge the different 
states would be unfeasible.


--
Regards,
Stefan Hett

Re: Improve svn warning/error message to faciliate troubleshooting

[Stefan Hett]

Hi Cosmere,

Hello,

I am using svn version 1.8.9 on Centos and I get the following warnings

svn: warning: W155022: Cannot insert a file external defined on 
'/home/cosm/svn/parser/packages' into the working copy 
'/home/cosm/svn/parser/packages/src'.
svn: warning: W155022: Cannot insert a file external defined on 
'/home/cosm/svn/parser/packages' into the working copy 
'/home/cosm/svn/parser/packages/src'.
svn: E205011: Failure occurred processing one or more externals 
definitions


Could you please improve the warning/error to include the external 
involved so that troubleshooting is easier?


Thanks

You might wanna upgrade your SVN version to the latest 1.8 build (which 
is 1.8.16 at the time of writing this).
There are multiple client fixes impacting the handling of externals. For 
instance 1.8.13:

"better error message if an external is shadowed (r1655712, r1655738)"

While I'm not sure whether that's helping in your case, I take it that 
chances are not that bad. .-)


--
Regards,
Stefan Hett

Re: view log problem with path authorization

[Stefan Hett]

Hi Phil,


​Any response to this? It does look like a bug to me...

​


*From:* Phil Crooker
*Sent:* Tuesday, 24 May 2016 6:10 PM
*To:* users@subversion.apache.org
*Subject:* view log problem with path authorization

Newbie question - I have authenticated users with read or r/w 
access are unable to view logs, eg:



# svn --username whatever --password x 
svn://svn/repos/project/yada.txt


svn: Item is not readable

I must grant anonymous read access in authz and then it works:


[/]

* = r


I've seen this reported earlier but no answer:


http://svn.haxx.se/users/archive-2011-02/0141.shtml

  http://stackoverflow.com/questions/6651997/svn-show-log-not-working


My question is why can't an authenticated user who has rights see the 
logs?


Send the original reply only directly to you (rather than to the list). 
Hence sending again to increase the chances that this might trigger some 
light for someone else (and also for you in case my reply got lost 
somewhere):


The issue seems to be on record in the SVN bugtracker: 
https://issues.apache.org/jira/browse/SVN-2960 .

Can't say much more unfortunately. :-/


--
Regards,
Stefan Hett

Re: Creating and Verifying a Reliable backup

[Stefan Hett]

On 6/1/2016 4:58 PM, Michael Schwager wrote:

Hello,
We are very paranoid about our Subversion repo, notwithstanding the 
fact that the previous sysadmin didn't back it up. But that's another 
story. Now I'm here at my job, I've inherited the repo admin duties, 
and I want to back it up reliably. If we lose it, we're all out of work.


My question is: How do I back it up reliably, and verify it so that I 
can deliver a 100% recovery guarantee to my boss? I have Subversion 
1.8.4 on a CentOS 6.3 server, and Tortoise SVN 1.8.11 on Windows 7 
clients.


I am thinking to do both an svn hotcopy to one directory, and an rsync 
to another. The svn hotcopy will give me a backup that I'm pretty sure 
is reliable (see Notes below). Assuming httpd is down and I can 
guarantee that I am the only person who will be logged into the SVN 
server, can I expect with 99.9% surety that the svn repos are quiescent?


Thanks.
--
-Mike Schwager

Notes:

We're a little worried about svn hotcopy; we ran into a bug that came 
about under 1.8 when working with older repos; the hotcopy exits with 
the following error:


svnadmin: E22: Serialized hash missing terminator
As far as I can tell this indicates a problem in the repository you are 
trying to hotcopy from. Run svnadmin verify on that to get details where 
the corruption might be located and resolve that (if possible).


I have compiled subversion-1.9.4 on the server under 
/opt/subversion-1.9.4. If I run that version of svn hotcopy, it 
appears to work and svnverify exits successfully. But if I look at all 
the files under both the original and the hotcopy on one of our repos, 
I find that a file is missing: repos2/db/rev-prop-atomics.shm . That's 
probably ok, but still- how do we know the latest hotcopy, and 
hotcopies of the future, are and will remain 100% bug-free?

To ensure the integrity of a backup close to 100% I go the fail safe way:
1. svnadmin verify to ensure the current repository is in a good state 
(if there are errors/issues resolve them)

2. svnadmin dump to dump the current repository
3. svnadmin load the dump into a fresh repository
4. svnadmin dump the newly loaded repository
5. compare the first and the last dump
6. run svnadmin verify on the loaded dump to en
If both dumps are equal, I'm certain enough the integrity is given. 
(Note: this implies the same fsfs-format as well as the same server 
version for the svnadmin calls).


This process however only works when you can take down access to a 
repository completely. Otherwise svnadmin hotcopy would be my choice 
too. In addition setting up a mirror which is kept in sync using svnsync 
is also a reasonable measurement to further increase the reliability of 
an SVN repository IMO.


However, it's also utterly vital to keep the server up to date with 
patch releases, so you are not suffering flaws/bugs which could impact 
the server side. Some examples for issues which have been fixed a long 
time ago and are not fixed in 1.8.4 (but might be relevant for your case 
of ensuring data correctness/integrity and a reliable backup system):
1.8.5: hotcopy: fix hotcopy losing revprop files in packed repos (issue 
#4448)

1.8.9: svnadmin dump: don't let invalid mergeinfo stop dump
1.8.9: svnrdump load: fix crash when svn:* normalization (issue #4490)
1.8.9: mod_dav_svn: detect out of dateness correctly during commit 
(issue #4480)

1.8.11: disable revprop caching feature due to cache invalidation problems
1.8.13: svnadmin load: tolerate invalid mergeinfo at r0 (issue #4476)
1.8.13: svnadmin load: strip references to r1 from mergeinfo (issue #4538)
1.8.13: svnsync: strip any r0 references from mergeinfo (issue #4476)
1.8.14: prevent possible repository corruption on power/disk failures
1.8.16: dump: don't write broken dump files in some ambiguously encoded 
fsfs repositories (issue #4554)


If you feel very conservative you might also wanna consider staying at 
the old stable version for the server (sidenote: even with the server 
running at 1.8, clients could use svn 1.9), if you don't need 
bugfixes/improvements of the current stable svn version. While the 
current stable build (1.9.4) contains fixes for issues still present in 
1.8.16 and also delivers new features, it also contains 
features/improvements which by the nature of software lifecycles have 
not been tested as long in the wild as the features present in 1.8.16. 
So one might argue that from the code integrity point of view, 1.8.16 
would be the safer choice to go.


If you are compiling your own server, be sure to keep the dependencies 
used also up to date.


--
Regards,
Stefan Hett

Re: E200004: Could not convert '<...>' into a number

[Stefan Hett]

Hi Vinicius,
On 6/7/2016 9:24 PM, Vinicius Massuchetto wrote:

Suddenly, the following error started to occur in the repository when
checking out or updating:

 svn: E24: Could not convert
'?\F6R?\EF?\F2?\9Bn1?\85?\9F?\A4?\AFm?\F5?\95?\8A
?\D4RJ?\80w3'h?\9A?\ED?\CC{!p?\B3?\C6?\C2!P?\DE?\EA?\F0?\C3


 ?\8D;?\E8?\E4 ?\D9


   s<=4' into a number

Cleaning up and running update again seems to change files properly,
but the error keeps coming back every time. I noticed using `svnadmin
verify` that the error applies to most revisions just after a specific
one. `svnadmin dump` also fails with:

 * Error verifying repository metadata.
 

Could you provide the error output from svn verify?


The repository was created with 1.9.1, and clients use the same
TortoiseSVN client version. I updated both svnserve and client to
1.9.4 (r1740329) with no success. `svn ls` gives the same error for
the revisions that fail with dump. `svnadmin restore` runs within 1
second but does nothing that can fix this. The server log shows
nothing else than the usual 'get-lock open get-latest-rev reparent'
messages.

I searched the Web and this mailing list about it, but could not find
a solution. Any help is much appreciated.

Thanks.
--
Vinicius Massuchetto



--
Regards,
Stefan Hett

Re: Upgrade SVN

[Stefan Hett]

Hi Anup,

Hi Team,
May I know how to upgrade SVN from 1.7.8 to 1.9?
Thanks,
Anup
If you are using a particular SVN distribution take a look at the docs 
of that distribution.
If you are building SVN yourself, see [1]: "[...] Subversion 1.9 servers 
can read and write to repositories created by earlier versions. To 
upgrade an existing server installation, just install the newest 
libraries and binaries on top of the older ones."


Don't forget to backup your repositories and server files before the 
upgrade though, to be sure that you have a backup at hand, if something 
goes wrong.


For your clients it's more or less the same (note that you don't need to 
have clients and servers running the same version --- you can also 
upgrade the client to 1.9 and keep the server at 1.7.8 or the other way 
around). Make sure their working directories are not locked (aka: run 
svn cleanup), upgrade the client to 1.9 and then upgrade the working 
directories (svn upgrade [2]).


[1] https://subversion.apache.org/docs/release-notes/1.9.html
[2] http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.upgrade.html

--
Regards,
Stefan Hett

Re: svn:mergeinfo updated for unchanged files/folders at merge of a feature branch to trunk - is this desirable?

[Stefan Hett]

On 6/12/2016 12:39 PM, Branko Čibej wrote:

On 12.06.2016 10:06, Yves Martin wrote:

On Sun, 2016-06-12 at 02:11 +0200, Branko Čibej wrote:


It's not a result of merge of individual folders. I find the pattern
in the log for commits I've done and I have most definitely not gone
out of my way to explicitly merge several subfolders one-by-one.

As I said, once the subtree mergeinfo is in the repository, it will be
updated in /every/ merge.


All users use TortoiseSVN. You think it's related to the client?
Should I ask the Tortoise community instead?

We'de really need a more detailed what's actually happening. I'm afraid
that for now we're only guessing based on your description of the logs;
that's far from enough.

Personally, the few times I've used TortoiseSVN for merging, I didn't
notice it behaving in any way differently from the command-line client.

Hello,

The main issue is that merge operation will add a "svn:mergeinfo" at the
current working directory where operation is applied.

Yes, as I noted above; and this is necessary in order to make 'svn
merge' work correctly.


But it is expected to be only on "root" folder aka /trunk or /branches/xxx

I'd rather say 'desired', not 'expected'. :)


Two ways to avoid that: guidelines to developers when merging (often
fails) and precommit hook to prevent addition of svn:mergeinfo property
to "non-root" folders.

To cleanup an existing working-copy, I have designed a Perl script that
checks if a svn:mergeinfo may be "moved" up to "root" folder:
https://github.com/ymartin59/svn-clean-mergeinfo

Let me point you at:

https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer

This is not part of any Subversion release yet, but it's fairly complete
feature-wise and could surely use a lot of testing in real-world
environments.
And in case you wanna give it a quick try: It's included in MaxSVN's 
trunk dev builds:

http://www.luke1410.de/typo3/index.php?id=97
(runs on Win Vista+ only - 64-bit)

As Brane stated, be careful and double check the results before 
committing any changes.


--
Regards,
Stefan Hett

Re: Segmentation fault in "svn resolve"

[Stefan Hett]

On 6/15/2016 10:26 AM, Stefan Sperling wrote:

On Wed, Jun 15, 2016 at 10:13:08AM +0200, Stefan wrote:

This sounds utterly familiar to me:

See this mail on the dev list: "[PATCH] error handling for
build_text_conflict_resolve_items" from 02/01/16:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201602.mbox/%3C56AEA607.7030209%40posteo.de%3E

The position you add the check seems to differ slightly (I added the
mine_abspath check above the line which determines the conflict style,
but I'd be +1 (non-binding) with any of the two patches.

Regards,
Stefan

Ah, I had missed that. Thanks!

Too bad this fell through the cracks back in February. Please try to
ping your own patches if you don't get a reply. We have a patch manager
role in the community who regularly pings every patch posted, but our
last patch manager has gone AWOL.
http://subversion.apache.org/docs/community-guide/roles.html#patch-manager
I kept it on my backlog, but since I got no replies, I thought best to 
get a repro case demonstrating the issue and verifying the proposed fix 
really solves the issue (so it's verifiable).
Unfortunately, I simply didn't get to that yet. So glad, you picked it 
up. :-)

One problem with your version of this fix is that it creates a case
where we run code before a variable declaration in the same block.
We can't do that because we remain compatible with old compilers.

Oh right. Completely overlooked that C89 violation in my patch. Nice spot.

--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473

Re: SVN upgrade

[Stefan Hett]

On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote:

Hi,
I am trying t compile the source code to upgrade from SVN 1.7 to 1.9.4 
but I am getting the below error.
Could you please send the steps for upgrading since I couldn’t find 
any good document in web ?
I am trying to follow the steps mentioned in 
_http://svn.apache.org/repos/asf/subversion/trunk/INSTALL_ .

And I want to upgrade in Linux
[USER@server subversion-1.9.4]$ sh autogen.sh
: command not found:
: command not found:
: command not found:
': not a valid identifiert: `CDPATH
: command not found:
'utogen.sh: line 35: syntax error near unexpected token `in
'utogen.sh: line 35: `  case "$1" in
Given the output you have here, I take it you downloaded the source as a 
tarball instead of getting it directly form the repository. In this 
case, please follow the instructions in INSTALL under II.A instead II.B.

I.e. run
./configure
make
make install

--
Regards,
Stefan Hett

Re: SVN upgrade

[Stefan Hett]

Hi,


Hello,

Thank you for your quick response.

I am able to proceed further but stuck at

[USER@server subversion-1.9.4]$ make install

/usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig

/usr/bin/install: cannot change permissions of 
`/usr/local/share/pkgconfig': No such file or directory


make: *** [install-fsmod-lib] Error 1

I take it you already troubleshooted the issue yourself and ruled out 
the obvious candidates like missing pkgconfig, missing permissions, and 
everything else google would point out in the first few links when 
searching the web for that error message, right?

If so, knowing your linux distribution would be useful.


*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* 2016, June, 15 8:04 AM
*To:* users@subversion.apache.org
*Subject:* Re: SVN upgrade

On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote:

Hi,

I am trying t compile the source code to upgrade from SVN 1.7 to
1.9.4 but I am getting the below error.

Could you please send the steps for upgrading since I couldn’t
find any good document in web ?

I am trying to follow the steps mentioned in
_http://svn.apache.org/repos/asf/subversion/trunk/INSTALL_.

And I want to upgrade in Linux

[USER@server subversion-1.9.4]$ sh autogen.sh

: command not found:

: command not found:

: command not found:

': not a valid identifiert: `CDPATH

: command not found:

'utogen.sh: line 35: syntax error near unexpected token `in

'utogen.sh: line 35: `  case "$1" in

Given the output you have here, I take it you downloaded the source as 
a tarball instead of getting it directly form the repository. In this 
case, please follow the instructions in INSTALL under II.A instead II.B.

I.e. run
./configure
make
make install


--
Regards,
Stefan Hett

___

This email is intended only for the use of the individual(s) to whom 
it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This 
e-mail in error, please advise immediately and delete the original 
message.
This message may have been altered without your or our knowledge and 
the sender does not accept any liability for any errors or omissions 
in the message.


Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas 
aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des 
renseignements qu'il contient par une personne autre que le (les) 
destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser 
immédiatement, par retour de courriel ou par un autre moyen.





--
Regards,
Stefan Hett

Re: SVN upgrade

[Stefan Hett]

On 6/16/2016 1:05 PM, Somashekarappa, Anup (CWM-NR) wrote:


Hello,

Is the pkgconfig related to apr or apr-util or it is independent of it?

Maybe someone else who's more familiar with building SVN on Linux can 
provide you some more details on this. From the install doc it's 
suggested that pkg-config is an optional dependency which is used to 
find appropriate options used at build time and is also required by 
other (optional) dependencies like Qt4, D-Bus, KDELibs 4, etc.



[USER@server subversion-1.9.4]$ make install

/usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig

/usr/bin/install: cannot change permissions of 
`/usr/local/share/pkgconfig': No such file or directory


make: *** [install-fsmod-lib] Error 1

*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* 2016, June, 15 8:32 AM
*To:* users@subversion.apache.org
*Subject:* Re: SVN upgrade

Hi,

Hello,

Thank you for your quick response.

I am able to proceed further but stuck at

[USER@server subversion-1.9.4]$ make install

/usr/bin/install -c -d /usr/local/lib /usr/local/share/pkgconfig

/usr/bin/install: cannot change permissions of
`/usr/local/share/pkgconfig': No such file or directory

make: *** [install-fsmod-lib] Error 1

I take it you already troubleshooted the issue yourself and ruled out 
the obvious candidates like missing pkgconfig, missing permissions, 
and everything else google would point out in the first few links when 
searching the web for that error message, right?

If so, knowing your linux distribution would be useful.


*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* 2016, June, 15 8:04 AM
*To:* users@subversion.apache.org <mailto:users@subversion.apache.org>
*Subject:* Re: SVN upgrade

On 6/15/2016 1:50 PM, Somashekarappa, Anup (CWM-NR) wrote:

Hi,

I am trying t compile the source code to upgrade from SVN 1.7 to
1.9.4 but I am getting the below error.

Could you please send the steps for upgrading since I couldn’t
find any good document in web ?

I am trying to follow the steps mentioned in
_http://svn.apache.org/repos/asf/subversion/trunk/INSTALL_.

And I want to upgrade in Linux

[USER@server subversion-1.9.4]$ sh autogen.sh

: command not found:

: command not found:

: command not found:

': not a valid identifiert: `CDPATH

: command not found:

'utogen.sh: line 35: syntax error near unexpected token `in

'utogen.sh: line 35: `  case "$1" in

Given the output you have here, I take it you downloaded the source as 
a tarball instead of getting it directly form the repository. In this 
case, please follow the instructions in INSTALL under II.A instead II.B.

I.e. run
./configure
make
make install



--
Regards,
Stefan Hett

___

This email is intended only for the use of the individual(s) to whom 
it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This 
e-mail in error, please advise immediately and delete the original 
message.
This message may have been altered without your or our knowledge and 
the sender does not accept any liability for any errors or omissions 
in the message.


Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas 
aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des 
renseignements qu'il contient par une personne autre que le (les) 
destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser 
immédiatement, par retour de courriel ou par un autre moyen.


--
Regards,
Stefan Hett



--
Regards,
Stefan Hett

Re: Which is the best tool /process to migrate VSS (with history) to Subversion

[Stefan Hett]

On 6/20/2016 1:07 PM, Yerra Babji wrote:

Hi,

I am looking for best tool / process to migrate VSS folders (with 
history ) to Subversion.


Thanks in advance for your suggestions.
7 years ago when I migrated VSS to SVN in our company, I used this tool: 
http://vssmigrate.codeplex.com/
Had some issues, but it turned out to do the job quite well (check out 
the reported issues there - think I reported everything I ran into back 
then which wasn't reported already).


7 years is quite a while ago. So maybe nowadays there are better 
solutions available. Just google and see if you find a more mature 
product out there. vss2svn seems to be suggested quite often and there 
also seems to be an commercial importer available from Polarion.


--
Regards,
Stefan Hett

Re: Compiling svn + httpd for windows python 2.x

[Stefan Hett]

Hi Mark,

Folks,

We use subversion with Trac behind httpd on Windows Server.  As Trac is written in 
"old" Python (2.x), I have had to resort to building everything from source.  
This is not simple and so I thought I would publish my notes here in case it helps anyone 
else and in the hope that if I have made any mistakes, someone will be kind enough to 
point them out to me!

~ Mark C

These are my notes for building Apache httpd and subversion for use with Trac 
[1].  All of the components need to be built using the same compiler to avoid 
run-time issues and, since Trac currently relies on Python 2.x, that means 
Visual Studio 2008.
Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN 
[1] is built using VS 2015 Update 1 (the upcoming builds will use VS 
2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any 
issue related to that.


[1] http://www.luke1410.de/typo3/index.php?id=97

--
Regards,
Stefan Hett

Re: Compiling svn + httpd for windows python 2.x

[Stefan Hett]

On 6/22/2016 2:01 PM, Cooke, Mark wrote:

-Original Message-
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: 22 June 2016 12:38

Hi Mark,


Folks,

We use subversion with Trac behind httpd on Windows Server.  As Trac is
written in "old" Python (2.x), I have had to resort to building everything
from source.  This is not simple and so I thought I would publish my notes
here in case it helps anyone else and in the hope that if I have made any
mistakes, someone will be kind enough to point them out to me!

~ Mark C

These are my notes for building Apache httpd and subversion for use with
Trac [1].  All of the components need to be built using the same compiler to
avoid run-time issues and, since Trac currently relies on Python 2.x, that
means Visual Studio 2008.

Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN
[1] is built using VS 2015 Update 1 (the upcoming builds will use VS
2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any
issue related to that.

[1] http://www.luke1410.de/typo3/index.php?id=97

I cannot remember specific references now but when I looked into this before it 
is because the official 2.x line is compiled using VC9.  When memory is passed 
between applications relying on different version of the CRT then you can end 
up with hard to diagnose memory corruptions that eventually cause problems.
This is correct. If you are building a project linking in the CRT, you 
should ensure that all DLLs and libraries you build with use the same 
CRT. Mixing different CRT versions is unsupported and you will have 
undefined behavior. The possibilities for memory corruptions is the most 
prominent effect one might observe, but there are other problems/issues 
this will cause too.

Digging a bit I found this thread [1] that highlights a similar CRT issue in 
python modules such as psycopg2 (which I use for PostGreSQL) that use the CRT 
internally...

[1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc
As far as I  skimmed through the thread the problem here is not with 
python being compiled using VC9, but rather the module the python script 
tries to load (psycopg2, which according to the web seems to be some 
postgre-sql-related library) was compiled with a different CRT than the 
Apache binaries. That's a general issue, yes, and that's why I don't 
distribute the svn-apache modules with MaxSVN, even though they are 
built as part of the buildprocess (and utilized for testing). It's 
imperative that the CRT for the Apache modules matches the ones used to 
build Apache and that only the distributor of the specific Windows 
Apache module can ensure.

If you can guarantee to me that isn't going to happen then it would make my 
life easier!
I might miss something here which exceeds my knowledge (tbh I've only 
average experience with Apache httpd and python), but as long as there's 
nothing pulled in from python when you build Apache (and I'm quite sure 
that's not the case), python is just used as a build tool (for building 
SVN, Apache) and lateron as a script tool (from Apache). It doesn't 
matter how the python executable is build in this regard and which CRT 
it uses. It however matters a lot for the modules you'd pull in with the 
python import statement.


Regards,
Stefan Hett

Re: Compiling svn + httpd for windows python 2.x

[Stefan Hett]

On 6/22/2016 5:30 PM, Cooke, Mark wrote:



-Original Message-
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: 22 June 2016 13:25
To: users@subversion.apache.org
Subject: Re: Compiling svn + httpd for windows python 2.x

On 6/22/2016 2:01 PM, Cooke, Mark wrote:

-Original Message-
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: 22 June 2016 12:38

Hi Mark,


Folks,

We use subversion with Trac behind httpd on Windows Server.  As Trac
is written in "old" Python (2.x), I have had to resort to building
everything from source.  This is not simple and so I thought I would
publish my notes here in case it helps anyone else and in the hope
that if I have made any mistakes, someone will be kind enough to
point them out to me!

~ Mark C

These are my notes for building Apache httpd and subversion for use
with Trac [1].  All of the components need to be built using the same
compiler to avoid run-time issues and, since Trac currently relies on
Python 2.x, that means Visual Studio 2008.

Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN
[1] is built using VS 2015 Update 1 (the upcoming builds will use VS
2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any
issue related to that.

[1] http://www.luke1410.de/typo3/index.php?id=97

I cannot remember specific references now but when I looked into this
before it is because the official 2.x line is compiled using VC9.  When
memory is passed between applications relying on different version of
the CRT then you can end up with hard to diagnose memory corruptions
that eventually cause problems.

This is correct. If you are building a project linking in the CRT, you
should ensure that all DLLs and libraries you build with use the same
CRT. Mixing different CRT versions is unsupported and you will have
undefined behavior. The possibilities for memory corruptions is the most
prominent effect one might observe, but there are other problems/issues
this will cause too.

Digging a bit I found this thread [1] that highlights a similar CRT
issue in python modules such as psycopg2 (which I use for PostGreSQL)
that use the CRT internally...

[1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc

As far as I  skimmed through the thread the problem here is not with
python being compiled using VC9, but rather the module the python script
tries to load (psycopg2, which according to the web seems to be some
postgre-sql-related library) was compiled with a different CRT than the
Apache binaries. That's a general issue, yes, and that's why I don't
distribute the svn-apache modules with MaxSVN, even though they are
built as part of the buildprocess (and utilized for testing). It's
imperative that the CRT for the Apache modules matches the ones used to
build Apache and that only the distributor of the specific Windows
Apache module can ensure.

...and that is my problem: Trac is running under py2.7 (via mod_wsgi from 
httpd) and using psycopg2 to connect to a PostGreSQL backend.  AFAIK, python 
2.7.x windows extensions should be built using VC++ 2008 to match the python 
build, so it is best if I build httpd, mod_wsgi and svn using that compiler too 
(especially as local policy means I need to be able to apply the latest e.g. 
OpenSSL updates as they come out).
Certainly that's working. But since you are recompiling psycopg2 
yourself, why don't you just recompile that then using VS 2015? Or are 
there other python libs involved?


--
Regards,
Stefan Hett

Re: Commit Size Restriction

[Stefan Hett]

Hi Sivaram,

Hi All,

My Subversion Edge is installed in Windows Server.

Is it possible to restrict commit size by repository or whole server?
Haven't done that myself yet, but I take it a way to do so is to add a 
pre-commit hook in combination with some perl script verifying the size 
of the commit doesn't exceed your specified limits.


--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473

Re: svnserve takes too much memory for "svn blame"

[Stefan Hett]

Hi Vincent,
On 7/27/2016 2:36 AM, Vincent Lefevre wrote:

When I do "svn blame" on some file (36972 lines), svnserve takes
more than 800 MB on the server (and is killed due to lack of
memory). So, it seems that svnserve is inefficient in terms of
memory usage (that's at least 22 KB per line!).

svnserve, version 1.8.8 (r1568071)
compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu


Can you try to bump your svnserve version to at least 1.8.15?
Skimming through the changelog suggests several memory related 
tweaks/fixes got in between your 1.8.8 version and the current one (not 
sure whether your particular case has been fixed already, though).


--
Regards,
Stefan Hett

Re: svn merge --record-only and svn log -g

[Stefan Hett]

On 7/27/2016 6:18 PM, Philippe Combes wrote:

Dear Subversion users,

The root cause of my question is the need to automatically process the
commit logs to generate a proper ChangeLog. In order to really list all
modifications done, I have got to use svn log --use-merge-history.
Since this command is based on the property svn:mergeinfo, it lists all
merged revisions, even those which were added by svn merge
--record-only. In other words, it lists some modifications which were
not actually done.
Looking for a solution to this issue, I discovered the existence of the
tool svnmerge.py. If I understand well how it used to work, two lists of
changesets were maintained in subversion properties, so that it kept
track of the changesets blocked. I have noticed that this tool has been
removed from subversion 1.8, yet svn merge appears not to be a
one-to-one replacement for it, since it looses track of the "recorded
only" changesets.
Am I missing something ? Is there any way to segregate the recorded only
changesets from the other with the svn commands ?

I know some of you may answer that using --record-only is bad practice,
but I am working on a project where it is used intensively, and it would
be very hard to rollback on these habits. By the way, my guess is that
as long as the option is provided, the other commands should be
consistent with its behaviour.
Has anyone already met this kind of issue ?

Thanks in advance for any piece of help or advice,
Philippe


Can't provide much help for your case, but the limitation of indicating 
whether some revision was merged or blocked is not new.


Unfortunately, one can't simply say that everything which uses the 
--record-only merge flag would correspond to indicating the revision was 
blocked. It can also mean that the corresponding changes were already 
manually merged (or no longer apply) to the target branch but still 
should be seen/considered as merged. We use this concept quite regularly 
and indicating in general that a --record-only merge would mean a 
revision was not integrated in the target branch would be wrong for 
these cases.


Hence the whole problem is a bit more complicated than it seems to be.

We don't run into this issue, because we do not use the mergeinfo to 
indicate a revision was blocked. In this case we simply don't merge it 
and skip it. For some automated tools we use a specific flag in the 
commit log of revisions which are not meant to be merged into some other 
branch(es). The tools check for these flags in the log and simply skip 
these revisions. Maybe this approach might be usable for you as well?


--
Regards,
Stefan Hett

Re: svnserve takes too much memory for "svn blame"

[Stefan Hett]

On 7/28/2016 2:06 PM, Vincent Lefevre wrote:

On 2016-07-27 11:12:47 +0200, Stefan Hett wrote:

Hi Vincent,
On 7/27/2016 2:36 AM, Vincent Lefevre wrote:

When I do "svn blame" on some file (36972 lines), svnserve takes
more than 800 MB on the server (and is killed due to lack of
memory). So, it seems that svnserve is inefficient in terms of
memory usage (that's at least 22 KB per line!).

svnserve, version 1.8.8 (r1568071)
 compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu


Can you try to bump your svnserve version to at least 1.8.15?

The machine is an Ubuntu 14.04 LTS, and 1.8.8 is the latest version
in this distribution. But I plan to upgrade it to 16.04 LTS in a few
days.
An alternative might be to use the packages provided by Wandisco: 
https://www.wandisco.com/subversion/os/downloads



--
Regards,
Stefan Hett

Re: differences in dump/load/dump cycle

[Stefan Hett]

On 7/31/2016 11:54 PM, Johan Corveleyn wrote:

On Sun, Jul 31, 2016 at 5:55 PM, Stefan  wrote:

Hi,

I went through a long overdue dump/load cycle of our main repository and
am wondering atm about a difference I see when comparing the dump of the
repository with the original dump.

There are a few (at a guess around 20-50) differences of the following
structure (using fc [olddump] [newdump] on Windows):

* svn.dump

Node-path: XRebirth/tags/XR v3.53 RC2 (final)/src/SDKs/DX9SDK
Node-kind: dir
Node-action: change


Revision-number: 193958
* SVN_NEW.DMP

Revision-number: 193958
*


svn.dump was generated using svnadmin 1.8.15 (32-bit).

The dump was then loaded in a new clean repository using svnadmin 1.8.16
(64-bit). svn_new.dmp was then written using svnadmin 1.8.16 (64-bit) as
well.

The original repository was created using SVN 1.7. At some point in the
past (around 2 years ago) the server was upgraded to SVN 1.8 but the
repository was still kept at fsfs format 5. Around a year later the
repository was upgraded to SVN 1.8 (fsfs format 6).

For the new repository fsfs.conf was modified to enable directory and
property deltification.

For the DX9SDK directory (which is reported being different in both
dumps in some revisions) this was originally using externals and at some
point we switched to a direct copy of the folder (not sure whether
that's relevant though).

Is this difference expected? I remember (and Bert mentioned it too) that
there were some cases for different handling of noop-changes. Is that
what explains the difference I see here? If so, I take it that's
expected and does not result in any difference between the repository
states, or does it? JCorvel, would you have an idea?


It's possible that this is a benign change, with no visible effects.
I'm not sure.

The problem I ran into with dump was a new bug in 1.9.0 (fixed in
1.9.3 I think). It was with no-op changes to files, not directories.
This was IMO definitely a bug, because the effect was visible in the
new repository (namely, if you ran 'svn log somepath', where somepath
was a file which had such a no-op change (not possible to create with
the standard svn client btw, but possible with other tools or from a
cvs2svn conversion) in revision R, then revision R would not be listed
as part of somepath's history). It's unclear to me if you can see a
similar loss of "changed-path / history" association.

In my case the change in the dumpfile was a bit different: the
Node-path / Node-kind / Node-action lines were still there, but the
Text-content lines were gone (if you dumped again from the new
repository, the entire block with Node-path etc would be gone). See
http://svn.haxx.se/dev/archive-2015-09/0269.shtml for the entire
(long) discussion, which lead to the bugfix for 1.9.3.
Ah right. Now i recall. Thanks for digging that up. So unless I observe 
any issues, I take it that the change I observed is just a benign one.


--
Regards,
Stefan Hett

Re: differences in dump/load/dump cycle

[Stefan Hett]

On 8/3/2016 3:40 PM, Nico Kadel-Garcia wrote:

On Wed, Aug 3, 2016 at 9:02 AM, Ryan Schmidt
 wrote:

On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:


On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:

On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:


On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:

[dump/load cycles omitted]

Please note. This sort of pernicious bug is why I suggest takeing a
clean export/import when moving to significantly newer versions, or
significantly new project versions, for Subversion repositories. Don't
hurt yourself trying to preserve burdensome, possibly flawed history
you *do not need*.

PLEASE STOP.

Sorry, Ryan, but it needed saying.

No. I understand you have personal experiences with transferring history that 
have led you to prefer not to do so, but most of the Subversion developers and 
other members of this list do not share your views on this matter and I ask you 
again to refrain from working this opinion into every thread on this mailing 
list. The one-time existence of a bug in a feature does not mean that one 
should forever avoid using such a feature even after the bug has been fixed. 
And just because something like transferring history can be difficult to get 
right does not mean that the correct answer for everyone is not to try to do so.

[...]

For new people: I've mentioned doing an svn export/import to a new
repository, instead of an svnadmin dump/load, as a useful migraiton
approach on various occasions for years now. It does discard history,
but it's the cleanest way to dump unwanted content and make a clean
start with a new layout.
And here is where IMHO the flaw in your argument lies: The assumption 
that the data you are discarding is unwanted.
Especially by suggesting new people to discard these information you are 
neglecting the fact that especially this user group is likely to have 
less experience with versioning systems than you or others would have 
and are possibly not in a position to correctly evaluate/realize what 
the impact of the discard will be for their particular case/needs.


You are focusing again on "only" losing the history data (which, I 
believe I've stated before, is IMHO one (if not THE ONE) most important 
data in a version system), while you actually will drop a lot more. 
Especially in the scenario you are now suggesting to perform an 
export/import process over a dump/load process when >upgrading< from one 
to another major subversion version (rather than doing a migration from 
one to another CVS).
In this case you will loose all the additional data SVN uses/collected, 
not only the history. Mostly I'm referring here to the SVN properties. 
Depending on the integration/use of this data, you'd break the 
integration in the infrastructure for example.

It was a potentially useful approach that
hadn't been mentioned for this thread, and  I felt that Stefan (and
others faced with expensive, potentially dangerous svnadmin dump/load
cycles) should keep it in mind for their next migration.
Sorry but I can't share your opinion about svnadmin dump/load being 
potentially dangerous --- at least not in that this is more dangerous 
than a simple export/import with regards to data consistency.

To perform a dump load and then verify the integrity you would do:
dump -> load -> dump -> compare old vs. new dump
If there are differences between the dumps (which really normally 
shouldn't be the case) you determine where the difference are coming 
from. The mailing list will provide you with the necessary support to 
evaluate the impact of the difference you see.


In your export/import approach you would do:
export -> import -> export -> compare old vs. new export
And like with the dump/load/dump approach above, if you see a difference 
between the two exports you would then investigate their cause.


Without the final verification step (in both approaches) you certainly 
can not be more confident that the process worked flawlessly and you 
ended up with what you want.
So once more: I'm sorry, but I really can't even to the slightest share 
your believe in that export/import is anywhere 
better/easier/more-suitable (in the general case) than a dump/load-cycle.


As said before: there might be very specific cases where this might be 
preferable over complete data migration step. But I can't imagine a 
single case where this would be preferable over a dump/load/dump cycle.


--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473

Re: Can svndumpfilter exclude specific named nodes only ?

[Stefan Hett]

Hi Richard,

On 8/3/2016 5:35 PM, Kerry, Richard wrote:


My understanding from the documentation is that svndumpfilter may be 
requested to exclude all nodes whose names have a specific prefix (ie 
this will exclude the named node and all its children).


My specific requirement is to exclude specific named nodes (and not 
their children).  Is it possible to request svndumpfilter to do this ?


The reason for this is that I am using cvs2svn to convert projects 
that need to end up inserting files/nodes within an existing repo 
tree.  In this case the dump file produced will include all nodes down 
from the root to the folder I am specifically interested in adding.  
This includes Root, Root/trunk, Root/tags, Root/branches, which 
already exist ('Root' here being just an example of the name at the 
top of the tree).  When I attempt to load this using svnadmin load it 
aborts as these already exist.  So I need them not to be present in 
the dump (or some significantly different approach).


At the moment I can manually edit them out, as there aren't many, 
which results in the tree as I want it (*), but I wondered if I could 
get svndumpfilter to do the job for me.


Regards,

Richard.

(*) Almost, but I'll ask about that separately.


Atm I can think of the following way (hope I got your requirements correct):
split up the load into separate chunks.
1. import everything excluding the whole Root-node - using dumpfilter 
exclude
2. import the separate child-nodes (aka: Root/branches/) using 
dumpfilter include in combination with svnadmin load --parent-dir [Dir] 
(aka: svnadmin load --parentdir [Dir]


Would that solve your case?

--
Regards,
Stefan Hett

Re: Recover broken local repo by a virus

[Stefan Hett]

Hi,
On 8/4/2016 8:25 PM, bluePlayer wrote:

I was yesterday attacked by Cerber Ransomware, encrypting my files and asking
money to decrypt.

Well I did not fall for that trick, instead i have my SVN server installed
on separate machine which is most of the time turned off.

I could create new forder and checkout there but how can i fix my current
local repository, as I have unversioned files which I might use later?

Also i have lot of files which would take a day to checkout locally.

Which commands should I run?

Currently my folder is not viewed as a SVN repository, it just shows "SVN
upgrade working copy" and Tortoise SVn menu items.

If the ransomware encrypted your whole working copy then all locally 
added files and changed data which wasn't committed to the repository 
cannot be restored via the repository. Unless you have another backup 
somewhere lying around, you'll have to find means to decrypt the files 
or accept the fact that these changes/files are lost and you need to 
somehow recreate them.


If you are at that point where the ransomware did indeed encrypt your 
local WC, you should really do a fresh checkout of your files from the 
repo. Trying to restore anything from the local working copy is 
pointless IMHO. A checkout might take long, but then you are sure it's 
in a proper/usable state.


If you haven't upgraded TSVN from <= 1.7 to a later version and the WC 
was accessible to you before the ransomware hit you, it's most likely 
showing the upgrade dialog now because it (incorreclty) believes (due to 
the encrypted files) that the working copy format is of an older format.


--
Regards,
Stefan Hett

Re: Issue report

[Stefan Hett]

Hi Mike,

On 8/10/2016 10:31 PM, Faynberg, Mike wrote:


Dear Madam/Sir,

I was trying to update the TortoiseSVN on my Win7/32-bit computer. The 
installer I have is 1.9.4 Build 27285 (see the screenshot below):



 [..]

However upon the installation – and rebooting the computer, the 
installed software’s properties report a different (earlier) version 
and therefore still suggest updating (see below).



 [..]

What could go wrong?

I will greatly appreciate your help.

In the case I am sending this report to a wrong address… first of all 
accept my apologies! Then I will even more grateful if you suggest me 
a right way to submit it.



This is indeed the wrong list. Since this is a TSVN specific question, 
you should post the question on TSVN's user list. See: 
https://tortoisesvn.net/community.html


--
Regards,
Stefan Hett

Re: FW: svn password -gnome- keyring

[Stefan Hett]

Hi Ivan,

Hello,
I have once made a password, after ran `svn udpdate`, it required me 
for a password keyring, so I made one.
I noted it somewhere, now it's lost and I can't work with svn anymore 
because I can't update anything. (it's not about the project host 
password).
I exported the working copy to another location, checkout, when update 
it asked again.

How could I reset/remove/troubleshoot it?

What is it for, anyway?

Have a great time.

Saudações,
Ivan de Miranda



To: ivang...@hotmail.com
From: supp...@beanstalkapp.com
Subject: Re: I'm confused about how something works
Date: Mon, 4 Jul 2016 13:48:48 +

Hi Ivan,

Thanks for writing in. Hope you had a pleasant weekend. :-)

Unfortunately, I'm no Lubuntu expert, but I did find something that 
could explain the dialog box you're seeing.


See: 
http://askubuntu.com/questions/184266/what-is-unlock-keyring-and-how-do-i-get-rid-of-it.


It sounds like this is a way to store password and encryption keys. 
I'd recommend keeping that password somewhere safe, in case you come 
across it again. I hope that helps but please let me know if you have 
any other questions.


Thanks!

--
Ashley Harpp
Customer Success, Wildbit <http://wildbit.com/>
Beanstalk <http://beanstalkapp.com/>, DeployBot 
<http://deploybot.com/>, Postmark <https://postmarkapp.com/>



How would you rate my reply?
Top Notch 
<https://secure.helpscout.net/satisfaction/87432461/record/585529611/1/> 
Fair 
<https://secure.helpscout.net/satisfaction/87432461/record/585529611/2/> 
Not Good 
<https://secure.helpscout.net/satisfaction/87432461/record/585529611/3/>

{#HS:222685451-212706#}
On Sun, Jul 3, 2016 at 1:24 PM EDT, Ivan GM  wrote:

Hello Beanstalk!
I checked out a beanstalk repository at terminal - on a lubuntu -
and inserted my username and password as usual. When I succeed to
do that, prompted a dialog box with something about a key ring
password, don't remember the message. So I made one and different
from my beanstalk password. What is that ? Should I keep it ? When
I will use it again?



This is a bit off topic here. As Ivan already proposed, most likely the 
password dialog you are seeing is the dialog box for getting access to 
your keyring. I'm not familiar with lubuntu, but normally there's no way 
to restore a keyring for which you've lost your password, afaik.


SVN seems to be setup on the server to require some means of 
authentication. You should get in touch with your administrator to 
determine the means to get access to your repository again (normally, 
he'd reset your credentials so you can reset your key pair or get 
alternative means to authenticate yourself).


--
Regards,
Stefan Hett

Re: A couple thousand mp3 files (this is not spam I swear )

[Stefan Hett]

Hi,
On 8/13/2016 2:56 AM, Adam Jensen wrote:

My primary concerns are related to any potential file corruption, any
data duplication, and/or any excessive network or disk I/O (other than
the expected load of direct data communication).
Just to have this mentioned: Be aware that the working copy (aka: the 
checked out data of the repository) will have a 2x storage requirement 
on the data since it will keep a copy of the pristine version of the 
file in addition to the "actual" file.
If this is a concern for your use-case, you could export the files and 
only use a working copy in cases where you need to commit or reorder files.


To clarify: This is purely a client side storage requirement. It does 
not apply to the storage requirements on the server side.


--
Regards,
Stefan Hett

Re: Permissions need for deletion

[Stefan Hett]

On 8/25/2016 11:13 AM, Ivan Zhakov wrote:

On 25 August 2016 at 11:50, Vacelet, Manuel  wrote:

On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
 wrote:

oops I hit shift+enter :/
see my message below

On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
 wrote:

Hi all,

I got a machine that was bumped from 1.6.x (centos6 default) to 1.8.16
(thanks wandisco!).
I identified a change of behaviour but failed to find an explanation in
book or change log.

Here we go, given a SVNAccessFile like:


->8-
[groups]
members = alice
admin = bob

[/]
* =
@members = r
@admin = rw

[/tags]
@members = rw
-8<-

WIth svn 1.6, as alice, I cannot rm /tags
Whereas with svn 1.8 I now can.

Is this detailed somewhere ?


Fun fact: the behaviour change also depending on the version of svn client
used.
For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 & svn 1.9
client but not with svn 1.6.
I failed to find in 1.7 release note something that explains this change.


It was bug in Subversion 1.7 that remove operation requires access to
repository root:
SVN-4219: svn delete fails with "403 Forbidden" if root is not readable [1]

This problem was fixed in Subversion 1.8. It's not server-side change.
It was client problem accessing repository root, while it's not
needed.

[1] https://issues.apache.org/jira/browse/SVN-4219
According to SVN-4219 the issue was present in 1.7 and also fixed in 
1.7, or is the JIRA issue record wrong in this regards?
Also I take it that with Manuel's report here, the issue was not only 
present in 1.7 but also existed on 1.6. Otherwise I think I'm missing 
something.


--
Regards,
Stefan Hett

Re: Permissions need for deletion

[Stefan Hett]

On 8/25/2016 11:35 AM, Ivan Zhakov wrote:

On 25 August 2016 at 12:30, Stefan Hett  wrote:

On 8/25/2016 11:13 AM, Ivan Zhakov wrote:

On 25 August 2016 at 11:50, Vacelet, Manuel 
wrote:

On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
 wrote:

oops I hit shift+enter :/
see my message below

On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
 wrote:

Hi all,

I got a machine that was bumped from 1.6.x (centos6 default) to 1.8.16
(thanks wandisco!).
I identified a change of behaviour but failed to find an explanation in
book or change log.

Here we go, given a SVNAccessFile like:


->8-
[groups]
members = alice
admin = bob

[/]
* =
@members = r
@admin = rw

[/tags]
@members = rw
-8<-

WIth svn 1.6, as alice, I cannot rm /tags
Whereas with svn 1.8 I now can.

Is this detailed somewhere ?


Fun fact: the behaviour change also depending on the version of svn
client
used.
For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 & svn
1.9
client but not with svn 1.6.
I failed to find in 1.7 release note something that explains this change.


It was bug in Subversion 1.7 that remove operation requires access to
repository root:
SVN-4219: svn delete fails with "403 Forbidden" if root is not readable
[1]

This problem was fixed in Subversion 1.8. It's not server-side change.
It was client problem accessing repository root, while it's not
needed.

[1] https://issues.apache.org/jira/browse/SVN-4219

According to SVN-4219 the issue was present in 1.7 and also fixed in 1.7, or
is the JIRA issue record wrong in this regards?
Also I take it that with Manuel's report here, the issue was not only
present in 1.7 but also existed on 1.6. Otherwise I think I'm missing
something.


The SVN-4219 is duplicate issue for SVN-4332.
Right, but what gets me confused there is that SVN-4332 explicitly 
states: "The 1.6/neon client can delete /A/B [...] but the 1.7/neon 
client fails[...]". That suggests to me the issue wouldn't be present 
with 1.6 but only with 1.7.0-1.7.9.
This would be contradicting to the OP report that removing the file is 
possible with his 1.6 client.


I take it, it's not worth continuing checking the history here, since 
the unquestionable conclusion is is that the behavior the OP sees in 
1.7+ is the correct one by design (aka: having write access to a path 
allows also to delete that path - FWIW: That's not quite what I'd 
expect, since I would assume that I also need write access to the parent 
path in order to remove a directory/path since that's also the access I 
require to create that directory/path).


--
Regards,
Stefan Hett

Re: Permissions need for deletion

[Stefan Hett]

On 8/25/2016 11:52 AM, Stefan Hett wrote:

On 8/25/2016 11:35 AM, Ivan Zhakov wrote:

On 25 August 2016 at 12:30, Stefan Hett  wrote:

On 8/25/2016 11:13 AM, Ivan Zhakov wrote:
On 25 August 2016 at 11:50, Vacelet, Manuel 


wrote:

On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
 wrote:

oops I hit shift+enter :/
see my message below

On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
 wrote:

Hi all,

I got a machine that was bumped from 1.6.x (centos6 default) to 
1.8.16

(thanks wandisco!).
I identified a change of behaviour but failed to find an 
explanation in

book or change log.

Here we go, given a SVNAccessFile like:


->8-
[groups]
members = alice
admin = bob

[/]
* =
@members = r
@admin = rw

[/tags]
@members = rw
-8<-

WIth svn 1.6, as alice, I cannot rm /tags
Whereas with svn 1.8 I now can.

Is this detailed somewhere ?


Fun fact: the behaviour change also depending on the version of svn
client
used.
For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 & 
svn

1.9
client but not with svn 1.6.
I failed to find in 1.7 release note something that explains this 
change.



It was bug in Subversion 1.7 that remove operation requires access to
repository root:
SVN-4219: svn delete fails with "403 Forbidden" if root is not 
readable

[1]

This problem was fixed in Subversion 1.8. It's not server-side change.
It was client problem accessing repository root, while it's not
needed.

[1] https://issues.apache.org/jira/browse/SVN-4219
According to SVN-4219 the issue was present in 1.7 and also fixed in 
1.7, or

is the JIRA issue record wrong in this regards?
Also I take it that with Manuel's report here, the issue was not only
present in 1.7 but also existed on 1.6. Otherwise I think I'm missing
something.


The SVN-4219 is duplicate issue for SVN-4332.
Right, but what gets me confused there is that SVN-4332 explicitly 
states: "The 1.6/neon client can delete /A/B [...] but the 1.7/neon 
client fails[...]". That suggests to me the issue wouldn't be present 
with 1.6 but only with 1.7.0-1.7.9.
This would be contradicting to the OP report that removing the file is 
possible with his 1.6 client.
Of cause this should read: "[...] OP's report that removing the file is 
*NOT* possible with his 1.6 client.


I take it, it's not worth continuing checking the history here, since 
the unquestionable conclusion is is that the behavior the OP sees in 
1.7+ is the correct one by design (aka: having write access to a path 
allows also to delete that path - FWIW: That's not quite what I'd 
expect, since I would assume that I also need write access to the 
parent path in order to remove a directory/path since that's also the 
access I require to create that directory/path).



--
Regards,
Stefan Hett

Re: How to remove a revision from the achieve

[Stefan Hett]

On 8/29/2016 5:38 AM, Eckard Klotz wrote:


Hello everybody.

Unfortunately I have added something wrong into the my svn archive. I 
know that it is possible how to remove it from the users content. But 
the file is still part of the archive and I want to undo the adding of 
the file.


  * Is it possible to remove it from the whole archive again by
deleting the last revisions?
  * Or it is possible to copy an archive just until a specific
revision with a command like hotcopy?

Best regards,

Eckard Klotz.

Here's some nice blog entry with the basics on how to do that: 
http://blog.christosoft.de/2012/02/subversion-svn-permanently-remove-files-from-repository-history/



--
Regards,
Stefan Hett

Re: export control Subversion ECCN

[Stefan Hett]

Hi Brendan,
On 8/30/2016 12:16 PM, Kelleher, Brendan T Export License Required - US 
UTRC-Ireland wrote:


Hello,

Can anyone tell me what the ECCN of subversion

I am trying to find out the ECCN of the Subversion product that I 
believe apache now own.


Vendor:* CollabNet

Title:* Subversion

Version:* 1.9.4

Thanks

Brendan


see: http://www.apache.org/licenses/exports/
"Each ASF product is classified 
<http://www.bis.doc.gov/licensing/exportingbasics.htm> with an Export 
Control Classification Number (ECCN) if it is believed to correspond to 
an entry in the Commerce Control List (CCL) and subject to the EAR. All 
ASF software is published in a publicly available source code form. 
Since publicly available software is only subject to the EAR 
<http://www.access.gpo.gov/bis/ear/txt/734.txt> when it is classified as 
ECCN 5D002 or 5D992 <http://www.access.gpo.gov/bis/ear/txt/ccl5-pt2.txt> 
, all ASF software product versions that do not fit those two 
classifications are noted as ECCN "n/a" (not applicable) or not included 
in the matrix."


That said: SVN is ECCN "n/a" as far as I know.

However, CollabNet's Subversion distribution incorporates other 
dependencies which might impose some ECCN classification (most likely 
OpenSSL and/or Apache are likely dependencies and to my knowledge in an 
end product they result in an ECCN classification then for you).


--
Regards,
Stefan Hett, Developer/Administrator

EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473