RE: Update-Only Checkout Enhancement

[Cooke, Mark]

> -Original Message-
> From: Mark Kneisler [mailto:mark.kneis...@tceq.texas.gov] 
> Sent: 11 December 2013 01:45
> 
> I have several environments where I'd like to use a SVN 
> checkout, but where I'd never ever want to make changes to 
> the files or perform a commit.  For these environments, I'd 
> only want to perform an update or an update to revision.
> 
> I'm hoping that this type of checkout would require far less 
> space for the .svn directory.
> 
AFAIK there is no such option for a "checkout", however, you can get the source 
without the .svn folder using the "export" command:-

http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.export.html

...you can specify the revision etc.  Note, however, that it will not remove 
unwanted files like an update can.

~ mark c

P.s. I think Thorsten just beat me to it...

Re: Update-Only Checkout Enhancement

[Thorsten Schöning]

Guten Tag Mark Kneisler,
am Mittwoch, 11. Dezember 2013 um 02:45 schrieben Sie:

> I’m hoping that this type of checkout would require far less space for the 
> .svn directory.

No it won't, during checkouts Subversion retrieves and locally saves
all the files it needs for the checked path and revision and stores
them regardless of future use. It currently simply can't know what you
plan to do with the working copy.

What's the size of your working copy that you are concerned about it?
Maybe you should use an export rather than a working copy? Depending
on your use case you can simply sync exports using rsync or such from
a machine where working copy size doesn't matter this much.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Update-Only Checkout Enhancement

[Mark Kneisler]

I have several environments where I'd like to use a SVN checkout, but where I'd 
never ever want to make changes to the files or perform a commit.  For these 
environments, I'd only want to perform an update or an update to revision.

I'm hoping that this type of checkout would require far less space for the .svn 
directory.

Re: Subversion 1.8 httpd.exe taking 100% CPU

[Ben Reser]

On 8/20/13 3:15 AM, Ivan Zhakov wrote:
> But from what I see process is stuck in
> libaprutil-1.dll!7489fc50(), given the last message in debug
> log is "auth_ldap authenticate: using URL" it most likely problem with
> communication with LDAP server (ldap protocol implemented in
> libapr-util). It could be misconfiguration or bug in libapr-util.

Note there was another similar thread on this here:
https://mail-archives.apache.org/mod_mbox/subversion-users/201311.mbox/%3CCEB51A88.2B46A%25davek%40gamehouse.com%3E

I came to the conclusion that there was an LDAP problem as well.

Things that would be interesting to know is if the httpd version changed along
with the Subversion version or if httpd was left alone and only Subversion was
updated.

Both threads seemed to be using CollabNet's Subversion Edge (basing that on the
other thread saying they had version 4.0.2-3732.117 which seems to corollate
with CollabNet's Subversion Edge version numbers, they're up to 4.0.4 now
though).  I believe that httpd is included as part of Subversion Edge so I'd
guess that httpd version changed as well.

Re: size of .svn/pristine directory (svn 1.7.x)

[Ben Reser]

On 12/10/13 5:28 AM, Branko Čibej wrote:
> The correct English term is "reclaim". We should review our release notes more
> diligently. :)

Agreed.  Fixed in r1549892.

Re: size of .svn/pristine directory (svn 1.7.x)

[Branko Čibej]

On 10.12.2013 14:15, Vincent Lefevre wrote:
> On 2013-12-10 12:12:06 +0100, Stefan Sperling wrote:
>> On Tue, Dec 10, 2013 at 01:28:52AM +0100, Vincent Lefevre wrote:
>>> First, "svn help cleanup" currently says:
>>>
>>> cleanup: Recursively clean up the working copy, removing locks, resuming
>>> unfinished operations, etc.
>>>
>>> I suggest to change it to something like:
>>>
>>> cleanup: Recursively clean up the working copy, removing locks, resuming
>>> unfinished operations, removing unreferenced pristines, etc.
>>> In 1.7, we recommend to run "svn cleanup" periodically to reduce the size
>>> of the working copy.
>> Perhaps saying "to remove unferenced pristine copies of files" or
>> something similar is clearer than "reduce the size of the wording copy"?
> Or "to claim back the disk space of unreferenced pristines" like in
> the release notes?

The correct English term is "reclaim". We should review our release
notes more diligently. :)

"Reclaim disk space used by unreferenced pristine files" sounds about right.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: size of .svn/pristine directory (svn 1.7.x)

[Vincent Lefevre]

On 2013-12-10 12:12:06 +0100, Stefan Sperling wrote:
> On Tue, Dec 10, 2013 at 01:28:52AM +0100, Vincent Lefevre wrote:
> > First, "svn help cleanup" currently says:
> > 
> > cleanup: Recursively clean up the working copy, removing locks, resuming
> > unfinished operations, etc.
> > 
> > I suggest to change it to something like:
> > 
> > cleanup: Recursively clean up the working copy, removing locks, resuming
> > unfinished operations, removing unreferenced pristines, etc.
> > In 1.7, we recommend to run "svn cleanup" periodically to reduce the size
> > of the working copy.
> 
> Perhaps saying "to remove unferenced pristine copies of files" or
> something similar is clearer than "reduce the size of the wording copy"?

