Re: subversion 1.7 - Internal server error (HTTP 500) - user account gets locked out

[jackson]

HI Mark ,

  Thank you so much , i will enable the debug mode and do the testing and
let you know once done.

Thanks & Regards,
Jackson J

On Fri, May 21, 2021 at 11:35 PM Mark Phippard  wrote:

> On Fri, May 21, 2021 at 8:49 AM jackson  wrote:
> >
> > Hi Team,
> >
> > We are using subversion 1.7 version and we are facing issues very often
> when the users trying to commit or checkout they are getting HTTP 500 error
> and the user is getting locked out.  The users are authenticated via LDAP.
> >
> > At first we thought it was a server resource crunch issue and we
> increased the server resources but still we are getting the same problem
> >
> >
> > We have around 100+ users accessing the repos and the CPU utilization is
> normal as checked in sar report.
> >
> > Any advice on the same.
>
> If you are getting a 500 then often there will be something logged in
> the Apache error log, it might be helpful to see what error, if any is
> logged. If the errors are predictable and reproducible then setting
> Apache to log DEBUG can also help. This logs a lot though so it is
> only useful if the errors can be reproduced easily in a short amount
> of time.
>
> On the server, Subversion is not really involved in the authentication
> process. That is all handled by Apache and in this case the LDAP
> modules. The Apache httpd version will probably be more relevant than
> the Subversion version for fixes to these problems. I can recall a few
> problems where setting LDAPTimeout to a low value like 5-10 seconds
> can fix some problems. I do not remember these resulting in 500 errors
> though, I seem they were more hung connections.
>
> Maybe if something is logged in error.log it could lead to some
> solutions. From what you have provided so far though, it sounds like
> the solutions would be in Apache httpd fixes more than it would be
> Subversion.
>
> Mark
>

Re: subversion 1.7 - Internal server error (HTTP 500) - user account gets locked out

[jackson]

Hi Nathan,

Yes, we are building a new subversion server with version 1.10.

We have been facing this issue for the past 3-4 months and  Meanwhile, is
there any performance tuning that can be done to fix this issue till the
migration is completed ?

Thanks & Regards,
Jackson J

On Fri, May 21, 2021 at 9:17 PM Nathan Hartman 
wrote:

> On Fri, May 21, 2021 at 8:48 AM jackson  wrote:
> > Hi Team,
> >
> > We are using subversion 1.7 version and we are facing issues very often
> when the users trying to commit or checkout they are getting HTTP 500 error
> and the user is getting locked out.  The users are authenticated via LDAP.
> >
> > At first we thought it was a server resource crunch issue and we
> increased the server resources but still we are getting the same problem
>
>
> Hello,
>
> Is this an issue that has begun recently or has this been an ongoing
> problem for a long time?
>
> I would like to point out that the 1.7 release line is somewhat old
> and has not been updated since late 2015. That by itself doesn't mean
> it is the cause of these issues, but if feasible it is probably a good
> idea to update to one of the currently supported release lines; the
> latest releases are 1.10.7 and 1.14.1.
>
> Thanks,
> Nathan
>

subversion 1.7 - Internal server error (HTTP 500) - user account gets locked out

[jackson]

Hi Team,


We are using subversion 1.7 version and we are facing issues very often
when the users trying to commit or checkout they are getting HTTP 500 error
and the user is getting locked out.  The users are authenticated via LDAP.



At first we thought it was a server resource crunch issue and we increased
the server resources but still we are getting the same problem



Here is the current details



Subversion running on single server

Repos : 135

Disk Used : Around 500GB

CPU : 4

RAM : 24

Subversion Repo file system type : FSFS



Below is the apache settings



Timeout 60



KeepAlive Off

MaxKeepAliveRequests 100

KeepAliveTimeout 15





StartServers   8

MinSpareServers5

MaxSpareServers   20

ServerLimit  256

MaxClients   256

MaxRequestsPerChild  4000







StartServers 4

MaxClients 300

MinSpareThreads 25

MaxSpareThreads 75

ThreadsPerChild 25

MaxRequestsPerChild  0







