Checkout fails on large repository

[Thomas]

Hello

I have a fairly large repository (~75 GB) containing mostly binary
files (photos).
When I try to do a checkout, it fails after checking out about 7.5 GB.

On the client, this error is shown:
svn: REPORT of '/svn/photo/!svn/vcc/default': Could not read response
body: Secure connection truncated (https://svn)
svn co https://svn/svn/photo tdn-photos  1635,48s user 289,84s system
8% cpu 6:03:45,40 total

On the server, this error is written in the log:
==> /data/www/virtual/svn/log/error.log <==
[Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Provider
encountered an error while streaming a REPORT response.  [500, #0]
[Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] A failure
occurred while driving the update report editor  [500, #103]
[Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Error writing
base64 data: Software caused connection abort  [500, #103]

==> /data/www/virtual/svn/log/access.log <==
10.0.0.4 - tdn [11/Aug/2011:18:38:35 +0200] "REPORT
/svn/photo/!svn/vcc/default HTTP/1.1" 200 4094599482 "-" "SVN/1.6.12
(r955767) neon/0.29.5"


I have tried turning off SSL and thus using regular HTTP instead of HTTPS.
This did not fix the problem. I receive the same error.

I hope you can help me fix this problem.


Client specs:
RAM: 1 GB
CPU: Intel(R) Atom(TM) CPU N270   @ 1.60GHz
Disk: 250 GB external harddisk connected via USB.
Filesystem: ext3 (encrypted via LUKS, but this should be transparent to svn)


Server:
RAM: 256 MB
CPU: Geode(TM) Integrated Processor by AMD PCS
Disk: 1000 GB external harddisk connected via USB.
Filesystem: ext3 (encrypted via LUKS, but this should be transparent to svn)


Med venlig hilsen/Kind regards
Thomas

Re: Checkout fails on large repository

[Thomas]

I would like to add some software specs for client and server:

Server:
OS: Debian GNU/Linux, squeeze
Subversion: 1.6.12dfsg-6
Apache: 2.2.16-6+squeeze

Client:
OS: Ubuntu 11.04
Subversion: 1.6.12dfsg-4ubuntu2.1


Furhter info:
There is only one user accessing the repository during checkout. So
issues caused by multiple users accessing it can be eliminated.
It seems to be the same place it fails every time. That is, the same path.
I am currently trying to checkout this path alone in a tmp dir to see
if it works. The checkout takes some some time though so I will post
the result later. If you already have some ideas as to what is wrong,
I will appreciate your suggestions.
Thanks.


Med venlig hilsen/Kind regards
Thomas

Re: Checkout fails on large repository

[Thomas]

2011/8/16 Thomas :
> There is only one user accessing the repository during checkout. So
> issues caused by multiple users accessing it can be eliminated.
> It seems to be the same place it fails every time. That is, the same path.
> I am currently trying to checkout this path alone in a tmp dir to see
> if it works. The checkout takes some some time though so I will post
> the result later.

I just checked. The checkout of this path went fine. Total size of the
WC of this path is 575 MB.

Med venlig hilsen/Kind regards
Thomas

Re: Checkout fails on large repository

[Thomas]

2011/8/16 Stefan Sperling :
> Does your Apache HTTPD Server use keep-alive?
> http://httpd.apache.org/docs/2.0/mod/core.html#keepalive
>
> Try to increase the KeepAliveTimeout option in your Apache
> configuration:
> http://httpd.apache.org/docs/2.0/mod/core.html#keepalivetimeout
>
> The default is 15 seconds. For large checkouts, the svn client could
> be busy for longer than 15 seconds before it sends another request.

I have now enabled KeepAlive and set Timeout and KeepAliveTimeout to 900.
We'll see how it goes.

Re: Checkout fails on large repository

[Thomas]

2011/8/16 Thomas :
> I have now enabled KeepAlive and set Timeout and KeepAliveTimeout to 900.
> We'll see how it goes.

Right now it has checked out 32 GB, this is a new record :)
It is still working, but enabling keepalive and increasing timeouts
seems to be working.
I will write again, if it fails.


Med venlig hilsen/Kind regards
Thomas

Data lost in a subversion repository

[thomas]

Dear ladies and gentlemen,

my name is Thomas Riller, I am working at the technical university of 
Munich.


I am sorry, that I directly contact you.

We have a problem (self made) with a subversion repository.

The repository was stored at a personal directory and is damaged. This 
means, some revision files are missing.


The repository uses the fsfs format 6 layout sharded 1000.

We have a working copy of the project in the last version.

Do you know any possibility, to extract datas from the /revs directory. 
We do not expect to get all datas back, but we would be happy, to get 
some diffs back from this files.


Best Regards

Thomas Riller

client crash on merge --reintegrate

[Becker, Thomas]

Hello,

 

When trying to reintegrate a branch into trunk the SVN client (version
1.6.15) crashed. It asked me to send the log file, so here it is.

 

The server had version 1.6.5, upgrading the server to 1.6.15 didn't
help.

 

On the other hand, a client with version 1.6.12 didn't crash.

 

Regards,

  Thomas

 

 

Process info:

Cmd line: svn merge --dry-run --reintegrate
https://localhost:8443/svn/FMCG

Version:  1.6.15 (r1038135), compiled Nov 24 2010, 15:10:31

Platform: Windows OS version 5.1 build 2600 Service Pack 3

 

Exception: ACCESS_VIOLATION

 

Registers:

eax= ebx=032f1640 ecx=000354ac edx= esi=0331a048
edi=0331a064

eip=100194c6 esp=0013fc34 ebp= efl=00210246

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=

 

Stacktrace:

#1  0x100194c6 in svn_client_merge_reintegrate ()

 

 

Loaded modules:

0x0040  C:\Program Files\Dev\Subversion Client\svn.exe
(1.6.15.55095, 155648 bytes)

0x7c90  C:\WINDOWS\system32\ntdll.dll (5.1.2600.5755, 729088 bytes)

0x7c80  C:\WINDOWS\system32\kernel32.dll (5.1.2600.5781, 1007616
bytes)

0x6eec  C:\Program Files\Dev\Subversion Client\libapr-1.dll
(1.4.2.0, 139264 bytes)

0x77dd  C:\WINDOWS\system32\advapi32.dll (5.1.2600.5755, 634880
bytes)

0x77e7  C:\WINDOWS\system32\rpcrt4.dll (5.1.2600.6022, 602112 bytes)

0x77fe  C:\WINDOWS\system32\secur32.dll (5.1.2600.5834, 69632 bytes)

0x71ab  C:\WINDOWS\system32\ws2_32.dll (5.1.2600.5512, 94208 bytes)

0x77c1  C:\WINDOWS\system32\msvcrt.dll (7.0.2600.5512, 360448 bytes)

0x71aa  C:\WINDOWS\system32\ws2help.dll (5.1.2600.5512, 32768 bytes)

0x71a5  C:\WINDOWS\system32\mswsock.dll (5.1.2600.5625, 258048
bytes)

0x7c9c  C:\WINDOWS\system32\shell32.dll (6.0.2900.6018, 8482816
bytes)

0x77f1  C:\WINDOWS\system32\gdi32.dll (5.1.2600.5698, 299008 bytes)

0x7e41  C:\WINDOWS\system32\user32.dll (5.1.2600.5512, 593920 bytes)

0x77f6  C:\WINDOWS\system32\shlwapi.dll (6.0.2900.5912, 483328
bytes)

0x1000  C:\Program Files\Dev\Subversion Client\libsvn_client-1.dll
(1.6.15.55095, 204800 bytes)

0x6ee6  C:\Program Files\Dev\Subversion Client\libaprutil-1.dll
(1.3.9.0, 192512 bytes)

0x6ee5  C:\Program Files\Dev\Subversion Client\libapriconv-1.dll
(1.2.1.0, 36864 bytes)

0x0034  C:\Program Files\Dev\Subversion Client\libsvn_delta-1.dll
(1.6.15.55095, 90112 bytes)

0x0043  C:\Program Files\Dev\Subversion Client\libsvn_subr-1.dll
(1.6.15.55095, 716800 bytes)

0x7678  C:\WINDOWS\system32\shfolder.dll (6.0.2900.5512, 36864
bytes)

0x774e  C:\WINDOWS\system32\ole32.dll (5.1.2600.6010, 1302528 bytes)

0x77a8  C:\WINDOWS\system32\crypt32.dll (5.131.2600.5512, 610304
bytes)

0x77b2  C:\WINDOWS\system32\msasn1.dll (5.1.2600.5875, 73728 bytes)

0x0036  C:\Program Files\Dev\Subversion Client\libsvn_diff-1.dll
(1.6.15.55095, 53248 bytes)

0x0037  C:\Program Files\Dev\Subversion Client\libsvn_ra-1.dll
(1.6.15.55095, 520192 bytes)

0x004e  C:\Program Files\Dev\Subversion Client\libsvn_repos-1.dll
(1.6.15.55095, 139264 bytes)

0x0051  C:\Program Files\Dev\Subversion Client\libsvn_fs-1.dll
(1.6.15.55095, 135168 bytes)

0x0054  C:\Program Files\Dev\Subversion Client\libeay32.dll
(1.0.0.2, 1286144 bytes)

0x0068  C:\Program Files\Dev\Subversion Client\ssleay32.dll
(1.0.0.2, 245760 bytes)

0x006c  C:\Program Files\Dev\Subversion Client\libsasl.dll
(2.1.23.0, 77824 bytes)

0x006e  C:\Program Files\Dev\Subversion Client\libsvn_wc-1.dll
(1.6.15.55095, 217088 bytes)

0x7639  C:\WINDOWS\system32\imm32.dll (5.1.2600.5512, 118784 bytes)

0x773d
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df
_6.0.2600.6028_x-ww_61e65202\comctl32.dll (6.0.2900.6028, 1060864 bytes)

0x5d09  C:\WINDOWS\system32\comctl32.dll (5.82.2900.6028, 630784
bytes)

0x5ad7  C:\WINDOWS\system32\uxtheme.dll (6.0.2900.5512, 229376
bytes)

0x7472  C:\WINDOWS\system32\MSCTF.dll (5.1.2600.5512, 311296 bytes)

0x71f8  C:\WINDOWS\system32\security.dll (5.1.2600.5512, 16384
bytes)

0x77c7  C:\WINDOWS\system32\msv1_0.dll (5.1.2600.5876, 151552 bytes)

0x7679  C:\WINDOWS\system32\cryptdll.dll (5.1.2600.5512, 49152
bytes)

0x76d6  C:\WINDOWS\system32\iphlpapi.dll (5.1.2600.5512, 102400
bytes)

0x6800  C:\WINDOWS\system32\rsaenh.dll (5.1.2600.5507, 221184 bytes)

0x754d  C:\WINDOWS\system32\cryptui.dll (5.131.2600.5512, 524288
bytes)

0x5b86  C:\WINDOWS\system32\netapi32.dll (5.1.2600.5694, 348160
bytes)

0x7712  C:\WINDOWS\system32\oleaut32.dll (5.1.2600.5512, 569344
bytes)

0x77c0  C:\WINDOWS\system32\version.dll (5.1.2600.5512, 32768 bytes)

0x3d93  C:\WINDOWS\system32\wininet.dll (7.0.6000.17091, 856064
bytes)

0x0117  C:\WINDOWS\system32\normaliz.dll (6.0.5441.0, 36864 bytes)

0x3dfd  C:\WINDOWS\system32\iertutil.dll (7.0.6000.17091, 282624
bytes)

0x76c3  C:\WINDOWS\system32\wintrust.dll (5.131.2600.5922, 188416
bytes)

0x7

Re: client crash on merge --reintegrate

[Becker, Thomas]

Hello,

 

It seems that the crash is related to improper preconditions for the
reintegration, don't know what SVN wants to tell me there:

 

client 1.6.15 crashes

client 1.6.13 crashes

client 1.6.12 doesn't crash but outputs an error message:

> cd trunk_wc

>svn merge --dry-run --reintegrate https://.../branches/... --accept
postpone

  svn: Reintegrate can only be used if revisions 255131 through 265563
were previously merged from https://.../trunk to the reintegrate source,
but this is not the case:

.../branches/...

  Missing ranges: /.../trunk:264250-265543

.../branches/...

  Missing ranges: /.../branches/...:260111-260850

.../branches/...

  Missing ranges: /.../branches/...:213101-260850

.../branches/...

  Missing ranges: /.../branches/...:260826-260850

  Missing ranges: /.../trunk/...:260811,260933

.../branches/...

  Missing ranges: /.../branches/...:260826-260850

  Missing ranges: /.../trunk/...:260805-260811,260933

.../branches/...

  Missing ranges: /.../branches/...:260826-260850

  Missing ranges: /.../trunk/...:260805-260811,260933

.../branches/...

  Missing ranges: /.../branches/...:174322-214515

  Missing ranges: /.../trunk/...:103707-174319

  Missing ranges: /.../branches/...:215928-236665

  Missing ranges: /.../branches/...:236669-250022

  Missing ranges: /.../branches/...:250348-260850

  Missing ranges: /.../trunk/...:260933

 

Regards,

  Thomas

 

--

 

Thomas Becker

 

Software Development, Torex

T: +49 (0)30 49901-0 E: thomas.bec...@torex.com

 

 

Torex Retail Solutions GmbH, Salzufer 8, D-10587 Berlin

T: +49 (0)30 49901-0  F: +49 (0)30 49901-139  www.torex.de

____

Von: Becker, Thomas 
Gesendet: Mittwoch, 12. Januar 2011 16:58
An: 'users@subversion.apache.org'
Betreff: client crash on merge --reintegrate

 

Hello,

 

When trying to reintegrate a branch into trunk the SVN client (version
1.6.15) crashed. It asked me to send the log file, so here it is.

 

The server had version 1.6.5, upgrading the server to 1.6.15 didn't
help.

 

On the other hand, a client with version 1.6.12 didn't crash.

 

Regards,

  Thomas

 

 

Process info:

Cmd line: svn merge --dry-run --reintegrate
https://localhost:8443/svn/FMCG

Version:  1.6.15 (r1038135), compiled Nov 24 2010, 15:10:31

Platform: Windows OS version 5.1 build 2600 Service Pack 3

 

Exception: ACCESS_VIOLATION

 

Registers:

eax= ebx=032f1640 ecx=000354ac edx= esi=0331a048
edi=0331a064

eip=100194c6 esp=0013fc34 ebp= efl=00210246

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=

 

Stacktrace:

#1  0x100194c6 in svn_client_merge_reintegrate ()

 

 

Loaded modules:

0x0040  C:\Program Files\Dev\Subversion Client\svn.exe
(1.6.15.55095, 155648 bytes)

0x7c90  C:\WINDOWS\system32\ntdll.dll (5.1.2600.5755, 729088 bytes)

0x7c80  C:\WINDOWS\system32\kernel32.dll (5.1.2600.5781, 1007616
bytes)

0x6eec  C:\Program Files\Dev\Subversion Client\libapr-1.dll
(1.4.2.0, 139264 bytes)

0x77dd  C:\WINDOWS\system32\advapi32.dll (5.1.2600.5755, 634880
bytes)

0x77e7  C:\WINDOWS\system32\rpcrt4.dll (5.1.2600.6022, 602112 bytes)

0x77fe  C:\WINDOWS\system32\secur32.dll (5.1.2600.5834, 69632 bytes)

0x71ab  C:\WINDOWS\system32\ws2_32.dll (5.1.2600.5512, 94208 bytes)

0x77c1  C:\WINDOWS\system32\msvcrt.dll (7.0.2600.5512, 360448 bytes)

0x71aa  C:\WINDOWS\system32\ws2help.dll (5.1.2600.5512, 32768 bytes)

0x71a5  C:\WINDOWS\system32\mswsock.dll (5.1.2600.5625, 258048
bytes)

0x7c9c  C:\WINDOWS\system32\shell32.dll (6.0.2900.6018, 8482816
bytes)

0x77f1  C:\WINDOWS\system32\gdi32.dll (5.1.2600.5698, 299008 bytes)

0x7e41  C:\WINDOWS\system32\user32.dll (5.1.2600.5512, 593920 bytes)

0x77f6  C:\WINDOWS\system32\shlwapi.dll (6.0.2900.5912, 483328
bytes)

0x1000  C:\Program Files\Dev\Subversion Client\libsvn_client-1.dll
(1.6.15.55095, 204800 bytes)

0x6ee6  C:\Program Files\Dev\Subversion Client\libaprutil-1.dll
(1.3.9.0, 192512 bytes)

0x6ee5  C:\Program Files\Dev\Subversion Client\libapriconv-1.dll
(1.2.1.0, 36864 bytes)

0x0034  C:\Program Files\Dev\Subversion Client\libsvn_delta-1.dll
(1.6.15.55095, 90112 bytes)

0x0043  C:\Program Files\Dev\Subversion Client\libsvn_subr-1.dll
(1.6.15.55095, 716800 bytes)

0x7678  C:\WINDOWS\system32\shfolder.dll (6.0.2900.5512, 36864
bytes)

0x774e  C:\WINDOWS\system32\ole32.dll (5.1.2600.6010, 1302528 bytes)

0x77a8  C:\WINDOWS\system32\crypt32.dll (5.131.2600.5512, 610304
bytes)

0x77b2  C:\WINDOWS\system32\msasn1.dll (5.1.2600.5875, 73728 bytes)

0x0036  C:\Program Files\Dev\Subversion Client\libsvn_diff-1.dll
(1.6.15.55095, 53248 bytes)

0x0037  C:\Program Files\Dev\Subversion Client\libsvn_ra-1.dll
(1.6.15.55095, 520192 bytes)

0x004e  C:\Program Files\Dev\Subversion Client\libsvn_rep

RE: Windows over linux

[Thomas Loy]

Agreed, but another benefit of any Unix OS is the ability to use symbolic 
links.  They aren't in Windows and they give some added stability to some 
things you may do such as link a specific version name to a more generic name 
you use in the build script.  This makes maintenance long term a lot easier.  
I'm working on a bunch of scripts right now where we had a version specific 
taskdef jar that I'm now using a symlink to create a generic jar name -- so I 
won't have to edit all the taskdef jar names in the scripts again.

Cheers,

Tom

Thomas Loy
Sysops - Build Engineer
Cbeyond
320 Interstate North Pkwy.
Suite 300
Atlanta, GA  30339
(678) 370-2383
thomas@cbeyond.net


-Original Message-
From: Chris Albertson [mailto:albertson.ch...@gmail.com]
Sent: Tuesday, January 25, 2011 11:56 AM
To: Oliver Marshall
Cc: users@subversion.apache.org
Subject: Re: Windows over linux

On Tue, Jan 25, 2011 at 12:43 AM, Oliver Marshall
 wrote:
> Hi,
>
>
>
> As far as subversion is concerned, is there any reason to go for one OS over
> another when setting up a new subversion server? Are any of the hooks or
> features OS dependant?

Choose the OS that is the best stabilty nd the best file system
performance.  That would be Solaris and ZFS.  But more people know
about Linux so that is what they recommend.   But do think about the
file system and how you will be able to continue running and not have
to re-boot or power down if a drive fails.  Lots of ways to handle
that.  Last I looked (a while back) Windows required a re-boot after
almost any trivial change of settings.  It would be good if you could
add additional storage space or even swap out drive without a re-boot.
 ZFS is made just for that.  Windows is not as nice for remote access.
 Again because you need to re-boot and of course the re-boot kills the
remote link.
--
=
Chris Albertson
Redondo Beach, California

Strange tree conflict problem

[Thomas Börkel]

HI!

I am merging the diff between branch A and branch B to a working copy of
branch C.

Now I get a tree conflict for some files. TortoiseSVN 1.6.12 says "The
last merge operation tried to delete/move/rename the file 'name', but it
was already edited."

I also get a tree conflict, if I do the merge with the svn commandline
client 1.6.12.

The strange thing is:
When I do a diff between the file in branch A and in branch B, it is not
different at all. So what does it want to merge?

Also, the file does exist in the target working copy and it is not
locally modified.

Our server runs svn 1.6.13.

Any help would be greatly appreciated.

Thomas

problem with mutated vowel in log-message-contents

[Thomas STEININGER]

i need a tip to solve my problem with log-messages in our 
subversion-repository. (see the mail-conversation with the tortoisesvn 
team below).
there are message that contain mutated vowel and i need to find all them 
and correct them.
f.e. i want to replace 'übergabe' by 'uebergabe' or if this is to 
difficult only by '_bergabe'.

can anybode give me tips / commands to do that or probably there is an 
tool (because the problem was already solved for another user)?

thanks for help
-thomas

Mails with TortoiseSvn-Team:
>>>>
>>>> Hello i have an really *big problem *using tortoise-svn.
>>>>
>>>> The same problem has - by the way - eclipse-subversive with
>>>> javahl-connector, but not with svnkit-connector.
>>>>
>>>> if i try to show the logs of ein entry/file/.. in tortoisesvn where 
the
>>>> log-messages contain a mutated vowel (german: deutscher umlaut)
>>>> then it brings an failure msg:
>>>>
>>>> and then it shows
>>>>
>>>> instead of the messages.
>>>>
>>>> can anybody help?
>>>> Thomas
>>>
>>>log messages must be in utf8 encoding. That's a requirement of the svn 
>>>library. If they're not, then anything can happen. For example if you 
>>>access the repository with http(s), then those messages have to be sent 

>>>in an xml response, and non-utf8 strings result in invalid xml.
>>>
>>>When you commit with TSVN, TSVN ensures the encoding. But it might be 
>>>that other svn clients have a bug and don't properly encode the log 
>>>messages. In that case you have to fix the repository on the server 
>>>directly using the command line tools (svnadmin).
>>>
>>>Stefan 
>>we already want to correct the log-messages, but we did not find an way 
to 
>>get all the log messages with failures and then to correct them.
>>is there a known way - a tip to help us?
>>
>>thanks
>>thomas 
>>
>You have to ask for help with this on the Subversion users list. This is 
>an issue with the server/repository, not with TSVN and you'll get much 
>more help about this over there.
>
>Stefan 
>



Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschließlich 
Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen über dieses Medium 
nicht ausgetauscht werden.

Correspondence with a.m. sender via e-mail is only for information purposes. 
This medium is not to be used for the exchange of legally-binding 
communications.

Antwort: Re: problem with mutated vowel in log-message-contents

[Thomas STEININGER]

do i really understand, that i have to execute this:
propedit --editor-cmd 'sed --flags'
on a file? on all urls that are in my svn-repository?
or how you mean?

-Thomas




Daniel Shahaf  
21.02.2011 19:34

An
Stephen Connolly 
Kopie
Thomas STEININGER , users@subversion.apache.org
Thema
Re: problem with mutated vowel in log-message-contents






Stephen Connolly wrote on Fri, Feb 18, 2011 at 14:01:52 +:
> unix shell scripting could solved it for you
> 
> bash
> for rev in $(svn log ... | sed -n -e "..."); do svn ps --revprop svn:log
> "$(svn pg svn:log -r $rev | sed -e "s/oldstring/newstring/g;")" ... ; 
done
> 
> I leave the ...'s as an exercise to tgeur reader

Simpler:
propedit --editor-cmd 'sed --flags'





Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschließlich 
Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen über dieses Medium 
nicht ausgetauscht werden.

Correspondence with a.m. sender via e-mail is only for information purposes. 
This medium is not to be used for the exchange of legally-binding 
communications.

Antwort: Re: Antwort: Re: problem with mutated vowel in log-message-contents

[Thomas STEININGER]

Ok - you mean that i start a script that iterates over all files and 
within over all revisions of the repository
and execute on it your command.
But you say 'and converts that file (in-place) from latin1 to utf8' and i 
have no problem with the file-contents itself.
The files have correct contents - including  mutated vowel.

My Problem is in the logs. 
The log-messages (commit-comments) have  mutated vowel  and if i try to 
show the log-comments of some file with Tortoisesvn or Eclipse-subversive 
with JavaHL-Connector
i have a error and see nothing.

So i must correct the checkin-comments.

How can i get this done?

Or does i have misunderstood your trick?

-Thomas




Daniel Shahaf  
22.02.2011 07:58

An
Thomas STEININGER 
Kopie
Stephen Connolly , 
users@subversion.apache.org
Thema
Re: Antwort: Re: problem with mutated vowel in log-message-contents






Thomas STEININGER wrote on Tue, Feb 22, 2011 at 07:39:49 +0100:
> do i really understand, that i have to execute this:
> propedit --editor-cmd 'sed --flags'
> on a file? on all urls that are in my svn-repository?
> or how you mean?
> 

On all revisions.

What you'll want is to write a script that takes a filename in argv[1]
and converts that file (in-place) from latin1 to utf8.  Then you can use
that file as --editor-cmd.

Something like 
% svn propedit --revprop -r $REV --editor-cmd 'perl -pi -e 
"s/\\xfc/\\xc3\\xbc/g"'
might just do the trick.  (untested)

> -Thomas
> 
> 
> 
> 
> Daniel Shahaf  
> 21.02.2011 19:34
> 
> An
> Stephen Connolly 
> Kopie
> Thomas STEININGER , 
users@subversion.apache.org
> Thema
> Re: problem with mutated vowel in log-message-contents
> 
> 
> 
> 
> 
> 
> Stephen Connolly wrote on Fri, Feb 18, 2011 at 14:01:52 +:
> > unix shell scripting could solved it for you
> > 
> > bash
> > for rev in $(svn log ... | sed -n -e "..."); do svn ps --revprop 
svn:log
> > "$(svn pg svn:log -r $rev | sed -e "s/oldstring/newstring/g;")" ... ; 
> done
> > 
> > I leave the ...'s as an exercise to tgeur reader
> 
> Simpler:
> propedit --editor-cmd 'sed --flags'
> 
> 
> 
> 
> 
> Der Austausch von Nachrichten mit o.a. Absender via e-mail dient 
ausschließlich Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen 
über dieses Medium nicht ausgetauscht werden.
> 
> Correspondence with a.m. sender via e-mail is only for information 
purposes. This medium is not to be used for the exchange of 
legally-binding communications.





Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschließlich 
Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen über dieses Medium 
nicht ausgetauscht werden.

Correspondence with a.m. sender via e-mail is only for information purposes. 
This medium is not to be used for the exchange of legally-binding 
communications.

RE: Build project in pre-commit

[Thomas Loy]

No, if your project takes more than a few seconds to compile, it WILL annoy 
committers.  I have a pre-commit that validates a Change Request Number in 
their comment against a database.  It is a quick query, but it takes about 15 
seconds to do the connect, query, and then disconnect.  My committers are 
annoyed by that short a time.

Cheers,

Tom


-Original Message-
From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
Sent: Tuesday, April 05, 2011 6:37 PM
To: San Martino
Cc: users@subversion.apache.org
Subject: Re: Build project in pre-commit

On Apr 5, 2011, at 17:08, San Martino wrote:

> we absolutely need to validate a project in the pre-commit trigger 
> with a build of the whole project being committed.
> 
> Is this possible? Are there any tools allowing this?

Yes, you could write a script to do this. There might be existing scripts to do 
this.

However, if your project takes more than a few seconds to compile, this will 
likely annoy committers.

RE: How do I escape a subversion keyword?

[Becker, Thomas]

How about:

if (length('$LastCheckedDate$') == 17) # keyword wasn't expanded

Regards,
  Thomas

> -Ursprüngliche Nachricht-
> Von: Bob Archer [mailto:bob.arc...@amsi.com]
> Gesendet: Freitag, 27. Mai 2011 19:08
> An: dar...@chaosreigns.com; users@subversion.apache.org
> Betreff: RE: How do I escape a subversion keyword?
> 
> > I'm working on some software (spamassassin) that uses the
> > subversion
> > keyword "$LastChangedDate$".  In the same file that it's used, I
> > want that
> > string to appear unmodified - not expanded by subversion, exactly
> > as
> > "$LastChangedDate$" instead of something like "$LastChangedDate:
> > 2010-03-30
> > 08:02:18 -0400 (Tue, 30 Mar 2010) $"
> >
> > Because I want to check for a case where svn keywords aren't
> > getting
> > expanded.
> >
> > Something like (perl):
> >
> >   if ('$LastChangedDate$' eq '$LastChangedDate$')
> >
> > But with one of them getting expanded, and the other not.
> >
> > I think it would work to do something like:
> >
> >   if ('$LastChangedDate$' eq '$LastChan'.'gedDate$')
> >
> > But I'd prefer to escape the keyword instead.
> >
> > Maybe something like \$LastChangedDate$ ?
> 
> I'm confused about what you are asking. Are you saying you don't want
> subversion to expand the keywords? If so, then remove them from the
> svn:keywords property. Any keywords not in the property are not expanded.
> 
> BOb



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.


.

Re: Subversion 1.6.17 Released

[Thomas Harold]

On 6/1/2011 7:27 PM, Daniel Shahaf wrote:


Be advised: the 1.6.17 tag [1] in our repository does not match the
tarballs at the time of this writing.  Until we fix this, please use the
tarballs or zip archives, and avoid installing 1.6.17 from the tag.

Daniel

[1] https://svn.apache.org/repos/asf/subversion/tags/1.6.17



I'm guessing that is why the following URL returns a 404 at the moment?

http://svn.apache.org/repos/asf/subversion/tags/1.6.17/CHANGES

Sparse check outs

[Stuempfig, Thomas]

We use svn as a document management system.
In our case we have different Roles in the same Project. We have Roles like 
Project Manager, Business Consultants and Technical Consultants.

Each of them have their own kind of files they are interested in.
My colleagues would like to sparse check out things based on some Rules like 
"*pptx" in a folder and its sub folders. Would like to ignore specific 
extensions like "*c,*cpp,*txt". Much the same way as the ignore list for non 
versioned files, but just for co.

Did somebody come along such a requirement?

Regards
Thomas

RE: For Siebel

[Thomas Loy]

Subversion does have lock mechanisms, but they are not enabled by default.  
Although Siebel has it's lock mechanisms for sifs, I believe they are binary 
and you will want to implement locking in Subversion for them as well.

I sure wish I could get our Siebel teams to use SVN instead of exclusively 
depending on Siebel's lock mechanisms!

Regards,

Tom

From: Geoff Hoffman [mailto:ghoff...@cardinalpath.com]
Sent: Wednesday, June 15, 2011 7:05 PM
To: users@subversion.apache.org
Subject: Re: For Siebel

On Wed, Jun 15, 2011 at 3:06 PM, Mudumbai, Venkat 
mailto:venkat.mudum...@mercer.com>> wrote:
Hi,
We are planning to user SUBVERSION & TortoiseSVN for our Siebel Tools as a 
source control tools.
Siebel development using tools,  as it is a a object based environment, where 
in we checkout and check in the several objects like 
applets,buscomps,picklist,links etc.

okay...


In my previous project we used VSS as the version control tools. In this when 
we check in a "sif"  of the  object checked in is created in the VSS Server.


I don't know what a "sif" is but SVN will store text and/or binary files under 
version control without any problems.


Siebel itself has a lock on the object created when an object is checkout. All 
we want is to know if the copy of the sif's whenever they are checked can be 
stored in Subversion, with details like who has checkedin, when it was cecked 
in.


Yes, that is exactly what it does. Here's some sample log output, gotten via 
command line:
svn log --verbose svn+ssh://path-to-server/svn/repos/sites/client


r279 | fredjones | 2011-04-26 17:10:40 -0700 (Tue, 26 Apr 2011) | 1 line
Changed paths:
   M /sites/client/www/.htaccess
   M /sites/client/www/application/frontend/controllers/main.php
   M /sites/client/www/application/frontend/views/footer.php
   M /sites/client/www/application/frontend/views/header.php
   A /sites/client/www/application/frontend/views/menu.php
   D /sites/client/www/application/frontend/views/promotions.php

Changed the .htaccess file and made the template modular.


With this, you can see on Apr 26, fredjones modified 4 files, added one, and 
deleted one


Also want to know how many versions of an object can be stored.


Limited only by hard drive space where your repo is stored.


Siebel is not a typical programming language.


There's no such thing as a typical programming language.


My question is : Can we use this SUBVERSION as a version control tools for our 
siebel tools. Please let me know as soon as possible as we are planning to 
install this s/w and do the set up as soon as possible.


I don't see why not.

Regarding this part:
> Siebel itself has a lock on the object created when an object is checkout.

The only thing is if you need Subversion to *not let Developer B checkout file 
X if Developer A already has it checked out*... I'm not sure it will do that. 
SVNt, by default, does not prevent checkout by Developer B. It expects you to 
instead merge manually, and expects you (the svn repository administrator, lead 
developer, etc) will do that part. If both Developer B and A checkout file X 
and they both modify it, the person who checks in first, gets their code into 
the repo without issue. The second developer probably will get a commit 
failure, with a message that his working copy is not up to date. He then has to 
merge his changes into the version in the repository, which is newer than what 
he checked out (because it was modified by the other developer's commit). It's 
not terribly difficult to manage merged code, but it is not a 
check-in-check-out system it is a version control system.

I hope that helps - good luck.

Re: Problem Loading Huge Repository

[Thomas Harold]

On 6/16/2011 7:05 PM, Bruno Antunes wrote:


Do you know any faster way to load the dump file or to filter out
some projects/revisions so I can speed up the process?



Are you CPU-bound? Or are you limited by disk speed? If you're limited
by disk access times, make sure that the source file that you're loading
from is on a different disk then the destination repository. Even if you
toss the 45GB dump file onto a USB2 external disk, you'll see a speed
increase.

And if you have a choice of file systems for the repository to be stored
on, make sure that it's something which can deal with a few hundred
thousand tiny files.  On Linux, I'd suggest going with ext4 over ext3.
While db/revs in a FSFS repository can have its revisions packed to
reduce the file count, the db/revprops folder still consists of 1 tiny
file for every revision in the project in a FSFS repository.

Re: Problem Loading Huge Repository

[Thomas Harold]

On 6/17/2011 10:54 AM, Daniel Shahaf wrote:

Thomas Harold wrote on Fri, Jun 17, 2011 at 10:31:43 -0400:

And if you have a choice of file systems for the repository to be stored
on, make sure that it's something which can deal with a few hundred
thousand tiny files.  On Linux, I'd suggest going with ext4 over ext3.
While db/revs in a FSFS repository can have its revisions packed to
reduce the file count, the db/revprops folder still consists of 1 tiny
file for every revision in the project in a FSFS repository.


revprops/ is sharded.

And in 1.7 (including the recent 1.7.0-alpha1) it is packed, too.



Good.  Another of the many reasons that we're looking forward to 1.7.

Even with the sharding, those little revprop files are causing us issues 
during backups (hotcopy -> rdiff-backup).  Being able to pack those 
revprop files is going to make a big difference as the backup process 
will only have to track 2000-2200 files instead of 30,000 to 50,000.


(We have a few long-lived repositories with up to 25k revisions.  And I 
just finished splitting a 22GB repository with 15-16k revs into a bunch 
of smaller repositories.  Now the nightly backup can look at doing a 
hotcopy on only the repositories with changes in the last 5 days.)

Performance

[Stuempfig, Thomas]

Hi everybody,

is there somewhere some documentation about svn performance(CPU/Network) other 
than the one at IBM pages?

regards
Thomas

WG: How to setup SVN with HTTPS on Apache for Windows?

[Stuempfig, Thomas]

Hi all,

inhttp://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html

I read the following:

* Getting httpd 2.0 up and running with the mod_dav module

Can't we use apache 2.2?

Regards
Thomas

Von: Geoff Hoffman [mailto:ghoff...@cardinalpath.com]
Gesendet: Mittwoch, 22. Juni 2011 22:47
An: Rob van Oostrum
Cc: Robert Dailey; Subversion (SVN) Mailing List
Betreff: Re: How to setup SVN with HTTPS on Apache for Windows?

Get everything working as a regular http://server/svn/repo then get a cert or 
self sign (not related to svn) and move your vhost to port 443 (open that port 
on your firewall if applicable).

AW: How to setup SVN with HTTPS on Apache for Windows?

[Stuempfig, Thomas]

I suggested in svnbook-...@red-bean.com to update to apache 2.2.

Regards
Thomas

-Ursprüngliche Nachricht-
Von: Cooke, Mark [mailto:mark.co...@siemens.com] 
Gesendet: Donnerstag, 23. Juni 2011 11:00
An: Stuempfig, Thomas; users@subversion.apache.org
Betreff: RE: How to setup SVN with HTTPS on Apache for Windows?

> Von: Geoff Hoffman [mailto:ghoff...@cardinalpath.com] 
> Gesendet: Mittwoch, 22. Juni 2011 22:47
> An: Rob van Oostrum
> Cc: Robert Dailey; Subversion (SVN) Mailing List
> Betreff: Re: How to setup SVN with HTTPS on Apache for Windows?
> 
> Get everything working as a regular http://server/svn/repo 
> <http://server/svn/repo>  then get a cert or self sign (not 
> related to svn) and move your vhost to port 443 (open that 
> port on your firewall if applicable). 
> 
> -Original Message-
> From: Stuempfig, Thomas 
> Sent: 23 June 2011 08:57
> To: users@subversion.apache.org
> Subject: WG: How to setup SVN with HTTPS on Apache for Windows?
> 
> Hi all,
> 
> in http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html
> 
> I read the following:
> 
> * Getting httpd 2.0 up and running with the mod_dav module
> 
> Can't we use apache 2.2?
> 
Indeed, I use apache 2.2 (latest) with the windows binaries from
alagazam no problems...

~ mark c

AW: SVN 1.7 - check out single file?

[Stuempfig, Thomas]

The possibility to check out a single file would probably be the base of 
checking out (or update) files that match certain criteria e.g. "*doc, *txt, 
*html"
I opened an other thread about this. Many of my colleagues would appreciate 
such a functionality. 

Regards
Thomas

-Ursprüngliche Nachricht-
Von: Andy Levy [mailto:andy.l...@gmail.com] 
Gesendet: Freitag, 1. Juli 2011 17:22
An: Andy Levy; users@subversion.apache.org
Betreff: Re: SVN 1.7 - check out single file?

On Fri, Jun 24, 2011 at 17:05, Stefan Sperling  wrote:
> On Fri, Jun 24, 2011 at 02:49:58PM -0400, Andy Levy wrote:
>> With the new way WCs are managed, will it be possible to check out a
>> single file, instead of having to do multiple steps with sparse
>> directories just to get a single file in a directory? Looking at the
>> release notes and CHANGES file, I think the answer is "no", but I need
>> someone more knowledgeable to back me up here before I take the answer
>> back to the person who asked me. Thanks.
>
> No, you still need to checkout a directory. But it sounds like the
> new --parents option of svn update might help you a bit:
> http://subversion.apache.org/docs/release-notes/1.7.html#update-parents

We'll have to see how Tortoise implements this, as that's what most
folks here are using.

It's an edge case for us, it's only 2 or 3 people who are affected by
the issue of too many items to check out just to update a single file.

AW: the best migrate solution of lower downtime

[Stuempfig, Thomas]

Migration depends on a lot of infrastructural constraints.

a) do you have full access of the servers
b) do you have virtualized systems, or plan to use on the new server.
c) what is the network layout between the servers, lan/wan,etc.
d) what is the allowed downtime.
e) is there a need for "cleaning" the data