Or "to claim back the disk space of unreferenced pristines" like in
the release notes?

Though "remove unreferenced pristine copies of files" implies more
disk space, saying it explicitly makes it clear that the goal of
this operation is to free some disk space (in addition to rare
security reasons, in case a file with sensitive information was
added by mistake in the past).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Subversion 1.8 httpd.exe taking 100% CPU

[Valentijn Scholten]

I never got a hold of the PDB files.
In the mean time I switched to a linux based install of Subversion edge 4.x.
Running for months now without problems.

-Original Message- 
From: Stefan Sperling

Sent: Tuesday, December 10, 2013 12:19 PM
To: back.flip.into.the.l...@gmail.com
Cc: 'Pavel Lyalyakin' ; 'users@subversion.apache.org' ; 
dinesh.hir...@decuragroup.com

Subject: Re: Subversion 1.8 httpd.exe taking 100% CPU

On Tue, Dec 10, 2013 at 02:29:00AM -0800, back.flip.into.the.l...@gmail.com 
wrote:

Hello,

To add more fuel to the fire, I encountered the same issue after migrating
from Subversion 1.6 to 1.8 (with the CollabNet distribution 2.0.0 ->
4.0.3). It seems to happen at night also.


Unfortunately, "will this be fixed?" and "me too" won't help.

As far as I understand, we're waiting for someone to figure out
the root cause by filling in the missing pieces of information.
See http://svn.haxx.se/users/archive-2013-08/0354.shtml

As an aside, I'm removing the subversion_user google groups address
from Cc because whenever I send something to that address I get a bounce.
It's annoying that they hook into existing mailing lists, lure users
into using their frontend as the primary interface to that list, and
then dare to send bounces to people who don't post via google groups!
Please don't use google groups to contact us.
Please subscribe to our list instead:
http://subversion.apache.org/mailing-lists.html

--

--- 
You received this message because you are subscribed to a topic in the 
Google Groups "subversion-users" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/subversion_users/Lk5EXRpAI7k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
subversion_users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out. 

Re: Subversion 1.8 httpd.exe taking 100% CPU

[Stefan Sperling]

On Tue, Dec 10, 2013 at 02:29:00AM -0800, back.flip.into.the.l...@gmail.com 
wrote:
> Hello,
> 
> To add more fuel to the fire, I encountered the same issue after migrating 
> from Subversion 1.6 to 1.8 (with the CollabNet distribution 2.0.0 -> 
> 4.0.3). It seems to happen at night also.

Unfortunately, "will this be fixed?" and "me too" won't help.

As far as I understand, we're waiting for someone to figure out
the root cause by filling in the missing pieces of information.
See http://svn.haxx.se/users/archive-2013-08/0354.shtml

As an aside, I'm removing the subversion_user google groups address
from Cc because whenever I send something to that address I get a bounce.
It's annoying that they hook into existing mailing lists, lure users
into using their frontend as the primary interface to that list, and
then dare to send bounces to people who don't post via google groups!
Please don't use google groups to contact us.
Please subscribe to our list instead:
http://subversion.apache.org/mailing-lists.html

Re: size of .svn/pristine directory (svn 1.7.x)

[Stefan Sperling]

On Tue, Dec 10, 2013 at 01:28:52AM +0100, Vincent Lefevre wrote:
> First, "svn help cleanup" currently says:
> 
> cleanup: Recursively clean up the working copy, removing locks, resuming
> unfinished operations, etc.
> 
> I suggest to change it to something like:
> 
> cleanup: Recursively clean up the working copy, removing locks, resuming
> unfinished operations, removing unreferenced pristines, etc.
> In 1.7, we recommend to run "svn cleanup" periodically to reduce the size
> of the working copy.

Perhaps saying "to remove unferenced pristine copies of files" or
something similar is clearer than "reduce the size of the wording copy"?

> I've attached a patch for the svnbook (not tested).

> Index: ch02-basic-usage.xml
> ===
> --- ch02-basic-usage.xml  (revision 4563)
> +++ ch02-basic-usage.xml  (working copy)
> @@ -2892,6 +2892,21 @@
>  
>  
>  
> +
> +
> +  Reducing the Size of a Working Copy
> +
> +  Subversion 1.7 does not automatically remove pristines
> +that are no longer referenced. As a consequence, a working
> +copy can grow up to several times the size that is really
> +needed. We recommend to run svn cleanup
> +periodically in order to claim back the disk space of
> +unreferenced pristinesSee  +url="http://subversion.tigris.org/issues/show_bug.cgi?id=4071";
> +/> for details..
> +
> +
> +
>
>  
>