We have around 100+ users accessing the repos and the CPU utilization is
normal as checked in sar report.



Any advice on the same.


Thanks & regards,

Jackson J

Re: Need help in Subversion migration

[jackson]

awesome thorsten , it worked :)

Thanks & regards,
Jackson J

On Tue, May 18, 2021 at 7:13 PM Thorsten  wrote:

> correction
>
> *will N O T  be picked correctly
> Am 18/05/2021 um 15:40 schrieb Thorsten:
>
> Hello,
>
> Either bypass svn completly (do not use svadmin create and just rsync or
> just use tools provided by svn and do not rsync.
>
> Your mixture cannot work:
>
> svnadmin creates an empty repo: srync copys files into that repo, but
> these files belongs to your old repo, not to the new one, so they will be
> picked up correctly
> Am 18/05/2021 um 15:33 schrieb jackson:
>
> Hello Everyone ,
>
>I did a rsync , but it looks like it is not working .
>
> Below are the steps i followed for rsync
>
> *commands run on the new svn server(1.10)*
>
> svnadmin create /subversion/repos/idea
>
> chown -R apache /subversion/repos/idea
>
> rsync -a username@sourceserver:/subversion/repos/idea
> /subversion/repos/idea
>
>
> rsync worked , but when I logged into the websvn to check the revisions ,
> it was not present in the new svn console .
>
>
> *data size on both the server is same after rsync*
>
> [root@old server repos]# du -sh idea
>
> 2.8Gidea
>
>
>  [root@new server repos]# du -sh idea
>
> 2.8Gidea
>
>
>
> screenshot of idea repo in old svn server show it has 9754 rev
> [image: image.png]
>
>
>
> screenshot of idea repo in new svn server show 0 rev
> [image: image.png]
>
>
>
> Looks like i have to follow svm dump and load with incremental or svnsync
> for this migration.
>
>
> Let me try these steps and let you know.
>
>
> Thanks & Regards,
>
> Jackson J
>
> On Tue, May 18, 2021 at 8:06 AM Nathan Hartman 
> wrote:
>
>> On Mon, May 17, 2021 at 8:26 PM Daniel Shahaf 
>> wrote:
>>
>>> Mark Phippard wrote on Mon, 17 May 2021 12:24 +00:00:
>>> >
>>> > > On May 17, 2021, at 8:21 AM, jackson  wrote:
>>> > >
>>> > > 
>>> > > Hello Everyone
>>> > >
>>> > >  We are using subversion 1.7 running in LInux 6.9.
>>> > > we are working on subversion migration along with OS upgrade
>>> > >
>>> > > Currently we have built RHEL 8.3 OS with subversion 1.10 and did all
>>> the configuration , the 1.10 setup is up and working as expected .
>>> > >
>>> > > We need help in migrating the repo from current setup (v1.7 to the
>>> new setup
>>> > >
>>> > > The current setup (v1.7) has the repo size of 500GB. we are using
>>> svn load and svn dump method to migrate the repos from current setup (v1.7)
>>> to new setup(v1.10) , but it takes a lot of time due to the size of the
>>> repo (500GB) , Also the current setup (v1.7 is being currently used by the
>>> customer ,soo even after taking the dump of one particular repo and loading
>>> it in new setup , a newer revision is being made in the  current setup
>>> (v1.7 by the customer  , thus making us to do the svn dump and lsvn load
>>> again.
>>> > >
>>> > > now we need your help in identifying an efficient way in migrating
>>> the repo from the current setup (v1.7  to the ew setup(v1.10) , Need your
>>> expert advise on this please
>>> > >
>>> > >
>>> > > Also let us know we can do rsync for this?
>>> > >
>>> > > Thanks & Regards,
>>> > > Jackson J
>>> >
>>> > You do not have to do anything. Just point the new server at the
>>> > existing repositories or move them to new location.
>>>
>>> That's not necessarily correct for BDB repositories.
>>>
>>> > You can use rsync, tar or whatever method you prefer.
>>>
>>> That's not correct for live repositories.
>>>
>>> Bo and David covered the svnsync and «svnadmin hotcopy» approaches; all
>>> I have to add is that for «svnadmin dump», the --deltas, --incremental,
>>> and -r options should be used as necessary.
>>
>>
>>
>> I'll add that several subsections of "Repository Maintenance" of Chapter
>> 5 of the Subversion book are relevant, especially [1] and [2].
>>
>> [1] Migrating Repository Data Elsewhere:
>>
>> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
>>
>> [2] Repository Replication:
>>
>> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
>>
>> (In this case I think [1] is the more relevant of these.)
>>
>> Cheers,
>> Nathan
>>
>>
>>

Re: Need help in Subversion migration

[jackson]

Hello Everyone ,

   I did a rsync , but it looks like it is not working .

Below are the steps i followed for rsync

*commands run on the new svn server(1.10)*

svnadmin create /subversion/repos/idea

chown -R apache /subversion/repos/idea

rsync -a username@sourceserver:/subversion/repos/idea /subversion/repos/idea


rsync worked , but when I logged into the websvn to check the revisions ,
it was not present in the new svn console .


*data size on both the server is same after rsync*

[root@old server repos]# du -sh idea

2.8Gidea


 [root@new server repos]# du -sh idea

2.8Gidea



screenshot of idea repo in old svn server show it has 9754 rev

[image: image.png]



screenshot of idea repo in new svn server show 0 rev

[image: image.png]



Looks like i have to follow svm dump and load with incremental or svnsync
for this migration.


Let me try these steps and let you know.


Thanks & Regards,

Jackson J

On Tue, May 18, 2021 at 8:06 AM Nathan Hartman 
wrote:

> On Mon, May 17, 2021 at 8:26 PM Daniel Shahaf 
> wrote:
>
>> Mark Phippard wrote on Mon, 17 May 2021 12:24 +00:00:
>> >
>> > > On May 17, 2021, at 8:21 AM, jackson  wrote:
>> > >
>> > > 
>> > > Hello Everyone
>> > >
>> > >  We are using subversion 1.7 running in LInux 6.9.
>> > > we are working on subversion migration along with OS upgrade
>> > >
>> > > Currently we have built RHEL 8.3 OS with subversion 1.10 and did all
>> the configuration , the 1.10 setup is up and working as expected .
>> > >
>> > > We need help in migrating the repo from current setup (v1.7 to the
>> new setup
>> > >
>> > > The current setup (v1.7) has the repo size of 500GB. we are using svn
>> load and svn dump method to migrate the repos from current setup (v1.7) to
>> new setup(v1.10) , but it takes a lot of time due to the size of the repo
>> (500GB) , Also the current setup (v1.7 is being currently used by the
>> customer ,soo even after taking the dump of one particular repo and loading
>> it in new setup , a newer revision is being made in the  current setup
>> (v1.7 by the customer  , thus making us to do the svn dump and lsvn load
>> again.
>> > >
>> > > now we need your help in identifying an efficient way in migrating
>> the repo from the current setup (v1.7  to the ew setup(v1.10) , Need your
>> expert advise on this please
>> > >
>> > >
>> > > Also let us know we can do rsync for this?
>> > >
>> > > Thanks & Regards,
>> > > Jackson J
>> >
>> > You do not have to do anything. Just point the new server at the
>> > existing repositories or move them to new location.
>>
>> That's not necessarily correct for BDB repositories.
>>
>> > You can use rsync, tar or whatever method you prefer.
>>
>> That's not correct for live repositories.
>>
>> Bo and David covered the svnsync and «svnadmin hotcopy» approaches; all
>> I have to add is that for «svnadmin dump», the --deltas, --incremental,
>> and -r options should be used as necessary.
>
>
>
> I'll add that several subsections of "Repository Maintenance" of Chapter 5
> of the Subversion book are relevant, especially [1] and [2].
>
> [1] Migrating Repository Data Elsewhere:
>
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
>
> [2] Repository Replication:
>
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
>
> (In this case I think [1] is the more relevant of these.)
>
> Cheers,
> Nathan
>
>
>

Need help in Subversion migration

[jackson]

Hello Everyone

 We are using subversion 1.7 running in LInux 6.9.
we are working on subversion migration along with OS upgrade

Currently we have built RHEL 8.3 OS with subversion 1.10 and did all the
configuration , the 1.10 setup is up and working as expected .

We need help in migrating the repo from current setup (v1.7 to the new setup

The current setup (v1.7) has the repo size of 500GB. we are using svn load
and svn dump method to migrate the repos from current setup (v1.7) to new
setup(v1.10) , but it takes a lot of time due to the size of the repo
(500GB) , Also the current setup (v1.7 is being currently used by
the customer ,soo even after taking the dump of one particular repo and
loading it in new setup , a newer revision is being made in the  current
setup (v1.7 by the customer  , thus making us to do the svn dump and lsvn
load again.

now we need your help in identifying an efficient way in migrating the repo
from the current setup (v1.7  to the ew setup(v1.10) , Need your expert
advise on this please


Also let us know we can do rsync for this?

Thanks & Regards,
Jackson J

Using Meld for Merge Conflicts

[Jamie Jackson]

I'm on Mac, and I thought I'd use Meld for merge conflicts. However,
this doesn't seem to work: http://stackoverflow.com/a/7418087.

What's the right way to do this with modern versions of SVN (1.9.5)
and Meld (3.16.0)?

Thanks,
Jamie

Enhancement: Expose Merge Whitespace Options in JavaHL

[Jamie Jackson]

Hi Folks,

I'd like to file an enhancement request:

JavaHL doesn't seem to expose some necessary merge options. From the CLI:

  -x [--extensions] ARG: Specify differencing options for external diff
or
 internal diff or blame. Default: '-u'. Options
are
 separated by spaces. Internal diff and blame
take:
   -u, --unified: Show 3 lines of unified
context
   -b, --ignore-space-change: Ignore changes in
 amount of white space
   -w, --ignore-all-space: Ignore all white
space
   --ignore-eol-style: Ignore changes in EOL
style
   -U ARG, --context ARG: Show ARG lines of
context
   -p, --show-c-function: Show C function name

The differ seems to have the options:

https://subversion.a​pache.org/docs/javah​l/latest/org/apache/​subversion/javahl/SV​NUtil.DiffOptions.Ig​noreSpace.html#chang​e


...but as far as I know, merge does not.

The option I'm particularly interested in is --ignore-space-change.
TortoiseSVN, for instance, makes easy work of merges that involve lots of,
say, indentation changes; whereas in Java clients, there can be *loads* more
confusing/manual conflict editing, due to the reduced merge support in
JavaHL.

For what it's worth, here's a thread I started on the Subclipse mailing
list, before I was referred upstream to the Subversion project.

Thanks,
Jamie

Assertion failed!

[Alex Jackson]

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

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

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\workqueue.c'
line 672: assertion failed (checksum != NULL)
---
OK
---


[SMT]

Alex Jackson
Platform Software Engineer
919 493 9390 (main)
919 354 4725 (direct)
919 200 3568 (cell)
a.jack...@smt.com
www.smt.com<http://www.smt.com>


<>

Dealing with Renamed Directories

[Jamie Jackson]

I have a dozen outstanding feature branches (based on the trunk), and
I need to rename a subdirectory. Since I've got so many branches, I
want to make sure I'm doing things properly.

Here's how I plan to do this, and propagate the change to the branches:

TRUNK
1. Rename the directory (and commit).
2. Change any code to reflect the new directory name (and commit).

BRANCH
3. Merge in step 1.
4. Resolve the resulting tree conflict with "mine-full".
5. SVN rename the changed directory (and commit).
6. Merge in step 2 (and commit).

Is that the standard approach?

Notes:
 * I don't like how 1 and 2 are separate commits, but it seems inevitable.
 * 3-5 could be done with record-only-merge, but 3-5 seems to have the
advantage that the eventual branch-to-trunk merge will have this merge
revision ignored.

Thanks,
Jamie

How to install Subversion the right right with fronted by Apache 2.2.x

[Earnest Jackson]

How to install Subversion the right right with fronted by apache 2.2.x

Thanks,
Earnest Jackson