All of these and probably other constraints should carefully be checked before 
being able to guide into a specific direction.


Amongst solution elements:
As others stated, you can use svn specific tools like svnsync.
An other approach would be more independent of svn:

You can also use,   filesystem or volume snapshots, if available. Stop the 
svn before taking the snapshot to be sure of a consistent snapshot. Then you 
can mount the repository snapshot to the new server. If everything is prepared 
upfront, then you should be able to migrate in just about seconds.
Keep in mind, that you have a huge snapshot volume, since the snapshot volume 
will become your working volume. This way you can probably drastically bring 
down the downtime.
Another way to minimize downtime is to run your server in a VM. In case you 
want just to migrate the server HW. You can use VM specific tools and means to 
easily migrate. I personally did even live migration of XEN VM in - fractions 
of a second - downtime.

Snapshot as well as VM Technology has to be thoroughly planned before use.


Regards
Thomas


-Ursprüngliche Nachricht-
Von: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Gesendet: Samstag, 9. Juli 2011 20:42
An: Les Mikesell
Cc: users@subversion.apache.org
Betreff: Re: the best migrate solution of lower downtime

On Sat, Jul 9, 2011 at 12:54 PM, Les Mikesell  wrote:
> On 7/9/11 11:30 AM, Nico Kadel-Garcia wrote:
>>
>> There are numerous others, such as pre-staging with "svnsync" to
>> switch arachitures or refactoring of projects into different
>> repositories, or finally getting things under $URL/project/trunk
>> instead of $URL/trunk/project.. In that case, the UUID's of the
>> repositories would be distinct, and switchover for clients is
>> trickier.
>
> You can use svnsync to do the copy, then change the uuid to match the old
> one as long as the final transaction matches - that is you do not do any
> commits during or after the last sync run.  It is much slower than rsync'ing
> the underlying files (and doesn't take hooks), but might be worth doing if
> the original repo started with an old version of subversion.

I've used that. It's potentially more dangerous, especially because
svnsync can be used with repository splitting.

Re: Move to a new repo and keep the history, Part 2

[Thomas Harold]

On 7/14/2011 12:29 PM, K F wrote:

Recap – I would like to move some directories from one repository to
another while keeping the history.



I went through this a few months ago (and maybe this will help).  We 
were using a big monolithic repository for all of our jobs. Our 
repository was arranged as:


("jobs" repository)
/A/ABClient/ABJob1/...
/A/AXClient/AXJob1/...
/A/AXClient/AXJob2/...
/B/BQClient/BQJob1/...
/C/CAClient/CAJob1/...
/C/CMClient/CMJob1/...
/C/CMClient/CMJob2/...

We wanted to split each client out to a different repository.  The 
output repositories would look like:


("jobs-ab")
/ABJob1/...

("jobs-ax")
/AXJob1/...
/AXJob2/...

("jobs-bq")
/BQJob1/...

("jobs-ca")
/CAJob1/...

("jobs-cm")
/CMJob1/...
/CMJob2/...

Which made all the URLs a lot shorter because the "/A/ABClient" was 
often something lengthy like "/A/AB_Acme_Border_Wings_Inc".


1) A shell script to split out a specific directory.  We had to edit the 
CLCODE and CLPATH lines for each run (took 30-40 minutes to parse the 
monolithic jobs repository and split out a particular client's tree).


Each time I did a new client, I had to make sure that everyone was ready 
for that client's project tree to move.  Alternately, I could have made 
the entire "jobs" tree read-only for a week...


(Apologies if there are errors in this as I had to quickly edit out some 
client/company specific paths.  I always executed the script as "bash -x 
scriptname" so I could spot errors.  The "date" lines are just there so 
I could keep track of how long it took.)


#!/bin/bash

DESTDIR=/var/svn/
DESTPFX=svn-raw-jobs-
DESTSFX=10xx.dump.gz

CLCODE=bq
CLPATH=B/BQClient

SDFOPTS='--drop-empty-revs  --renumber-revs'

date

echo ${DESTDIR}${DESTPFX}${CLCODE}${DESTSFX}

svnadmin dump --quiet /var/svn/jobs | \
svndumpfilter include --quiet $SDFOPTS $CLPATH | gzip > \
${DESTDIR}${DESTPFX}${CLCODE}${DESTSFX}

date

2) Created the new repository (such as "jobs-bq" for the BQClient). 
Although you could probably roll that into the import script.