Thanks!
This list is not the right list for svnbook patches.
I've forwarded your patch to the right list, and put you in Cc.

Re: Subversion 1.8 httpd.exe taking 100% CPU

[back . flip . into . the . lava]

Hello,

To add more fuel to the fire, I encountered the same issue after migrating 
from Subversion 1.6 to 1.8 (with the CollabNet distribution 2.0.0 -> 
4.0.3). It seems to happen at night also.

As far as I can see, its the sub HTTPD process which take 100% (Subversion 
one?), not the top apache HTTPD process.

We can also see there's new rotate logs processes spawned by apache. But 
they don't seems in cause : they do nothing while HTTPD takes 100%.

Le lundi 9 décembre 2013 15:41:07 UTC+1, Dinesh Hirani a écrit :
>
>  Hello Pavel,
>
>  
>
> Do you know when this issue will be fix?
>
>  
>  
> *From:* Dinesh Hirani 
> *Sent:* 02 October 2013 11:49
> *To:* Pavel Lyalyakin; us...@subversion.apache.org 
> *Subject:* RE: Subversion 1.8 httpd.exe taking 100% CPU
>  
>  
>
> Hello Pavel,
>
>  
>
> Any update on this issue as the bug still exists?
>
>  
>  
> *From:* Dinesh Hirani 
> *Sent:* 04 July 2013 16:30
> *To:* 'Pavel Lyalyakin'; us...@subversion.apache.org 
> *Subject:* RE: Subversion 1.8 httpd.exe taking 100% CPU
>  
>  
>
> Hello Pavel,
>
>  
>
> Answer is in red below
>
>  
>
> -Original Message-
> From: Pavel Lyalyakin [mailto:pave...@visualsvn.com ] 
> Sent: 04 July 2013 16:19
> To: us...@subversion.apache.org ; Dinesh Hirani
> Subject: Re: Subversion 1.8 httpd.exe taking 100% CPU
>
>  
>
> Hello Dinesh,
>
>  
>
> > We just upgraded subversion from 1.7 to 1.8 and noticed that the process 
> httpd.exe takes 100% and maxes the box and we have to keep killing the 
> httpd.exe, are you aware of this problem?
>
>  
>
> * What's your environment (svn client / server / Apache HTTP Server 
> version)?
>
> We using TortoiseSVN 1.8 / CollabNet Edge / Apache HTTP Server version 
> 2.4.4
>
> * What exactly do you do when the httpd.exe starts to consume 100% CPU 
> time?
>
> We don’t know exactly what causes it because nothing is written to any 
> logs as far we can see, however once we kill the httpd.exe then it’s find 
> for another couple of hours.
>
>  
>
> * Any related events on the server log?
>
> *Error log*
>
> *Last message logged. Then at 9.35 I killed httpd.exe*
>
> [Thu Jul 04 09:24:49.798629 2013] [authz_svn:error] [pid 4844:tid 892] 
> [client 10.9.11.84:56153] Access denied: 'bparker' OPTIONS 
> risk-dev:/Build/trunk/RabbitMQ
>
>  
>
> [Thu Jul 04 09:35:45.690450 2013] [mpm_winnt:notice] [pid 4204:tid 480] 
> AH00428: Parent: child process 4844 exited with status 4294967295 -- 
> Restarting.
>
>  
>
> *Subversion log*
>
> *Last message logged. Then at 9.35 I killed httpd.exe *
>
> [04/Jul/2013:09:33:52 +0100] svc-teamcity Risk-DEV log (/) r41581:41690 
> discover-changed-paths revprops=all 0
>
>  
>
> [04/Jul/2013:09:35:02 +0100] svc-teamcity Risk-DEV log (/) r41581:41690 
> discover-changed-paths revprops=all 0
>
>  
>
> --
>
> With best regards,
>
> Pavel Lyalyakin
>
> VisualSVN Team
>  
>
> The information in this e-mail is confidential and may be legally 
> privileged. It is intended solely for the addressee(s). Access by any other 
> person to this e-mail is not authorized. If you are not the intended 
> recipient, please delete this e-mail. Any disclosure of this e-mail or of 
> the parties to it and any copying or distribution of it is prohibited (and 
> may be unlawful). The information expressed herein may be changed at any 
> time without notice or obligation to update. We do not represent that this 
> message is virus-free, complete or accurate and it should not be relied 
> upon as such. Electronic communications may be monitored for operational 
> and business purposes to the extent permitted by applicable law. This email 
> does not constitute legal or tax advice, and the information contained in 
> this communication should not be regarded as such.
>
> Decura IM LLP is authorised and regulated by the Financial Conduct 
> Authority. Registered office address: 11-12 St James's Square, London SW1Y 
> 4LB. Registered in England and Wales: OC375344
>
>  
>
> Decura LLP is authorised and regulated by the Financial Conduct Authority. 
> Registered office address: 11-12 St James's Square, London SW1Y 4LB. 
> Registered in England and Wales: OC377231
>