# svnadmin create jobs-bq

3) Edited the following import script for each new run.  Loading it up 
was a fairly quick process.  Note that we update the UUID of the new 
repository to make sure that nobody commits outdated stuff.


I gave up on trying to re-base on the fly using "sed" and simply moved 
all of the individual job folders into the root of the new repository 
and then cleaned up the left-over folder.


Our script also had to create the "letter" level in the new repository. 
 Otherwise the import had no place to hang itself off of.


You may want to drop the chmod/chgrp lines towards the end.  For our 
server, we only use svn+ssh authentication.  Each users has their own 
local account on the server and they belong to a "svn-jobs" group which 
gives them read/write access to the entire repository.


#!/bin/bash

SRCDIR=/var/svn/
SRCPFX=svn-raw-jobs-
SRCSFX=10xx.dump.gz

DESTDIR=/var/svn/
DESTPFX=svn-newbase-jobs-
DESTSFX=10xx.dump.gz

CLPARENT=B
CLCODE=bq

date

svn mkdir -m "Import from jobs" \
file:///var/svn/jobs-${CLCODE}/${CLPARENT}

gunzip -c ${SRCDIR}${SRCPFX}${CLCODE}${SRCSFX} | \
svnadmin load --quiet /var/svn/jobs-${CLCODE}

svnlook uuid /var/svn/jobs-${CLCODE}
svnadmin setuuid /var/svn/jobs-${CLCODE}
svnlook uuid /var/svn/jobs-${CLCODE}
svnadmin pack /var/svn/jobs-${CLCODE}

chmod -R 775 /var/svn/jobs-${CLCODE}
chmod -R g+s /var/svn/jobs-${CLCODE}/db
chgrp -R svn-jobs /var/svn/jobs-${CLCODE}

date

4) After the load into the new repository, I would access the repository 
through TortoiseSVN's Repository Browser and drag all of the individual 
jobs folders from being under "/A/ABClient/" up to the root of the new 
repository.  Then I deleted the "/A/ABClient/" tree.


If I could have figured out how to remap on the fly via "sed", I could 
have avoided step #4.  But it was good enough for our purposes and a few 
historical entries in the SVN log showing the movement of the folders 
wasn't a big deal.


5) After we finished the splits, we chmod'd the old repository to be 
read-only and took it completely offline a month or two later.

Archiving old Data

[Stuempfig, Thomas]

Hi everybody,

how can I systematically get rid of very old data, that is not used anymore.

My repository is 300GB large 15000 revs.
Is svnadmin dump ... svndumpfilter ...  the only supported way?

Would it be useful to have an svnadmin command deleting a node(recursively)?

regards
Thomas Stümpfig

Re: Subversion: existing users

[Thomas Harold]

On 7/17/2011 2:07 AM, Andy Canfield wrote:

The most obvious authorization scheme is that of the host server; if
there is a user named "andy" on that server with a password "jackel"
then I would like to simply be able to talk to the subversion server as
user named "andy" password "jackel". This is how ssh and sftp work. But
apparently subversion can't handle that. True?


You can use individual accounts, the main trickiness is in making sure 
that the svn repository directory is group owned, group writable and 
that new files created within the repo/db tree are owned by the group 
and not the individual's primary group.  A quick "chmod -R g+s repo/db" 
after setting up the repository takes care of that.


Our server only allowed SSH public-key authentication, so the only way 
to login (other then physically at the console) is via the SSH keys.  So 
the "command=" line in the authorized_keys files is reasonably secure 
for our purposes.  Very few users actually have a way to get to the 
shell.  And most of those don't even know the password for their account 
on the server.


(Naturally, we run backups daily, just in case someone does figure out 
how to get a shell through the svnserve process and deletes a 
repository.  But if they can commit to the repository, there are more 
nefarious things they can do there too.)


We prefix our ssh-rsa lines in the ~/.ssh/authorized_keys file with:

command="/usr/bin/svnserve -t -r /var/svn",
no-agent-forwarding,no-pty,
no-port-forwarding,no-X11-forwarding

This also has the advantage that remote URL ends being:

svn+ssh://servername/repositoryname/path/within/repo

Instead of:

svn+ssh://servername/var/svn/repositoryname/path/within/repo

With SSH ~/.ssh/config files or by setting up PuTTY sessions correctly 
you can get rid of having the usernames / port numbers in the svn+ssh 
URL.  (We run our SSH servers on a non-standard port.)

Re: Subversion access control / Linux users etc.

[Thomas Harold]

The issues with passwords is why we ended up going with SSH public-key 
authentication.  Load the SSH key into the SSH agent, unlock it with the 
passphrase, then don't worry about it again until we reset the SSH agent 
at logout.


Less prompts, happier users.

(Plus it makes it harder to get into our servers since we don't allow 
password authentication.)

1.7 compatibility issue

[Becker, Thomas]

Hi,

 

I tried to list a repository served by Visual SVN 2.1.9 (Subversion
1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded
from Collabnet
(https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn
_binaries.windows ).

 

With the "alpha" and "beta" clients I get the following error:

 

>svn.exe ls https://:8443/

svn: E175009: Unable to connect to a repository at URL
'https://:8443/'

svn: E175009: XML parsing failed: (400 Bad Request)

 

The Visual SVN event log shows the message "Hostname :8443 provided
via SNI and hostname  provided via HTTP are different". There seems
to be a missing port number which reminded me of a discussion in thread
"1.7.0-alpha1 feedback"
(http://svn.haxx.se/users/archive-2011-06/0263.shtml). Maybe this is
related.

 

Versions svn-1.7.0-dev-win32-r1136035.zip and earlier work, though.

 

Regards,

  Thomas

 

 

 



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschaftsfuhrer: Stephen Callaghan, Martin Timmann.


.

AW: 1.7 compatibility issue

[Becker, Thomas]

Yes,  actually starts with svn. The URL looks like this: 
https://:8443/svn/

Regards,
  Thomas

-Ursprüngliche Nachricht-
Von: Ivan Zhakov [mailto:i...@visualsvn.com] 
Gesendet: Dienstag, 26. Juli 2011 11:26
An: Becker, Thomas
Cc: users@subversion.apache.org
Betreff: Re: 1.7 compatibility issue

On Tue, Jul 26, 2011 at 12:34, Becker, Thomas  wrote:
> Hi,
>
>
>
> I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17,
> Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from
> Collabnet
> (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows
> ).
>
>
>
> With the "alpha" and "beta" clients I get the following error:
>
>
>
>>svn.exe ls https://:8443/
>
> svn: E175009: Unable to connect to a repository at URL
> 'https://:8443/'
>
The URL for VisualSVN Server repositories should be like
https:/xxx:8443/svn/. Please make sure that you are using correct
URL to repository.

-- 
Ivan Zhakov


 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.


.

strange merge conflict wrt. keywords

[Becker, Thomas]

Hi,

 

We encountered a strange merge conflict:

 

A branch was created from trunk, nothing was ever committed to this
branch and this branch was never the source of a merge. After some time,
when merging from trunk to the freshly checked-out branch we got a text
conflict for a particular file.

 

It turned out that the trunk version of this file had substituted
keywords in the repository when the branch was created. With the next
commit on trunk this changed back to the un-expanded forms.

 

The change of the revision where the substituted keywords appeared in
the repository was a move of three files in order to change an upper
case letter to lower case in the file names. However, the substituted
keywords appeared only in one of the files. The svn:keywords property
was "Id Date Revision Author URL" for all three files in all revisions.

 

My assumption is that when doing the merge from trunk to branch the
keyword line is subject to an incoming change (because they changed back
to the generic form on trunk) as well as to local substitution which
leads to the observed conflict.

 

My questions now are:

-  Is this the expected behaviour or should incoming changes on
keywords be ignored?

-  How could the substituted keyword get into the repository?

 

For the revision where the substituted keywords appear in the repository
we used Windows clients and server (Visual SVN) in whatever version was
recent in January 2011. The merge conflict can be observed with Linux
and Windows clients in various 1.6 versions.

 

Regards,

  Thomas

 



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschaftsfuhrer: Stephen Callaghan, Martin Timmann.


.

Question about commit/udpate inside externals

[Thomas Clement]

Hello list,

I have a repository which contains an external to another repository with a 
fixed revision number.
Something like: "-rxxx svn+ssh://..."

I noticed I can make modifications inside this external and commit the 
modifications.
At which point the external is actually above its fixed revision number (xxx+1 
for example).

"svn status" does not mention this particular state and "svn up" does not bring 
the external back to its fixed revision number.

What bothers my is that doing a checkout of the repository will get me to a 
different state but doing "svn status" and "svn up" on my working copy does not 
alert me of that.
How can I check if my externals are above their fixed revision number?

Maybe it is just a bad idea to edit and commit inside externals?


Regards,
Thomas

AW: 1.7 compatibility issue

[Becker, Thomas]

Sorry for the confusion:  stands for svn/,  stands
for . The URL looks like
https://:8443/svn/.

 

Regards,

  Thomas

 



Von: Mark Phippard [mailto:markp...@gmail.com] 
Gesendet: Dienstag, 26. Juli 2011 16:54
An: Becker, Thomas
Cc: users@subversion.apache.org
Betreff: Re: 1.7 compatibility issue

 

On Tue, Jul 26, 2011 at 4:34 AM, Becker, Thomas
 wrote:

Hi,

 

I tried to list a repository served by Visual SVN 2.1.9
(Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client
downloaded from Collabnet
(https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn
_binaries.windows ).

 

With the "alpha" and "beta" clients I get the following error:

 

>svn.exe ls https://:8443/

svn: E175009: Unable to connect to a repository at URL
'https://:8443/'

svn: E175009: XML parsing failed: (400 Bad Request)

 

Does the SVN ls command even support this?  I was not aware that it did.
When I try it from OSX using 1.6 and 1.7 this is what I get:

 

1.6:

$ /usr/bin/svn ls http://cu171.cloud.sp.collab.net/svn/

svn: Repository moved temporarily to
'http://cu171.cloud.sp.collab.net/svn/'; please relocate

 

1.7:

$ svn ls http://cu171.cloud.sp.collab.net/svn/

svn: E175011: Unable to connect to a repository at URL
'http://cu171.cloud.sp.collab.net/svn'

subversion/libsvn_ra_neon/util.c:607: (apr_err=175011)

svn: E175011: Repository moved temporarily to
'http://cu171.cloud.sp.collab.net/svn'; please relocate

 

In my case the server is running 1.7 as well.  I can browse the list of
repositories using my web browser.  FWIW, that is all I thought this
feature was supposed to support.


-- 
Thanks

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



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschaftsfuhrer: Stephen Callaghan, Martin Timmann.


.

AW: 1.7 compatibility issue

[Becker, Thomas]

I can confirm that listing the repository works with --config-option
servers:global:http-library=neon.

 

As reported by Ivan he fixed this issue in r1151177.

 

Thanks!

 

Regards,

  Thomas

 



Von: Mark Phippard [mailto:markp...@gmail.com] 
Gesendet: Dienstag, 26. Juli 2011 18:17
An: Becker, Thomas
Cc: users@subversion.apache.org
Betreff: Re: 1.7 compatibility issue

 

On Tue, Jul 26, 2011 at 11:44 AM, Becker, Thomas
 wrote:

Sorry for the confusion:  stands for svn/, 
stands for . The URL looks like
https://:8443/svn/.

 

So you are saying you cannot even do svn ls against a repository?

 

The automated test suite would exercise that.  It could be some
incompatibility between the client binaries and the way VisualSVN
configures authentication or something like that.  The binaries are
probably using ra_serf to talk to the repository, which is new in 1.7.
You can try configuring your client to use Neon as the default.  Edit
%APPDATA%\Subversion\config and add:

 

http-library = neon

 

At the bottom.

 


-- 
Thanks

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



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschaftsfuhrer: Stephen Callaghan, Martin Timmann.


.

AW: strange merge conflict wrt. keywords

[Becker, Thomas]

One more note: the file that went into the repository with expanded keywords 
also has Windows (CRLF) line endings in the repository. It looks like the svn 
client sent the file "as is" ignoring the svn:keywords and svn:eol-style=native 
properties (or is this a server issue?). This can also be seen nicely in the 
output of svn diff -c : for the file in question there are lines like "+ 
... $Author some.user $" and all the lines end with ^M. Strange enough that 
this happened only to one file in a commit that included three file renames.

 

I'm still trying to reproduce this behaviour. Any hints would be appreciated.

 

Regards,

  Thomas

 

____

Von: Becker, Thomas [mailto:thomas.bec...@torex.com] 
Gesendet: Dienstag, 26. Juli 2011 14:09
An: users@subversion.apache.org
Betreff: strange merge conflict wrt. keywords

 

Hi,

 

We encountered a strange merge conflict:

 

A branch was created from trunk, nothing was ever committed to this branch and 
this branch was never the source of a merge. After some time, when merging from 
trunk to the freshly checked-out branch we got a text conflict for a particular 
file.

 

It turned out that the trunk version of this file had substituted keywords in 
the repository when the branch was created. With the next commit on trunk this 
changed back to the un-expanded forms.

 

The change of the revision where the substituted keywords appeared in the 
repository was a move of three files in order to change an upper case letter to 
lower case in the file names. However, the substituted keywords appeared only 
in one of the files. The svn:keywords property was "Id Date Revision Author 
URL" for all three files in all revisions.

 

My assumption is that when doing the merge from trunk to branch the keyword 
line is subject to an incoming change (because they changed back to the generic 
form on trunk) as well as to local substitution which leads to the observed 
conflict.

 

My questions now are:

-  Is this the expected behaviour or should incoming changes on 
keywords be ignored?

-  How could the substituted keyword get into the repository?

 

For the revision where the substituted keywords appear in the repository we 
used Windows clients and server (Visual SVN) in whatever version was recent in 
January 2011. The merge conflict can be observed with Linux and Windows clients 
in various 1.6 versions.

 

Regards,

  Thomas

 





This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those 
of Torex (Torex Group of Companies).  If you are not the intended recipient of 
this email and its attachments, you must take no action based upon them, nor 
must you copy or show them to anyone.  Please contact the sender if you believe 
you have received this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.


.

Re: AW: Web site: checkout or export?

[Thomas Harold]

On 7/27/2011 8:57 AM, Markus Schaber wrote:

Hi, Andy,

Von: Andy Canfield [mailto:andy.canfi...@pimco.mobi]


- Using 'svn checkout', the working web site will have the
subversion control files in the .svn subdirectory, which might be a
security hole.


You could use some pattern based access control (Apache is very
configurable in that respect) to prevent remote access to all pathes
containing .svn in their url.

And the security hole should be not that large, as the .svn directory
usually does not contain any authentication information.

Subversion 1.7 will further improve on that situation, you only have
a single .svn directory then. And you can use the trick of directing
the webserver to a subdir of your working copy, so the .svn directory
is completely out of the web servers path.



Alternately, if it is a Linux based host, you can use a tool like FSVS 
which also doesn't create the .svn metadata directories in the file 
system.  (Although we use FSVS more in a tripwire / change log fashion 
on our servers to track and note configuration changes.)  But SVN 1.7 
with a central .svn folder will also make things much easier.


One thing that I do wish SVN would add to their export command would be 
a "sync" where it would only bring down files that are actually changed 
content instead of bringing everything down.  Which would make the SVN 
export method more bandwidth friendly.

SVN externals - using a GUID style instead of a path?

[Thomas Harold]

http://subversion.apache.org/docs/release-notes/1.5.html#externals

The relative URLs being allowed in svn:externals was a huge step 
forward.  But it still relies on the source path not ever changing.


For example:

/repos/zag foo/bar1

Which is fine as long as "zag" never changes its name.

What if there was some sort of a GUID value for each object, created the 
first time that the object is added to the repository, that could then 
be used as the source URL?


/repos/GUID:4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 foo/bar1

Which would hopefully track /repos/zag as it changes from /repos/zag to 
/repos/zig to /repos/forgreatjustice.


(I suspect this all ties in with the copy/rename issue, which is itself 
a rather hairy topic.)


Is this also a moot point if you use the "pegged revision" style of 
svn:externals where you prefix the property value with "-r "?  That 
even if "/repos/zag" changes to "/repos/zig" it won't matter because 
you're pegging to a revision before the name change occured?

AW: Subversion Branch/Merge Graphical Display

[Stuempfig, Thomas]

Try subeclipse.
You can rightclick on he rev and display the merge graph then.

It is still not trivoal since you just see the merge rev prop.

Regards
Thomas
Email sent from blackberry.

Von: Tony Butt [mailto:tony.b...@cea.com.au]
Gesendet: Monday, August 01, 2011 06:50 AM
An: users@subversion.apache.org 
Betreff: Subversion Branch/Merge Graphical Display


I have been looking around at various tools which graphically display
subversion history for some time now.

In the past 3 months, we have changed our processes here to make more
use of Branching and Merging, in an effort to maintain a stable trunk.
Development tasks are performed on Branches. They are reviewed and
tested with design reviews, code reviews, integrated system tests, ...

Some tools (noticeably TortoiseSVN and kdesvn) are quite capable of
showing the branch history. I have found nothing which is capable of
showing merge history. I would have thought that with the advent of
svn:mergeinfo, that sufficient information is present to deduce the
merges.

Since it has not been done, I can only assume that the task is
non-trivial (certainly), probably difficult, and perhaps not practical.
Is that correct?

In any event, does anyone know of a tool which will provide such a
history?

Thanks in advance,

--
Tony Butt 
CEA Technologies

AW: Strange behavior on directory delete/commit

[Becker, Thomas]

You could also delete the directory directly in the repository using "svn 
delete  -m ". This way you would avoid the problem of committing 
partial changes of your working copy.

Regards,
  Thomas

-Ursprüngliche Nachricht-
Von: Dominik Psenner [mailto:dpsen...@gmail.com] 
Gesendet: Dienstag, 2. August 2011 08:41
An: users@subversion.apache.org
Betreff: Strange behavior on directory delete/commit

[...]

To get things done, one would have to backup foobar somewhere, revert
foobar, do the commit without PATH arguments and copy foobar over to the WC.
*eek*

Let me know what you think about this!

Greetings,
D.



 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschäftsführer: Stephen Callaghan, Martin Timmann.


.

Python optional location in centos 5 for compiling from source

[Florent THOMAS]

Hy all of you,

I'm running under centos 5.6 and I would like to use submin that 
requires python2.5 instead of the 2.4 availbale in the yum.

So I successfully installed the python 2.5 in the /opt directory.
Unfortunately, all the subversion python files given by the official 
pacckages are located in the 2.4 python path so taht the /opt/python2.5 
instructions aren't able to manage with the libraries.
Naturally I suppose that I muste compile from source the svn in against 
the python2.5 path.

I you think I'm not wrong, could you help me on the configure process?

Regards from france,

Florent THOMAS

BUG: Inconsistent handling of challenge-on-commit for conflicting user credentials

[Thomas Robinson]

The following is a bug report for triage and review. I've been unable to 
locate an adequate fix or discussion for this issue; however, I have 
found an acceptable workaround.



When built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17 (r1128011) 
appear to handle authentication challenges on commit in a non-robust 
manner.


The testing that follows is against a Google Code project that I 
currently maintain code for, which may be found here:

http://code.google.com/p/rf-ace/


Here is a sparse log of a fresh checkout and commit using SVN version 
1.6.16 (r1073529) on OSX. All builds are inclusive of ra-neon:


$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn 
--username trobin...@systemsbiology.org

... file data ...
Checked out revision 265.

$ cd rf-ace.svn
... make some changes to existing files ...

$ svn commit
... write the log in my default editor ...

"svn-commit.tmp" 35L, 1392C written
svn: Commit failed (details follow):
svn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf' 
forbidden

svn: Your commit message was left in a temporary file:
svn: 
'/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'


This same behavior exhibits in 1.6.17 (r1128011), and when a log message 
is given using -m.




Here is an approximately equivalent session using SVN version 1.6.11 
(r934486) in CentOS 6:


$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace 
--username trobin...@systemsbiology.org

... file data ...
Checked out revision 265.

$ cd rf-ace
... make some changes to existing files ...

$ svn up
... file data ...
Checked out revision 269.

$ svn commit -m "Irrelevant log message you can find in r270 of rf-ace"
Authentication realm:  Google Code 
Subversion Repository

Password for 'trobinso':
[In which I press enter here to fall back to explicit Username 
specification]


Authentication realm:  Google Code 
Subversion Repository

Username: trobin...@systemsbiology.org
Password for 'trobin...@systemsbiology.org': [My correct password is 
entered here]

Sendingtest/argparse_test.hpp
Transmitting file data .
---
ATTENTION!  Your password for authentication realm:

    Google Code Subversion Repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/my/home/directory/.subversion/servers'.
---
Store password unencrypted (yes/no)? yes [I know, I know. See my notes 
below.]


Committed revision 270.


Note that on personal dev boxes, authentication information has been 
stored locally in ~/.subversion (which, I note as an aside, is something 
I only do with definedly-insecure passwords like those automatically 
generated by Google Code on machines that are for internal development 
only). This, too, may cause the issue.


My workaround, of course, is obvious. For all versions of SVN, 
specifying the username explicitly (a la "--username 
trobin...@systemsbiology.org") immediately follows up with a challenge 
for my password. I have not verified if this resolves future commit 
attempts.



The catalyst for the issue is Google's recent transition of Google Code 
login system to that of Google Accounts. In this case, for conflicting 
users, the issue only exposed itself when we cut back over to our 
original usernames, and I would speculate this occurs if (and only if)

the same username is specified with an alternate password (as mine was).

Thus, we have a compelling case for potentially spurious handling of 
conflicting user credentials, as may well expose themselves in the 
migration of Google Code SVN repositories. In which I would speculate 
that the right approach would be to invalidate the cached copy of the 
user's credentials and re-challenge both the username and the password. 
Ideally, this behavior would be grafted into a configuration value, 
should it not already exist.



As you might expect, searching for this information is nigh-impossible 
for this exact edge condition, and you will probably receive several 
queries of a similar nature as Google continues to transition accounts 
with access to Google Code. Thus my posting of this bug report: assuming 
my hypothesis is correct, it's a case of inconsistent credential 
handling that results in a non-intuitive error message. As above, this 
would be better handled by configurable invalidation of the user's 
cached credentials.


Thus concludes my report. Please copy me on any mail you expect for me 
to see, as I am not a subscriber to this list.



Best regards,
- Tom

Re: BUG: Inconsistent handling of challenge-on-commit for conflicting user credentials

[Thomas Robinson]

Daniel:

As mentioned in my original mail, this is indeed a cache invalidation 
problem reliant on the contents of ~/.subversion/auth, which is 
trivially worked around by removing the contents thereof. The problem 
I'm trying to raise is a lack of parity with the behavior of plain SVN, 
which also handles the server challenge on commit poorly but in a less 
obtrusive way. That is, in their case, --username takes precedence over 
the contents of the cache.


In both cases, the lack of a descriptive error message is more 
problematic than the lack of an automated fix for the problem. I have of 
course raised the issue with SVN as well, such that if they add this 
message, Git will also handle this issue more gracefully when the 
changes are integrated through Perl SVN.



Thank you for your response,
- Tom Robinson

On 8/20/11 5:08 AM, Daniel Shahaf wrote:

Passing --username at checkout time is a no-op for HTTP-served
repositories that allow anonymous read access.

Seems that you have your username/password cached on the first box but
not on the second box?

In any case: rm -rf ~/.subversion/auth/svn.simple/ will remove the
locally-cached usernames/passwords.  (Note for the archives: it won't
remove details associated with client certificates.)  Or, alternatively,
pass --username to the 'svn commit' command too.

Does this address your issue?



Thomas Robinson wrote on Fri, Aug 19, 2011 at 14:06:40 -0700:

The following is a bug report for triage and review. I've been
unable to locate an adequate fix or discussion for this issue;
however, I have found an acceptable workaround.


When built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17
(r1128011) appear to handle authentication challenges on commit in a
non-robust manner.

The testing that follows is against a Google Code project that I
currently maintain code for, which may be found here:
http://code.google.com/p/rf-ace/


Here is a sparse log of a fresh checkout and commit using SVN
version 1.6.16 (r1073529) on OSX. All builds are inclusive of
ra-neon:

$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn
--username trobin...@systemsbiology.org
... file data ...
Checked out revision 265.

$ cd rf-ace.svn
... make some changes to existing files ...

$ svn commit
... write the log in my default editor ...

"svn-commit.tmp" 35L, 1392C written
svn: Commit failed (details follow):
svn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf'
forbidden
svn: Your commit message was left in a temporary file:
svn: '/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'

This same behavior exhibits in 1.6.17 (r1128011), and when a log
message is given using -m.



Here is an approximately equivalent session using SVN version 1.6.11
(r934486) in CentOS 6:

$ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace
--username trobin...@systemsbiology.org
... file data ...
Checked out revision 265.

$ cd rf-ace
... make some changes to existing files ...

$ svn up
... file data ...
Checked out revision 269.

$ svn commit -m "Irrelevant log message you can find in r270 of rf-ace"
Authentication realm:<https://rf-ace.googlecode.com:443>  Google
Code Subversion Repository
Password for 'trobinso':
[In which I press enter here to fall back to explicit Username
specification]

Authentication realm:<https://rf-ace.googlecode.com:443>  Google
Code Subversion Repository
Username: trobin...@systemsbiology.org
Password for 'trobin...@systemsbiology.org': [My correct password is
entered here]
Sendingtest/argparse_test.hpp
Transmitting file data .
---
ATTENTION!  Your password for authentication realm:

<https://rf-ace.googlecode.com:443>  Google Code Subversion Repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/my/home/directory/.subversion/servers'.
---
Store password unencrypted (yes/no)? yes [I know, I know. See my
notes below.]

Committed revision 270.


Note that on personal dev boxes, authentication information has been
stored locally in ~/.subversion (which, I note as an aside, is
something I only do with definedly-insecure passwords like those
automatically generated by Google Code on machines that are for
internal development only). This, too, may cause the issue.

My workaround, of course, is obvious. For all versions of SVN,
specifying the username explicitly (a la "--username
trobin...@systemsbiology.org") immediately follows up with a
challeng

SVN File Size

[Stümpfig , Thomas]

Hi all,
what is the reason that svn log does not tell me the actual file size. I would 
be more patient ;-), probably as a separate option or within -v
All I can find about in the net is a pre/or post commit that does a svnlook cat 
operation. But this is an expensive operation.
The Server should be able to deal with it during the "commit operation".

regards
Thomas Stümpfig
Presales Knowledge Management

Siemens Industry Sector
Siemens Industry Software GmbH & Co. KG
Franz-Geuer-Str. 10
50823 Köln

Tel.:+49 2153 9107117
Mobil: +49 175 2205712
Fax.:   +49 221 248928

thomas.stuemp...@siemens.com
www.siemens.com/plm

Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

AW: SVN File Size

[Stümpfig , Thomas]

Hi all,
First of all, I would like to thank you for your dedication to this issue
I would like to resume:

a) there is work on serverside in 1.7 that cares about file size
b) svnlook filesize makes use of it in 1.7
c) there might be issues related to svn:eol and svn:keywords
d) It is worth to create a ER for svn log

I will try to dig into the code and see if I am able to understand, the rough 
structure of it. 
Where should I look to, as a starting point? I am not anymore so fluent in C 
but I will try my best.
For sure I should know more details about the architecture, but I would like to 
concentrate on the part that 
deals with this one.

Regards
Thomas 



> -Ursprüngliche Nachricht-
> Von: Stefan Sperling [mailto:s...@elego.de]
> Gesendet: Freitag, 16. September 2011 10:43
> An: Stümpfig, Thomas; users@subversion.apache.org
> Betreff: Re: SVN File Size
> 
> On Fri, Sep 16, 2011 at 10:31:05AM +0200, Stefan Sperling wrote:
> > So what you're asking amounts to either a performance hit for 'svn
> log'
> > or to a new feature in the filesystem (record the size of the full
> > text of a file along with the changed-path data which 'svn log'
> reads).
> 
> Ooops, I was wrong here, sorry. The expanded size of the full text is
> already recorded in the filesystem. As Johan pointed out, there is
> 'svnlook
> filesize' which prints this number (which is stored in the FS, so there
> is no need to compute it). There wouldn't be a performance hit for 'svn
> log'.
> 
> The below is still valid as-is:
> 
> > I think the feature you are requesting is reasonable.
> > If you like, you can file an 'enhancement request' issue in our issue
> > tracker about this. Maybe somebody will have time to work on it.
> > (In case you know somebody who would like to work on this I'd like
> > to point out that we're always happy to help newcomers get started :)

AW: SVN File Size

[Stümpfig , Thomas]

Hi all,

I found the following when examining the svnlook code
svn_fs_file_length where svn look gets the filesize. This is obviously the fs 
side function.

In /libsvn_ra_svn/protocol 
I found the commands "stat" and "log"

"stat" contains a response token of size:number
"log" does not contain such a token

I then had a search for svn_ra functions in various header files. But I could 
not locate an ra api counterpart for svn_fs_file_length.

I cannot see if svn_ra_stat is providing filesize info, whilst being defined in 
/libsvn_ra_svn/protocol. (I hope I am interpreting this correctly) I neither 
can see if the server_side part encodes filesize information into the stream. 
Can somebody tell me where the answer is put into the stream?


Am I on the right path? Is this already subject to the Dev Mailinglist? This is 
my starting point of subversion coding. 

Regards
Thomas



==
stat
params:   ( path:string [ rev:number ] )
response: ( ? entry:dirent )
dirent:   ( name:string kind:node-kind size:number has-props:bool
created-rev:number [ created-date:string ]
[ last-author:string ] )


===



log
params:   ( ( target-path:string ... ) [ start-rev:number ]
[ end-rev:number ] changed-paths:bool strict-node:bool
? limit:number
? include-merged-revisions:bool
all-revprops | revprops ( revprop:string ... ) )
Before sending response, server sends log entries, ending with "done".
If a client does not want to specify a limit, it should send 0 as the
limit parameter.  rev-props excludes author, date, and log; they are
sent separately for backwards-compatibility.
log-entry: ( ( change:changed-path-entry ... ) rev:number
 [ author:string ] [ date:string ] [ message:string ]
 ? has-children:bool invalid-revnum:bool
 revprop-count:number rev-props:proplist
 ? subtractive-merge:bool )





> -Ursprüngliche Nachricht-
> Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Gesendet: Montag, 19. September 2011 13:41
> An: Stümpfig, Thomas
> Cc: users@subversion.apache.org
> Betreff: Re: SVN File Size
> 
> Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 09:18:06 +:
> > Hi all,
> > First of all, I would like to thank you for your dedication to this
> issue
> > I would like to resume:
> >
> > a) there is work on serverside in 1.7 that cares about file size
> > b) svnlook filesize makes use of it in 1.7
> 
> IIRC, in 1.7 svnlook simply exposed a long-existing FS API.
> 
> > c) there might be issues related to svn:eol and svn:keywords
> 
> The FS returns the length of the repository-normal form, i.e., LF
> linefeeds and contracted keywords.
> 
> > d) It is worth to create a ER for svn log
> >
> 
> I'm not sure; where do you draw the line between 'svn log' and 'svn
> info'?
> 
> > I will try to dig into the code and see if I am able to understand,
> the rough structure of it.
> > Where should I look to, as a starting point? I am not anymore so
> fluent in C but I will try my best.
> > For sure I should know more details about the architecture, but I
> would like to concentrate on the part that
> > deals with this one.
> >
> 
> First of all you should determine whether your patch needs to extend
> the
> wire protocol or not.  See subversion/libsvn_ra_svn/protocol or
> subversion/include/svn_ra.h
> 
> > Regards
> > Thomas
> >
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Stefan Sperling [mailto:s...@elego.de]
> > > Gesendet: Freitag, 16. September 2011 10:43
> > > An: Stümpfig, Thomas; users@subversion.apache.org
> > > Betreff: Re: SVN File Size
> > >
> > > On Fri, Sep 16, 2011 at 10:31:05AM +0200, Stefan Sperling wrote:
> > > > So what you're asking amounts to either a performance hit for
> 'svn
> > > log'
> > > > or to a new feature in the filesystem (record the size of the
> full
> > > > text of a file along with the changed-path data which 'svn log'
> > > reads).
> > >
> > > Ooops, I was wrong here, sorry. The expanded size of the full text
> is
> > > already recorded in the filesystem. As Johan pointed out, there is
> > > 'svnlook
> > > filesize' which prints this number (which is stored in the FS, so
> there
> > > is no need to compute it). There wouldn't be a performance hit for
> 'svn
> > > log'.
> > >
> > > The below is still valid as-is:
> > >
> > > > I think the feature you are requesting is reasonable.
> > > > If you like, you can file an 'enhancement request' issue in our
> issue
> > > > tracker about this. Maybe somebody will have time to work on it.
> > > > (In case you know somebody who would like to work on this I'd
> like
> > > > to point out that we're always happy to help newcomers get
> started :)

AW: SVN File Size

[Stümpfig , Thomas]

Hi Daniel,

The reason for file size in 'Svn log' would be to easily estimate the amount of 
an update operation. It is already in 'svn list' which helps for "checkout and 
export". Let's assume you work offline for a week. Your colleague commits many 
jpg's, or tutorial avis to the documentation directory.
You are unaware of this since you just update your project directory. If you're 
on a WAN bandwidth you will have to wait or interrupt, and probably svn 
cleanup. Things I do not really like. 
I agree, one could script around and produce deltas of 'svn list', but I would 
expect this in core. Sure it's not an obvious use case, but this would 
definitely help my guys to work smoother with svn.

I still will have to convince TortoiseSVN to calculate filesize for directories 
in the Browser and in logsummery.



With respect to the question of how to implement I would appreciate any input, 
since I am a newbie in svn programming.

Regards
Thomas




> -Ursprüngliche Nachricht-
> Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Gesendet: Dienstag, 20. September 2011 00:03
> An: Stümpfig, Thomas
> Cc: users@subversion.apache.org
> Betreff: Re: SVN File Size
> 
> svn_ra_stat() does return the filesize, and it's the API that 'svn
> info'
> uses.  The next/prev links in the chain are svn_client_info3() and
> ra_svn_stat() (the latter is a file-private function in libsvn_ra_svn).
> 
> So, yes, you're on the right path.  However, I knew all these APIs
> would
> exist, so I'm still where I was before: I'd like to know why the
> proposed new feature is generally useful enough to be included in the
> core, where it stands wrt 'svn log' and 'svn info', and how it would be
> implemented.
> 
> In particular, implementing a protocol change involves a non-negligible
> amount of work (to revv four transports, client and server, plus compat
> code for old servers), while if it doesn't involve a protocol change
> the
> question is "Why is a bindings script not a sufficient solution?".
> 
> Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 21:33:11 +:
> > Hi all,
> >
> > I found the following when examining the svnlook code
> > svn_fs_file_length where svn look gets the filesize. This is
> obviously the fs side function.
> >
> > In /libsvn_ra_svn/protocol
> > I found the commands "stat" and "log"
> >
> > "stat" contains a response token of size:number
> > "log" does not contain such a token
> >
> > I then had a search for svn_ra functions in various header files. But
> I could not locate an ra api counterpart for svn_fs_file_length.
> >
> > I cannot see if svn_ra_stat is providing filesize info, whilst being
> defined in /libsvn_ra_svn/protocol. (I hope I am interpreting this
> correctly) I neither can see if the server_side part encodes filesize
> information into the stream. Can somebody tell me where the answer is
> put into the stream?
> >
> >
> > Am I on the right path? Is this already subject to the Dev
> Mailinglist? This is my starting point of subversion coding.
> >
> > Regards
> > Thomas
> >
> >
> >
> > ==
> > stat
> > params:   ( path:string [ rev:number ] )
> > response: ( ? entry:dirent )
> > dirent:   ( name:string kind:node-kind size:number has-props:bool
> > created-rev:number [ created-date:string ]
> > [ last-author:string ] )
> >
> >
> > ===
> >
> >
> >
> > log
> > params:   ( ( target-path:string ... ) [ start-rev:number ]
> > [ end-rev:number ] changed-paths:bool strict-
> node:bool
> > ? limit:number
> > ? include-merged-revisions:bool
> > all-revprops | revprops ( revprop:string ... ) )
> > Before sending response, server sends log entries, ending with
> "done".
> > If a client does not want to specify a limit, it should send 0 as
> the
> > limit parameter.  rev-props excludes author, date, and log; they
> are
> > sent separately for backwards-compatibility.
> > log-entry: ( ( change:changed-path-entry ... ) rev:number
> >  [ author:string ] [ date:string ] [ message:string ]
> >  ? has-children:bool invalid-revnum:bool
> >  revprop-count:number rev-props:proplist
> >  ? subtractive-merge:bool )
>

AW: SVN File Size

[Stümpfig , Thomas]

Daniel,

nice url xy...

svn_ra_progress_notify_func_t: callback
Notification callback for network progress information.

it is not the progress I am looking for. It is an upfront information about the 
amount of data I am going to update before initiating the update. 

or is svn_ra_progress_notify_func_t doing this also?

Thanks
Thomas


> -Ursprüngliche Nachricht-
> Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Gesendet: Dienstag, 20. September 2011 14:20
> An: Stümpfig, Thomas
> Cc: users@subversion.apache.org
> Betreff: Re: SVN File Size
> 
> http://s.apache.org/xy-problem
> 
> See svn_ra_progress_notify_func_t.
> 
> Daniel
> 
> Stümpfig, Thomas wrote on Tue, Sep 20, 2011 at 09:55:09 +:
> > Hi Daniel,
> >
> > The reason for file size in 'Svn log' would be to easily estimate the
> amount of an update operation. It is already in 'svn list' which helps
> for "checkout and export". Let's assume you work offline for a week.
> Your colleague commits many jpg's, or tutorial avis to the
> documentation directory.
> > You are unaware of this since you just update your project directory.
> If you're on a WAN bandwidth you will have to wait or interrupt, and
> probably svn cleanup. Things I do not really like.
> > I agree, one could script around and produce deltas of 'svn list',
> but I would expect this in core. Sure it's not an obvious use case, but
> this would definitely help my guys to work smoother with svn.
> >
> > I still will have to convince TortoiseSVN to calculate filesize for
> directories in the Browser and in logsummery.
> >
> >
> >
> > With respect to the question of how to implement I would appreciate
> any input, since I am a newbie in svn programming.
> >
> > Regards
> > Thomas
> >
> >
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> > > Gesendet: Dienstag, 20. September 2011 00:03
> > > An: Stümpfig, Thomas
> > > Cc: users@subversion.apache.org
> > > Betreff: Re: SVN File Size
> > >
> > > svn_ra_stat() does return the filesize, and it's the API that 'svn
> > > info'
> > > uses.  The next/prev links in the chain are svn_client_info3() and
> > > ra_svn_stat() (the latter is a file-private function in
> libsvn_ra_svn).
> > >
> > > So, yes, you're on the right path.  However, I knew all these APIs
> > > would
> > > exist, so I'm still where I was before: I'd like to know why the
> > > proposed new feature is generally useful enough to be included in
> the
> > > core, where it stands wrt 'svn log' and 'svn info', and how it
> would be
> > > implemented.
> > >
> > > In particular, implementing a protocol change involves a non-
> negligible
> > > amount of work (to revv four transports, client and server, plus
> compat
> > > code for old servers), while if it doesn't involve a protocol
> change
> > > the
> > > question is "Why is a bindings script not a sufficient solution?".
> > >
> > > Stümpfig, Thomas wrote on Mon, Sep 19, 2011 at 21:33:11 +:
> > > > Hi all,
> > > >
> > > > I found the following when examining the svnlook code
> > > > svn_fs_file_length where svn look gets the filesize. This is
> > > obviously the fs side function.
> > > >
> > > > In /libsvn_ra_svn/protocol
> > > > I found the commands "stat" and "log"
> > > >
> > > > "stat" contains a response token of size:number
> > > > "log" does not contain such a token
> > > >
> > > > I then had a search for svn_ra functions in various header files.
> But
> > > I could not locate an ra api counterpart for svn_fs_file_length.
> > > >
> > > > I cannot see if svn_ra_stat is providing filesize info, whilst
> being
> > > defined in /libsvn_ra_svn/protocol. (I hope I am interpreting this
> > > correctly) I neither can see if the server_side part encodes
> filesize
> > > information into the stream. Can somebody tell me where the answer
> is
> > > put into the stream?
> > > >
> > > >
> > > > Am I on the right path? Is this already subject to the Dev
> > > Mailinglist? This is my starting point of subversion coding.
> > > >
> > > > Regards
> > > > Thomas
>

svn upgrade with dump/load

[Stümpfig , Thomas]

Hi all,
I plan to upgrade a 250GB Repository from 1.5 to 1.7. As I learned from other 
threads in this list, it is wise to dump and load the repository in order to 
bring everything to the latest features.
I have to keep the revision numbers and transaction dates.

Now svn dump and load offer some flexibility. And my server has 32GB Memory and 
16 Cores.
Now, in order to optimize the migration process would it be worth to split the 
dump into multiple dumps? And if yes, would you use delta dumps?


Thomas Stümpfig

Invalid character "/" in revision list

[Thomas Gier]

Hello,

this is my first post to the list so first of all I'd like to say hello 
to everybody :).


I'm stuck with a problem for which even google doesn't seem to find a 
solution, so I decided to post to this list. We're using SVN  1.5.1 
(r32289) and access our repository with linux, mac (SmartSVN, IntelliJ 
plugin) and windows clients (Eclipse plugin, TortoiseSVN)


Problem:
Loading a dump into a repository fails with "Invalid character "/" in 
revision list".


After many hours of trying and searching for fixes I decided to take a 
closer look to the binary files under /db/revs. Since I know 
the affected revision (12943), I inspected the file home>/db/revs/12/12943. This file contains a line similar to this:


/path/to/some/file:1234,1235,1237/path/to/some/other/file

Other lines never have a path except at the beginning but never inside 
the revision list and they always end with a line feed  (0A in binary). 
This particular line however doesn't. Editing the file with an hex 
editor and putting an 0A at the correct position (while preserving as 
much of the revision numbers as possible) seems to do the trick.


I know that by fiddling with these entries the mergeinfo will get 
useless for this particular file/revision. I really don't like the idea 
of messing around like this but I need to make sure that the dumps 
remain usable. My backup strategy is dependent on usable dumps which are 
created every night and moved off-site. If I can't recover from a 
breakdown using the latest dump, I'm in serious trouble.


So here are my questions:
- Does anybody else have had this or a similar problem, too? What did 
he/she do to fix it?
- How can this happen? Does anybody have hints/tips for further 
investigation of the cause of this mess?
- Is there a way to correct this issue without using a binary editor on 
the db files?


Thanks a lot for reading. Any comment is much appreciated.

Cheers
Thomas Gier
Aachen, Germany

Possible regression with empty checkouts of repos in 1.7.

[Thomas Dziedzic]

Hi,

I used to be able to do:
svn checkout --depth=empty svn://svn.archlinux.org/packages
cd packages
svn up pacman
rm -r pacman
svn up

and it would leave me with an empty, working copy on my computer in
subversion 1.6.17

When I upgraded to subversion 1.7.2, after doing the same set of
commands as described above,
the last svn up brings back the pacman folder into the working copy.

So far, I haven't been able to find any documented proof that this is
an intentional change.

Finally, when I run:

svn up --set-depth exclude pacman

This works as expected.

So my question is, am I experiencing a regression? Or is this new,
intended behavior with subversion 1.7?

Thanks for your time!

Re: Invalid character "/" in revision list

[Thomas Gier]

Am 14.12.2011 17:33, schrieb Daniel Shahaf:

Thomas Gier wrote on Wed, Dec 14, 2011 at 17:10:26 +0100:

Hello,

this is my first post to the list so first of all I'd like to say
hello to everybody :).

I'm stuck with a problem for which even google doesn't seem to find
a solution, so I decided to post to this list. We're using SVN
1.5.1 (r32289) and access our repository with linux, mac (SmartSVN,
IntelliJ plugin) and windows clients (Eclipse plugin, TortoiseSVN)


What version of svn runs on the client side?  If it's 1.5, upgrade;
there have been robustness fixes in the last 3.5 years.


Problem:
Loading a dump into a repository fails with "Invalid character "/"
in revision list".

After many hours of trying and searching for fixes I decided to take
a closer look to the binary files under/db/revs. Since I
know the affected revision (12943), I inspected the file/db/revs/12/12943. This file contains a line similar to this:

/path/to/some/file:1234,1235,1237/path/to/some/other/file


For the record, you could have run 'propget --strict' or 'diff' against
the revision in question.


Other lines never have a path except at the beginning but never
inside the revision list and they always end with a line feed  (0A
in binary). This particular line however doesn't. Editing the file
with an hex editor and putting an 0A at the correct position (while
preserving as much of the revision numbers as possible) seems to do
the trick.

DO NOT EDIT REVISION FILES; you just corrupted it.

The correct thing to do is a dump/load and change the property value
during that process.  Doing it by hand to a dumpfile is easier to get
right (but you will still have lengths and checksums to adjust), or you
could use some third-party dumpfile manipulation tool (some tools are
standard recommendations on this list; I don't recall which offhand).


I know that by fiddling with these entries the mergeinfo will get
useless for this particular file/revision. I really don't like the

No, the mergeinfo will be fine; it's the rest of the changes in that
revision that will be corrupt.  And if a file text change becomes
invalid, later revisions of that file may or may not be affected.


idea of messing around like this but I need to make sure that the
dumps remain usable. My backup strategy is dependent on usable dumps
which are created every night and moved off-site. If I can't recover
from a breakdown using the latest dump, I'm in serious trouble.

So here are my questions:
- Does anybody else have had this or a similar problem, too? What
did he/she do to fix it?
- How can this happen? Does anybody have hints/tips for further
investigation of the cause of this mess?
- Is there a way to correct this issue without using a binary editor
on the db files?

Thanks a lot for reading. Any comment is much appreciated.

Cheers
Thomas Gier
Aachen, Germany

Looks like someone committed a bad svn:mergeinfo property.  Newer
servers check for this and newer clients handle that gracefully (so you
may not _have_ to fix your history).  Just don't get in the habit of
editing revision files if you care about your data.


Daniel,

thanks for your comments! My gut feeling told me, that it's a bad idea 
to edit the revision files. That's why I asked on the list. For the 
record: The live server is still untouched. I edited the revision files 
in a copy of our svn server (it runs as a virtual machin.



 What version of svn runs on the client side?  If it's 1.5, upgrade;
 there have been robustness fixes in the last 3.5 years.


We have several different clients due to our heterogeneous 
infrastructure. All of them should be set up to use 1.5. An upgrade is 
definitely a good idea, discussions about doing this have just started.


I found 3 corrupted revisions so far starting at rev. 12943, HEAD was at 
14667 yesterday evening. I haven't checked in depth yet, whether all of 
the corrupted revisions are caused by the same client; my main focus is 
to get the backups up and running again. Punishing the culprit will be 
my next focus ;).


I going to search the list archives for the tools you mentioned to 
manipulate dump files. Thanks again for helping me. If there are other 
tips worth sharing these would be much appreciated.



Cheers
Thomas Gier
Aachen, Germany

TortoiseSVN assertion failed

[Thomas Krebs]

Hi,

I encountered the following problem in subversion/TortoiseSVN.

Background: We want to move our VisualSVN server from a W2k3 x86 to a
new server hardware/OS W2k8 x64.
I tried to move the repository by dumping/importing to the new
subversion installation. In the first place I tried CollabNet Subversion 
Edge as it has a x64 variant. I could dump the repository

and import it again in the new server without problems.
When I checkout a project the icons do not get the Tortoise overlay
icons and when I right click on the project directory the Windows
shell crashes. This is absolutely reproducibly.
Using the command line tools I can produce the following error with
svn diff:
svn: E235000: In file 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\wc_db.c' 
line 6846: assertion failed (repos_id == last_repos_id)


As I'm not sure if the problem comes from Tortoise or subversion
I tried also VisualSVN and another way to transfer the repository not
by dump/load rather than copying the hotcopy we create on a daily basis
for backup purposes. This showed the same behaviour.

I need to mention that the project in question has some svn:externals
both directories and files. Another project without externals
works fine.
The old server with the still on-line repository also still runs fine.

Hope I could contribute to find the problem.

Thomas

Re: TortoiseSVN assertion failed

[Thomas Krebs]

Am 23.12.2011 02:52, schrieb Stefan Sperling:

On Fri, Dec 23, 2011 at 01:48:58AM +0100, Stefan Sperling wrote:

On Thu, Dec 22, 2011 at 06:16:58PM +0100, Thomas Krebs wrote:

When I checkout a project the icons do not get the Tortoise overlay
icons and when I right click on the project directory the Windows
shell crashes. This is absolutely reproducibly.
Using the command line tools I can produce the following error with
svn diff:
svn: E235000: In file 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 6846: assertion failed (repos_id == last_repos_id)


This is probably a file external which points to a foreign repository.


Are you sure you checked out a new working copy before this happened?


The assertion only happens from the working copy checked out from the
new server.


It wasn't upgraded from a 1.6 working copy?


No, not this working copy.



Can you get the sqlite3 command shell program from
http://sqlite.org/download.html , e.g.
http://sqlite.org/sqlite-shell-win32-x86-3070900.zip ,
and run the following commands in cmd.exe in the working copy?
This will help us understand the problem better.

In the top-level directory of the working copy, run this:
   sqlite3 .svn\wc.db

This will prompt with 'sqlite>'. Enter:
   select repos_id from nodes where local_relpath = '';
   select repos_id, local_relpath from nodes where file_external is not null;


Gives:
sqlite> select repos_id from nodes where local_relpath = '';
1
sqlite> select repos_id, local_relpath from nodes where file_external is 
not null;

2|acisapp.rc
sqlite>

The file acisapp.rc is an external file.


If my suspicion about file externals is correct this should provide some
insight. Normally the repos IDs shown in the first column should all match up.
In your case there will be one or more paths shown with a repos_id that
differs. Can you check the corresponding external definitions for correctness?


What do you mean with correctness? In the original repository they are 
correct in the way that they work. The URL points to a file on the

server like: https://myserver.mydomain.tld/svn/main/.../blabla


Do you have any idea when and how these externals definitions were set
and which client version was used to set them?



It was done 15. of March 2010. The hole repository was converted from
MS VisualSourceSafe before. As we try to use the most recent version
of available tools it was the VisualSVN/TortoiseSVN available then,
1.6.x maybe?


Thanks for your help!


Hope this helps.
Thomas

Re: TortoiseSVN assertion failed

[Thomas Krebs]

Am 23.12.2011 13:08, schrieb Stefan Sperling:

On Fri, Dec 23, 2011 at 12:05:43PM +0100, Thomas Krebs wrote:

Am 23.12.2011 02:52, schrieb Stefan Sperling:

Are you sure you checked out a new working copy before this happened?


The assertion only happens from the working copy checked out from the
new server.



sqlite>  select repos_id from nodes where local_relpath = '';
1
sqlite>  select repos_id, local_relpath from nodes where
file_external is not null;
2|acisapp.rc
sqlite>

The file acisapp.rc is an external file.


Thanks. That clearly shows that svn has a problem.


If my suspicion about file externals is correct this should provide some
insight. Normally the repos IDs shown in the first column should all match up.
In your case there will be one or more paths shown with a repos_id that
differs. Can you check the corresponding external definitions for correctness?


What do you mean with correctness? In the original repository they
are correct in the way that they work. The URL points to a file on
the
server like: https://myserver.mydomain.tld/svn/main/.../blabla


Well, is the URL of this file in the same _repository_ as the working
copy root folder, or not? One server can serve multiple repositories so
your statement doesn't clearly explain the situation.


Yes, in the original server/repository it is in the same
server/repository, after moving it to the new server it (of course)
points to the original server/repository. I would not expect it to be
changed by the transfer.



Can you show the output of these commands?
  cd working_copy
  svn info
  svn info acisapp.rc


Path: .
Working Copy Root Path: D:\tools\Nextra_Application-sonne
URL: https://sonne.mecadtron.de/svn/main/Nextra_Application
Repository Root: https://sonne.mecadtron.de/svn/main
Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
Revision: 19125
Node Kind: directory
Schedule: normal
Last Changed Author: Joachim
Last Changed Rev: 19125
Last Changed Date: 2011-12-21 19:01:41 +0100 (Mi, 21 Dez 2011)


D:\tools\Nextra_Application-sonne>svn info acisapp.rc
Path: acisapp.rc
Name: acisapp.rc
Working Copy Root Path: D:\tools\Nextra_Application-sonne
URL: https://merkur.mecadtron.de/svn/main/Acis_Application/acisapp.rc
Repository Root: https://merkur.mecadtron.de/svn/main
Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
Revision: 19127
Node Kind: file
Schedule: normal
Last Changed Author: thomas
Last Changed Rev: 19056
Last Changed Date: 2011-11-29 14:47:25 +0100 (Di, 29 Nov 2011)
Text Last Updated: 2011-12-22 17:38:40 +0100 (Do, 22 Dez 2011)
Checksum: 2ba869d8c2b25d271149e4fe535f0313a99f1868

I see the situation - the external file points to a URL that is in a
different server, but even that should work, right?


Thanks!


Thomas

Re: TortoiseSVN assertion failed

[Thomas Krebs]

Am 23.12.2011 14:59, schrieb Stefan Sperling:

On Fri, Dec 23, 2011 at 02:26:12PM +0100, Thomas Krebs wrote:

Am 23.12.2011 13:08, schrieb Stefan Sperling:

Well, is the URL of this file in the same _repository_ as the working
copy root folder, or not? One server can serve multiple repositories so
your statement doesn't clearly explain the situation.


Yes, in the original server/repository it is in the same
server/repository, after moving it to the new server it (of course)
points to the original server/repository. I would not expect it to be
changed by the transfer.



Can you show the output of these commands?
  cd working_copy
  svn info
  svn info acisapp.rc


Path: .
Working Copy Root Path: D:\tools\Nextra_Application-sonne
URL: https://sonne.mecadtron.de/svn/main/Nextra_Application
Repository Root: https://sonne.mecadtron.de/svn/main
Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
Revision: 19125
Node Kind: directory
Schedule: normal
Last Changed Author: Joachim
Last Changed Rev: 19125
Last Changed Date: 2011-12-21 19:01:41 +0100 (Mi, 21 Dez 2011)


D:\tools\Nextra_Application-sonne>svn info acisapp.rc
Path: acisapp.rc
Name: acisapp.rc
Working Copy Root Path: D:\tools\Nextra_Application-sonne
URL: https://merkur.mecadtron.de/svn/main/Acis_Application/acisapp.rc
Repository Root: https://merkur.mecadtron.de/svn/main
Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
Revision: 19127
Node Kind: file
Schedule: normal
Last Changed Author: thomas
Last Changed Rev: 19056
Last Changed Date: 2011-11-29 14:47:25 +0100 (Di, 29 Nov 2011)
Text Last Updated: 2011-12-22 17:38:40 +0100 (Do, 22 Dez 2011)
Checksum: 2ba869d8c2b25d271149e4fe535f0313a99f1868

I see the situation - the external file points to a URL that is in a
different server, but even that should work, right?


Ah, this explains it. The repos_id is generated based on root URL and UUID.
So you'll get a different repos_id for the file external.
See create_repos_id() in this file:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_wc/wc_db.c

We might need to revisit this and generated unique repos_id's based
on the UUID only. Not sure if that can be made to work without a working
copy format bump though. This would mean a fix could only be released in 1.8.

Try making the URLs match. That should fix the issue.
If you use relative external syntax you should be able to checkout from
either UR.L Put a line like this in the svn:externals property on the
Nextra_Application folder: ^/Acis_Application/acisapp.rc acisapp.rc


I changed the property values to ^/... and now it is somewhat better but
there is still one referenced subproject that does not work! What can I
do here?

But even though, I apparently won't be able to checkout or update to
older revisions any more...?
I'm getting somewhat nervous ...



Thanks a lot for your help in figuring this out!


Thomas

Re: svnversion documentation bug in the redbook?

[Thomas Gier]

Am 10.01.2012 12:16, schrieb Markus Schaber:

Hi,

http://svnbook.red-bean.com/en/1.7/svn.ref.svnversion.re.html states:


If invoked on a directory that is not a working copy, svnversion assumes
it is an exported working copy and prints "exported":

$ svnversion
exported

However, calling svnversion.exe 1.7.2 (r1207936), installed by the TortoiseSVN 64 Bit 
installer, outputs the message "Unversioned directory":


D:\>svnversion
Unversioned directory

I did not test with older svn versions, as I have no older version available 
here right now, but this may be either a documentation bug or inaccuracy, or it 
also might be an incompatible change which is likely to break some scripts 
relying on the documented behaviour.

Best regards

Markus Schaber

Hi,

just to confirm that older versions behave as documented:

1.)
me@mine:some_unversioned_dir$ svnversion --version
svnversion, Version 1.6.12 (r955767)

2.)
me@mine:some_unversioned_dir$ svnversion
exported


Cheers
Thomas Gier
Aachen, Germany

RE: Permanent removal

[Stümpfig , Thomas]

There may be Companywide retention policies for Document archival. Working, 
Approved, Archived, Deleted. There might be cases where deletion is required by 
these policies. 

Dumpfilter is just a workaround for a new command and privilege (r,w,d). From 
what I can see, permanent delete Issues has already been discussed several 
times. AFAIK there is no plan to implement such a command. Please correct me if 
I am wrong. 


Regards
Thomas Stümpfig

> -Original Message-
> From: Cooke, Mark [mailto:mark.co...@siemens.com]
> Sent: Donnerstag, 12. Januar 2012 08:15
> To: sureshkumar nandakumar; users
> Cc: Sureshkumar.Nandakumar
> Subject: RE: Permanent removal
> 
> Hello,
> 
> > -Original Message-
> > From: sureshkumar nandakumar [mailto:suresh1256...@gmail.com]
> > Sent: 12 January 2012 06:58
> > Subject: Permanent removal
> >
> > Dear Expert,
> >
> I'm not an expert, just another user...
> 
> > Our repository size are increasing on daily basis, we were planed and
> > removed unused tags in SVN.
> 
> "Tags" are very cheap copies that take hardly any space:
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.tags.html
> 
> > But still the size is not increased. And also whatever I have removed
> > all those files are still persist in earlier version.
> > Then there is no use of my removal.
> >
> Correct.  "delete"ing stuff in subversion does not remove the data, just
> removes the items from subsequent revisions.  That is one of the main
> features of source code control...
> 
> > Suppose, I would like to do permanent removal in SVN, how can it
> > possible and how to do permanent removal in SVN?
> 
> You can dump the repository, run it through svndumpfilter and then reload
> the filtered dump into a new repository.
> 
> http://svnbook.red-
> bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svn
> dumpfilter
> 
> http://svnbook.red-
> bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.filteri
> ng
> 
> > If I do permanent removal, how I can take those files in case if it is
> > require for future reference.
> 
> Whilst filtering your dump, also create a different dump file with the stuff
> you "don't want", then you can load it somewhere else in future if you want
> to.
> 
> > Please advise me  with good practice.
> > Your suggestion is more use to me.
> >
> Personally I chose to go the multiple-repository route from the start, 
> creating
> new repos under a parent path for all new projects.  This makes it a lot 
> easier
> to move stuff around (so long as the projects are not too intimately related,
> of course)...
> 
> 
> I have to say that I do not consider 100GB to be hugh these days (although
> disk prices have gone up somewhat recently due to the flooding in Thailand)
> but 1000GB disks are still relativley cheap?
> 
> Hope that helps,
> 
> ~ mark c

Re: TortoiseSVN assertion failed

[Thomas Krebs]

Am 13.02.2012 23:07, schrieb Stefan Sperling:

...

Stefan,

Please be patient. Our new server is not yet back from service, so I
can't check. Furthermore I'll have to investigate to build from
sources, which I didn't do so far.

Thomas
--
Mecadtron GmbH
Sitz der Gesellschaft: Nürnberg
Amtsgericht Nürnberg, HRB20209
Geschäftsführer: Dr. Thomas Krebs
Allersberger Str. 185
90461 Nürnberg
Germany
Tel.: +49 911 462369-0
Fax:  +49 911 462369-11
www.mecadtron.de
www.mecadtron.com

RE: SVN as DMS

[Stümpfig , Thomas]

Hi all,
we have svn through  tortoisesvn successfully running 4 Years for 110 Users / 
>20 documents as DMS.

SVN is successful because
a) it provides History of Projects
b) it provides very good Offline Capabilities!
c) it is simple

one important characteristic about our guys is, that they work in different 
locations throughout Germany and are 50% out of office. So simple collaboration 
while being able to efficiently work offline is key for us.
An other key to the success was the fact that we were able to full text search 
in the Repository. SOLR/Lucene were at hands. 

regards
Thomas

> -Original Message-
> From: Geoffrey Myers [mailto:li...@serioustechnology.com]
> Sent: Mittwoch, 21. März 2012 12:36
> To: Phil Pinkerton
> Cc: Laura Mohiuddin; users@subversion.apache.org
> Subject: Re: SVN as DMS
> 
> Check out 1mage.
> 
> That is the number one followed by 'mage'
> 
> It's not a typo.
> 
> On 03/21/2012 07:20 AM, Phil Pinkerton wrote:
> > SharePoint for documentation. As Subversion has no built-in search
> > attribute so to speak, however there are 3rd party application that
> > claim to search Subversion,
> > but why go thorough all that. I here there have been substantial
> > improvement is the SharePoint application.
> >
> > 2 cents
> >
> > On Mar 14, 2012, at 12:32 PM, Laura Mohiuddin wrote:
> >
> >> Dear Sir/Madam,
> >>
> >> My company IBCS-PRIMAX Software (BD) Ltd. (http://www.ibcs-primax.com
> >> <http://www.ibcs-primax.com/>) is looking to install a Document
> >> Management System for the organization. I suggested SVN, but the DMS
> >> should also come with a dashboard and search facilities. Is there any
> >> way that I can setup subversion to provide me with a dashboard and
> >> search facilities?
> >>
> >> Thank you for your kind cooperation
> >>
> >> Regards,
> >> --
> >> *Laura Mohiuddin***
> >> Manager, Marketing
> >> IBCS-PRIMAX Software (Bangladesh) Limited
> >> House # 51, Road # 10A, Dhanmondi R/A
> >> Dhaka - 1209, Bangladesh
> >> Web: http://www.ibcs-primax.com <http://www.ibcs-primax.com/>
> >
> 
> 
> --
> Until later, Geoffrey
> 
> "I predict future happiness for America if they can prevent
> the government from wasting the labors of the people under
> the pretense of taking care of them."
> - Thomas Jefferson

AW: Subversion 1.6.18 released

[Becker, Thomas]

Hi Stefan,

Thanks for the new release! From the list of changes for 1.6.18 I
learned that the server side performance of "log -g" was improved
(r1152282). This sounds particularly interesting for our setup. Does a
similar fix exist in 1.7.4, too?

Regards,
  Thomas 


 

This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed 
are solely those of the author and do not necessarily represent those of Torex 
(Torex Group of Companies). If you are not the intended recipient of this email 
and its attachments, you must take no action based upon them, nor must you copy 
or show them to anyone.  Please contact the sender if you believe you have 
received 
this email in error.

Torex Retail Solutions GmbH
Sitz der Gesellschaft: Berlin. HRB 102273B Amtsgericht Berlin Charlottenburg.
UST.-ID: DE170817515. Steuer-Nr. 27/448/07028. WEEE-Reg.-Nr. DE 30664749.
Geschaftsfuhrer: Stephen Callaghan, Martin Timmann.


.

RE: Subversion limits?

[Thomas Loy]

This brings up a question for me.  I have a couple of repos that are over 5 
years old and reaching close to 400GB of storage.  I'd like to "trim" the first 
couple of years of versions and store them to some sort of "archive" repo and 
keep the most recent versions in an "active" repo.  I've been toying with 
export commands but haven't had any success.  I would like to back us away from 
any possible limits.

Cheers,

Thomas

From: kmra...@rockwellcollins.com [mailto:kmra...@rockwellcollins.com]
Sent: Friday, September 28, 2012 10:52 AM
To: CHAZAL Julien
Cc: users@subversion.apache.org
Subject: Re: Subversion limits?

> I manage a Subversion server that has the following configuration :
> - SVN 1.6.9
> - FSFS storage mode
> - Apache + mod_dav + subversion modules
> - Linux Suse Enterprise Edition 32-bit
>
> On this SVN server, there are around 1100 SVN repositories for
> around 2000 users. I have small repositories and also very heavy
> repositories (the heaviest weighs around 33 GB on my linux
> filesystem). The sum of my repositories weighs around 1TB.
>
> Do you know if there is a size limitation for a SVN repository in Subversion?
> Do you know if there is a number limitation for SVN repositories on
> a Subversion server? Does-it really decrease performances on the
> subversion server?

This really depends upon the hardware and how the users are using
the server.  That said, the largest server I have has 1800
repositories serving around 6500 users.  The largest repository
is around 400GB with around 7TB of total storage.  The largest
single commit I have seen is around 53GB.

The larger repositories get, the longer it may take to do
maintenance activities such as verifying, filtering, dumping,
and loading a repository.  This is why I'd recommend staying
away from large repositories and large commits, but they do work.

Subversion seems to be I/O bound, even on a high-end SAN.  1.7
seems to definitely chew more CPU and memory though.  But, I've
also seen multiple 1GB NICs near saturation on the server too...

Things that can kill performance:
- Slow filesystem I/O
- Poorly written hook scripts
- Commits with large numbers of files (1M+)
- Lots of files locked (hundred of thousands+)
- Slow authentication servers

You could easily run into issues depending upon the filesystem
type and how you have organized the repositories.  For example,
one large partition *might* be less efficient.

Kevin R.

svn update with --no-auth-cache crashes on Windows 7 x64

[Thomas Oftring]

Hello Guys,

 

on Windows 7 x64 svn update with the parameter --no-auth-cache crashes if
the credentials

has been stored before. The result is a locked working copy that has to be
unlocked by

svn cleanup.

 

The Subversion Client is installed from TortoiseSVN 1.7.10, Build 23359 - 64
Bit

 

svn --version

svn, version 1.7.7 (r1393599)

   compiled Oct  8 2012, 20:42:17

 

Copyright (C) 2012 The Apache Software Foundation.

This software consists of contributions made by many people; see the NOTICE

file for more information.

Subversion is open source software, see http://subversion.apache.org/

 

The following repository access (RA) modules are available:

 

* ra_neon : Module for accessing a repository via WebDAV protocol using
Neon.

  - handles 'http' scheme

  - handles 'https' scheme

* ra_svn : Module for accessing a repository using the svn network protocol.

  - with Cyrus SASL authentication

  - handles 'svn' scheme

* ra_local : Module for accessing a repository on local disk.

  - handles 'file' scheme

* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.

  - handles 'http' scheme

  - handles 'https' scheme

 

Best regards
i.A. Thomas Oftring



smime.p7s
Description: S/MIME cryptographic signature

RE: lock tree or branch - quick question

[Thomas Hemmer]

Have a look at
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html.

If you are in need of a conditional commit access control mechanism, you
should consider using a start-commit hook - see
http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.start-commit.html for
details.


Best regards,

Thomas


-Original Message-
From: Z W [mailto:mpc8...@gmail.com] 
Sent: Tuesday, February 12, 2013 6:49 PM
To: users@subversion.apache.org
Subject: lock tree or branch - quick question

Hi All

We like to stop commits to a certain tree or branch.
Is there a way to do that on SVN ?
Is this an svn admin command ?

Thanks


GO Engineering GmbH - Stolzenbergstr. 13/IV - 76532 Baden-Baden
Geschäftsführer:
Helmut Gerstner, Dipl.-Ing. (FH)
Ralf Wörner, Dipl.-Ing. (FH)
Registergericht: Mannheim HRB 201811

Re: How do I share files?

[Thomas Harold]

On 1/4/2010 7:20 PM, Rolf Marsh wrote:

Hello... I have two projects in Subversion. I am trying, in Visual
Studio 2008 Pro, to share some of the .cs files in Project 'A' with a
new project ('B') I am writing.

I know how to share .cs files from within VS, but how to I get them out
of the repository?


Unlike VSS / SourceOffSite, SVN doesn't (currently... with no plans to 
change) support the sharing of individual files, instead it likes to 
work on a folder (project) level.


So if you can put the resources to be shared in a sub-folder of your VS 
project, you can then use svn:externals to share them to another folder 
as a sub-folder.


http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html

Re: How do I share files?

[Thomas Harold]

On 1/5/2010 10:05 AM, Andy Levy wrote:


As of SVN 1.6, file-level externals are supported. This is very close
to VSS's sharing IIRC (been a few years since I've dealt with VSS).

http://subversion.tigris.org/svn_1.6_releasenotes.html#externals
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html


Ah ha!  I knew as soon as I typed that up that I'd be proven wrong.

RE: ModificationDate after commit

[Thomas Hemmer]

No chance for that, sorry.

Anyway, version information should rather be stored within the resource
area of the PE file instead of abusing the time stamp for this purpose
(provided that you are really talking about Windows, as the term
"EXE-Files" implies).
Perhaps you might ask them to use the VERSIONINFO statement in their
resource script in order to achieve that. This is the recommended
practice within the Windows world.


Best regards,

Thomas

> -Original Message-
> From: Claudius Sailer [mailto:claudius.sai...@lbbw.de]
> Sent: Wednesday, January 13, 2010 9:52 AM
> To: users@subversion.apache.org
> Subject: ModificationDate after commit
>
>
> Hello,
>
> we have at the moment a little problem with svn and the
> modification date of files we want to commit.
>
> we use a software with a lot of EXE-Files where the developer
> company uses the modification date as version information. So
> this informations are important for us.
> the software we get from this company is imported into a
> vendor branch (for every patch or hotfix delivery a new
> vendor brnach) and when we check out we see the correct
> modification date in our file structure because we activated
> use-commit-times = yes. After imported the sent software we
> want to merge this with a branch or trunk and commit the
> changes. After that the modification date is lost.
>
> What can we do that the modification date we can see on file
> structur is also stored in svn and is also possible to see
> after checkout/update?
>
> thanks for help
>
> bye
>
>
> Claudius
>
> Landesbank Baden-Wuerttemberg
> Anstalt des oeffentlichen Rechts
> Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704
> Amtsgericht Stuttgart
>
>



GO Engineering GmbH - Stolzenbergstr. 13/IV - 76532 Baden-Baden
Geschäftsführer:
Helmut Gerstner, Dipl.-Ing. (FH)
Ralf Wörner, Dipl.-Ing. (FH)
Registergericht: Mannheim HRB 201811

RE: svnserve: Interacting in tunnel mode

[Thomas Loy]

Why not use SVN Notifier available at http://svnnotifier.tigris.org?

Cheers,
 
Tom Loy

-Original Message-
From: Piotr Sipika [mailto:psip...@cengen.com] 
Sent: Wednesday, January 13, 2010 2:54 PM
To: users@subversion.apache.org
Subject: svnserve: Interacting in tunnel mode

Hi,
I'm trying to write a notification application which would monitor 
specific repositories and pop-up a dialog when an update has been 
detected. I noticed that 'svn log svn+ssh://...' launches 'svnserve -t' 
via ssh and believe this to be the best way for me to proceed. I tried 
running 'svnserve -t' on the command line and entering sample 'client' 
responses (following the syntax described in 
subversion/libsvn_ra_svn/protocol) to see if that approach would work, 
but no responses were visible. What is the best way for me to interact 
with svnserve in tunnel mode?
Any and all help and suggestions will be much appreciated.
Thanks,
Pete

RE: svn dump and load not preserving all files

[Thomas Loy]

Which OS?  Some operating systems have file size limits of 4 GB or less.

Cheers,
 
Tom Loy


-Original Message-
From: Jeremy Conlin [mailto:jlcon...@gmail.com] 
Sent: Tuesday, January 19, 2010 3:03 PM
To: users@subversion.apache.org
Subject: svn dump and load not preserving all files

I am migrating my repository to a new server.  This requires that I
dump the original and the create a new repository on the new server
and use the svnadmin load command to import everything.  I have been
able to do this for a few of my repositories, but one in particular
isn't working.  The dump file for this repository is > 9 GB.  The load
command starts out, but never finishes.  The size of my repository
gets to 2.1 GB and then it seems to stop even though the svnadmin load
command is still running.  Eventually (> 24 hours) the command stops
(finishes) but the size of my repository is only 2.1 GB when it should
be around 9 GB.  Also, not all of the files have been restored.

Is there a limit in the size of a dump file that can be used?  I would
be surprised if that limit were around 9 GB.  I'm sure there are
repositories that are much larger than that.

Any ideas on what could be wrong?

Thanks,
Jeremy

RE: svn dump and load not preserving all files

[Thomas Loy]

UNIX has actual physical limits to file size determined by the number of bytes 
a 32 bit file pointer can index, about 2.4 GB. for older file systems or 
runtimes.

Depending on your system, you may or may not have large file support. Try

 man fopen64

if you have an older UNIX.

Cheers,
 
Tom Loy


-Original Message-
From: Jeremy Conlin [mailto:jlcon...@gmail.com] 
Sent: Tuesday, January 19, 2010 3:22 PM
To: Thomas Loy
Cc: users@subversion.apache.org
Subject: Re: svn dump and load not preserving all files

On Tue, Jan 19, 2010 at 1:05 PM, Thomas Loy  wrote:
> Which OS?  Some operating systems have file size limits of 4 GB or less.
>
> Cheers,
>
> Tom Loy
>
The original OS was on a Mac, the new OS is some *nix server, probably
Linux.  I don't believe either of these have limitations as small as
4GB.  Am I wrong?

Thanks,
Jeremy


>
> -Original Message-
> From: Jeremy Conlin [mailto:jlcon...@gmail.com]
> Sent: Tuesday, January 19, 2010 3:03 PM
> To: users@subversion.apache.org
> Subject: svn dump and load not preserving all files
>
> I am migrating my repository to a new server.  This requires that I
> dump the original and the create a new repository on the new server
> and use the svnadmin load command to import everything.  I have been
> able to do this for a few of my repositories, but one in particular
> isn't working.  The dump file for this repository is > 9 GB.  The load
> command starts out, but never finishes.  The size of my repository
> gets to 2.1 GB and then it seems to stop even though the svnadmin load
> command is still running.  Eventually (> 24 hours) the command stops
> (finishes) but the size of my repository is only 2.1 GB when it should
> be around 9 GB.  Also, not all of the files have been restored.
>
> Is there a limit in the size of a dump file that can be used?  I would
> be surprised if that limit were around 9 GB.  I'm sure there are
> repositories that are much larger than that.
>
> Any ideas on what could be wrong?
>
> Thanks,
> Jeremy
>

RE: Automated Merging

[Thomas Loy]

Although I can't speak for the poster, this looks to be commercial software.  A 
look at the parent website shows another build product for $1995 per server.  
Could be a useful tool, but since it isn't open source I doubt we'll take a 
close look at it since Build Engineering is at the bottom of the money food 
chain.

Cheers,
 
Tom Loy


-Original Message-
From: Pat Farrell [mailto:pfarr...@pfarrell.com] 
Sent: Monday, February 22, 2010 4:57 PM
Cc: users@subversion.apache.org
Subject: Re: Automated Merging

k...@timpanisoftware.com wrote:
> look at it, please check out the web site http://www.mergemagician.com. 
> If you'd like to download it, shoot me an e-mail and I'll send you the
> download link.

The website has some critical information missing. Before I look futher:

What license do you expect to use?
Is this FOSS? or commercial?

If you expect users/companies to pay for your product, this is close to
SPAM.

-- 
Pat Farrell
http://www.pfarrell.com/

svnserve.exe crashes with "can't create thread"

[Thomas Börkel]

HI!

We have the problem, that the svnserve.exe process crashes when doing a
pretty large commit.

It seems to allocate 700 MB memory and then it crashes with "can't
create thread".

Using svnserve.exe 1.5.5. The machine has 6 GB memory.

Any hints would be greatly appreciated.

Thanks!

Thomas

Could not resolve path ... for history error

[Thomas O'Brien]

Hi all,

I recently ran into a problem retrieving revision information. The errors
for retrieving revision
history (using svn blame) happened after a recent move of a directory
containing Java
files. After the move I started to receive errors when using 'svn blame' so
I tried to do a
reverse merge. When using 'svn blame' continued to have errors I tried using
svn delete to
remove the directory and svn copy with the revision number before the
directory move to
restore the directory to the revision before the move. Now when I try to use
svn blame I am
receiving "Could not resolve path ... for history".

The exact line I am using is:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/ArchitectSession.java


which returned:
svn: Could not resolve path
/trunk/src/ca/sqlpower/architect/ArchitectSession.java for history

Running the command:
svn cat
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/ArchitectSession.java


returned the file as it existed before the directory move.

I have tried searching the web and the mailing list for users with a similar
problem but have
found none. From the "Version Control with Subversion" section on
resurrecting deleted items
using 'svn delete' on the directory then 'svn copy' on the revision before
the change should link
the new directory and files with the ones before the move and remove this
error but it did not.

Is there a way to restore my directory so the revision history of the files
are linked with the originals?



The full set of changes were as follows:
For reference:
Project: http://code.google.com/p/power-architect/
svn: version 1.6.3
Eclipse: version 3.4.1
Subclipse: version 1.6.3

Before any changes I was on r3393.

I started with moving the directory and all subdirectories and files at
trunk/src/ca to
trunk/src/main/java/ca using Eclipse and Subclipse.
The log:
svn log -v -r 3394 http://power-architect.googlecode.com/svn/trunk/

returned:
r3394 | thomasobrie...@gmail.com | 2010-03-24 17:07:56 -0400 (Wed, 24 Mar
2010) | 3 lines
Changed paths:
...
   D /trunk/src/ca
...
   A /trunk/src/main
   A /trunk/src/main/java
   A /trunk/src/main/java/ca (from /trunk/src/ca:3393)
...
This appears that the folder was moved correctly and the history of
/trunk/src/main/java/ca
is linked to /trunk/src/ca as expected.

Next I tried to view revision information:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/main/java/ca/sqlpower/architect/architectsession.j...@3394

returned:
svn: Could not resolve path /trunk/src/ca/ArchitectSession.java for history
I noticed the path at this point was wrong. The ArchitectSession.java file
is located at
/trunk/src/ca/sqlpower/architect.

Verifying revision information:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/architectsession.j...@3393

returned:
1600 fuerth /*
  2099 jeff...@sqlpower.ca  * Copyright (c) 2008, SQL Power Group Inc.
  2099 jeff...@sqlpower.ca  *
  2099 jeff...@sqlpower.ca  * This f
Since the revision before my commit caused the error I decided it would be
best to
reverse the change.

The first step I took to try and reverse the change was I went to Eclipse
and did a reverse
merge from r3394 to r3393. This reversed the file move but retrieving
revision information
was still failing:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/architectsession.j...@3395

returned:
svn: Could not resolve path
/trunk/src/ca/sqlpower/architect/ArchitectSession.java for history
The path to the file was now correct but the path still could not be
resolved.

Finally, I decided to try and remove the entire directory and copy
everything from r3393,
before the directory change.
I tried:
svn delete -m "removing all of src to check it back in to fix history."
https://power-architect.googlecode.com/svn/trunk/src
followed by:
svn copy https://power-architect.googlecode.com/svn/trunk/s...@3393
https://power-architect.googlecode.com/svn/trunk/src

However, this still resulted in:
svn blame
http://power-architect.googlecode.com/svn/trunk/src/ca/sqlpower/architect/ArchitectSession.java


returning:
svn: Could not resolve path
/trunk/src/ca/sqlpower/architect/ArchitectSession.java for history

Any help in restoring my revision history would be greatly appreciated.

Thanks,

Thomas

Getting started with Subversion.

[Thomas Garrod]

OK, I'm a complete rube. I don't know the second thing about  
Subversion (I know it is version control). I need Subversion, and I  
don't know where to start. Here are a few facts:


1. I have a foundation.
2. I need collaborators to be able to work together virtually sharing  
development files.
3. We are working with graphics, .swf, .as, .fla, XML, XSLT, audio and  
video files.

4.  Google Project uses Subversion.
5. I have a Mac with 10.5.8 OS
6. I don't know where to start with Subversion.

I don't know what a binary package is, but I do know I need to have a  
version of Subversion on my Mac. Others will need to have a version  
for Windows. Let's start with me, what do I need to download? Looking  
at the options for Mac OS X, I have no idea which to chose.


Can someone give me a start?

Thomas Garrod, M.Ed.
KeelWorks Foundation
Executive Director

Is there a simple log/diff frontend (like gitk)?

[Thomas Allen]

Hello everyone,

One thing that I took for granted when doing all of my development in
Git was the always-reliable gitk which provides cross-platform log and
diff browsing. I'm sure it does more, but those were the main things I
used it for.

I am now working with a Subversion repository. Maybe I have not yet
mastered the "log" command, but  I find the output of the following
two commands to be confusing:

$ svn log -r HEAD

r3617 | tallen | 2010-04-12 15:57:35 -0400 (Mon, 12 Apr 2010) | 1 line

full comments + jslint fixes

$ svn log | grep tallen # outputs nothing

In general it would be very nice to have a tool to facilitate browsing
recent revisions and their diffs; I do not need it to help with
committing my changes or anything along those lines.

So, does anybody know of a simple, cross-platform, open-source
Subversion browser? I am on a Mac, and it seems that the only options
are proprietary and heavy, such as Versions and CornerStone...

Thomas Allen

Slowness on checkouts after upgrade/migration

[Thomas Loy]

Greetings,

We just upgraded from 1.3.1 to 1.6.9 (Woo hoo!) and put the new SVN on some 
brand new servers.  At the same time, we also setup some basic disaster 
recovery using svnsync to mirror the commits from our primary SVN server to our 
backup SVN server.  I expected some performance degradation on commits, but we 
are getting some extreme degradation on checkouts as well.  One of our 
applications uses Ivy for dependency management and it has a lot of third-party 
jars, some very large.  On our build server, a build that used to take 10 
minutes is now taking 30 minutes.  Most of the additional time appears to be in 
the Ivy update/checkout for the application, but time to update/checkout the 
application's source code is also taking increased time.  Keep in mind that 
these are essentially "clean" builds with complete retrievals of the Ivy 
repository and the source code repository.  Does anyone have any ideas why our 
checkouts are taking so much longer than they used to?

Regards,

Thomas Loy

Software Build Engineer
Cbeyond, Inc.

RE: SVN Error

[Thomas Loy]

That would be the first thing I would do.  What is the current timeout?  Are 
you trying to use http or https?

Regards,

Tom

From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com]
Sent: Wednesday, May 19, 2010 10:58 AM
To: users@subversion.apache.org
Subject: SVN Error

Hello,
I am getting an error like this. I am using SVN 1.6.11 and Apache 2.2.14

svn: REPORT of '/!svn/vcc/default': Could not read response body: connection 
was closed by server

I tried SVN checkout using file:/// method and it did not have any 
issues.

Will changing "Timeout" in Apache configuration will help here?

Best,
Hemant
Unstoppable..

RE: SVN Error

[Thomas Loy]

Glad to hear it.  We had similar problems using svnsync when performing the 
initial sync.  We had a couple of historic commits of a lot of third-party 
libraries that were very large.  We had to bump the timeout up to 600 sec. to 
get svnsync to complete the sync.  Now that we are syncing happily along, we 
will probably turn it back down to 300.

Regards,

Tom

From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com]
Sent: Thursday, May 20, 2010 3:17 AM
To: Thomas Loy; users@subversion.apache.org
Subject: RE: SVN Error

Hey - setting Timeout as 300 resolved the problem.

Best,
Hemant
Unstoppable..

From: Wadhavankar, Hemant
Sent: Thursday, May 20, 2010 10:27 AM
To: 'Thomas Loy'; users@subversion.apache.org
Subject: RE: SVN Error

Thanks Tom. I am using http and not https. I noticed "Timeout 300" in 
conf/extra/httpd-default.conf - but it is not getting called (include) in 
httpd.conf. So I will play around with it.

Best,
Hemant
Unstoppable..

From: Thomas Loy [mailto:thomas@cbeyond.net]
Sent: Wednesday, May 19, 2010 8:50 PM
To: Wadhavankar, Hemant; users@subversion.apache.org
Subject: RE: SVN Error

That would be the first thing I would do.  What is the current timeout?  Are 
you trying to use http or https?

Regards,

Tom

From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com]
Sent: Wednesday, May 19, 2010 10:58 AM
To: users@subversion.apache.org
Subject: SVN Error

Hello,
I am getting an error like this. I am using SVN 1.6.11 and Apache 2.2.14

svn: REPORT of '/!svn/vcc/default': Could not read response body: connection 
was closed by server

I tried SVN checkout using file:/// method and it did not have any 
issues.

Will changing "Timeout" in Apache configuration will help here?

Best,
Hemant
Unstoppable..

RE: Automatic commission?

[Thomas Loy]

No.  You must use the SVN rename.

Regards,

Tom


-Original Message-
From: Peng Yu [mailto:pengyu...@gmail.com] 
Sent: Monday, May 24, 2010 5:54 PM
To: Daniel Becroft
Cc: users
Subject: Re: Automatic commission?

On Mon, May 24, 2010 at 4:46 PM, Daniel Becroft  wrote:
> On Tue, May 25, 2010 at 7:40 AM, Peng Yu  wrote:
>> It seems that I have to specify which file or files to commit. This
>> will be a problem if I always simultaneously edit tens of files before
>> I can do a commission. Is there an automatic way to figure out which
>> files should be commit and commit them?
>
> You can not specify anything, and it will commit all changes (e.g. svn
> commit -m ).
>
> See the book for an example:
> http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.commit

If I rename the files locally without using svn command, then I commit
without any arguments. Will the command 'commit' be able to figure
about the file with new name is modified from the old file?

-- 
Regards,
Peng

RE: compact repository (many files)

[Thomas Loy]

I wish I had an answer for you.  We have a similar situation.  I manage a dozen 
production SVN Repos and some are getting quite large.  One repo has over 
35,000 revisions.  Some of the original revisions from years ago I'd like to 
extract and archive and just maintain the archive with history for say the past 
two or three years.  I know I can dump a revision range, but as I understand 
it, a delete really doesn't delete.  I can always go back to the deleted 
revisions in the history and get them.  I would love to have a "permanent 
delete" that would help me eliminate some of the detritus my repos have and 
would help reduce their size.

Regards,

Tom


-Original Message-
From: Paul Ebermann [mailto:paul-eberm...@gmx.de] 
Sent: Wednesday, May 26, 2010 11:53 AM
To: users@subversion.apache.org
Subject: compact repository (many files)

Hello,

I have here a personal Subversion repository hosted on my university account 
(for easy
access from everywhere via SSH). (Its format is a 1.5 FSFS, from the 
information in the
meta-files.)

I'm now to revision 2529, which means the whole repository has 5098 files (most 
of them in
db/revs and db/revprops), and which each new revision I get two more files.

(The whole repository is about 45 MB big, but that's not the matter here.)

The problem now is that I have a quota limitation of 3 files here 
(additionally to a
size limit), and my svn repository fills now about 1/6 of this, steadily 
growing, forcing
me to delete other files ...

Is there any way to reduce the file number of the repository without throwing 
away
information? As in, throw the changes in revisions 0 ... 999 together in one 
file (and
this way even safe some space for better compression)? (I don't care for worse
performance, as those old revisions are used only very seldom.)

I found nothing about this by extensive googling so I assume such a function is 
not yet
implemented. Is this really a new idea, or was it discussed before and 
rejected? Or is
there a simple workaround?


Paul

I need a volunteer subversion manager

[Thomas Garrod]

Dear Subversion friends. Call me stupid, call me tech-ignorant, or call me
lazy, but I'm having difficulty understanding how to set up subversion. Part
of my problem is that I am the director of the organization; I don't get as
much chance to focus on this. And frankly, the manual puzzles me.

KeelWorks is a non-profit foundation with no paid staff. We are building a
learning intervention to help learners learn better. We hope to reach out to
the economically disadvantaged across the globe. I have ten teams of
instructional designers building eLearning storyboards and we hope to move
soon to eLearning development.

To do this we need to have a way to post files and share them without chaos.
Most of the people developing will learn as they go. We'll work with
Dreamweaver, Captivate, and Flash.

Getting people to volunteer their time is a hard sell. It won't work if they
have to figure anything out. I have to give them well-formed process and
clear instructions. I don't have anyone who has stepped up to manage this
subversion repository. And I can't seem to do it myself.

If someone in this community would be good enough to help us set up our
Google Project server repository and to guide users in setting up and using
clients, it would be a great help.

Thomas Garrod
The KeelWorks Foundation
http://keelworks.org

replacing all code with latest SVN regardless of conflicts or uncommitted changes or whatever

[Thomas Anderson]

Say I've added a bunch of debug code to files in a particular
directory and that I want to now remove all the debug code.  I could
search through the file and manually remove it all or I could just re
checkout the directory from SVN and replace the debug directory with
the latest SVN code.  Problem is, typing in "svn checkout" requires
you know the URL of the repository / directory you're checking out.

If you could do something like "svn refresh" and have it just look at
the .svn/entries file to get the URL that'd be a lot easier.  I mean,
ease of use is why "svn update" exists.  You could just recheck out a
repository every time you wanted to update your code to the latest
version and manually do diffs comparing the newly checked out against
your own and merging where conflicts exist as appropriate but "svn
update" makes it a lot easier.  Similarly, although technically maybe
unnecessary, I think an "svn refresh" command would be nice.

Fw: Potential issue with svn:externals

[Thomas Giesel]

Hi,

still searching for somebody who could confirm or disprove if this is a bug 
for the issue tracker.

In the meantime there was a conversation on IRC which might contain 
additional useful information:
http://www.pastie.org/1006865

The original mail I sent to dev list:

Hi all,

there's an issue with svn:externals when using them in subdirectories,
which should be fine according to the documentation.

The main question is if you agree wether I should file a bug about this.

Let's start with these svn:externals:

^/tags/libs/a/1.0   a
^/tags/libs/b/2.0   b
^/tags/apps/c/1.1   src/c
^/tags/apps/d/2.0   src/d

svn up .
svn st .

>>>>>>>>>>>>>>>
 M  .
X   a
X   b
X   src
Performing status on external item at 'a'
Performing status on external item at 'b'
Performing status on external item at 'src/c'
Performing status on external item at 'src/d'
<<<<<<<<<<<<<<<

This look okay so far, even if "X src/c" and "X  src/d" would be better
IMHO, since "src" was created implicitely and is not really a direct
external. (empty lines removed from output)

Now let's remove two of these lines, the rest looks like this:

^/tags/libs/a/1.0 a
^/tags/apps/c/1.1 src/c

svn up .
svn st .

Results in output which looks inconsistent to me:

>>>>>>>>>>>>>>>
 M  .
X   a
?   b
X   src
Performing status on external item at 'a'
Performing status on external item at 'src/c'
<<<<<<<<<<<<<<<

The directory src/d remains unchanged on my hard disk and does not get
any comment on "svn st". I would expect something like "?  src/d" like
is is printed for the directory "b".

This may be dangerous if people use 
"svn ps svn:externals -F  ." and don't check
carefully for removed entries.

btw: Subversive even shows "src/d" as normal external in the project
explorer after these two lines have been removed, while "b" is shown
with an exclamation mark (Obstructed). "src/d" can't be removed with
Eclipse then, one has to "rm -r" it manually from a shell window.

Our software has many different configurations with different versions
of different subsystems, this can be done easily with externals, better
than using branches for all variations. Hopefully this feature will 
get even better in the future ;)

(Server: >= 1.6.x, Client: 1.6.11, both on Linux)

Regards,
Thomas

RE: older versions of the subversion server

[Thomas Loy]

We just upgraded from 1.3 to 1.6.x.  Fortunately, we also got new servers for 
the new version, so that helped up.  We upgraded by installing SVN on the new 
servers, exporting our repositories from the old (current production) servers, 
and importing to the new servers.  If you have that option, it worked very well 
for us as we were able to do a dry run of the complete upgrade process.

No, when working with the enterprise’s software repository, you can’t be too 
cautious.  When planning an “in place” upgrade, it would be good to start with 
your current version and work out any issues you find on the upgrade.  On the 
bright side, we had virtually no issues on our upgrade – the major issue was 
trying to get all of our users to upgrade their clients.

Regards,

Tom

From: Alin [mailto:alin.tomoi...@ttu.edu]
Sent: Thursday, June 17, 2010 4:09 PM
To: Ryan Schmidt
Cc: users@subversion.apache.org
Subject: Re: older versions of the subversion server

That is a very good question.

Our subversion server has not been updated in a while and it is still on 
version 1.4.2. I was looking into updating it to take advantage of the new 
merge tracking features (among others).

Since we are using such an old version, I wanted to replicate our production 
environment on a test server (thus requiring version 1.4.2)  and performing the 
upgrade there first.

Do you think I am being overly cautious? What are the chances for a problem to 
occur in the upgrade process?

Thank you,
Alin



-Original Message-
From: Ryan Schmidt 
mailto:ryan%20schmidt%20%3csubversion-20...@ryandesign.com%3e>>
To: Tomoiaga, Alin 
mailto:%22Tomoiaga,%20alin%22%20%3calin.tomoi...@ttu.edu%3e>>
Cc: users@subversion.apache.org 
mailto:%22us...@subversion.apache.org%22%20%3cusers@subversion.apache.org%3e>>
Subject: Re: older versions of the subversion server
Date: Wed, 16 Jun 2010 16:13:32 -0500



On Jun 16, 2010, at 11:11, Alin wrote:



> I am trying to install an older version of subversion (1.4.2) on two Linux 
> systems Ubuntu and Red Hat ( 2.6.31-20-generic Ubuntu and  2.6.18-164.el5 ) 
> and I am having a hard time locating the older version packages for 
> subversion.

> I tried both the Ubuntu and Red Hat repositories and the subversion website.

> Can you please tell me if these packages are still available for download?



Certainly the source is still available from the Subversion project's web site. 
Not sure where you'd get older precompiled packages for various OSes.



Note that Subversion 1.4.x and earlier are unsupported by now, and when 1.7.0 
comes out, support for 1.5.x will be dropped. Why do you need to use such an 
old version?

RE: older versions of the subversion server

[Thomas Loy]

No problem.  That was a good tip from Ryan on the start-commit hook.  I wish I 
had know about it, although we did publicize to our users well in advance that 
they needed to upgrade and they could do it anytime before we did our server 
upgrade.  I really only got one call from a user and he was and Eclipse user.

Regards,

Tom

From: Alin [mailto:alin.tomoi...@ttu.edu]
Sent: Thursday, June 17, 2010 4:29 PM
To: Ryan Schmidt; Thomas Loy
Cc: users@subversion.apache.org
Subject: Re: older versions of the subversion server

Ryan and Thomas,
Thank you very much for your advice.


-Original Message-
From: Ryan Schmidt 
mailto:ryan%20schmidt%20%3csubversion-20...@ryandesign.com%3e>>
To: Thomas Loy 
mailto:thomas%20loy%20%3cthomas@cbeyond.net%3e>>
Cc: Tomoiaga, Alin 
mailto:%22Tomoiaga,%20alin%22%20%3calin.tomoi...@ttu.edu%3e>>,
 users@subversion.apache.org 
mailto:%22us...@subversion.apache.org%22%20%3cusers@subversion.apache.org%3e>>
Subject: Re: older versions of the subversion server
Date: Thu, 17 Jun 2010 15:24:56 -0500



On Jun 17, 2010, at 15:18, Thomas Loy wrote:



> On the bright side, we had virtually no issues on our upgrade – the major 
> issue was trying to get all of our users to upgrade their clients.



There is at least a way you can automate advising your users to upgrade to 
Subverison 1.5 or later if they have 1.4.x or earlier: the start-commit hook 
script. This hook script will be passed a list of client capabilities; if the 
client capabilities do not include mergeinfo, you know it's older than 1.5. You 
could at that point abort the commit and print an error message advising the 
user to upgrade their client.



http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html



I don't know of a way to detect the client version beyond that, though. And 
unfortunately early versions of 1.5.x weren't totally satisfactory for merge 
tracking, so you really do want your clients to be the latest version.

Getting started with subversion

[Thomas Garrod]

I'm sorry guys (and gals), I have a very basic question: How to you get
files into your repository. I've got the O'Reilly book (2nd Edition), but
I'm afraid is presumes too much of me.

I looked at chapter 2, page 18, and it includes the following:

...typically use this when you have an existing tree of files that you want
to begin tracking in your Subversion repository. For example:

$ svnadmin create /ver/svn/newrepos
$ svn import mytree file:///var/svn/newrepos/some/project \

For the first line: what part of this is variable?
For the second line: how do I know what to enter for "var/svn?newreos/
some/project?"

The path to my files on my computer is Macintosh HD/Users/TommyHome/
KeelWorks/Projects/GraphicArt.

My command client is Path Finder is set to "Macintosh: MyTaxes09
TommyHome$" This is wrong, but I don't know how to change the
directory. All tips accepted, except "get a brain" (I tried that).

When I typed 'svnadmin create /ver/svn/newrepos' I got the following
response:

svnadmin: Repository creation failed
svnadmin: Could not create top-level directory
svnadmin: Can't create directory '/var/svn/newrepos': No such file or
directory
Macintosh:GraphicArt TommyHome$

If someone would simple pretend that I am a 2-year old and tell me how to
add files to the repository, I would be eternally grateful (or at least for
a long time).

Tomas

Re: Getting started with subversion

[Thomas Garrod]

Thanks Bob. I looked at the free book, but it looks word-for-word the same,
Getting New Data into Your Repository is exactly the same. Can you point me
to the right place?

I thought perhaps the information under Initial Check Out would set up an
initial file structure.

I tried:
Macintosh:GraphicArt TommyHome$  svn checkout
https://ksfgraphics.goolecode.com/svn/trunk/ kwfgraphics --username
whidbeytomas

---and got this:
svn: OPTIONS of 'https://ksfgraphics.goolecode.com/svn/trunk': Could not
resolve hostname `ksfgraphics.goolecode.com': Host not found (
https://ksfgraphics.goolecode.com)

I tried this again appending "--password *mypassword" *to the end, that got
me 'path not found'

I tried:
Macintosh:GraphicArt TommyHome$ *svnadmin create /var/svn/newrepos*
*
*
---and got:
svnadmin: Repository creation failed
svnadmin: Could not create top-level directory
svnadmin: Can't create directory '/var/svn/newrepos': No such file or
directory

Surely someone has been here before?! You can't all start with a repository?
Can someone tell me which section of the free manual addresses my situation?
or give me explicit instructions? If I can get this down, I will be training
a host of interns to use this system. They are waiting for me.

Tomas


You might want to read the free book... it seems to me it explains it well
> and for someone that has never used it.

http://svnbook.red-bean.com/nightly/en/svn-book.html

On Wed, Jul 14, 2010 at 12:49 PM, Bob Archer  wrote:

> > I'm sorry guys (and gals), I have a very basic question: How to you
> > get files into your repository. I've got the O'Reilly book (2nd
> > Edition), but I'm afraid is presumes too much of me.
>
> You might want to read the free book... it seems to me it explains it well
> and for someone that has never used it.
>
> http://svnbook.red-bean.com/nightly/en/svn-book.html
>
>
> > I looked at chapter 2, page 18, and it includes the following:
> >
> > ...typically use this when you have an existing tree of files that
> > you want to begin tracking in your Subversion repository. For
> > example:
> >
> > $ svnadmin create /ver/svn/newrepos
> > $ svn import mytree file:///var/svn/newrepos/some/project \
> >
> > For the first line: what part of this is variable?
> > For the second line: how do I know what to enter for
> > "var/svn?newreos/
> > some/project?"
>
> The first line creates the repository. You specify whatever location you
> want.
>
> The second line you know it is /var/svn/newrepos , which is the path to
> your repository, frankly because you remember what path you used when you
> created it. If course, the file:// protocol is probably not what you will
> use in production unless you are a single dev working on your projects.
>
> >
> > The path to my files on my computer is Macintosh
> > HD/Users/TommyHome/
> > KeelWorks/Projects/GraphicArt.
> >
> > My command client is Path Finder is set to "Macintosh: MyTaxes09
> > TommyHome$" This is wrong, but I don't know how to change the
> > directory. All tips accepted, except "get a brain" (I tried that).
>
> I'm not sure what you mean here by "this is wrong". BTW: I haven't used
> PathFinder with svn. I just use the command line on my Mac.
>
> >
> > When I typed 'svnadmin create /ver/svn/newrepos' I got the
> > following response:
> >
> > svnadmin: Repository creation failed
> > svnadmin: Could not create top-level directory
> > svnadmin: Can't create directory '/var/svn/newrepos': No such file
> > or directory
> > Macintosh:GraphicArt TommyHome$
> >
>
> On your mac you probably want to create the repository in your home
> folder... something like:
>
> svnadmin create ~/svn/mytestrepo
>
>
> > If someone would simple pretend that I am a 2-year old and tell me
> > how to add files to the repository, I would be eternally grateful
> > (or at least for a long time).
> >
> > Tomas
>
> Read the redbook... I think it explains it very well.
>
> BOb
>
>
>

RE: viewing svn logs?

[Thomas Loy]

On Windows, Tortoise SVN is my choice.

Regards,

Tom

From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com]
Sent: Friday, August 06, 2010 10:58 AM
To: 'Tom Cruickshank'; users@subversion.apache.org
Subject: RE: viewing svn logs?

What about TortoiseSVN?




Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03




From: Tom Cruickshank [mailto:tcruic...@gmail.com]
Sent: 06 August 2010 15:54
To: users@subversion.apache.org
Subject: viewing svn logs?
Hey Guys,
   Wondering if there is any software out there (open source or 
proprietary) which would allow someone to view SVN logs in a gui based 
environment?

What do you folks typically use if you don't mind me asking?

Tom

RE: Setting "tags" to read only ?

[Thomas Loy]

We use access control to keep tags read-only, although pre-commit hooks would 
work as well, access control was simpler and a bit more foolproof.

Regards,

Tom


-Original Message-
From: a.sk...@gmail.com [mailto:a.sk...@gmail.com] On Behalf Of Alexander Skwar
Sent: Wednesday, September 29, 2010 11:11 AM
To: Phil Pinkerton
Cc: users@subversion.apache.org
Subject: Re: Setting "tags" to read only ?

Hi.

2010/9/29 Phil Pinkerton :

> Is it possible to set these tags to read-only once ther are copied from the
> trunk to the tags directory ?

How about using access control
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
so that only a certain user or group has rw access to the tags directory,
while all others have just read r access?

Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯
↯ Chat (Jabber/Google Talk) ↣ a.sk...@gmail.com , AIM: alexws77  ↯

Update Error over VPN

[Stümpfig , Thomas]

Hi everybody,
we have a strange issue here with svn 1.8.11
upon svn update with we get a REPORT require on '/svn//!svn/me' failed

but only on a specific WAN connection.
With a lan connection everything is fine. Updates to the same working folder 
are ok.
The WAN connection is a Juniper VPN connection (ipsec, nat traversal 
compatible)  over a carrier grade nat internet connection.

Any idea what is going wrong here?

Regards
Thomas




-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Update Error over VPN

[Stümpfig , Thomas]

Nobody has any suggestions? What are the influences on networkside other than a 
correct http(s)/tcp/ip transmission.
Where can I get info about timouts etc..

From: Stümpfig, Thomas [mailto:thomas.stuemp...@siemens.com]
Sent: Mittwoch, 4. März 2015 15:27
To: users@subversion.apache.org
Subject: Update Error over VPN

Hi everybody,
we have a strange issue here with svn 1.8.11
upon svn update with we get a REPORT require on '/svn//!svn/me' failed

but only on a specific WAN connection.
With a lan connection everything is fine. Updates to the same working folder 
are ok.
The WAN connection is a Juniper VPN connection (ipsec, nat traversal 
compatible)  over a carrier grade nat internet connection.

Any idea what is going wrong here?

Regards
Thomas




-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Update Error over VPN

[Stümpfig , Thomas]

Hi Bert, All
"a REPORT require on '/svn//!svn/me' failed " this is the only message my 
colleague is getting. Same message with command line tools ,
. Server side (VisualSVN) error cannot exactly be linked to the users action 
-perhaps this could be an enhancement to mod_dav_svn - send a transaction id in 
the http header and log it. The server Error very probably is: "Error writing 
base64 data: APR does not understand this error code  [500, #620018] (We have 
~300 commits per day and many more reading operations.
The error occurs only in WAN circumstances, and only on large updates (>2GB). 
In LAN environment everything is ok. The user in question has got a 100Mb/s 
DOCIS3.0 line IPV6 based IPV4 carrier grade nat accessing the companies network 
via juniper client.
 Meanwhile I read about apache timeout,... and set this to 1800 -> 30min... I 
hope this fixes the issues  I'll keep this list informed


regards
Thomas

From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Sonntag, 8. März 2015 13:20
To: Stümpfig, Thomas; users@subversion.apache.org
Subject: RE: Update Error over VPN

Hi Thomas,

It is kind of hard to answer questions on what might have failed if you only 
post a specific part of a failure.

Usually the error would contain a lot more details, such as how it failed; 
possibly network related errors.  You just note that it failed... and then try 
to ask us why.

In general the Subversion client should have told you why, and then we might be 
able to help you resolve why it failed... Now the only thing we can do is note 
that it failed... Which is something you already knew.

The E0001234 codes provide valuable information and in many cases allow you to 
google for the result, but in many cases there are even more helpful hints in 
the error messages.

        Bert


From: Stümpfig, Thomas [mailto:thomas.stuemp...@siemens.com]
Sent: zondag 8 maart 2015 10:12
To: Stümpfig, Thomas; 
users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: RE: Update Error over VPN

Nobody has any suggestions? What are the influences on networkside other than a 
correct http(s)/tcp/ip transmission.
Where can I get info about timouts etc..

From: Stümpfig, Thomas [mailto:thomas.stuemp...@siemens.com]
Sent: Mittwoch, 4. März 2015 15:27
To: users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: Update Error over VPN

Hi everybody,
we have a strange issue here with svn 1.8.11
upon svn update with we get a REPORT require on '/svn//!svn/me' failed

but only on a specific WAN connection.
With a lan connection everything is fine. Updates to the same working folder 
are ok.
The WAN connection is a Juniper VPN connection (ipsec, nat traversal 
compatible)  over a carrier grade nat internet connection.

Any idea what is going wrong here?

Regards
Thomas




-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Copy and Reduce the size of SVn repos

[Stümpfig , Thomas]

Hi all
Actually splitting projects is not a solution to something that eliminates old 
data. Think of a project with one file only. Legally one might be forced to 
keep the file at least for 5 or 10 Years. But after this period the very same 
old revisions of the file must be destroyed because of other legal or 
contractual obligations. There is enough reason for final deletion of old data. 
I appreciate very much the work of open source programmers. And as a matter of 
fact we deal with svn's limitations as we use it with much success for our 
purposes.  Said this, one of the most wanted feature is obliteration.

Regards
Thomas

-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com]
Sent: Dienstag, 10. März 2015 23:37
To: Nico Kadel-Garcia
Cc: Branko Čibej; Subversion
Subject: Re: Copy and Reduce the size of SVn repos

On Sun, Mar 8, 2015 at 8:27 PM, Nico Kadel-Garcia  wrote:
> >>
>> Heh, I have to ask, where did you find that doctrine? There's no such
>> thing. It's all a lot more mundane: First, you have to get people to
>
> I've had to deal with that doctrine personally and professionally
> since first working with Subversion in 2006. It comes up again eveyr
> so often, for example in
> http://subversion.tigris.org/issues/show_bug.cgi?id=516 and is
> relevant to the original poster's request.
>
> There can be both software and legal reasons to ensure that the
> history is pristine and never forgets a single byte. But in most
> shops, for any lengthy project, *someone* is going to submit
> unnecessary bulky binaries, and *someone* is going to create spurious
> branches, tags, or other subdirectories that should go the way of the
> passenger pigeon.
>
>> agree what "obliterate" actually means; there are about five meanings
>> that I know of. And second, all five are insanely hard to implement
>> with our current repository design (just ask Julian, he spent about a
>> year trying to come up with a sane, moderately backwards-compatible 
>> solution).
>>
>> -- Brane
>
> I appreciate that it's been awkward. The only workable method method
> now is the sort of "svn export; svn import to new repo and discard old
> repo" that I described, or a potentially dangerous and often fragile
> dump, filter, and reload approach that preserves the original URL's
> for the repo, but it's really not the same repo.
>
> It remains messy as heck. This is, in fact, one of the places where
> git or other systems's more gracious exclusion or garbage collection
> tools doe better. Even CVS had the ability to simply delete a
> directory on the main fileserver to discard old debris: it's one of
> the risks of the more database based approach of Subversion to
> managing the entire repository history.

Maybe it is time to change the request from 'obliterate' to _any_
reasonable way to fix a repository that has accumulated cruft.   And a
big warning to new users to put separate projects in separate repositories from 
the start because they are too hard to untangle later.  I've considered dumping 
ours and trying to split by project, but I'm not even sure that is possible 
because many were imported from CVS then subsequently moved to improve the 
layout.  So I can't really filter by path.

--
   Les Mikesell
 lesmikes...@gmail.com
-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Update Error over VPN

[Stümpfig , Thomas]

Hi all,
i'll try to get a Wireshark extract that covers the error. The problem I have 
with it, is that Wireshark on the server will capture a huge amount of data. We 
have ~20-100 parallel updates on the server. I observed peaks with 250 http 
sessions. Capturing the interface for a long time will be difficult. (I am not 
very good with Wireshark capture filters). How can I produce a serf debug 
output? The platform is Windows Server 2008R2 with current Microsoft patches.  
I am not aware of the exact configuration of the network. Siemens is a big 
company, and the hardware over the WAN is also unknown to me. :-(. I am just 
the guy who cares about the svn server.


Regards
Thomas

-Original Message-
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Dienstag, 10. März 2015 14:33
To: 'Alfred von Campe'
Cc: 'Branko Čibej'; Stümpfig, Thomas; users@subversion.apache.org; 'Nico 
Kadel-Garcia'
Subject: RE: Update Error over VPN



> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: dinsdag 10 maart 2015 13:59
> To: Alfred von Campe
> Cc: Branko Čibej; Stümpfig, Thomas; users@subversion.apache.org
> Subject: Re: Update Error over VPN
>
> On Tue, Mar 10, 2015 at 7:16 AM, Alfred von Campe  campe.com> wrote:
> > I was going to chime in earlier, but something in Brane’s response
> > finally put me over the edge.  We are having a very similar error
> > when updating
> over
> > VPN (the problem does not occur when in the office):
> >
> > Summary of conflicts:
> >   Text conflicts: 1
> > svn: E175002: REPORT request on '/hepd/Shelby/!svn/me’ failed

This error can be triggered (without further details) if our serf HTTP library 
decides to cancel the request... But for that it would need a good reason.

It would be very interesting to know what caused this... A network trace (or 
serf debug output) would be very valuable. What platform do you see these 
problems on?


In another somehow related case that I'm investigating (strict firewall over a 
VPN link) it really helped to switch to the Subversion 1.9 pre-beta version... 
It would be very interesting to know if this has the same effect for you.

Bert

-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

RE: Update Error over VPN

[Stümpfig , Thomas]

I forgot to mention, indeed, the full path in the error message indicates that 
large avi files were involved in the update operation.

-Original Message-
From: Alfred von Campe [mailto:alf...@von-campe.com]
Sent: Dienstag, 10. März 2015 15:59
To: Bert Huijben
Cc: Branko Čibej; Stümpfig, Thomas; users@subversion.apache.org; Nico 
Kadel-Garcia
Subject: Re: Update Error over VPN

Bert:

> This error can be triggered (without further details) if our serf HTTP 
> library decides to cancel the request... But for that it would need a good 
> reason.
>
> It would be very interesting to know what caused this... A network trace (or 
> serf debug output) would be very valuable. What platform do you see these 
> problems on?

The client and server are both running Linux: CentOS 6.6 with WANdisco V1.8.11 
binaries on the client and Red Hat 5.8 with compiled from source 1.7.5 binaries 
on the server.  How to I create a network trace and/or serf debug output?

> In another somehow related case that I'm investigating (strict firewall over 
> a VPN link) it really helped to switch to the Subversion 1.9 pre-beta 
> version... It would be very interesting to know if this has the same effect 
> for you.

I can ask the user to give this a try.  Do you have binaries for CentOS 6.6 
available?

Alfred
-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50823 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

[no subject]

[Thomas Chua]

Hi, 


 
Our company use Subversion in UK for some years now but theknowledge of the 
setup and administration was lost due to staff turnover. 


I am seeking a competent professional or vendor in Singapore to help usmigrate 
a library from UK to Singapore.  Ifyou know someone willing to take up a short 
paid assignment to assist us.  Appreciate your help to link up.


Best regardsThomas

svn crash

[Thomas Sußebach]

please find attached the minidump file

cheers,
thomas


svn-crash-log20151123073914.dmp
Description: svn-crash-log20151123073914.dmp


svn-crash-log20151123073914.log
Description: svn-crash-log20151123073914.log

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

[Stümpfig , Thomas]

Hi,

While I fully agree with Stefan, I would like to mention that we use svn in a 
non-standard way. We think still with very good performance and use case 
coverage. It is not for source code. It is technical sales project management. 
Sharing all kind of doks jpegs,mp3,mp4,pdf,word,... We successfully have 
~3.000.000 Files in our repository. ~250 (commiters) ~1500 read only users 
since 2008.

We use tortoisesvn for most use cases. In addition to standard svn 
functionality, we created an SOLR based application for PowerPoint slide search 
and full text search.

The reasons to decide were:
a) SVN provides versioning (hey I am able to recover my presentation)
b) provides Path based authorization with Active Directory integration (as a 
large company we have to care about ip)
c) simple ui (tortoise) (even Sales can use it ;-))
d) checkout/check-in for offline usage is simple... (Good on customer site 
where we have no access to network)
e) Very good storage and network efficiency. (Good for home office/Hotel guys)
f) stable and reliable (we can use it 24/7 99% of the time)
g) active community (we can ask someone for help - and get it fast)
h) free and open source :-) - no compliance issues
i) multisite is supported, several multisite solutions exist.  But keep in mind 
svn is not a distributed scm tool. (we thought we might need it, but actually 
not implemented it, just for speed of recovery we have a 2nd server that 
mirrors the data)
j) updates were smooth we started with svn 1.3 - and are now on 1.9 (no big 
invest in upgrades ... my boss is happy)


SVN was the tool that fitted best the needs of our project teams. And even 
better we have 2 part time admin (~10% of the effective Time) for the system.

However,
Svn has some "weaknesses' you should be aware of. OOTB it is not trivial/fast 
to query a file by properties like in Typical DMS. Backing up such large 
repositories through a dump is not feasible. Other means like btrfs/lvm2 should 
be put in place. SVN OOTB does not provide persistent encryption. You could 
encrypt during a commit by 3rd party tools. Transport encryption (https) is 
supported. And finally I would like to add that svn is not a file system, 
despite the fact that svn provides webdav capabilities. As Stefan stated, it is 
a scm tool :-) and it does the job really well.


Regards
Thomas

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Donnerstag, 18. August 2016 09:46
To: Adam Jensen 
Cc: users@subversion.apache.org
Subject: Re: A couple thousand mp3 files (this is not spam  I swear 
)

On Wed, Aug 17, 2016 at 09:09:27PM -0400, Adam Jensen wrote:
> What I need (and what I think is generally needed) is a high-capacity,
> large-file repository with a focus on data integrity (mandatory audit
> trails), sophisticated access control (smart contracts (maybe
> blockchain based)), probably (almost certainly) an encrypted
> file-system, and distribution/replication (that is maybe torrent
> based). Files in this type of system might need to be deleted but they 
> wouldn't be revised.
> This would not be a revision management system.
>
> I'm not sure how much of Subversion could be used/leveraged to build
> such a system.

Indeed it won't. I believe you should use something else for this job.
Not tracking changes contradicts a core requirement SVN was built for.

> At a minimum, it seems like it would involve a project fork and
> serious gutting and refactoring of the code-base after rethinking the
> basic principles, specifying the new requirements, and devising the
> new architecture. (And definitely a name change ).

You're free to use our code in whatever way you wish.
And we're always open to patches, of course.

But keep in mind that the code base is 16 years old and widely deployed.
Adding new features was easy in the early stages of development but is getting 
increasingly hard because of growing complexity and very strict reliability 
requirements imposed by our user base.

And we can't sever our roots:
"""
Apache Subversion is a full-featured version control system originally designed 
to be a better CVS. Subversion has since expanded beyond its original goal of 
replacing CVS, but its basic model, design, and interface remain heavily 
influenced by that goal. Even today, Subversion should still feel very familiar 
to CVS users.
"""
http://subversion.apache.org/features.html

So if you're really going to write a new piece of software for this you'll be 
much happier starting a new project from scratch rather than using SVN as a 
base.

-
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
84564

svnsync on large files

[Stümpfig , Thomas]

Hi everybody,
i get an error with svnsync for large files. svnsync: E175002: REPORT request on

The rev to be synced is 2,291,973,385 Bytes large (Size in txn-protorevs 
directory. Of target mirror)
The sync is with svn 1.9.5 (Visual SVN Server) over both https

I tried to rdump, svnadmin load incremental (works) and adjust revprop info in 
rev 0 to the new imported files. But the I got a path already exists for 
following syncs.
Might not be related to my manipulations but could be the case.

Any Help is appreciated

Mit freundlichen Grüßen
Thomas Stümpfig

Siemens Indusry Software GmbH
Product Lifecycle Management
Global Sales & Services

Franz-Geuer Straße 10
50823 Köln
Franz-Geuer-Straße 10
50823 Köln Tel.: +49 (2153 )9107117
Fax.: +49 (221) 20802699
Mobil: +49 (175) 2205 712
thomas.stuemp...@siemens.com<mailto:thomas.stuemp...@siemens.com>
www.siemens.com/plm<http://www.siemens.com/plm>


-
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
84564

RE: svnsync on large files

[Stümpfig , Thomas]

Hi guys
Thank you for your support.
Here is the full error message.

E:\svnbackup>svnsync sync --source-username=myusername --source-password=x  
--sync-username= myusername --sync-password=x https://mydesturl/repository  
https://mysourceturl/repository
Transmitting file data .svnsync: E175002: REPORT request on 
'/svn/projektablage
age/!svn/rev/54618' failed

(I modified the urls for infosec puposes ... )

E:\svnbackup>svn proplist --revprop -r 0 file:///E:/svnmirror/projektablage
Unversioned properties on revision 0:
  svn:date
  svn:sync-currently-copying
  svn:sync-from-url
  svn:sync-from-uuid
  svn:sync-last-merged-rev

E:\svnbackup>svn propget --revprop -r 0 svn:sync-currently-copying  
file:///E:/svnmirror/projektablage
54618

E:\svnbackup>svn propget --revprop -r 0 svn:sync-last-merged-rev  
file:///E:/svnmirror/projektablage
54617

E:\svnbackup>svn info -r HEAD file:///E:/svnmirror/projektablage
Path: projektablage
URL: file:///E:/svnmirror/projektablage
Relative URL: ^/
Repository Root: file:///E:/svnmirror/projektablage
Repository UUID: e75c21af-ffb9-1a4d-8d4e-43c49f6e0dd9
Revision: 54617
Node Kind: directory
Last Changed Author: xxx
Last Changed Rev: 54617
Last Changed Date: 2016-12-05 11:38:18 +0100 (Mon, 05 Dec 2016)


This is the situation of the starting point. (I restored)

Regards
Thomas

-Original Message-
From: Daniel Shahaf [mailto:danie...@apache.org]
Sent: Mittwoch, 7. Dezember 2016 23:09
To: Pavel Lyalyakin 
Cc: Stümpfig, Thomas (DF PL S&SE DE PSM EAI) ; 
users@subversion.apache.org
Subject: Re: svnsync on large files

Pavel Lyalyakin wrote on Wed, Dec 07, 2016 at 20:59:24 +0300:
> On Wed, Dec 7, 2016 at 8:54 PM, Stümpfig, Thomas
>  wrote:
> >
> > The rev to be synced is 2,291,973,385 Bytes large (Size in
> > txn-protorevs directory. Of target mirror)
> >
> > The sync is with svn 1.9.5 (Visual SVN Server) over both https
>
>
> You should use file:/// access to the local repository instead of
> HTTP(S).

Why?  There are perfectly good reasons to use http://localhost/, for example, 
to have a one-stop-shop killswitch for disabling "everything"
from accessing the repository.

I'm guessing the dump/incremental-load/update-r0-revprops surgery went wrong.  
I would (a) double-check that the revision that had been manually synced did in 
fact sync correctly, (b) review the r0 revprops.
(Thomas: you can just post the 'proplist -v' here if you aren't sure whether 
it's correct now.)

Also, as Pavel says, we need the full error message.

Cheers,

Daniel

> Here is an example:
> [[[
> svnsync sync "https://svn.example.com/svn/MyRepo";
> "file:///C:/Repositories/MyRepo/"
> ]]]
>
> Does the error occur when you use file:/// access to local repository?
>
> > I tried to rdump, svnadmin load incremental (works) and adjust
> > revprop info in rev 0 to the new imported files. But the I got a
> > path already exists for following syncs.  Might not be related to my
> > manipulations but could be the case.
-
Siemens Industry Software GmbH; Anschrift: Franz-Geuer-Str. 10, 50823 Köln; 
Gesellschaft mit beschränkter Haftung; Geschäftsführer: Urban August, Daniel 
Trebes; Sitz der Gesellschaft: Köln; Registergericht: Amtsgericht Köln, HRB 
84564