Subversion for ARM9 on an Iomega IX2-200

[tony]

Hi,

I wonder if someone can help me, I have purchased a Iomega NAS  
(IX2-200) and there is only one feature missing from it. I want to  
compile subversion for it. Has anyone ever done this before? or can  
anyone help me to compile subversion for ARM9 Processor?


Hope someone can help.

Kind Regards

Tony

[no subject]

[tony]

RE: Howto Disable Localistation?

[Tony Sweeney]

alias svn='LANG=en_US svn'




From: Lechner Martin [mailto:martin.lech...@alicona.com] 
Sent: 06 October 2010 14:54
To: users@subversion.apache.org
Subject: Howto Disable Localistation?



Hi, 

I have a question: Is it possible to disable the localization?

As a developer I prefer the english texts but unfortunately svn
translate everything to the language of my OS.

Help would be welcome!

 

Br

Martin

 



__
This email has been scanned by the MessageLabs Email Security
System.
For more information please visit
http://www.messagelabs.com/email 

__

Unusual merge result

[Tony Butt]

I have had 2 unusual occurrences with merges with some of our software
engineers here in the last month. I wrote the first off as user error,
but a similar event has occurred - still possibly user error.

We are using subversion 1.6.12 on our server, and a mix of TortoiseSVN
1.5 and 1.6 clients on our clients, as well as some commandline usage
through an automated tool.

What has happened is that twice now, an engineer has branched some code,
and then seen unusual checking behaviour. The second instance was today,
and occurred after merging the trunk of the software module into the
branch, then checking the results back in to the branch. What actually
happened is that 2 source files were checked back in to the trunk
instead. The first instance is less clear cut. Unfortunately, in both
cases, the engineers involved discovered the problem, took steps to
correct it, including deleting and checking out the relevant working
copies again, then thought to tell me about it - not too much evidence
left to trace from.

The first time I assumed that the user involved had performed a switch
inadvertently, this time I am less sure.

What is most puzzling is that looking at the mergeinfo properties on the
branch , I see the following:

Properties for /Branches/
svn:mergeinfo   /Branches/branchA:49494-49689
/Branches/branchB:47790-51680
/Branches/branchC:52621-53396
/Trunk:54546-54710

Which seems OK,

But in a subdirectory, I see
Properties for /Branches/Implementation/IlluminationManager
svn:mergeinfo   
/Branches/branchA/Implementation/IlluminationManager:49494-49689

/Branches/branchB/Implementation/IlluminationManager:47790-51680

/Branches/branchC/Implementation/IlluminationManager:52621-53396

/Trunk/Implementation/IlluminationManager:54546-54710*

Where I expected to see no mergeinfo recorded at all, since our merges
are done at the  level only. Further, I don't know what the
trailing '*' on the last property line means.

If anyone could explain what the trailing '*' is for, and for extra
bonus points :-) explain why the mergeinfo is set on the subdirectory, I
would be quite grateful. I have looked at the subversion book for some
explanation, but could find no further explanation of the '*'.

Thanks in advance,
Tony Butt

CEA Technologies
-- 
Tony Butt 

Re: Unusual merge result

[Tony Butt]

On Tue, 2010-10-19 at 18:23 +1100, Tony Butt wrote:
> I have had 2 unusual occurrences with merges with some of our software
> engineers here in the last month. I wrote the first off as user error,
> but a similar event has occurred - still possibly user error.
> 
> We are using subversion 1.6.12 on our server, and a mix of TortoiseSVN
> 1.5 and 1.6 clients on our clients, as well as some commandline usage
> through an automated tool.
> 
> What has happened is that twice now, an engineer has branched some code,
> and then seen unusual checking behaviour. The second instance was today,
  Whoops - make that   *check-in*
> and occurred after merging the trunk of the software module into the
> branch, then checking the results back in to the branch. What actually
> happened is that 2 source files were checked back in to the trunk
> instead. The first instance is less clear cut. Unfortunately, in both
> cases, the engineers involved discovered the problem, took steps to
> correct it, including deleting and checking out the relevant working
> copies again, then thought to tell me about it - not too much evidence
> left to trace from.
> 
> The first time I assumed that the user involved had performed a switch
> inadvertently, this time I am less sure.
> 
> What is most puzzling is that looking at the mergeinfo properties on the
> branch , I see the following:
> 
> Properties for /Branches/
> svn:mergeinfo /Branches/branchA:49494-49689
>   /Branches/branchB:47790-51680
>   /Branches/branchC:52621-53396
>   /Trunk:54546-54710
> 
> Which seems OK,
> 
> But in a subdirectory, I see
> Properties for /Branches/Implementation/IlluminationManager
> svn:mergeinfo 
> /Branches/branchA/Implementation/IlluminationManager:49494-49689
>   
> /Branches/branchB/Implementation/IlluminationManager:47790-51680
>   
> /Branches/branchC/Implementation/IlluminationManager:52621-53396
>   
> /Trunk/Implementation/IlluminationManager:54546-54710*
> 
> Where I expected to see no mergeinfo recorded at all, since our merges
> are done at the  level only. Further, I don't know what the
> trailing '*' on the last property line means.
> 
> If anyone could explain what the trailing '*' is for, and for extra
> bonus points :-) explain why the mergeinfo is set on the subdirectory, I
> would be quite grateful. I have looked at the subversion book for some
> explanation, but could find no further explanation of the '*'.
> 
> Thanks in advance,
> Tony Butt
> 
> CEA Technologies

-- 
Tony Butt 

Re: Unusual merge result

[Tony Butt]

Johan,
On Tue, 2010-10-19 at 11:59 +0200, Johan Corveleyn wrote:
> On Tue, Oct 19, 2010 at 9:40 AM, Tony Butt  wrote:
> > On Tue, 2010-10-19 at 18:23 +1100, Tony Butt wrote:
> >> I have had 2 unusual occurrences with merges with some of our software
> >> engineers here in the last month. I wrote the first off as user error,
> >> but a similar event has occurred - still possibly user error.
> >>
> >> We are using subversion 1.6.12 on our server, and a mix of TortoiseSVN
> >> 1.5 and 1.6 clients on our clients, as well as some commandline usage
> >> through an automated tool.
> >>
> >> What has happened is that twice now, an engineer has branched some code,
> >> and then seen unusual checking behaviour. The second instance was today,
> >  Whoops - make that   *check-in*
> >> and occurred after merging the trunk of the software module into the
> >> branch, then checking the results back in to the branch. What actually
> >> happened is that 2 source files were checked back in to the trunk
> >> instead. The first instance is less clear cut. Unfortunately, in both
> >> cases, the engineers involved discovered the problem, took steps to
> >> correct it, including deleting and checking out the relevant working
> >> copies again, then thought to tell me about it - not too much evidence
> >> left to trace from.
> >>
> >> The first time I assumed that the user involved had performed a switch
> >> inadvertently, this time I am less sure.
> >>
> >> What is most puzzling is that looking at the mergeinfo properties on the
> >> branch , I see the following:
> >>
> >> Properties for /Branches/
> >> svn:mergeinfo /Branches/branchA:49494-49689
> >>   /Branches/branchB:47790-51680
> >>   /Branches/branchC:52621-53396
> >>   /Trunk:54546-54710
> >>
> >> Which seems OK,
> >>
> >> But in a subdirectory, I see
> >> Properties for /Branches/Implementation/IlluminationManager
> >> svn:mergeinfo 
> >> /Branches/branchA/Implementation/IlluminationManager:49494-49689
> >>   
> >> /Branches/branchB/Implementation/IlluminationManager:47790-51680
> >>   
> >> /Branches/branchC/Implementation/IlluminationManager:52621-53396
> >>   
> >> /Trunk/Implementation/IlluminationManager:54546-54710*
> >>
> >> Where I expected to see no mergeinfo recorded at all, since our merges
> >> are done at the  level only. Further, I don't know what the
> >> trailing '*' on the last property line means.
> >>
> >> If anyone could explain what the trailing '*' is for, and for extra
> >> bonus points :-) explain why the mergeinfo is set on the subdirectory, I
> >> would be quite grateful. I have looked at the subversion book for some
> >> explanation, but could find no further explanation of the '*'.
> 
> You should probably read
> http://www.collab.net/community/subversion/articles/merge-info.html
> (very long article) for a thorough understanding. The '*' means
> "non-inheritable mergeinfo", which means that this mergeinfo only
> applies up to /Branches/Implementation/IlluminationManager, and will
> not be inherited by its children (i.e. these revisions from trunk were
> not merged into the subtree of
> /Branches/Implementation/IlluminationManager).
> 
> This kind of thing can happen when working with sparse working copies,
> and merging into them. Subversion notes that it only merged those
> revisions up to /Branches/Implementation/IlluminationManager and not
> below it (see the article for an example, in the section "Mergeinfo
> Inheritance and Non-Inheritable Ranges").
> 
> What you should also know is: once a subtree gets its own explicit
> mergeinfo, subversion needs to maintain this mergeinfo all the time,
> because it now no longer inherits the mergeinfo from the root.
> 
> So a scenario that could explain your mergeinfo is: some user merged
> /Trunk:54546-54710 into a sparse working copy of the branch, where
> everything below /Branches/Implementation/IlluminationManager was
> excluded, and then committed this merge. The same can probably also
> happen when /Branches/Implementation/IlluminationManager is switched
> in the working copy where you are merging into. The first paragraph of
> the section "Mergeinfo Inheritance and Non-Inheritable Ranges" in the
> article says:
> 
> "Subversion allows a working copies which are incomplete
>

RE: Promoting a mirror repository as a source repository

[Tony Sweeney]

This is doable (I've done it).  The shadow repository needs to have the
same UUID as the source, and you either have to repoint the DNS at it or
svn switch all existing clients.  See Andrey's link for the skinny.

Tony.

-Original Message-
From: Gingko [mailto:from_tig...@nospam.homelinux.org] 
Sent: 05 November 2010 23:50
To: Subversion User List
Subject: Promoting a mirror repository as a source repository

Hello again,

I have a (now theoretical) question :

Suppose I have a repository that is a mirror repository of a remote
source 
repository, regularly synced using svnsync.

Suppose now that the source repository become broken or deleted for any 
reason (server breakdown, fire, etc)
So the only available copy of the repository is now the synced mirror 
repository.

How could I promote my mirror repository in order to have it becoming
the 
new source repository on the mirror server or on another server ?

(I think that just using the mirror repository without change is not
enough 
as it contains somewhere inside it information about the old source 
repository, given at the beginning by "svnsync initialize", which would 
certainly need to be removed)

Gingko 


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: Promoting a mirror repository as a source repository

[Tony Sweeney]

Plus, you need to set a number of properties on the zeroeth revision of
the target repository (if I recall correctly) and add a hook script for
the sync user to be allowed to modify revision commit text in order for
svnsync to run successfully.  (And delete the revo #0 properties when
you're done, though I don't think that was essential).  Look in the red
bean book at svnsync.

Tony.

-Original Message-
From: Gingko [mailto:from_tig...@nospam.homelinux.org] 
Sent: 06 November 2010 01:02
To: Subversion User List
Subject: Re: Promoting a mirror repository as a source repository


- Original Message - 
From: "Andrey Repin" 
To: "Gingko" ; 

Sent: Saturday, November 06, 2010 1:30 AM
Subject: Re: Promoting a mirror repository as a source repository


> Greetings, Gingko!
>
>> I have a (now theoretical) question :
>
>> Suppose I have a repository that is a mirror repository of a remote 
>> source
>> repository, regularly synced using svnsync.
>
>> Suppose now that the source repository become broken or deleted for
any
>> reason (server breakdown, fire, etc)
>> So the only available copy of the repository is now the synced mirror
>> repository.
>
>> How could I promote my mirror repository in order to have it becoming
the
>> new source repository on the mirror server or on another server ?
>
>> (I think that just using the mirror repository without change is not 
>> enough
>> as it contains somewhere inside it information about the old source
>> repository, given at the beginning by "svnsync initialize", which
would
>> certainly need to be removed)
>
> svn help switch
> http://svnbook.org/

Thank you very much for your answer, but I'm sorry, this is not an
answer to 
my question.

"svn switch" is about changing URLs in working copies, I know how to do
this 
(actually I made several of these changes today).

But what I want to know is what I have to do on the REPOSITORY side.

Gingko 


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: Mail-Copies-To

[Tony Sweeney]

Which again is not part of any email standard, just Daniel J.
Bernstein's wish list from 1997, codified as an IETF draft in 2000, but
never actually elevated to an approved RFC.  Although a number of MUAs
honour it, some (like Mozilla Thunderbird) explicitly rejected honouring
these headers by default as they are not part of an approved standard.

Tony. 

> -Original Message-
> From: Gary [mailto:subversion-u...@garydjones.name] 
> Sent: 19 November 2010 11:19
> To: users@subversion.apache.org
> Subject: Re: Mail-Copies-To
> 
> Ryan Schmidt wrote:
> 
> > If you don't wish to receive copies of replies on the list, one 
> > possible solution is to set the Reply-To header of your 
> outgoing mail 
> > to the list's address.
> 
> Mail-Followup-To was also set.
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: On commit attempt, Server sent unexpected return value (403 Forbidden) in response to CHECKOUT

[Tony Sweeney]

 

 



From: benjamin.ort...@wellsfargo.com
[mailto:benjamin.ort...@wellsfargo.com] 
Sent: 01 January 2011 17:13
To: users@subversion.apache.org
Subject: On commit attempt, Server sent unexpected return value (403
Forbidden) in response to CHECKOUT

 

I'm trying to integrate a SVN Authz authorization file with apache
configuration files to provide a solution for not just directory level
restrictions, but also file level restrictions. It's my understanding
that the SVN Authorization file is not capable of handling file-specific
restrictions, only directory level.

The SVN Authz file is set up and i'm able to use it with absolutely no
issues what-so-ever. If I switch to using just the Apache Conf file by
itself, it works exactly as expected with no issues. But if I combine
them I get something very weird. Everything works just fine, except the
trying to commit the file that was restricted by the following
Location/Limit:



Require user my_username



I'm able to view, update, and checkout the file, and am able to do
anything (checkout, commit, etc) to other files in the same directory,
but when I attempt perform a commit of changes to the "RestrictedFile",
I get the following error:
Error: Commit failed (details follow):
Error: Server sent unexpected return value (403 Forbidden) in response
to CHECKOUT
Error: request for
'/subversion/repo/!svn/ver/110/folder/structure/RestrictedFile'

the apache access log file gives me the following:
ip_address - - [30/Dec/2010:15:49:58 -0600] "OPTIONS
/subversion/repo/folder/structure HTTP/1.1" 401 1337
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "OPTIONS
/subversion/repo/folder/structure HTTP/1.1" 200 -
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPFIND
/subversion/repo/folder/structure HTTP/1.1" 207 816
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "OPTIONS
/subversion/repo/folder/structure HTTP/1.1" 200 195
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "MKACTIVITY
/subversion/repo/!svn/act/71f51505-a174-8349-ab61-843f80a40f8f HTTP/1.1"
201 234
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPFIND
/subversion/repo/!svn/vcc/default HTTP/1.1" 207 414
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "CHECKOUT
/subversion/repo/!svn/bln/110 HTTP/1.1" 201 250
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPPATCH
/subversion/repo/!svn/wbl/71f51505-a174-8349-ab61-843f80a40f8f/110
HTTP/1.1" 207 469
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "PROPFIND
/subversion/repo/folder/structure HTTP/1.1" 207 526
ip_address - - [30/Dec/2010:15:49:59 -0600] "CHECKOUT
/subversion/repo/!svn/ver/110/folder/structure/RestrictedFile HTTP/1.1"
403 1021
ip_address - my_username [30/Dec/2010:15:49:59 -0600] "DELETE
/subversion/repo/!svn/act/71f51505-a174-8349-ab61-843f80a40f8f HTTP/1.1"
204 -

If I remove the  entry listed above, i'm able to commit
just fine.

My svnauthz file basically has this:

[/]

* =

my_username = rw

The ordering is important.  Authz uses the fist match.  The first rule
matches for all users, including 'my_username', so the second rule is
ignored.  Try swapping the order of the directives, i.e.

[/]

my_username = rw

* = 

If I change "* = " to "* = r", I get the same issue.  If I change it to
"* = rw", I'm able to commit.

Benjamin Ortega

Benjamin Ortega
--
Operations Systems Engineer
Wells Fargo Bank, Des Moines, IA
CORE Build & Deploy Team
* : benjamin.ort...@wellsfargo.com
 
* : 515-720-2700 (cell)

MAC: X2301-01X

This transmission may contain information that is confidential and/or
proprietary. If you are not the individual or entity to which it is
addressed, note that any review, disclosure, copying, retransmission, or
other use is strictly prohibited. If you received this transmission in
error, please notify the sender immediately and delete the material from
your system.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: svnadmin create and not being method agnostic

[Tony Sweeney]

-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: 02 January 2011 12:55
To: Philip Prindeville
Cc: Ryan Schmidt; users@subversion.apache.org
Subject: Re: svnadmin create and not being method agnostic

>On Sun, Jan 2, 2011 at 2:49 AM, Philip Prindeville
> wrote:
>> On 1/1/11 8:29 PM, Nico Kadel-Garcia wrote:

>>> To set up the first time for testing? No. To set up securely? Youch.
>>> It's paide me some very remunerative consulting wages, becuase it took
>>> someone as paranoid as me to clean it up. It's quite painful due to
>>> lack of documentation of necessary single-user configurations, the
>>> multiplicity of access technologies each with entirely different
>>> access control tools, and the expectation that each admin will *of
>>> course write their own little wrappers for standard, sensible
>>> behavior.
>>
>> So you're ok being made redundant and slaughtering this cash-cow?  :-)
>>
>> -Philip
>>

>It's not cow. Subversion security is *goat*. Inexpensive to buy the
>unprepared meat, but it;'s fairly gamey, risky for inexperienced
>chefs, and raises suspicious eyebrows if anyone sees you with the big
>hammer you need to tenderize it. But if the chef's time costs less
>than the raw materials, some customers want it.

Ahem.  Subversion security is not goat.  Goat is fine eating, from the 
Caribbean to the middle east and central and southern Asia.  Subversion 
security is *roadkill*.  At the top end, Apache security is venison; a delicacy 
that many would be happy to pay for or indeed to hunt themselves.  At the low 
end, svnserve security is possum; hey, it's free, and it does the job so long 
as you hold your nose while you swallow.  I'll leave it to others to fill in 
the intermediate tiers/tieren*.

>If we can get the goat meat tenderized before it lands in our
>kitchens, that saves me time to make sure the busboys (of whatever
>gender) aren't drinking all the table wine and writing the init
>scripts in Perl.

Don't get me started on perl: "it was a hungry man that ate the first oyster".

Tony.
[*] A nod to our German correspondents.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: Trival merge of big text file: Dismal performance, 540x faster if binary.

[Tony Sweeney]

Why bother with a script?  Just wget a few high traffic websites (slashdot, 
yahoo, dailykos, google news) or similar into a file every now and again.

Tony. 

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com] 
> Sent: 13 January 2011 14:26
> To: krueger, Andreas (Andreas Krüger, DV-RATIO); 
> users@subversion.apache.org
> Subject: Re: Trival merge of big text file: Dismal 
> performance, 540x faster if binary.
> 
> On Thu, Jan 13, 2011 at 2:07 PM, Stefan Sperling 
>  wrote:
> > On Thu, Jan 13, 2011 at 01:55:58PM +0100, Johan Corveleyn wrote:
> >> Textual merging in svn makes use of a variant of the standard diff 
> >> algorithm, namely diff3. Just a couple of days ago, I finally 
> >> succeeded in making diff3 take advantage of those performance 
> >> improvements (haven't committed this to the branch yet, but maybe 
> >> I'll get to it tonight).
> >>
> >> Would you be able to build an svn client from source? If so, could 
> >> you perhaps build a client from 
> >> 
> http://svn.apache.org/repos/asf/subversion/branches/diff-optimization
> >> s-bytes
> >> ?
> >
> > Hey Johan,
> >
> > I would be interested in doing testing and reviewing the changes on 
> > your branch. There might still be enough time to get them into 1.7.
> 
> Thanks, that would be great (btw, danielsh also expressed an 
> interest in reviewing the branch). I will try to give an 
> status update on the dev-list after I've committed the 
> changes for diff3.
> 
> > I don't have any suitably large XML files though.
> > If you and/or Andreas could provide some that would be great.
> 
> I was thinking of writing a python script (as philip already
> suggested) that can generate several variants of large files 
> with semi-random data. I have some prototype code for this 
> lying around, so if I find the time, I'll try to wrap this up 
> and send it to the dev list. OTOH, real-world examples are 
> probably even better.
> 
> Cheers,
> --
> Johan
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: SVN 1.6.15 checkout fails on particular file

[Tony Sweeney]

You can't mix Subversion client releases where the middle digit of the
version number differs.  Subversion clients are backwards compatible
when talking to the server, but not when writing workspace metadata to
the filesystem.  You can, in theory, use whatever version you like on
the client side against any server version.  However, when you invoke a
client on a workspace, it checks to see if the local metadata is the
same version as itself, and if it discovers an older version, silently
upgrades the format to its own.  At this point, older clients will no
longer work on that workspace.

Tony.

> -Original Message-
> From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com] 
> Sent: 14 January 2011 18:36
> To: users@subversion.apache.org
> Subject: SVN 1.6.15 checkout fails on particular file
> 
> This is a continuation of my experiences described in the 
> "What SVN command-line client distro should I get to work 
> properly with SVN 1.4.x on the server?" subject.
> 
> My SVN server is running version 1.4.x.  I'm using the latest 
> Subversive in Eclipse, but the connector associated with SVN 
> 1.5.6.  This works well enough in Eclipse.
> 
> I installed SVN 1.6.15 from CollabNet.  I created a new 
> directory from the shell and did a checkout of two of the 
> projects I have checked out in Eclipse.  One of them 
> completed successfully, but another one fails each time with 
> an error like the following:
> 
> svn: Your .svn/tmp directory may be missing or corrupt; run 
> 'svn cleanup' and try again
> svn: Can't open file '...\.svn\tmp\text-base\svn-base': 
> The system cannot find the path specified.
> 
> I elided the full path to the file.
> 
> I looked in the "text-base" directory being referenced here, 
> and it's empty.
> 
> I did a "svn cleanup", and it chugged for a second and then 
> went back to the prompt.
> 
> I tried the checkout again, and it failed with the exact same error.
> 
> I also tried changing into the directory and doing "svn 
> update", and that also failed with the same error.
> 
> Any ideas?
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: SVN 1.6.15 checkout fails on particular file

[Tony Sweeney]

 

> -Original Message-
> From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com] 
> Sent: 14 January 2011 19:07
> To: Tony Sweeney; users@subversion.apache.org
> Subject: RE: SVN 1.6.15 checkout fails on particular file
> 
> > -Original Message-
> > From: Tony Sweeney [mailto:tswee...@omnifone.com]
> > Sent: Friday, January 14, 2011 10:57 AM
> > To: KARR, DAVID (ATTSI); users@subversion.apache.org
> > Subject: RE: SVN 1.6.15 checkout fails on particular file
> > 
> > You can't mix Subversion client releases where the middle 
> digit of the 
> > version number differs.  Subversion clients are backwards 
> compatible 
> > when talking to the server, but not when writing workspace 
> metadata to 
> > the filesystem.  You can, in theory, use whatever version 
> you like on 
> > the client side against any server version.  However, when 
> you invoke
> a
> > client on a workspace, it checks to see if the local 
> metadata is the 
> > same version as itself, and if it discovers an older 
> version, silently 
> > upgrades the format to its own.  At this point, older 
> clients will no 
> > longer work on that workspace.
> 
> Just so we're clear here, I have these projects checked out 
> in Eclipse, but not in the same directory that I'm trying to 
> do the command-line checkout.  I'm trying to do a separate 
> checkout of these projects, just using the 1.6.15 client.  
> I'm not using multiple client versions in the same 
> checked-out directory, but I am attempting to checkout a 
> module from SVN with the 1.6.15 client that has been 
> previously checked out with different client versions.
> 
> Is the conflict in mixing client versions relevant to the 
> module in the server, or in the client-side directory?  If 
> it's the latter, then there should be no conflict, as I'm 
> only using the 1.6.15 client in this directory.
> 

Only in the client.  If your workspaces are disjoint then that should
have worked.  Subversion doesn't keep any record of workspace state
(more's the pity).

Tony.

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

[Tony Sweeney]

 

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: 22 February 2011 09:34
> To: Johan Corveleyn
> Cc: Thomas STEININGER; Stephen Connolly; users@subversion.apache.org
> Subject: Re: Re: Antwort: Re: problem with mutated vowel in 
> log-message-contents
> 
> Daniel Shahaf wrote on Tue, Feb 22, 2011 at 11:26:25 +0200:
> > Johan Corveleyn wrote on Tue, Feb 22, 2011 at 09:43:25 +0100:
> > > So, all that being said, what Daniel means is that you 
> could apply 
> > > something like:
> > > 
> > > svn propedit --revprop -r $REV --editor-cmd 'perl -pi -e 
> > > "s/\\xfc/\\xc3\\xbc/g"'
> > > 
> > > to all revisions (REV) that need to be corrected (either 
> a list that 
> > > you make up manually, or something automated with "svn propget 
> > > --revprop" combined with "sed", or something similar ...).
> > 
> > By the way, please don't consider this a generic solution.  It's a 
> > *shortcut*, which is probably okay for ü, but WILL corrupt your log 
> > messages if you adapt it for §.
> 
> ... because the latin1 byte sequence for § is part of some 
> UTF-8 byte sequences.

Which is why you should probably use iconv(1) or any of the APIs listed here:

http://www.unicodetools.com/

instead of dicking around with perl or sed and hard coded hand crafted single 
character mappings.  There's potentially a lot more than just u-umlaut to worry 
about.

Tony.

> 
> (I'm assuming that at least some log messages are already in UTF-8.)
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

Re: ^M Appends to every line?

[Tony Butt]

On Wed, 2011-02-23 at 20:03 -0600, Ryan Schmidt wrote:
> On Feb 23, 2011, at 19:48, David Chapman wrote:
> > On 2/23/2011 4:44 PM, Nico Kadel-Garcia wrote:
> >> On Wed, Feb 23, 2011 at 11:39 AM, Les Mikesell wrote:
> >>> Short version: set the svn:eol-style property to native on the files where
> >>> you want subversion to manage line endings.  Your client may have a list 
> >>> of
> >>> file suffixes where this would be set automatically.
> >> But in general, avoid it. If you're in a mixed platform environment,
> >> and you are tweaking files back and forth in end-of-line settings when
> >> you check them out in UNIX versis checking them out in Windows, you
> >> are in for a *world* of hurt. This is a source of enormous confusion
> >> for programmers when it works right, on one system, but not on the
> >> other due to local re-writing.
> >> 
> >> If you're on the UNIX or Linux sides, the "dos2unix" and "unix2dos"
> >> utilities are available with almost every distribution. For Windows,
> >> there are other tools, including the same tools under CygWin.
> > 
> > Uh, no.  Use of "svn:eol-style" avoids a world of hurt - programmers do not 
> > have to run a script *every* time they check out a file.  Requiring users 
> > to run a script to fix line endings in every sandbox is a recipe for 
> > disaster.
> > 
> > "dos2unix" and "unix2dos" are precisely the kind of local rewriting you 
> > want to avoid.
> 
> 
> Some have the view that setting svn:eol-style to native is a problem; perhaps 
> that's what Nico meant. Certainly, it would be a problem (wouldn't work as 
> designed) if you check out a working copy on a platform with one eol 
> convention (e.g. Mac OS X) and move that working copy to an OS with a 
> different eol convention (e.g. Windows). If that is something you plan to do, 
> the alternative is to still use svn:eol-style but set it to a specific eol 
> style instead -- for example LF. Then you would have to configure all your 
> editors on all platforms to use that line ending style.*
> 
> * Actually it does not matter if the editor decided, for example, to 
> completely convert the file from, say, LF to CRLF line endings. On commit, 
> your Subversion client would notice the change and convert it back to just LF 
> before submitting it to the repository. The situation Subversion won't handle 
> for you, and will abort the commit with an error message, is if your editor 
> decides to save a file with mixed line endings. Such editors are broken IMHO. 
> UltraEdit is an example of an editor we used which was broken in this way, 
> unless you remembered to change a particular preference setting.
Another example is emacs (the one true ring (um) editor). But only if
there were mixed line endings to begin with.
> 
> NOT using svn:eol-style at all will remove all eol checks that Subversion 
> does, and if you are using multiple editors on multiple platforms, you will 
> most probably end up with files of mixed line ending styles. THAT is a recipe 
> for disaster.
> 
I have in the past tried to use a smb exported share form a unix box on
a windows client. Don't do that, nothing but trouble.
> 

-- 
Tony Butt 
CEA Technologies

RE: Unresolvable conflicts?????

[Tony Sweeney]

> -Original Message-
> From: Michael Durket [mailto:dur...@highwire.stanford.edu] 
> Sent: 03 March 2011 15:48
> To: users@subversion.apache.org
> Subject: Unresolvable conflicts?
> 
> I am running a Subversion 1.4 repository (because Redhat 5 
> supplied only svn at release 1.4) and accessing it with a 1.6 
> client (because that's the current release level supplied by 
> Mac OS X). Michael,

I strongly, strongly suggest that you upgrade your repository to 1.6:
either figure out to get it from rpmforge or build it from source.

Tony. 

RE: Using svn with cron?

[Tony Sweeney]

 

> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
> Sent: 07 March 2011 12:57
> To: Ole Pinto
> Cc: bimininavels; users@subversion.apache.org
> Subject: Re: Using svn with cron?
> 
> On Mon, Mar 7, 2011 at 3:24 AM, Ole Pinto  wrote:
> > As you are scheduling your job to run with your user, I 
> don't think it 
> > is a permissions related problem. But maybe the env. vars 
> do matter, 
> > including any needed to get to your stored password.
> >
> > Once you get to stderr you'll probably have a clue about 
> what is happening.
> > If not, from your perl script print the environment vars, and 
> > reproduce that in an interactive shell. If it doesn't work, 
> there you 
> > have it. Now you would only need to compare this to a 
> "normal" shell, 
> > and make small modifications until you make it work.
> >
> > On Sun, Mar 6, 2011 at 20:45, bimininavels  wrote:
> >>
> >> I've been struggling all morning with what should be a very simple 
> >> problem.
> >>
> >> I would like to commit and update a svn repository daily 
> using cron. 
> >> I've encapsulated my svn calls into a perl script, which runs the 
> >> following
> >>
> >> 
> >> #!/usr/bin/perl
> >>
> >> print "To run svn commit\n";
> >> $thetime=time;
> >>
> >> system "cd ~/docs; /usr/bin/svn commit --message '$thetime' \n"; 
> >> system "cd ~/docs; /usr/bin/svn info \n";
> 
> Hello. Is that "$thetime" getting parsed?
> 
> Look, for 3 lines of code, you don't need perl.
> 
> #!/bin/sh
> cd ~/docs || exit 1
> /usr/bin/svn commit --message "`date`"
> /usr/bin/svn info
> 
> Done. Note the exit if  the "cd" fails, and set whatever 
> "date" format you want.

That isn't valid Bourne shell; tilde expansion is a C shell feature that
has found its way into Bash.  Either invoke Bash explicitly or use $HOME
where you have the tilde.

Tony.

> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: pre-lock.bat Failed in Repo browser

[Tony Sweeney]

 




From: Waseem Bokhari [mailto:waseem.bokh...@netsoltech.com] 
Sent: 08 March 2011 14:24
To: 'Bert Huijben'; users@subversion.apache.org
Subject: RE: pre-lock.bat Failed in Repo browser



I don't think %VISUALSVN_SERVER% is set in your lock script.

 

What is meant by this? 

 

The hook scripts are deliberately run with as few environment
variables set as possible (same as with cron on Unix) to mitigate
security risks.  So if you knnow exactly where svnlook.exe is on your
server machine, you should set this explicitly:

 

 VISUALSVN_SERVER="C:\Program FIles\Virtual SVN"

 

or whatever, right at the start.

 

How can I found "svnlook.exe"  ??

 

Can you please re-edit this script for me.

 

Thanks in advance

 

 

 

From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: Tuesday, March 08, 2011 7:04 PM
To: 'Waseem Bokhari'; users@subversion.apache.org
Subject: RE: pre-lock.bat Failed in Repo browser

 

I don't think %VISUALSVN_SERVER% is set in your lock script.
Subversion explicitly clears most environment variables before calling
hook scripts.

 

Most likely your script can't find svnlook.exe

 

Bert

 

From: Waseem Bokhari [mailto:waseem.bokh...@netsoltech.com] 
Sent: dinsdag 8 maart 2011 7:52
To: users@subversion.apache.org
Subject: pre-lock.bat Failed in Repo browser

 

Hi Experts!
   Below is the "pre-lock.bat " Script 

Only User who lock the file can unlock the file. Other users are
forbidden to Unlock file.

@echo off

:: Set all parameters
set repository=%1
set repopath=%2
set user=%3

:: Set path to svnlook
set svnlook=%VISUALSVN_SERVER%bin\svnlook.exe

:: First check that the lock exists already.
:: In that case svnlook prints the lock description.
"%svnlook%" lock "%repository%" %repopath% | findstr /B /L "UUID
Token:" > NUL 2>&1

:: If the lock does not exist, allow locking
if ERRORLEVEL 1 exit 0

:: Now check the lock's owner
"%svnlook%" lock "%repository%" %repopath% | findstr /C:"Owner:
%user%" > NUL 2>&1

:: If the person locking matches the lock's owner, allow locking
if %ERRORLEVEL% EQU 0 exit 0

:: Otherwise, return failure
echo "Error: %repopath% is locked already." >&2
exit 1


Issue/Problem!!

This scenario failed in Repo Browser. Any one can Unlock
File/Folder through Repo Browser.

Please advice me accordingly.

Thanks 

 


DISCLAIMER: This e-mail and any file transmitted with it are
confidential and intended solely for the use of the addressee. If you
are not the intended recipient, you are hereby advised that any
dissemination, distribution or copy of this email or its attachments is
strictly prohibited. If you have received this email in error, please
immediately notify us by return email and destroy this email message and
its attachments. This communication may contain forward-looking
statements relating to the development of NetSol Technologies' products
and services and future operations. The words "believe," "expect,"
"anticipate," "intend," variations of such words, and similar
expressions, identify forward looking statements, but their absence does
not mean that the statement is not forward-looking. Views and opinions
contained herein are those of the author of this email and do not
necessarily represent those of NetSol Technologies. Statements contained
herein are not guarantees of future performance and are subject to
certain risks, uncertainties and assumptions that are difficult to
predict. The company will not undertake to update any statements
contained herein.

WARNING: The recipient should check this email and any
attachment for the presence of viruses. Although the company has taken
reasonable precautions to ensure no viruses are present in this email,
the company does not accept responsibility for any loss or damage
arising from the use of this email or attachment. Note: Please consider
the environment before printing this e-mail. 


DISCLAIMER: This e-mail and any file transmitted with it are
confidential and intended solely for the use of the addressee. If you
are not the intended recipient, you are hereby advised that any
dissemination, distribution or copy of this email or its attachments is
strictly prohibited. If you have received this email in error, please
immediately notify us by return email and de

RE: Upgrade subversion 1.5.1

[Tony Sweeney]

This isn't on Ubuntu Hardy LTS by any chance, is it?  Because that just
happens to be the latest backported version on that platform.  As others
have already said, you should move to either 1.5.latest or 1.6.latest.

Tony.

> -Original Message-
> From: Cecil Westerhof [mailto:ce...@decebal.nl] 
> Sent: 21 March 2011 16:15
> To: users@subversion.apache.org
> Subject: Upgrade subversion 1.5.1
> 
> I am asked to implement a repository system for a client. 
> When looking at the version, I see:
> svnserve, version 1.5.1 (r32289)
>compiled Mar  1 2011, 17:20:34
> 
> I find this a bit strange. Only three weeks ago compiled, but 
> still on 1.5.1. Should I ask them to upgrade, or is that not 
> very important?
> 
> --
> Cecil Westerhof
> Senior Software Engineer
> LinkedIn: http://www.linkedin.com/in/cecilwesterhof
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: beginner admin question: no repository found

[Tony Sweeney]

You need to tell svnserve where your repository is on the machine.  e.g.

svnserve -d -r /path/to/repo 

It's probably trying to serve a repository rooted at /, which is
probably not where yours is.

> -Original Message-
> From: Stephen Bloch [mailto:sbl...@adelphi.edu] 
> Sent: 08 April 2011 18:11
> To: users@subversion.apache.org
> Subject: beginner admin question: no repository found
> 
> The machine on which my svn repository lives was recently 
> upgraded.  I didn't have svnserve in a run-on-reboot script, 
> so I started it by hand (log in as "svn", then type "svnserve 
> -d").  But whenever I make any requests of the server (e.g. 
> "svn ls svn://localhost", much less "svn update"), I get the 
> error message "svn: No repository found in 
> 'svn://localhost'".  I then do a "ps x", and I see something like
> 11550 ?Ss 0:00 svnserve -d
> 11556 ?Z  0:00 [svnserve] 
> 
> Is 11556 just a subprocess created to handle this request, 
> which for whatever reason hasn't gone away yet?  Or is it the 
> actually svn server, which for some reason died as soon as it 
> was asked to do any work?

The former.  The svnserve daemon spawns a child process for each
connection.  On UNIX derivatives, zombie processes (the Z above) are
created when a child process exits and the parent doesn't call wait() to
retrieve its exit status.  They get cleaned up by the init process
eventually.

> 
> I've done an "svnadmin verify", and the repository seems to 
> be fine.  None of the config files has been changed in over a 
> year, so I doubt they're corrupted.  Any ideas?
> 
> 
> 
> Stephen Bloch
> sbl...@adelphi.edu
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

Error with svn diff

[Tony Butt]

We are using Subversion 1.6.16 on a Ubuntu Lucid box, and a Ubuntu Hardy
(8.04) box hosting a subversion 1.6.16 repository via apache.

We use this configuration to support codestriker 1.9.10 for code
reviews, and have recently hit a problem with some of our reviews. After
carefully stepping through the codestriker code with some of our
affected source code, I found a problem with svn diff

The codestriker code checks the summary of lines changed at the top of
each diff block against the actual lines in the block, and rejects the
diff as malformed if they do not match.

On a particular piece of code, the svn diff header claims 33 old lines,
when there are actually 32.

I have re-run this with an external diff command 
(svn diff -r 57968:57969 --old  --diff-cmd=/usr/bin/diff > out.diff)

and the problem goes away.

I reverted my subversion installation to 1.6.6, and the problem is still 
present.

I am loathe to post the diff, as the project is somewhat sensitive - we
build systems for defence here.

Finally, I am away on leave for a week, so cannot reply until after 26th
April.

-- 
Tony Butt 
CEA Technologies

Re: Error with svn diff

[Tony Butt]

On Fri, 2011-04-15 at 02:31 -0500, Ryan Schmidt wrote:
> 
> On Apr 15, 2011, at 01:06, Tony Butt wrote:
> 
> > On a particular piece of code, the svn diff header claims 33 old lines,
> > when there are actually 32.
> > 
> > I have re-run this with an external diff command 
> > (svn diff -r 57968:57969 --old  --diff-cmd=/usr/bin/diff > 
> > out.diff)
> > 
> > and the problem goes away.
> 
> You're talking about the header that looks like this?
> 
> @@ -183,6 +185,8 @@
> 
> (Meaning, in this case: The old version had 6 lines beginning at line 183; 
> the new version has 8 lines beginning at line 185)
> 
> Is it possible the document has mixed line ending styles? -- some lines 
> ending with CRLF and some ending with LF? If so, fix this, ideally by making 
> use of the svn:eol-style property.
> 
> 
It is probable the document has mixed line style endings - I have
updated the line endings in a test repository, but that does not help
with a historical diff. In the meantime, I am trying to educate the
engineers involved about the merits of auto-props, so this is less
likely to happen in the future.

Thanks,
Tony
> 

-- 
Tony Butt 
CEA Technologies

Re: Error with svn diff

[Tony Butt]

On Wed, 2011-04-27 at 02:05 -0500, Ryan Schmidt wrote:
> On Apr 26, 2011, at 18:46, Tony Butt wrote:
> 
> > On Fri, 2011-04-15 at 02:31 -0500, Ryan Schmidt wrote:
> >> 
> > 
> >> Is it possible the document has mixed line ending styles? -- some lines 
> >> ending with CRLF and some ending with LF? If so, fix this, ideally by 
> >> making use of the svn:eol-style property.
> >> 
> > 
> > It is probable the document has mixed line style endings - I have
> > updated the line endings in a test repository, but that does not help
> > with a historical diff.
> 
> If you can afford to take the repository offline for awhile, and force 
> everybody to check out new working copies, you can fix your historical line 
> endings by using svndumptool's eolfix option.
> 
> http://svn.borg.ch/svndumptool/
> 
> 
Unfortunately not practical, unless I work overnight.
>From past experience with our repo, that takes several hours.

For me, using an external diff (gnu diff) with the offending package
(codestriker) works fine in this case.
> > In the meantime, I am trying to educate the
> > engineers involved about the merits of auto-props, so this is less
> > likely to happen in the future.
> 
> Do educate on which files should have svn:eol-style set to what value, and do 
> encourage developers to use auto-props to automate what they learned, but 
> also install a pre-commit hook script in the repository that absolutely 
> prevents the problem from happening in the future. If you've decided for 
> example that .txt files shall have the svn:eol-style set to native, then 
> write and install a pre-commit hook script that prevents anyone from adding 
> any .txt file that does not have svn:eol-style set to native.
> 
Do you know offhand of a similar script to require particular
properties?
> 

-- 
Tony Butt 
CEA Technologies

RE: Branching Questions

[Tony Sweeney]

 

-Original Message-
From: Phil Pinkerton [mailto:pcpinker...@gmail.com] 
Sent: 01 July 2011 11:58
To: Subversion User List
Subject: Branching Questions


1. We are creating branch out of previous branch, if we want to delete a
old branch or archive it how it will impact the current branch ?

It won't

2. There is no limit on number of branches you can create, is this true
?

Effectively.

3. What is the best way to lock the Trunk so only certain users can
access it, using Hook Script or using admin tool?

Horses for courses.


Phil


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11

RE: Branching Questions

[Tony Sweeney]

Sorry, that's a common British idiom which obviously doesn't travel.
Racehorses vary in strength, speed, stamina and temperament; some race
horses do better in "heavier going" (i.e. a softer, muddier track), some
race faster on a dry course, and of course racecourses vary in length.
So there's no single answer to "which is the best horse", as there are
"horses for courses".  Makes sense now?  Which approach you take to (3)
depends on the existing customer set up.  There are a number of
tradeoffs, so there's no single right answer.

Tony.

-Original Message-
From: Phil Pinkerton [mailto:pcpinker...@gmail.com] 
Sent: 01 July 2011 12:45
To: Tony Sweeney
Cc: Subversion User List
Subject: Re: Branching Questions

Thanks for the quick response.

However I have no clue what you mean by Horses for courses.

and I certainly cannot reply to my clients question with such an answer.

On 7/1/2011 7:03 AM, Tony Sweeney wrote:
>
>
> -Original Message-
> From: Phil Pinkerton [mailto:pcpinker...@gmail.com]
> Sent: 01 July 2011 11:58
> To: Subversion User List
> Subject: Branching Questions
>
>
> 1. We are creating branch out of previous branch, if we want to delete

> a old branch or archive it how it will impact the current branch ?
>
> It won't
>
> 2. There is no limit on number of branches you can create, is this 
> true ?
>
> Effectively.
>
> 3. What is the best way to lock the Trunk so only certain users can 
> access it, using Hook Script or using admin tool?
>
> Horses for courses.
>
>
> Phil
>
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> __
>
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 
> 06/30/11
>

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11

RE: Branching Questions

[Tony Sweeney]

 

-Original Message-
From: Phil Pinkerton [mailto:pcpinker...@gmail.com] 
Sent: 01 July 2011 15:50
To: Andy Levy
Cc: Tony Sweeney; Subversion User List
Subject: Re: Branching Questions



On 7/1/2011 9:57 AM, Andy Levy wrote:
> Please stop top-posting.

> I was simply following the responce format to my orignial email, I
understand about bottom response, but thing change so I just followed
what I recieved.

Which was, in fact, my fault, as I thought I was replying only to Phil.
(I would blame Outlook, which is what my employer provides, but a bad
workman &c.).

Tony.

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1388 / Virus Database: 1516/3736 - Release Date: 06/30/11

Trials with memcached

[Tony Butt]

We are running subversion 1.6.17 on a vmware hosted server. We recently
reconfigured the server to give 4 virtual CPUs (up from 1), and a
significant amount of memory.


In order to spruce up our performance a little, I looked into the use of
memcached with subversion again, found the correct config parameter, and
set it up. Our server is running Ubuntu 10.04, Apache 2.2. Access
mechanism is http (of course). The client used is running Ubuntu 11.04,
and svn commandline (1.6.17 also)

The results were interesting, to say the least.

Checkout of a tree, about 250M in size:

Without memcached, 1 1/2 to 2 minutes, varies with server load
With memcached, 12 minutes (!)

Update of the same tree, 
Without memcached, 9 seconds
With memcached, 14 seconds - repeated several times, similar results.

I am not sure what anyone else's experience is, but we will not be
enabling memcached for subversion any time soon.
-- 
Tony Butt 
CEA Technologies

Re: Trials with memcached

[Tony Butt]

On Fri, 2011-07-08 at 02:59 +0300, Daniel Shahaf wrote:
> This doesn't address memcached directly, but there has been a /lot/ of
> work on server-side optimization and caching in 1.7 (also for
> non-memcached-backed caches).
> 
> http://subversion.apache.org/docs/release-notes/1.7#server-performance-tuning
> 
> You might want to take 1.7.0-alpha3 for a spin...
> 
Probably don't want to do that.
We are in a commercial environment, with some 20 developers relying on
subversion - not the time for an alpha release.

We are actually happy with the current performance, particularly since
the load of other tasks on the server (backups, opengrok indexing of the
repo for instance) is now shared by 4 processors instead of 1. I was
reviewing the overall configuration, and we already use memcached to
support ReviewBoard for code reviews.

We will be particularly interested in server side performance
improvements when 1.7.0 is released - we have home grown build
dependency tools that are sometimes heavy on the repository usage -
these will be difficult to upgrade to 1.7.0, but if there are uncoupled
server performance improvements, the server upgrade is trivial by
comparison.

Thanks,
Tony Butt
> Tony Butt wrote on Wed, Jul 06, 2011 at 15:20:27 +1000:
> > We are running subversion 1.6.17 on a vmware hosted server. We recently
> > reconfigured the server to give 4 virtual CPUs (up from 1), and a
> > significant amount of memory.
> > 
> > 
> > In order to spruce up our performance a little, I looked into the use of
> > memcached with subversion again, found the correct config parameter, and
> > set it up. Our server is running Ubuntu 10.04, Apache 2.2. Access
> > mechanism is http (of course). The client used is running Ubuntu 11.04,
> > and svn commandline (1.6.17 also)
> > 
> > The results were interesting, to say the least.
> > 
> > Checkout of a tree, about 250M in size:
> > 
> > Without memcached, 1 1/2 to 2 minutes, varies with server load
> > With memcached, 12 minutes (!)
> > 
> > Update of the same tree, 
> > Without memcached, 9 seconds
> > With memcached, 14 seconds - repeated several times, similar results.
> > 
> > I am not sure what anyone else's experience is, but we will not be
> > enabling memcached for subversion any time soon.
> > -- 
> > Tony Butt 
> > CEA Technologies
> > 

-- 
Tony Butt 
CEA Technologies

Re: Trials with memcached

[Tony Butt]

On Thu, 2011-07-07 at 17:31 -0700, Geoff Hoffman wrote: 


Tony - 



Strange results to be sure. You probably thought of all this, but... 

Did you check Memcached is working correctly without Subversion?


It seems to be - reviewboard works OK, and running memcached-tool shows cache 
hits, etc, as expected. 

Did you check the results of checking out or updating the 2nd or 3rd 
time?


I ran the update several times, it was consistent.
I did not do the original checkout more than once. 

In other words, it may take longer the first time because every object 
in the repo has to be checked for existence/expiry in the cache.


Yes - memcached-util showed plenty of cache hits after the initial checkout. 

Did you check that you gave Memcached enough memory to fit the entire 
250mb repo (comfortably) in RAM?


Configured memcached with 256M memory. Might not be enough. I will try with 
512M, and watch the performance on the server.
Our entire repository is several gigabytes in size, checkout sizes might be 
around 500M or so. If populating the cache causes a 6x slowdown, it is probably 
not worth it for 20 developers anyway.
The issue there is that it blows out our 'worst case' timing. 

If not then memcached itself tries to use swap space? 

32-bit or 64-bit VM?


PAE kernel, 

Did you try it on physical hardware?


No - we have a test machine that runs on physical hardware, I will try it there 
when I have time. 







On Thu, Jul 7, 2011 at 4:59 PM, Daniel Shahaf  
wrote: 

This doesn't address memcached directly, but there has been a 
/lot/ of
work on server-side optimization and caching in 1.7 (also for
non-memcached-backed caches).


http://subversion.apache.org/docs/release-notes/1.7#server-performance-tuning

You might want to take 1.7.0-alpha3 for a spin...

    Tony Butt wrote on Wed, Jul 06, 2011 at 15:20:27 +1000:
> We are running subversion 1.6.17 on a vmware hosted server. 
We recently
> reconfigured the server to give 4 virtual CPUs (up from 1), 
and a
> significant amount of memory.
>
>
> In order to spruce up our performance a little, I looked into 
the use of
> memcached with subversion again, found the correct config 
parameter, and
> set it up. Our server is running Ubuntu 10.04, Apache 2.2. 
Access
> mechanism is http (of course). The client used is running 
Ubuntu 11.04,
> and svn commandline (1.6.17 also)
>
> The results were interesting, to say the least.
>
> Checkout of a tree, about 250M in size:
>
> Without memcached, 1 1/2 to 2 minutes, varies with server load
> With memcached, 12 minutes (!)
>
> Update of the same tree,
> Without memcached, 9 seconds
> With memcached, 14 seconds - repeated several times, similar 
results.
>
> I am not sure what anyone else's experience is, but we will 
not be
> enabling memcached for subversion any time soon.
> --
> Tony Butt 
> CEA Technologies
> 








-- 
Tony Butt 
CEA Technologies

Re: Trials with memcached

[Tony Butt]

On Fri, 2011-07-08 at 03:58 +0300, Daniel Shahaf wrote:
> Tony Butt wrote on Fri, Jul 08, 2011 at 10:41:43 +1000:
> > On Fri, 2011-07-08 at 02:59 +0300, Daniel Shahaf wrote:
> > > This doesn't address memcached directly, but there has been a /lot/ of
> > > work on server-side optimization and caching in 1.7 (also for
> > > non-memcached-backed caches).
> > > 
> > > http://subversion.apache.org/docs/release-notes/1.7#server-performance-tuning
> > > 
> > > You might want to take 1.7.0-alpha3 for a spin...
> > > 
> > Probably don't want to do that.
> > We are in a commercial environment, with some 20 developers relying on
> > subversion - not the time for an alpha release.
> > 
> 
> I wasn't suggesting that you upgrade your production server!
I didn't really think you would be :-)
> 
> Just that you install the alpha in a test environment to see if it
> improves the situation for you.  (or if there is anything you see that
> requires modification /before/ the release --- before compatibility
> promises apply --- as in eg issue #3952)
> 
My available test server also syncs the production repository to itself
as a hot spare. I am probably brave enough to install 1.7.0-alpha3 on
that, so long as there are no issues syncing from 1.6.17 to 1.7.0

I was starting to think that apache 2.2 + subversion 1.6.17 probably did
as much caching as was necessary for good performance, and that adding
in memcache to serve what is almost static data was really adding an
overhead.

Anyway...
Not really complaing about the performance of apache + subversion, just
surprised at the effect of apache + subversion + memcached, and
wondering if anyone else had any positive or negative experiences.

Thanks,
Tony

> > We are actually happy with the current performance, particularly since
> > the load of other tasks on the server (backups, opengrok indexing of the
> > repo for instance) is now shared by 4 processors instead of 1. I was
> > reviewing the overall configuration, and we already use memcached to
> > support ReviewBoard for code reviews.
> > 
> > We will be particularly interested in server side performance
> > improvements when 1.7.0 is released - we have home grown build
> > dependency tools that are sometimes heavy on the repository usage -
> > these will be difficult to upgrade to 1.7.0, but if there are uncoupled
> > server performance improvements, the server upgrade is trivial by
> > comparison.
> > 
> > Thanks,
> > Tony Butt
> > > Tony Butt wrote on Wed, Jul 06, 2011 at 15:20:27 +1000:
> > > > We are running subversion 1.6.17 on a vmware hosted server. We recently
> > > > reconfigured the server to give 4 virtual CPUs (up from 1), and a
> > > > significant amount of memory.
> > > > 
> > > > 
> > > > In order to spruce up our performance a little, I looked into the use of
> > > > memcached with subversion again, found the correct config parameter, and
> > > > set it up. Our server is running Ubuntu 10.04, Apache 2.2. Access
> > > > mechanism is http (of course). The client used is running Ubuntu 11.04,
> > > > and svn commandline (1.6.17 also)
> > > > 
> > > > The results were interesting, to say the least.
> > > > 
> > > > Checkout of a tree, about 250M in size:
> > > > 
> > > > Without memcached, 1 1/2 to 2 minutes, varies with server load
> > > > With memcached, 12 minutes (!)
> > > > 
> > > > Update of the same tree, 
> > > > Without memcached, 9 seconds
> > > > With memcached, 14 seconds - repeated several times, similar results.
> > > > 
> > > > I am not sure what anyone else's experience is, but we will not be
> > > > enabling memcached for subversion any time soon.
> > > > -- 
> > > > Tony Butt 
> > > > CEA Technologies
> > > > 
> > 
> > -- 
> > Tony Butt 
> > CEA Technologies

-- 
Tony Butt 
CEA Technologies

Re: Trials with memcached

[Tony Butt]

On Thu, 2011-07-07 at 17:31 -0700, Geoff Hoffman wrote: 


Tony - 



Strange results to be sure. You probably thought of all this, but... 

Did you check Memcached is working correctly without Subversion? 

Did you check the results of checking out or updating the 2nd or 3rd 
time? 

In other words, it may take longer the first time because every object 
in the repo has to be checked for existence/expiry in the cache. 

Did you check that you gave Memcached enough memory to fit the entire 
250mb repo (comfortably) in RAM? 

If not then memcached itself tries to use swap space? 

32-bit or 64-bit VM?


As before, PAE kernel. Processor claims to be a Xeon. Not sure how to tell what 
the underlying VM software is doing.

I ran my test with memcached -m 512
That is, 512M memory. Checkout completed in 11 minutes - better than before, 
but still slower than without memcached.
memcached-tool localhost stats reports 
  get_hits481964
  get_misses   71527
among many other things, so the cache is certainly working (numbers were much 
smaller before the checkout).
Running again completed in 8m 34s, still too slow...

Tony




Did you try it on physical hardware? 







On Thu, Jul 7, 2011 at 4:59 PM, Daniel Shahaf  
wrote: 

This doesn't address memcached directly, but there has been a 
/lot/ of
work on server-side optimization and caching in 1.7 (also for
non-memcached-backed caches).


http://subversion.apache.org/docs/release-notes/1.7#server-performance-tuning

You might want to take 1.7.0-alpha3 for a spin...

    Tony Butt wrote on Wed, Jul 06, 2011 at 15:20:27 +1000:
> We are running subversion 1.6.17 on a vmware hosted server. 
We recently
> reconfigured the server to give 4 virtual CPUs (up from 1), 
and a
> significant amount of memory.
>
>
> In order to spruce up our performance a little, I looked into 
the use of
> memcached with subversion again, found the correct config 
parameter, and
> set it up. Our server is running Ubuntu 10.04, Apache 2.2. 
Access
> mechanism is http (of course). The client used is running 
Ubuntu 11.04,
> and svn commandline (1.6.17 also)
>
> The results were interesting, to say the least.
>
> Checkout of a tree, about 250M in size:
>
> Without memcached, 1 1/2 to 2 minutes, varies with server load
> With memcached, 12 minutes (!)
>
> Update of the same tree,
> Without memcached, 9 seconds
> With memcached, 14 seconds - repeated several times, similar 
results.
>
> I am not sure what anyone else's experience is, but we will 
not be
> enabling memcached for subversion any time soon.
> --
    > Tony Butt 
> CEA Technologies
> 








-- 
Tony Butt 
CEA Technologies

Re: Fwd: [Tony Butt: Trials with memcached]

[Tony Butt]

On Sat, 2011-07-09 at 15:02 +0200, Stefan Fuhrmann wrote:
> On 08.07.2011 01:56, Daniel Shahaf wrote:
> > FYI from users@
> >
> > - Forwarded message from Tony Butt  -
> > Date: Wed, 6 Jul 2011 15:20:27 +1000
> >> We are running subversion 1.6.17 on a vmware hosted server. We recently
> >> reconfigured the server to give 4 virtual CPUs (up from 1), and a
> >> significant amount of memory.
> >>
> >> In order to spruce up our performance a little, I looked into the use of
> >> memcached with subversion again, found the correct config parameter, and
> >> set it up. Our server is running Ubuntu 10.04, Apache 2.2. Access
> >> mechanism is http (of course). The client used is running Ubuntu 11.04,
> >> and svn commandline (1.6.17 also)
> >>
> >> The results were interesting, to say the least.
> >>
> And the sad thing that these results are in line with
> what can be expected in 1.6. That's why the whole
> caching code has been reworked in 1.7.
> >> Checkout of a tree, about 250M in size:
> >>
> >> Without memcached, 1 1/2 to 2 minutes, varies with server load
> >> With memcached, 12 minutes (!)
> >>
> >> Update of the same tree,
> >> Without memcached, 9 seconds
> >> With memcached, 14 seconds - repeated several times, similar results.
> You can expect all similarly structured repositories
> to show similar performance patterns. Only for very
> different content and usage patterns, there might be
> a performance improvement (see below).
> >> I am not sure what anyone else's experience is, but we will not be
> >> enabling memcached for subversion any time soon.
> I will try to answer that with some indication towards
> what you may try and when that might aid performance
> in 1.6 and 1.7. But first, let me give you some technical
> background because there is obviously no simple
> recipe for making things fast in 1.6.
> 
> The key factors here is latency and trade-off. To read
> a userfile@rev from the repository, the back-end has to
> follow a short chain of objects (roughly: rev->offset in repo
> file, userfile -> last change, last change -> offset in repo file,
> chain of deltas to combine). All that data will ultimately
> come from disk.
> 
> Most servers boast large amounts of file system cache
> that can be accessed in < 0.1ms. SVN itself will cache
> the index information used at the beginning of the lookup
> chain in in its application memory. By default, only the
> user file deltas need to be read (from file system cache),
> decompressed and combined into the original content.
> 
> For typical files < 100k, only 5 or less of these delta
> blocks need to be read while the index / admin info
> at the beginning of the lookup chain contains also about
> 5 steps which can often be satisfied directly from internal
> caches, i.e. are "for free". So, the default in 1.6 is < 1ms
> for reading the data plus come CPU load from unzipping it.
> 
> With memcached, the picture changes and parts of that
> can be considered a design flaw in 1.6. All index objects
> will be stored in the memcached, i.e. accessing them is
> no longer for free. OTOH, reconstructed user-file content
> will no be cached, i.e. no need to reconstruct it from
> deltas over and over again. So, we traded 3 or 4 file
> cache reads plus unzip CPU load for ~5 memcached reads.
> 
> But the latter involves a TCP/IP communication between
> processes with latencies 2+ times that of the file system
> cache. To make things worse, memcached seems to
> shut off for a few seconds when being hammered with
> a large number of requests in a short period of time
> (I observed that behavior under Ubuntu 9.04). To mitigate
> that, i.e. have *some* process to answer your requests,
> start 3 or 4 of them. They all will end up with redundant
> information.
> 
Without understanding the details, that is similar to what I thought
must be happening. Since it is fairly simple to switch in/out memcached,
I will try again when we go to 1.7.

Thanks for the thoughtful response -

Tony Butt
> So, when can memcached be useful in 1.6?
> 
> * when the file system cache in ineffective (repositories
>on NFS-like shares)
> * disk (NAS) latency is higher than TCP/IP latency
> * large external memcached servers are available
>compared to usable file system cache on the SVN
>server machine
> * huge repositories where the combined amount of
>frequently requested information is larger than what
>the file system cache can buffer.
> 
> For 1.7, things are quite different. Memcached will only
> be used for

Re: SVN 1.7 SVNParentPath broken

[Tony Butt]

On Tue, 2011-07-26 at 10:04 +0200, Mario Brandt wrote:
> I installed SVN/1.7.0-beta2 using it over apache 2.3.12, also tried
> the alphas before. With none of it I'm able to use SVNParentPath. I'm
> getting
> 
> 
> Could not open the requested SVN filesystem
> 
> 
This is because the repository format changed slightly between the alpha
releases and the beta2 release. You will need to re-create the
repository.
I had the exact same problem, dump and load into a new repository worked
for me.

Tony Butt
> the same error if that wouldn't be a repo instead of showing the list of 
> repos.
> 
> my config
>   
>DAV svn
>SVNParentPath "/opt/repos"
>SVNListParentPath on
>SVNPathAuthz on
>#SVNIndexXSLT "/svnindex.xsl"
> 
>AuthType Basic
>AuthName "Subversion Repository"
>AuthUserFile /opt/repos/htpasswd
>Require valid-user
>
> 
> 
> Cheers
> Mario

-- 
Tony Butt 
CEA Technologies

Re: SVN 1.7 SVNParentPath broken

[Tony Butt]

On Tue, 2011-07-26 at 11:13 +0200, Mario Brandt wrote:
> >> This is because the repository format changed slightly between the alpha
> >> releases and the beta2 release. You will need to re-create the
> >> repository.
> >> I had the exact same problem, dump and load into a new repository worked
> >> for me.
> 
> The issues are not the repos. I can access my 1.6.17 and older repos
> without any issues.
> 
That was the case for me too - I had one repository which I created with
alpha2, and load from a dump file. It worked fine with alpha3, and then
I saw the error you have with beta2. At the same time, alpha2, alpha3,
and beta2 all worked happily with my other repositories, which had been
created by svn 1.6.x. I was not using SVNParentPath with these
repositories, so can't comment on that, but definitely could not access
my alpha2 created repository from beta2 using mod_dav_svn and apache.

Tony
> The file system layout is
> 
> /opt/repos  <--- ParentPath
> /opt/repos/repo1
> /opt/repos/repo2
> /opt/repos/repo3
> /opt/repos/repoN
> 
> As it was in SVN 1.6 SVNParentPath should show a list of the repos
> 1,2,3 to N [1]
> 
> > Second of all, don't you get the error documented in
> > <http://subversion.apache.org/docs/release-notes/1.7#revprop-packing> in
> > that case?
> 
> Nope I don't get that error. This is might related to the mod_dav_svn.
> I'm not sure. But at leat I can say that over apache (I don't use
> svnserve) I never had an issue with the 1.6.x repos with the
> mod_dav_svn 1.7.x apache module.
> 
> Cheers
> Mario
> 
> 
> [1] 
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.httpd.basic

-- 
Tony Butt 
CEA Technologies

Re: SVN 1.7 SVNParentPath broken

[Tony Butt]

On Wed, 2011-07-27 at 06:56 +0300, Daniel Shahaf wrote:
> Tony Butt wrote on Wed, Jul 27, 2011 at 10:47:39 +1000:
> > could not access my alpha2 created repository from beta2 using
> > mod_dav_svn and apache.
> 
> That's expected.  Did you get the error documented at
> http://subversion.apache.org/docs/release-notes/1.7#revprop-packing
> or some other error?
It was not that error, but some other. There was some mention of XML in
the browser window. Sorry, I can't remeber more of it than that. I put
it down to an upgrade incompatibility from alpha[2|3] to beta2,
recreated the repo, and did not see the problem again.

I can try to reproduce it using my alpha3 build if you like...

-- 
Tony Butt 
CEA Technologies

Re: SVN 1.7 SVNParentPath broken

[Tony Butt]

On Thu, 2011-07-28 at 03:11 +0300, Daniel Shahaf wrote:
> Tony Butt wrote on Thu, Jul 28, 2011 at 09:53:35 +1000:
> > On Wed, 2011-07-27 at 06:56 +0300, Daniel Shahaf wrote:
> > > Tony Butt wrote on Wed, Jul 27, 2011 at 10:47:39 +1000:
> > > > could not access my alpha2 created repository from beta2 using
> > > > mod_dav_svn and apache.
> > > 
> > > That's expected.  Did you get the error documented at
> > > http://subversion.apache.org/docs/release-notes/1.7#revprop-packing
> > > or some other error?
> > It was not that error, but some other. There was some mention of XML in
> > the browser window. Sorry, I can't remeber more of it than that. I put
> > it down to an upgrade incompatibility from alpha[2|3] to beta2,
> > recreated the repo, and did not see the problem again.
> > 
> > I can try to reproduce it using my alpha3 build if you like...
> 
> If you have a beta1 or beta2 build, can you try:
> 
> * Creating a repository using <=1.6.x or >=beta1
Already have at least one of each
> * Making sure you can access that repository
Can definitely do that, for both 1.6.17, and 1.7.0 beta2
> * Either: rm -rf the repository, and recreate it using 1.7.0-alpha3
Recreated using alpha3
>   or: change '4' to '5' on the first line of $REPOS_DIR/db/format
> * Trying to access the repository, reporting what error you get
> 
Tried to access the repository using mod_dav_svn 1.7.0 beta2

Saw this in the browser:

This XML file does not appear to have any style information associated with it. 
The document tree is shown below.

Could not open the requested SVN filesystem


I checked the ownership of the repository files, all owned by www-data

Other repo's in the tree can be accessed normally (1.6.17 and 1.7.0 beta2)
> Thanks!
> 
> Daniel
> 

-- 
Tony Butt 
CEA Technologies

Re: SVN 1.7 SVNParentPath broken

[Tony Butt]

On Thu, 2011-07-28 at 10:50 +1000, Tony Butt wrote:
> On Thu, 2011-07-28 at 03:11 +0300, Daniel Shahaf wrote:
> > Tony Butt wrote on Thu, Jul 28, 2011 at 09:53:35 +1000:
> > > On Wed, 2011-07-27 at 06:56 +0300, Daniel Shahaf wrote:
> > > > Tony Butt wrote on Wed, Jul 27, 2011 at 10:47:39 +1000:
> > > > > could not access my alpha2 created repository from beta2 using
> > > > > mod_dav_svn and apache.
> > > >
> > > > That's expected.  Did you get the error documented at
> > > >
> http://subversion.apache.org/docs/release-notes/1.7#revprop-packing
> > > > or some other error?
> > > It was not that error, but some other. There was some mention of
> XML in
> > > the browser window. Sorry, I can't remeber more of it than that. I
> put
> > > it down to an upgrade incompatibility from alpha[2|3] to beta2,
> > > recreated the repo, and did not see the problem again.
> > >
> > > I can try to reproduce it using my alpha3 build if you like...
> >
> > If you have a beta1 or beta2 build, can you try:
> >
> > * Creating a repository using <=1.6.x or >=beta1
> Already have at least one of each
> > * Making sure you can access that repository
> Can definitely do that, for both 1.6.17, and 1.7.0 beta2
> > * Either: rm -rf the repository, and recreate it using 1.7.0-alpha3
> Recreated using alpha3
> >   or: change '4' to '5' on the first line of $REPOS_DIR/db/format
> > * Trying to access the repository, reporting what error you get
> >
> Tried to access the repository using mod_dav_svn 1.7.0 beta2
> 
> Saw this in the browser:
> 
> This XML file does not appear to have any style information associated
> with it. The document tree is shown below.
> 
> Could not open the requested SVN filesystem
> 
> 

I checked the apache logs, and found this:
[Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] (20014)Internal error: 
Found format '5', only created by unreleased dev builds; see 
http://subversion.apache.org/docs/release-notes/1.7#revprop-packing
[Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not fetch 
resource information.  [500, #0]
[Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not open the 
requested SVN filesystem  [500, #160043]
[Thu Jul 28 10:48:14 2011] [error] [client 172.16.2.39] Could not open the 
requested SVN filesystem  [500, #160043]

I think this is what you were expecting.
> I checked the ownership of the repository files, all owned by www-data
> 
> Other repo's in the tree can be accessed normally (1.6.17 and 1.7.0
> beta2)
> > Thanks!
> >
> > Daniel
> >
> 
> --
> Tony Butt 
> CEA Technologies
> 
> 

-- 
Tony Butt 
CEA Technologies

Subversion Branch/Merge Graphical Display

[Tony Butt]

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

Re: Svn Searcher

[Tony Butt]

On Tue, 2011-08-02 at 17:14 +0200, Michael Diers wrote:
> On 2011-07-27 17:18, Phil Pinkerton wrote:
> > Anyone have experience installing and using Svn Searcher ?
> > 
> > http://svn-search.sourceforge.net/
> > 
> > I have a client that would like to do Repository Searches.
We use Opengrok for repository searching and browsing, and find it very
useful.

Tony Butt
CEA Technologies
> 
> Other tools that offer repository indexing and searching:
> 
>  * Atlassian FishEye
>http://www.atlassian.com/software/fisheye/
> 
>  * Subversion Repository Search Engine (SupoSE)
>http://www.supose.org/
> 
>  * SvnQuery
>http://svnquery.tigris.org/
> 
> -- 
> Michael Diers, elego Software Solutions GmbH, http://www.elego.de

-- 
Tony Butt 
CEA Technologies

RE: How to fix corrupt revision in repo?

[Tony Sweeney]

Unlike 'svnadmin dump', hotcopy will happily back up a corrupt revision
and not tell you.  It's really just a clever filesystem backup with a
very careful time ordering of certain key files in case there is a
transaction in progress when it runs.  Having been bitten by this
myself[*], we now run svnadmin out of cron every night before we run our
hotcopy.  We also keep a week's worth of hotcopies, and I check my cron
emails every morning.

Tony.
[*] fsfsverify.py is your friend

-Original Message-
From: Neil Bird [mailto:n...@jibbyjobby.co.uk] 
Sent: 16 September 2011 09:54
To: users@subversion.apache.org
Subject: Re: How to fix corrupt revision in repo?

Around about 15/09/11 03:30, David Hopkins typed ...
> I have an SVN repo that is failing svnadmin verify on revision 192.

   Slightly OT, if I may:  would a 'svnadmin hotcopy' also show up
errors that 'verify' would?  We use hotcopy to pull our repos off the
SVN server onto a backup-up network drive, but we don't use verify
regularly.

   The network drive has incremental backups so if we see an error
during the copy we can still get older, valid, copies of revs. back.

   Do we need to be running verify as well?

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory [neil@fnx ~]# exit

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3899 - Release Date: 09/15/11

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: How to Maintain "timestamp" in Repository & Working copy ?

[Tony Sweeney]

 

-Original Message-
From: Phil Pinkerton [mailto:pcpinker...@gmail.com] 
Sent: 11 October 2011 15:42
To: users@subversion.apache.org
Subject: How to Maintain "timestamp" in Repository & Working copy ?

I have a request to keep the "commit" timestamps associated with the
file in the working copy the same.

Is that possible ? most users have their working copy on a Windows OS ,
Subversion Server is on a Unix Server ( not that that matters ).

Is there a parameter in TortoiseSVN perhaps ?


---

In the TortoiseSVN settings menu, "General" section, there is a setting
'Set file dates to the "last commit time"' -- is that perhaps what you
want?

Tony.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3943 - Release Date: 10/07/11

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: How to Maintain "timestamp" in Repository & Working copy ?

[Tony Sweeney]

 

-Original Message-
From: Phil Pinkerton [mailto:pcpinker...@gmail.com] 
Sent: 11 October 2011 16:31
To: Tony Sweeney
Cc: users@subversion.apache.org
Subject: Re: How to Maintain "timestamp" in Repository & Working copy ?

How might this be done in a script where the command line is used ?

---8<-

Edit the subversion local configuration in either
$HOME/.subversion/config  or %APPDATA%\Subversion\config and uncomment
the entry for use-commit-times:

### Set use-commit-times to make checkout/update/switch/revert
### put last-committed timestamps on every file touched.
# use-commit-times = yes

Tony.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1410 / Virus Database: 1520/3943 - Release Date: 10/07/11

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: svn 1.7 assertion failed

[Tony Sweeney]

 

-Original Message-
From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] 
Sent: 17 October 2011 16:02
To: users@subversion.apache.org
Cc: ponomarenko yaroslav
Subject: Re: svn 1.7 assertion failed

Am 17.10.2011 16:42, schrieb ponomarenko yaroslav:
> Got this error while trying svn cleanup
> 
> svn: E235000: In file 
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversi
> on\libsvn_wc\workqueue.c' line 672: assertion failed (checksum != 
> NULL)
> 
> win7 64
> Is there a way to recover?

This has been reported ad nauseam. Please do as the message box tells you to, 
i.e. tell as much as possible about what you did and please first search the 
web before being the onehundredandtwentieth to report the same issue.

-

1). There is no search facility in the Apache mailing list archive
2). Searching for his exact error on svn.haxx.se returns zero results
3). Searching for his exact error on gmane.org returns zero results

The error message clearly states: "Please take the time to report this on the 
Subversion mailing list".  The caveat to search the mailing list is clearly 
worthless if there is no obvious way to do what it suggests.

Tony.



Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1831 / Virus Database: 2090/4556 - Release Date: 10/16/11

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: svn 1.7 assertion failed

[Tony Sweeney]

 

-Original Message-
From: David Chapman [mailto:dcchap...@acm.org] 
Sent: 17 October 2011 16:36
To: Tony Sweeney
Cc: users@subversion.apache.org; ponomarenko yaroslav
Subject: Re: svn 1.7 assertion failed

On 10/17/2011 8:24 AM, Tony Sweeney wrote:
>
>
> -Original Message-
> From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com]
> Sent: 17 October 2011 16:02
> To: users@subversion.apache.org
> Cc: ponomarenko yaroslav
> Subject: Re: svn 1.7 assertion failed
>
> Am 17.10.2011 16:42, schrieb ponomarenko yaroslav:
>> Got this error while trying svn cleanup
>> 
>> svn: E235000: In file
>> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subvers
>> i on\libsvn_wc\workqueue.c' line 672: assertion failed (checksum !=
>> NULL)
>> 
>> win7 64
>> Is there a way to recover?
> This has been reported ad nauseam. Please do as the message box tells
you to, i.e. tell as much as possible about what you did and please
first search the web before being the onehundredandtwentieth to report
the same issue.
>
> -
>
> 1). There is no search facility in the Apache mailing list archive 2).

> Searching for his exact error on svn.haxx.se returns zero results 3). 
> Searching for his exact error on gmane.org returns zero results
>
> The error message clearly states: "Please take the time to report this
on the Subversion mailing list".  The caveat to search the mailing list
is clearly worthless if there is no obvious way to do what it suggests.
>
> Tony.
>

Major search engines crawl the archives.  This seems to be an obvious
way.

At the time of writing, Google also returned zero hits for Ponomarenko's
error message.

Tony.

-- 
 David Chapman dcchap...@acm.org
 Chapman Consulting -- San Jose, CA


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1831 / Virus Database: 2090/4556 - Release Date:
10/16/11

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: subversion-1/svn_wc.h:1210: error: comma at end of enumerator list

[Tony Sweeney]

 

-Original Message-
From: Peter Johansson [mailto:peterandrejohans...@gmail.com] 
Sent: 18 October 2011 22:35
To: users@subversion.apache.org
Cc: svndigest-us...@lists.sourceforge.net
Subject: subversion-1/svn_wc.h:1210: error: comma at end of enumerator
list

Hello,

When I compiled with GCC (4.2.1) with compiler option -pedantic against
header file `svn_wc.h' in subversion version 1.7 I get the following
error:

In file included from main.cc:1:
/opt/local/include/subversion-1/svn_wc.h:1210: error: comma at end of
enumerator list
make: *** [main] Error 1

I suspect this is caused by a typo in svn_wc.h at line 1210:

   /** The operation skipped the path because it was conflicted.
* @since New in 1.7. */
   svn_wc_notify_skip_conflicted,

} svn_wc_notify_action_t;

because other enums in the same file have no comma after the last item. 
Is there are reason to have this comma that I'm missing or could it be
removed?

--

The trailing comma is explicitly invalid per ANSI C 89 (though some
compilers, notably GCC, permitted it).  C99 removes this restriction.
It's valid everywhere without the comma, so it's perfectly safe (and
probably desirable) to remove it.  A Google search on 'trailing comma
enum' will find many instances of people submitting similar patches to
other open source projects.

Tony.


Thanks and please let me know if you need further information from me.

--
Cheers,
Peter

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1831 / Virus Database: 2092/4560 - Release Date:
10/18/11

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: Explore repository "head" live on NFS

[Tony Sweeney]

From: Eli Bocek-Rivele [mailto:boc...@gmail.com] 
Sent: 19 October 2011 04:06
To: users@subversion.apache.org
Subject: Explore repository "head" live on NFS


Hi all, 
I'm very new to the community and I can only imagine this question has
been asked before but google searching (and looking in archives) has not
helped but it may be because I don't know how to correctly phrase the
question, but here goes. Is there a way to have an expanded view into a
repository's projects on NFS such that a user can explore it in a shell
in a read-only fashion? What I mean is if I have a repository like:

file:///repos/myproj/stuff/foo.c
I'd have on disk
/svn_explore/repos/myproj/stuff/foo.c
As a set of directories / files that I could look at that are always
'head' and are read-only and are kept up to date. I was thinking I could
orchestrate this with a cron, or maybe some changes to hooks but I was
wondering if there was an easy supported way or standard way in which
people do this. This would allow people to look into the 'latest' in the
repository without actually having to run any svn commands. 
 
You're looking for this:
http://www.jmadden.eu/index.php/svnfs/
Tony.

 

Thanks in advance for any help and I appreciate you reading such a
novice question. I'm very new to svn but already find it a powerful and
promising system.
-Eli
 

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1831 / Virus Database: 2092/4560 - Release Date:
10/18/11


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

RE: Apparent "svn rm" scaling problem in 1.7.x

[Tony Sweeney]

From: michael_rytt...@agilent.com [mailto:michael_rytt...@agilent.com] 
Sent: 01 November 2011 17:19
To: markp...@gmail.com
Cc: s...@elego.de; users@subversion.apache.org
Subject: RE: Apparent "svn rm" scaling problem in 1.7.x



Perhaps I wasn't clear, the second set of runs where with a local
working copy instead of an nfs mounted working copy. 

 

 

What are your NFS mount options?

 

From: Mark Phippard [mailto:markp...@gmail.com] 
Sent: Tuesday, November 01, 2011 11:18 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: s...@elego.de; users@subversion.apache.org
Subject: Re: Apparent "svn rm" scaling problem in 1.7.x

 

On Tue, Nov 1, 2011 at 1:10 PM,  wrote:

LOL!  I love the env variable.

Here is some similar data for a local working copy.  These are
all run with the env variable set.  Again, svn rm is significantly
slower than all other operations.

svn rm   0.35s
svn st 0.105s
svn blame  0.041s
svn unlock 0.056s
svn lock  0.053s
svn log   0.036s
svn info 0.014s

 

But look how much it improved compared to how much the others improved?


 

svn rm7s
svn add   0.126s
svn st   2s
svn blame  0.2s
svn lock   0.12s
svn unlock  0.103s
svn log 0.089s
svn revert   0.133s
svn info   0.074s

 

Many of these commands are not even impacted by that variable.  That
said, I do not get how this envvar can shave 7 seconds off the operation
when it usually only sleeps for a second.

 

-- 
Thanks

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


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1834 / Virus Database: 2092/4589 - Release Date:
11/01/11


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Subversion repository config problem

[Tony Butt]

Hi all,

We have recently upgraded our subversion servers from 1.6.17 to 1.7.1,
and as I usually do when making the 'semi-major' upgrade, dumped and
reloaded the repository. 

Our environment is Ubuntu 10.04.03 LTS server, apache 2.2, subversion
1.7.1 (was 1.6.17). Our clients are mixed windows and linux subversion
1.6.x.

We run multiple access methods, usually http://, but sometimes 
svn+ssh:// on the repository, so some effort is made to implement and
tune the 'multiple repository access method' as outlined in the manual.

To this end, the repository is owned by the web user, and the group is
'svn', which all users who should have svn+ssh access belong to.

In the process of doing that, I found one or two checkins  failed, as
group write permission was required to the db directory. I added that,
and at the same time checked the trees under db/revs , and db/revprops.

Here I noticed 2 things:
1) the individual revs and revprops files are now read-only, previously
they were read/write for group and owner.
2) the svn+ssh committed files were owned by the committing user (myself
in the test case)

I tried to edit the log message of a commit made with svn+ssh://, using
http:// access, and failed. Now the strange thing, after changing a
different commit message for a test (using http:// access only,
successsfully), drafting this email, and re-checking the revprops file
in question, it was now owned by www-data - the apache user.

In short, this is unexpected behaviour for me, but not exactly broken.

Tony Butt
CEA Technologies
Canberra

Re: Subversion repository config problem

[Tony Butt]

On Tue, 2011-11-08 at 15:07 +1100, Tony Butt wrote:


Hi all,

We have recently upgraded our subversion servers from 1.6.17 to 1.7.1,
and as I usually do when making the 'semi-major' upgrade, dumped and
reloaded the repository.

Our environment is Ubuntu 10.04.03 LTS server, apache 2.2, subversion
1.7.1 (was 1.6.17). Our clients are mixed windows and linux subversion
1.6.x.

We run multiple access methods, usually http://, but sometimes
svn+ssh:// on the repository, so some effort is made to implement and
tune the 'multiple repository access method' as outlined in the manual.

To this end, the repository is owned by the web user, and the group is
'svn', which all users who should have svn+ssh access belong to.

In the process of doing that, I found one or two checkins  failed, as
group write permission was required to the db directory. I added that,
and at the same time checked the trees under db/revs , and db/revprops.

Here I noticed 2 things:
1) the individual revs and revprops files are now read-only, previously
they were read/write for group and owner.
2) the svn+ssh committed files were owned by the committing user (myself
in the test case)

I tried to edit the log message of a commit made with svn+ssh://, using
http:// access, and failed. Now the strange thing, after changing a
different commit message for a test (using http:// access only,
successsfully), drafting this email, and re-checking the revprops file
in question, it was now owned by www-data - the apache user.

In short, this is unexpected behaviour for me, but not exactly broken.

Tony Butt
CEA Technologies
Canberra




I re-checked this scenario, again making a trivial change and committing using 
svn+ssh://
Tried to edit the log message using http:// access, TortoiseSVN fails, and 
reports:

DAV request failed; It's possible that the repository's pre-revprop-hook either 
failed or is non-existent.
At least one property change failed; repository is unchanged
Error setting property 'log';

There are also some post-commit-hook failures reported, relating to our trac 
integration.

When I check the revprop file for 63490, the ownership of the file has changed 
from tjb:svn to www-data:svn, and the log message has actually changed.

If I repeat this process, but use http:// access throughout, no such errors 
occur.

Tony Butt
CEA Technologies
Canberra 

Re: Subversion repository config problem

[Tony Butt]

On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote:
> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100:
> > Hi all,
> > 
> > We have recently upgraded our subversion servers from 1.6.17 to 1.7.1,
> > and as I usually do when making the 'semi-major' upgrade, dumped and
> > reloaded the repository. 
> > 
> 
> 1.6 and 1.7 use the same backend format.  dump/load gains nothing.  And
> the release notes say that...
Yes, I found that out the day after I went throught the dunp/load
process. The back end format may be the same, but the file permissions
are not, which has had a flow-on effect to our current practices.
> 
> > Here I noticed 2 things:
> > 1) the individual revs and revprops files are now read-only, previously
> > they were read/write for group and owner.
> > 2) the svn+ssh committed files were owned by the committing user (myself
> > in the test case)
> > 
> > I tried to edit the log message of a commit made with svn+ssh://, using
> > http:// access, and failed. Now the strange thing, after changing a
> > different commit message for a test (using http:// access only,
> > successsfully), drafting this email, and re-checking the revprops file
> > in question, it was now owned by www-data - the apache user.
> > 
> 
> We make rev files read only intentionally.  I don't remember offhand
> how revprop files would be affected, but in any case those are never
> changed either --- we only ever rename(2) new versions on top of old
> ones.
> 
> And, anyway, I really don't understand your bottom line.  Are you saying
> the new behaviour is non backwards compatible?  That it should be
> changed?  Or just that it's surprising?
The new behaviour is slightly different, and slightly incompatible in
our corner case. It was more surprising than anything else, and I wanted
to check that I didn't need to tweak the repository config in some way
to allow for this - possibly some subtlety with umasks that I was not
aware of.
> 
> > In short, this is unexpected behaviour for me, but not exactly broken.
> > 
> > Tony Butt
> > CEA Technologies
> > Canberra
> 
> Next time can you try to be more concise, rather than bury your question
> somewhere in the middle.  Thanks.
OK - 
Repository behaviour is slightly different to 1.6.17, as detailed
(verbosely) above.
Asking for advice as to whether this is a defect, or configuration
error.
This may bite anyone that uses multiple access methods and revprop
edits.
Humour intended too. :-)

Thanks,
Tony Butt
CEA Technologies
Canberra

Re: Subversion repository config problem

[Tony Butt]

On Wed, 2011-11-09 at 06:28 +0200, Daniel Shahaf wrote:
> On Wednesday, November 09, 2011 11:03 AM, "Tony Butt"  
> wrote:
> > On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote:
> > > Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100:
> > > > Hi all,
> > > > 
> > > > We have recently upgraded our subversion servers from 1.6.17 to 1.7.1,
> > > > and as I usually do when making the 'semi-major' upgrade, dumped and
> > > > reloaded the repository. 
> > > > 
> > > 
> > > 1.6 and 1.7 use the same backend format.  dump/load gains nothing.  And
> > > the release notes say that...
> > Yes, I found that out the day after I went throught the dunp/load
> > process. The back end format may be the same, but the file permissions
> > are not, which has had a flow-on effect to our current practices.
> > > 
> > > > Here I noticed 2 things:
> > > > 1) the individual revs and revprops files are now read-only, previously
> > > > they were read/write for group and owner.
> > > > 2) the svn+ssh committed files were owned by the committing user (myself
> > > > in the test case)
> > > > 
> > > > I tried to edit the log message of a commit made with svn+ssh://, using
> > > > http:// access, and failed. Now the strange thing, after changing a
> > > > different commit message for a test (using http:// access only,
> > > > successsfully), drafting this email, and re-checking the revprops file
> > > > in question, it was now owned by www-data - the apache user.
> > > > 
> > > 
> > > We make rev files read only intentionally.  I don't remember offhand
> > > how revprop files would be affected, but in any case those are never
> > > changed either --- we only ever rename(2) new versions on top of old
> > > ones.
> > > 
> > > And, anyway, I really don't understand your bottom line.  Are you saying
> > > the new behaviour is non backwards compatible?  That it should be
> > > changed?  Or just that it's surprising?
> > The new behaviour is slightly different, and slightly incompatible in
> > our corner case. It was more surprising than anything else, and I wanted
> > to check that I didn't need to tweak the repository config in some way
> > to allow for this - possibly some subtlety with umasks that I was not
> > aware of.
> > > 
> > > > In short, this is unexpected behaviour for me, but not exactly broken.
> > > > 
> > > > Tony Butt
> > > > CEA Technologies
> > > > Canberra
> > > 
> > > Next time can you try to be more concise, rather than bury your question
> > > somewhere in the middle.  Thanks.
> > OK - Repository behaviour is slightly different to 1.6.17, as detailed
> > (verbosely) above. Asking for advice as to whether this is a defect,
> > or configuration error. This may bite anyone that uses multiple access
> > methods and revprop edits. Humour intended too. :-)
> > 
> 
> There was a code change, by me, intending to make revision files read-only to 
> try and make it harder to corrupt them.  (This was motivated by some 
> corruption bug that Philip filed, reproduced via gdb, and then added code to 
> detect.)
> 
> Sorry for brief / lack of details, enotime this morning, I'll look again 
> later,
Thanks Daniel,
For me, this is truly a corner case. Some time ago, we struggled with
the performance of http:// access, so went to svn+ssh:// as an
alternate. Those issues are long gone, but we still have a few long
lived working copies with svn+ssh:// access, one of which triggered our
problem. The work-around, of course, is trivial, either relocate the WC
to the http:// access, or just remove it and check it out again.

We still need svn+ssh is some form, as we have an overnight build
process that uses it, otherwise I would just remove it completely.

In terms of reproducing, if you want to, you need
1) A 1.7.1 repository with http:// and svn+ssh:// access methods
configured.
2) property updates enabled - we allow log message and user name to be
updated.
3) Commit anything using http://, then edit the log message using svn
+ssh://

I used TortoiseSVN only as a client as it was convenient. I will try
testing the command line client tomorrow for my own curiosity.

Tony Butt
CEA Technologies
Canberra
> 
> > Thanks,
> > Tony Butt
> > CEA Technologies
> > Canberra
> > 
> > 

Re: Subversion repository config problem

[Tony Butt]

On Wed, 2011-11-09 at 10:00 +, Philip Martin wrote:
> "Tony Butt"  writes:
> 
> > On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote:
> >> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100:
> >> > I tried to edit the log message of a commit made with svn+ssh://, using
> >> > http:// access, and failed. Now the strange thing, after changing a
> >> > different commit message for a test (using http:// access only,
> >> > successsfully), drafting this email, and re-checking the revprops file
> >> > in question, it was now owned by www-data - the apache user.
> >> > 
> >> 
> >> We make rev files read only intentionally.  I don't remember offhand
> >> how revprop files would be affected, but in any case those are never
> >> changed either --- we only ever rename(2) new versions on top of old
> >> ones.
> >> 
> >> And, anyway, I really don't understand your bottom line.  Are you saying
> >> the new behaviour is non backwards compatible?  That it should be
> >> changed?  Or just that it's surprising?
> > The new behaviour is slightly different, and slightly incompatible in
> > our corner case. It was more surprising than anything else, and I wanted
> > to check that I didn't need to tweak the repository config in some way
> > to allow for this - possibly some subtlety with umasks that I was not
> > aware of.
> 
> The fact that the files are read-only should have no effect on
> Subversion operations.  It should be possible to use svn+ssh and http
> access simulataneously provided the repository Unix permissions are
> correct:
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.multimethod
> 
I have configured the repository permissions and wrapper script as
outlined in the aubversion 1.6 reference. I just checked, and that is
essentially unchanged in the current 17. manual. 

I also rechecked my config -
* group set to svn throughout
* group write permissions set wherever there are owner write
permissions
* setgid bit set on the relevant directories to preserve group
ownerships correctly

I tried the command line propedit this morning to set the log message,
and found some more useful information returned.

The short story is that there is NOT a subversion problem, but rather 2
problems with some of my hooks.

The first problem is that the hooks log information to files in /tmp,
which did not have the correct group set. This was causing my initial
symptoms.

The second problem is that we run trac, and (as recommended by the trac
project) use post-commit hooks to log repository changes into the trac
timeline. This fails when svn+ssh:// is used, as the process owner does
not have permission to use trac-admin in that way.

Thanks for your responses, and my apologies for the noise!

Tony Butt
CEA Technologies

RE: Subversion repository config problem

[Tony Butt]

On Thu, 2011-11-10 at 06:59 +, Cooke, Mark wrote:
> 
> > The second problem is that we run trac, and (as recommended 
> > by the trac project) use post-commit hooks to log repository
> > changes into the trac timeline. This fails when svn+ssh://
> > is used, as the process owner does not have permission to
> > use trac-admin in that way.
> 
> ...as a trac user (but being a windoze shop, not svn+ssh) I was wondering, is 
> this a fundamental trac problem or a local configuration issue?  If it is 
> trac then it should be reported to trac-users too...
Normally your svn+ssh process runs as the user who's credentials were
supplied. Trac-admin does not allow general users to do much of anything
on a linux box, not sure about windows.

I would say it was a fundamental trac problem, resulting from a
collision of 2 sets of assumptions for security. That is, svnserve will
run as a local, authenticated user for security, audit trail, etc.
trac-admin will only update the timeline (or make any other change) if
it is superuser (or somesuch).

There might be a way to configure trac-admin to allow anyone to make
those changes, but that exposes the trac installation to greater risk.

Sigh - I will just strongly suggets to our engineers that they use
http:// protocol only, most do already.

Tony
> 
> ~ mark c

RE: svn+ssh making too many requests

[Tony Sweeney]

SSH connections require some expensive computation at startup, so the
maximum number of outstanding connections allowed is much lower than for
regular socket connections to prevent denial of service attacks by
connection flooding.  This is governed by the MaxStartups value in the
/etc/ssh/sshd_config file.  If no value is set explicitly, the default
is 10.  You can experiment with setting this higher (we use it inhouse
for a parallel master-server cluster installer, so we set it to the # of
slaves in the cluster plus a little extra).  If your server isn't
Internet facing, this might be an adequate workround for you if you
don't want to swap out TortoisePlink.

Tony.

-Original Message-
From: Markus Schaber [mailto:m.scha...@3s-software.com] 
Sent: 21 November 2011 11:06
To: Ingmar Heinrich
Cc: users@subversion.apache.org
Subject: AW: svn+ssh making too many requests

Hi, Ingmar,

Von: Ingmar Heinrich [mailto:ingmar.heinr...@gmail.com] 

> when using svn+ssh, TortoisePlink seems to open a new connection for
every atomic action. The remote sshd would lock me out due to excessive
conections. Is there any way to circumvent that?

Some SSH implementations support connection multiplexing:
http://en.wikipedia.org/wiki/Comparison_of_SSH_clients

Install one of those and reconfigure your TortoiseSVN to use that ssh
client instead of the default TortoisePlink (which is based on putty).

Best regards

Markus Schaber
--
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys
sample projects: http://www.3s-software.com/index.shtml?sample_projects

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 


__
This email has been scanned by the Symantec Email Security.cloud
service.
For more information please visit http://www.symanteccloud.com
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4629 - Release Date:
11/20/11

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Perforce to subversion migration

[Tony Sweeney]

If you start Perforce without a license file you are restricted in the number 
of users/clients allowed, but it is still possible to use a suitable repository 
(or copy thereof).  The "free" limit used to be 2 users/5 clients, but I see 
the latest release (2011.1) allows 20 users/20 clients without a license (or 
unlimited users, but only 1000 files in the depot).  The problem is that the 
free server won't start if these limits are breached.  You used to be able to 
fix the user count by simply truncating db.user, but the client information is 
spread across several tables.  If your existing installation is still working 
and can be trimmed down to 20 users/clients, then that might be a viable route. 
 Also worth checking is whether your license file is in fact invalid with a 
newer version.  Most Perforce licenses lock the expiry date, not the version 
(although I believe their licensing mechanism does allow for that as well).

Tony.


From: Nrupen Kantamneni [mailto:n...@cypress.com]
Sent: 19 January 2012 08:41
To: 'users@subversion.apache.org'
Subject: Perforce to subversion migration

All,
I was trying to migrate a perforce database to SVN using p42svn.pl (0.21 
version) script. This requires the perforce to be 2006 or later. However my 
perforce version is 2005.2. Is there a way I can migrate the database from 
perforce to  svn retaining the version history ? Upgrading perforce is ruled 
out as we do not have any support .

Thanks,
Nrupen




This message and any attachments may contain Cypress (or its subsidiaries) 
confidential information. If it has been received in error, please advise the 
sender and immediately delete this message.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1901 / Virus Database: 2109/4751 - Release Date: 01/18/12

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Errors with mtime-retaining import script: pre-revprop-change issue?

[Tony Sweeney]

Alex,

the '.tmpl' scripts in the hooks directory are there for reference purposes 
only.  If you want the script to be executed, it needs to be named 
'pre-revprop-change' with no extension, and have execute permission.

Tony.


From: Alexander Shenkin [mailto:subvers...@shenkin.org]
Sent: 25 January 2012 15:10
To: users@subversion.apache.org
Subject: Errors with mtime-retaining import script: pre-revprop-change issue?

Hello,

I'm using the svn import script by Oliver Betz to retain file mtime upon 
initial import (http://svn.haxx.se/users/archive-2006-10/1345.shtml), but i'm 
getting some errors.  I'm hoping someone might be able to help me out.

when i run the script, i get the following error:
$ perl importWithMtime.pl
svn propset svn:date 2001-10-29T18:34:10.00Z --revprop -r HEAD
svn: E175002: DAV request failed; it's possible that the repository's 
pre-revprop-change hook either failed or is non-existent
svn: E175008: At least one property change failed; repository is unchanged
svn: E175002: Error setting property 'date':
Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook
I do have a pre-revprop-change.tmpl hook in the repository.  It contains the 
code below.  I'm using VisualSVN 2.5.2 on a Windows 7 x64 machine with Cygwin 
Perl and TortoiseSVN.  Any help would be greatly appreciated!

Thanks,
Alex


---

$ cat pre-revprop-change.tmpl
#!/bin/sh

# PRE-REVPROP-CHANGE HOOK
#
# The pre-revprop-change hook is invoked before a revision property
# is added, modified or deleted.  Subversion runs this hook by invoking
# a program (script, executable, binary, etc.) named 'pre-revprop-change'
# (for which this file is a template), with the following ordered
# arguments:
#
#   [1] REPOS-PATH   (the path to this repository)
#   [2] REV  (the revision being tweaked)
#   [3] USER (the username of the person tweaking the property)
#   [4] PROPNAME (the property being set on the revision)
#   [5] ACTION   (the property is being 'A'dded, 'M'odified, or 'D'eleted)
#
#   [STDIN] PROPVAL  ** the new property value is passed via STDIN.
#
# If the hook program exits with success, the propchange happens; but
# if it exits with failure (non-zero), the propchange doesn't happen.
# The hook program can use the 'svnlook' utility to examine the
# existing value of the revision property.
#
# WARNING: unlike other hooks, this hook MUST exist for revision
# properties to be changed.  If the hook does not exist, Subversion
# will behave as if the hook were present, but failed.  The reason
# for this is that revision properties are UNVERSIONED, meaning that
# a successful propchange is destructive;  the old value is gone
# forever.  We recommend the hook back up the old value somewhere.
#
# On a Unix system, the normal procedure is to have 'pre-revprop-change'
# invoke other programs to do the real work, though it may do the
# work itself too.
#
# Note that 'pre-revprop-change' must be executable by the user(s) who will
# invoke it (typically the user httpd runs as), and that user must
# have filesystem-level permission to access the repository.
#
# On a Windows system, you should name the hook program
# 'pre-revprop-change.bat' or 'pre-revprop-change.exe',
# but the basic idea is the same.
#
# The hook program typically does not inherit the environment of
# its parent process.  For example, a common problem is for the
# PATH environment variable to not be set to its usual value, so
# that subprograms fail to launch unless invoked via absolute path.
# If you're having unexpected problems with a hook program, the
# culprit may be unusual (or missing) environment variables.
#
# Here is an example hook script, for a Unix /bin/sh interpreter.
# For more examples and pre-written hooks, see those in
# the Subversion repository at
# http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and
# http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/


REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi

echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1901 / Virus Database: 2109/4764 - Release Date: 01/24/12

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Can relocate from a svnserve based server that was 'svn sync' to a new http based server

[Tony Sweeney]

From: Brent Webster [mailto:bwebs...@belairnetworks.com]
Sent: 31 January 2012 03:08
To: users@subversion.apache.org
Cc: Brent Webster
Subject: Can relocate from a svnserve based server that was 'svn sync' to a new 
http based server

I have numerous large svn repositories accessible by svnserve on an older linux 
server that I'm moving to a new VMWare VM server using http authentication.  
I'm using svnsync to transfer the older "svn://" repositories to the new 
"http://"; repositories.  The problem that I'm having is trying to "relocate" 
the existing checked out "svn://" based working copy and point it to the new 
"http://"; repository.  An example existing WC:
svn@svna: svn info
Path: .
Working Copy Root Path: /home/svn/bin
URL: svn://svnrepo/BelAir/admin/main/svnserver/bin
Repository Root: svn://svnrepo/BelAir/admin
Repository UUID: ad8b7147-7818-0410-a3fb-ed15fa4e4e0d
Revision: 256
Node Kind: directory
Schedule: normal
Last Changed Author: bwebster
Last Changed Rev: 256
Last Changed Date: 2012-01-30 16:38:51 -0500 (Mon, 30 Jan 2012)

I've tried numerous command syntax combinations like
svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin 
svn://svnrepo/BelAir/admin/main/svnserver/bin
svn relocate svn://svnrepo/BelAir/admin/main/svnserver/bin 
http://svnrepo2:18080/svn/admin/main/svnserver/bin
svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin .

This is the type of error message:
svn@svna: svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin .
svn: E195009: The repository at 
'http://svnrepo2:18080/svn/admin/main/svnserver/bin' has uuid 
'65d03f8f-4f6b-4b7c-8505-7ddab04e9aed', but the WC has 
'ad8b7147-7818-0410-a3fb-ed15fa4e4e0d'

What am I doing wrong (i.e. hopefully I'm doing something wrong).

For this to work, both the old and new repositories must have the same UUID. 
You should change the UUID of the new repository to match the old one. You can 
do this using the svnadmin command on the server hosting the new repository:

[sweeney@luke ~]$ svnadmin --help setuuid
setuuid: usage: svnadmin setuuid REPOS_PATH [NEW_UUID]
Reset the repository UUID for the repository located at REPOS_PATH. If
NEW_UUID is provided, use that as the new repository UUID; otherwise,
generate a brand new UUID for the repository.
[sweeney@luke ~]$

Once this is done, one of your relocate commands should work as you intend.

Tony.




Thanks Brent




This email, including any attachments, may contain confidential information, 
privileged material (including material protected by solicitor-client and/or 
other applicable privileges) or constitute non-public information under 
securities law(s). Any exploitation of the information contained in this email 
(including any attachments) by anyone other than the intended recipient is 
prohibited. If you have received this email in error, please reply to the 
sender and delete this information from your system as soon as reasonably 
practicable. Use, dissemination, distribution, reproduction, publication or any 
other exploitation of this email by unintended recipients is not authorized and 
may be unlawful.


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1901 / Virus Database: 2109/4776 - Release Date: 01/30/12

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Subversion exception while merging

[Nancarrow, Tony]

I was merging revisions in a branch back to the trunk (which also had local 
revisions). (Tortoise SVN merge type = "Merge a range of revisions").
I had 2 conflicting files which I manually merged (using Araxis Merge) to 
resolve the conflicts (and marked them as "resolved").
The error occurred at the end of the merge process.

The whole merge process appears to have been successful with new files having 
been added and conflicts resolved.

Using Tortoise SVN 1.7.4, Subversion client 1.7.2, Subversion server 1.6.11.

---
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.4\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 4131: assertion failed (presence == svn_wc__db_status_normal)
---
OK
---

Regards,

Tony Nancarrow

Tony Nancarrow
Senior Software Engineer
Cobham Tactical Communications and Surveillance
T: +44 (0)1252 848315
F: +44 (0)1252 848301
M: +44 (0)7909 732264
tony.nancar...@cobham.com<mailto:tony.nancar...@cobham.com>

Registered Number: 03118074   VAT Number: GB 719 0658 22
Registered Office: Brook Road, Wimborne, Dorset, BH21 2BJ, England

Please consider the environment before printing this email.

This e-mail and any files transmitted with it ("E-mail") is intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the addressee(s), any disclosure, reproduction, 
copying, distribution or other use of the E-mail is prohibited. If you have 
received this E-mail in error, please delete it and notify the sender 
immediately via our switchboard or return e-mail.

Neither the company nor any subsidiary or affiliate or associated company nor 
any individual sending this E-mail accepts any liability in respect of the 
content (including errors and omissions) nor shall this e-mail be deemed to 
enter the company or any subsidiary or affiliate or associated company into a 
contract or to create any legally binding obligations unless expressly agreed 
to in writing under separate cover and timeliness of the E-mail which arise as 
a result of transmission. If verification is required, please request a hard 
copy version from the sender.



This E-mail and any files transmitted with it ("E-mail") is intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the addressee(s), any disclosure, reproduction, 
copying, distribution or other use of the E-mail is prohibited. If you have 
received this E-mail in error, please delete it and notify the sender 
immediately via our switchboard or return e-mail.
 
Neither the company nor any subsidiary or affiliate or associated company nor 
any individual sending this E-mail accepts any liability in respect of the 
content (including errors and omissions) nor shall this e-mail be deemed to 
enter the company or any subsidiary or affiliate or associated company into a 
contract or to create any legally binding obligations unless expressly agreed 
to in writing under separate cover and timeliness of the E-mail which arise as 
a result of transmission. If verification is required, please request a hard 
copy version from the sender.

svnsync fails on a 'pull' operation

[Tony Butt]

We synchronise our production repository to a backup server, using a 
push model from post-commit and post-revprop hooks, and also a pull 
model (from the backup server) to a different synchronised copy as an 
hourly cron job.
We also make a nightly hotcopy of the repository which is backed up to 
tape. The proverbial 'belt, braces, and a piece of string' backup approach.


This has run quite well for us for some years, through various 1.6.x 
releases of subversion, and then 1.7.x releases.
I was recently away for a few weeks, and returned to find the pull sync 
was failing, not able to lock the repository. I suspected some transient 
problem, likely a network glitch, had corrupted the target. We were 
running subversion 1.7.5 on both the source and target repositories.


I re-created the target repository, re-initialised the synchronisation, 
and tried again. After 91 revisions copied, the svnsync command aborted. 
I thought, maybe something about that revision? So I recreated the 
repository, checked the permissions, and started again. After some 4 
revisions, the svnsync command aborted again.


I have since updated the target server to subversion 1.7.6, svnsync 
still crashes, always at a different point.
I have just updated the source server to subversion 1.7.6, I have not 
had the chance to try svnsync again, but I am not hopeful.


So, currently, we have
Production server, svnsync source repository, Ubuntu 10.04 with a hand 
built subversion 1.7.6
Backup server, svnsync target repository, Ubuntu 12.04 with a hand built 
subversion 1.7.6


The repository has around 77000 revisions currently.

The push svnsync still works correctly, but I am not sure if this is chance.

Unfortunately our mail gateway has a history of blocking some mails from 
this list, so I will try to follow up via web archives. Replies cc'd to 
me should also make it through (I hope).


Tony Butt
CEA Technologies
Canberra, Australia.

Re: svnsync fails on a 'pull' operation

[Tony Butt]

On Tue, 2012-08-21 at 12:08 +0100, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Tue, Aug 21, 2012 at 12:01:28 +0100:
> > You copy and paste the error message into the email for us.
> 
> I meant to say: "You forgot to copy"

OK - here is the failure with 1.7.6 server as source and destination,
which I ran last night. I didn't past it, as there is not much to see,
but that is sometimes an indication itself - sorry.

Copied properties for revision 1.
Committed revision 1.
...
Copied properties for revision 10612.
Committed revision 10613.
Copied properties for revision 10613.
Segmentation fault (core dumped)


The apache log at the source end shows this:
...
[21/Aug/2012:19:29:04 +1000] tjb rev-proplist r10612
[21/Aug/2012:19:29:05 +1000] tjb replay / r10612
[21/Aug/2012:19:29:05 +1000] tjb rev-proplist r10613
[21/Aug/2012:19:29:05 +1000] tjb replay / r10613
[21/Aug/2012:19:29:06 +1000] tjb rev-proplist r10614
[21/Aug/2012:19:29:06 +1000] tjb replay / r10614

And then nothing.

From previous events, this occurs with (apparently) random revisions,
never the same revision at the failure point.


-- 
Tony Butt 
CEA Technologies

Re: svnsync fails on a 'pull' operation

[Tony Butt]

On Tue, 2012-08-21 at 12:08 +0100, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Tue, Aug 21, 2012 at 12:01:28 +0100:
> > You copy and paste the error message into the email for us.
> 
> I meant to say: "You forgot to copy"
I found the correct ulimit setting to enable core dumps, and was able to
use that to obtain a stack trace - see attached.

According to gdb, the failing function call is this memcmp(), called
from svn_dirent_skip_ancestor().

1440  if (0 != memcmp(parent_dirent, child_dirent, len))
1441return NULL; /* parent_dirent is no ancestor of child_dirent */

The string arguments are evident from the stack trace.
parent_dirent=0xb47faeb0 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj"
child_dirent=0xb468ef80 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI"
len == 147

Strangely enough, parent and child seem to back back to front. I am
assuming the memcmp is running off the end of child_dirent, and causing
my failure.
This was built with gcc 4.6.3-1ubuntu5, using '-O2 -g'

I will try setting a breakpoint here, and looking for a consistent
pattern.

-- 
Tony Butt 
CEA Technologies
(gdb) bt
#0  0xb75f08fe in ?? () from /lib/i386-linux-gnu/libc.so.6
#1  0xb76d98f2 in svn_dirent_skip_ancestor (
parent_dirent=0xb47faeb0 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj",
 
child_dirent=0xb468ef80 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI")
 at subversion/libsvn_subr/dirent_uri.c:1440
#2  0xb76d9a83 in svn_dirent_is_ancestor (
parent_dirent=0xb47faeb0 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj",
 
child_dirent=0xb468ef80 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI")
 at subversion/libsvn_subr/dirent_uri.c:1546
#3  0xb723b7b4 in find_descendents_in_cache (baton=0xbf831610, key=0xb468ef80, 
klen=123, val=0xb451fba0, pool=0xb47d9018)
at subversion/libsvn_fs_fs/tree.c:231
#4  0xb76cd152 in iter_cb (baton=0xbf8315a8, key=0xb468ef80, klen=123, 
val=0xb468ef68, pool=0xb47d9018)
at subversion/libsvn_subr/cache-inprocess.c:443
#5  0xb76e5956 in hash_do_callback (baton=0xbf831560, key=0xb468ef80, klen=123, 
value=0xb468ef68)
at subversion/libsvn_subr/iter.c:58
#6  0xb767c6c3 in apr_hash_do () from /usr/lib/libapr-1.so.0
#7  0xb76e59d4 in svn_iter_apr_hash (completed=0x0, hash=0xb4630478, 
func=0xb76cd120 , baton=0xbf8315a8, 
pool=0xb47e9018) at subversion/libsvn_subr/iter.c:79
#8  0xb76cd445 in inprocess_cache_iter (completed=0x0, cache_void=0xb4630420, 
user_cb=0xb723b780 , 
user_baton=0xbf831610, scratch_pool=0xb47e9018) at 
subversion/libsvn_subr/cache-inprocess.c:459
#9  0xb76d0722 in svn_cache__iter (completed=0x0, cache=0xb46303f0, 
user_cb=0xb723b780 , 
user_baton=0xbf831610, scratch_pool=0xb47e9018) at 
subversion/libsvn_subr/cache.c:117
#10 0xb7223ae8 in dag_node_cache_invalidate (root=0xb46303a8, path=, pool=0xb4517018)
at subversion/libsvn_fs_fs/tree.c:257
#11 0xb723ef4c in fs_delete_node (root=0xb46303a8, 
path=0xb483a1d0 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj",
 pool=0xb4517018) at subversion/libsvn_fs_fs/tree.c:1899
#12 0xb72d8630 in svn_fs_delete (root=0xb46303a8, 
path=0xb483a1d0 
"/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj",
 pool=0xb4517018) at subversion/libsvn_fs/fs-loader.c:1033
#13 0xb72e5c96 in delete_entry (
path=0x8ad9a80 
"auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj",
 revision=-1, parent_baton=0xb45249d8, pool=0xb4517018)
at subversion/libsvn_repos/commit.c:410
#14 0x0804d33c in delete_entry (
path=0x8ad9a80 
"auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/W---Type
  to continue, or q  to quit---
in32-x86-MULTI/DevelopmentShared.gpj", base_revision=-1, 
parent_baton=0xb4517060, pool=0xb4517018)
at subversion/svnsync/sync.c:215
#15 0xb7721f03 in delete_entry (
path=0x8ad9a80 
"auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj",
 base_revision=-1, parent

Re: svnsync fails on a 'pull' operation

[Tony Butt]

On Thu, 2012-08-23 at 10:28 +1000, Tony Butt wrote:
> On Tue, 2012-08-21 at 12:08 +0100, Daniel Shahaf wrote:
> > Daniel Shahaf wrote on Tue, Aug 21, 2012 at 12:01:28 +0100:
> > > You copy and paste the error message into the email for us.
> > 
> > I meant to say: "You forgot to copy"
> I found the correct ulimit setting to enable core dumps, and was able to
> use that to obtain a stack trace - see attached.
> 
> According to gdb, the failing function call is this memcmp(), called
> from svn_dirent_skip_ancestor().
> 
> 1440if (0 != memcmp(parent_dirent, child_dirent, len))
> 1441  return NULL; /* parent_dirent is no ancestor of child_dirent */
> 
> The string arguments are evident from the stack trace.
> parent_dirent=0xb47faeb0 
> "/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI/DevelopmentShared.gpj"
> child_dirent=0xb468ef80 
> "/auspar/trunk/Modules/VirtualShip/Trunk/RadarGeometry/RadarGeometryManager/Trunk/Test/TestApplication/Build/Win32-x86-MULTI"
> len == 147
> 
> Strangely enough, parent and child seem to back back to front. I am
> assuming the memcmp is running off the end of child_dirent, and causing
> my failure.
> This was built with gcc 4.6.3-1ubuntu5, using '-O2 -g'
> 
> I will try setting a breakpoint here, and looking for a consistent
> pattern.
> 
OK, I set the breakpoint, and ran it.
In all cases, either the parent_dirent is identical to child_dirent, or
the parent_dirent is longer than the child_dirent !
I expect that the memcmp fails based on the vagaries of dynamic memory
allocation, and how much usable space is left at the end of the shorter
string.
I still don't know if this is unique to my build, or a broader problem.

-- 
Tony Butt 
CEA Technologies

RE: problem with dialog box uisng Tortoisesvn

[Tony Sweeney]

From: Carmit Shiran [mailto:carmit.shi...@gmail.com]
Sent: 12 September 2012 08:14
To: Ryan Schmidt
Cc: Cooke, Mark; users@subversion.apache.org
Subject: Re: problem with dialog box uisng Tortoisesvn

thanks for your help.
Seems like I didn't have the whole svn package.
I reinstalled the svn and made sure I pick the "command tool" and now the svn 
commands work for me.

Though I have a problem with the tag command:

I wrote a script in perl:
my $target_path = "file:///C:/svn_repos3/trunk/Widget3"
my $tag = "file:///C:/svn_repos3/tags/Release_63"

system ("svn copy -m \"tagging the file\" \"$target_path\" \"$tag\" ");

and got the following error:

svn: E160005: Invalid control character '0X0a' in path 'Release_63\012'

Does anyone know what this error is?

That's just a line feed at the end of one of your variable strings.  Use chomp 
to get rid of it and you should be golden.

Tony.

thanks!!



On Wed, Sep 5, 2012 at 1:21 PM, Ryan Schmidt 
mailto:subversion-20...@ryandesign.com>> wrote:

On Sep 5, 2012, at 04:14, Carmit Shiran wrote:

> c:\Program files\TortoiseSVN\bin> $svn commit
>
> I got the following message:
> '$svn' is not recognized as an internal or external command, operable program 
> or batch file.

You're not supposed to type "$". We just use "$" to indicate "type the things 
after this". It's a fairly common character for a command prompt. This same 
convention is used by the SVN Book [1], which is a good document to read to get 
familiar with how to use Subversion.


[1] http://svnbook.org/







__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.2221 / Virus Database: 2437/5262 - Release Date: 09/11/12

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Making same source available in 2 areas of the repository

[Tony Martin]

Hi

I have an application that is made up of a windows executable and  
several dll's. One of these dll's needs to be worked on directly to  
develop and bug fix, however it must also be deployed as source to  
allow changes and recompiles when the application suite is deployed to  
production. (Probably poorly explained - sorry)


To highlight what I mean here is the folder structure (Windows) of the  
installed application on a production machine :


\
|
|--- Program.exe
|
|--- winDll_1.dll
|
|--- winDll_2.dll
|
|--- winDll_3.dll
|
|--- 
|
|--- {Src files, make files etc for 
winDll_1}

What I want in Subversion is the following :

Root
|
|--- Program
|   |
|   |--- Branches
|   |--- Tags
|   |--- Trunk
|   |--- Src for Program.exe
|   |
	|			|--- Folder for src of winDll_1 (Versioned to match  
Program.exe version))

|--- winDll_1
|   |
|   |--- Branches
|   |--- Tags
|   |--- Trunk
|   |--- winDll_1
/
...
/
|--- winDll_3
|
|--- Branches
|--- Tags
|--- Trunk
|--- Src for winDll_3

Can I have :
	- Subversion maintained relationship between Program version and  
winDll_1 version
	- A 'symbolic' link from Program version to appropriate winDll_1  
version to force winDll_1 export/checkout whenever Program is checked  
out etc


Hope this makes sense. If needs be it can be done manually outside  
Subversion but not my preference.


Thanks in advance.

Tony

Re: svn:eol-style does not work on update

[Tony Butt]

On Tue, 2010-03-30 at 16:05 +0200, Dirk wrote:
> Hello,
> 
> i've enabled
> 
> enable-auto-props=yes
> 
> and
> 
> *.php=svn:eol-style:native
> 
> on linux...
> 
> but when i "svn update" i still have msdos linefeeds in the php file... even 
> when i delete the php file before updating..
> 
> i am using only the client... no idea where or what the server is...
> 
> 
> 
> Dirk

There is a svn_apply_autoprops as part of the subversion distribution
(in contrib, I think), which will apply your current auto props to a
working copy.

My current copy of that script is attached - needs python.

I use it a lot, and it works well for me.
Tony Butt
CEA Technologies
-- 
Tony Butt 
#!/usr/bin/python

# This script reads the auto-properties defined in the
# $HOME/.subversion/config file and applies them recursively to all
# the files and directories in the current working copy.  It may
# behave differently than the Subversion command line; where the
# subversion command line may only apply a single matching
# auto-property to a single pathname, this script will apply all
# matching lines to a single pathname.
#
# To do:
# 1) Switch to using the Subversion Python bindings.
# 2) Allow a command line option to specify the configuration file to
#load the auto-properties from.
#
# $HeadURL: http://svn.collab.net/repos/svn/branches/1.6.x/contrib/client-side/svn_apply_autoprops.py $
# $LastChangedRevision: 20787 $
# $LastChangedDate: 2006-07-20 03:41:28 + (Thu, 20 Jul 2006) $
# $LastChangedBy: blair $
#
# Copyright (C) 2005,2006 Blair Zajac 
#
# This script is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This script is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# A copy of the GNU General Public License can be obtained by writing
# to the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
# Boston, MA 02111-1307 USA.

import fnmatch
import os
import re
import sys

# The path to the Subversion configuration file.
SVN_CONFIG_FILENAME = '$HOME/.subversion/config'

# The name of Subversion's private directory in working copies.
SVN_WC_ADM_DIR_NAME = '.svn'

def get_autoprop_lines(fd):
  lines = []
  reading_autoprops = 0

  re_start_autoprops = re.compile('^\s*\[auto-props\]\s*')
  re_end_autoprops = re.compile('^\s*\[\w+\]\s*')

  for line in fd.xreadlines():
if reading_autoprops:
  if re_end_autoprops.match(line):
reading_autoprops = 0
continue
else:
  if re_start_autoprops.match(line):
reading_autoprops = 1
continue

if reading_autoprops:
  lines += [line]

  return lines

def process_autoprop_lines(lines):
  result = []

  for line in lines:
# Split the line on the = separating the fnmatch string from the
# properties.
try:
  (fnmatch, props) = line.split('=', 1)
except ValueError:
  continue

# Remove leading and trailing whitespace from the fnmatch and
# properties.
fnmatch = fnmatch.strip()
props = props.strip()

# Create a list of property name and property values.  Remove all
# leading and trailing whitespce from the propery names and
# values.
props_list = []
for prop in props.split(';'):
  prop = prop.strip()
  if not len(prop):
continue
  try:
(prop_name, prop_value) = prop.split('=', 1)
prop_name = prop_name.strip()
prop_value = prop_value.strip()
  except ValueError:
prop_name = prop
prop_value = '*'
  if len(prop_name):
props_list += [(prop_name, prop_value)]

result += [(fnmatch, props_list)]

  return result

def filter_walk(autoprop_lines, dirname, filenames):
  # Do no descend into directories that do not have a .svn directory.
  try:
filenames.remove(SVN_WC_ADM_DIR_NAME)
  except ValueError:
filenames = []
print "Will not process files in '%s' because it does not have a '%s' " \
  "directory." \
  % (dirname, SVN_WC_ADM_DIR_NAME)
return

  filenames.sort()

  # Find those filenames that match each fnmatch.
  for autoprops_line in autoprop_lines:
fnmatch_str = autoprops_line[0]
prop_list = autoprops_line[1]

matching_filenames = fnmatch.filter(filenames, fnmatch_str)
if not matching_filenames:
  continue

for prop in prop_list:
  command = ['svn', 'propset', prop[0], prop[1]]
  for f in matching_filenames:
command += ["%s/%s"

RE: Applying multiple commits done to a branch to another branch

[Tony Sweeney]

 svn merge [source svn location] -c 444,469,480

> -Original Message-
> From: emerson [mailto:echofloripa.y...@gmail.com] 
> Sent: 05 July 2010 17:38
> To: Andy Levy; users@subversion.apache.org
> Subject: Re: Applying multiple commits done to a branch to 
> another branch
> 
> Hi
> 
> I was told that I could use the following syntax to merge 
> different revisions at once:
> 
> svn merge [source svn location] -c 444 -c 469 -c 480
> 
> However, when I tried using this syntax I found out that all 
> merges are done against the initial state of the current 
> folder which resulted in conflicts, as in some cases the 
> differents commits were related to the same bit of code.
> 
> Is there anyway to have in one command line a behaviour that 
> would take in account the previous revisions?
> 
> thanks
> Emerson
> 
> On 17 June 2010 14:53, emerson  wrote:
> > On 17 June 2010 13:29, Andy Levy  wrote:
> >> On Thu, Jun 17, 2010 at 05:38, emerson 
>  wrote:
> >>> Hi Guys
> >>>
> >>> Thanks for the answers.
> >>> First Andy, yes, we put more than the story code on the 
> commits :) 
> >>> We are using svn 1.4.4 ont he server, so to be able to 
> keep track of 
> >>> the ancestors logs we will probably need to upgrade.
> >>
> >> Note that the 1.4 series has not been supported for quite 
> some time, 
> >> and when 1.7 is released, 1.5 support will be dropped. You 
> definitely 
> >> ought to upgrade.
> >>
> >
> > We are going to move to the latest stable 1.6.11.
> >
> >>> Still, I believe we need some tool to search the logs for that 
> >>> especific # code of the story.
> >>> Correct me if I am wrong, but from there I would have to 
> collect all 
> >>> the revision numbers, and apply them in a single merge 
> manually? Is 
> >>> there any way to automate this?
> >>
> >> If each story gets its own branch, then you don't have to 
> worry about that.
> >
> > We might in the future go for a bigger isolation level like 
> this, but 
> > at this point we will work with two different branches, a unstable 
> > (which would be our current trunk) and a stable, which will get 
> > promoted a story at a time.
> >
> > We needed something like this:
> >
> > Ex: searchsvnapp http://[repo location root] #s1322
> >
> > result:
> > revisions: 4233,4249,4313
> >
> > This would then be copied and pasted in a merge command that would 
> > allow to apply all the revisions at once.
> >
> > I know that tortoise can do that, how can that be done on 
> the command 
> > line? Or through some API maybe?
> >
> > BTW, Is there any way to use the merge command to apply several 
> > revisions at once?
> >
> > Thanks
> > Emerson
> >
> >>> On 16 June 2010 22:40, Daniel Becroft 
>  wrote:
>  On Thu, Jun 17, 2010 at 4:20 AM, Bob Archer 
>  wrote:
> >
> >> You're describing a normal usage of merging.
> >> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
> >>
> >> You don't want to redo all those commit messages, you want the 
> >> merge to be aware of the history behind everything that's been 
> >> done (which, if you're using 1.5 or later, is taken 
> care of), so 
> >> that svn log can trace back & all those messages fall 
> right in line.
> >
> > Really... I didn't know this happened. If you look at 
> the log of trunk where you have merged in from branch won't 
> it only show the merge as a single rev with the message you 
> made in the merge commit. How will you be able to trace the 
> log back through the changes made in branch?
> 
>  It does, but not by default. You need to use the 
>  '-g/--use-merge-history' switch.
> 
>  
> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.htm
>  l#svn.branchmerge.advanced.logblame
> 
>  Cheers,
>  Daniel B.
> 
> >>>
> >>
> >
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: SVN "Relay"

[Tony Sweeney]

Actually, I think he's looking at something more along the lines of
Perforce's P4Proxy server, but for Subversion. 

http://www.perforce.com/perforce/doc.current/manuals/p4sag/09_p4p.html  

Svnsync doesn't help in the event that someone not on his LAN
independently commits to the Subversion server on the WAN, as you'd need
to be able to sync bidirectionally, and I'm not even sure that's
possible.

Tony.

> -Original Message-
> From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
> Sent: 02 August 2010 10:42
> To: Istace Emmanuel
> Cc: users@subversion.apache.org
> Subject: Re: SVN "Relay"
> 
> 
> On Aug 2, 2010, at 04:38, Istace Emmanuel wrote:
> 
> > Hi, first of all, sorry for my bad english, i'm belgium and 
> i'll try to do my best.
> > I have a little problem. I've got a SVN server hosted in 
> WAN. In LAN i've got many user who use this service, but, 
> it's really < chatty >. I want to make a SVN Relay into the 
> LAN. This svn server will sync to the WAN server twice per 
> day and my user will connect to the LAN server and not the 
> WAN server. How can i do that ? Is a sync between two svn 
> server possible ?
> 
> Yes, "svnsync" is the software you are looking for. You can 
> read all about it in the book:
> 
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.ht
> ml#svn.reposadmin.maint.replication
> 
> You will probably want to sync constantly, not just twice a day.
> 
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: Reconstruct repository from checkouts?

[Tony Sweeney]

Short answer: no. 

> -Original Message-
> From: a.sk...@gmail.com [mailto:a.sk...@gmail.com] On Behalf 
> Of Alexander Skwar
> Sent: 03 August 2010 07:59
> To: users@subversion.apache.org
> Subject: Reconstruct repository from checkouts?
> 
> Hello!
> 
> I'm curious: Is it somehow possible, to "reconstruct" a 
> Subversion repository, if all you have is a checked out 
> directory? I mean, does such a check out hold enough 
> information reg. who did what and when in the past? Does it 
> also hold information about what (ie. diffs) has changed?
> 
> Best regards,
> 
> Alexander
> --
> ↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/  
>    ↯ ↯ Chat (Jabber/Google Talk) ↣ a.sk...@gmail.com , AIM: 
> alexws77  ↯
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: corrupt revision, "Reading one svndiff window read beyond the end of the representation"

[Tony Sweeney]

 
I don't recall exactly where I found this file (author's own site, I
think), but this works for me on CentOS 5.3; If the attachment doesn't
come through, ask and I'll email directly.  Ah, here's where I got it:

http://www.szakmeister.net/fsfsverify/

Download link is at the bottom.

Tony.

> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com] 
> Sent: 03 August 2010 01:24
> To: Mark Phippard
> Cc: users@subversion.apache.org
> Subject: RE: corrupt revision, "Reading one svndiff window 
> read beyond the end of the representation"
> 
> It doesn't come with the CollabNet precompiled binaries (even 
> the -extras package) so I grabbed a copy from 
> http://svn.apache.org/viewvc/subversion/trunk/contrib/server-s
> ide/fsfsverify.py?view=log. I'm on a RH4.6 with python 2.4.4. 
> With no options it exits with
> 
> Traceback (most recent call last):
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 1120, in ?
> for noderev in strategy:
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 839, in _nodeWalker
> for x in self._nodeWalker():
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 832, in _nodeWalker
> noderev = NodeRev(self.f, self.currentRev)
>   File "/opt/CollabNet_Subversion/sbin/fsfsverify.py", line 
> 678, in __init__
> (rev, offset, length, size, digest) = value.split(' ')
> ValueError: too many values to unpack
> [svnad...@hourdcm1 ~]$
> 
> 
> From: Mark Phippard [markp...@gmail.com]
> Sent: Monday, August 02, 2010 5:47 PM
> To: Justin Georgeson
> Cc: users@subversion.apache.org
> Subject: Re: corrupt revision, "Reading one svndiff window 
> read beyond the end of the representation"
> 
> Have you tried fsfsverify.py?
> 
> Sent from my iPhone
> 
> On Aug 2, 2010, at 6:39 PM, Justin Georgeson 
> mailto:jgeorge...@lgc.com>> wrote:
> 
> I have a repo with >39k revisions. Last week, r39245 was 
> committed, a merge of a single file from trunk to branch. It 
> is the HEAD revision of that file on that branch. Turns out 
> this revision is corrupt
> 
> [svnad...@hourdcm3 ~]$ svnadmin verify -r 39245 /repos/prowess
> svnadmin: Reading one svndiff window read beyond the end of 
> the representation
> 
> I've searched from r3 to HEAD in this repo and that's the 
> only rev that fails the verify. All our backup copies have 
> the same issue too. I'm wondering what our options for 
> recovery are. Some suggestions we have come up with internally are:
> 
> 1. Developer still has sandbox which reports the parent 
> folder as updated, so have him 'svn cat' the previous version 
> and commit that, then re-commit the changes from the corrupt 
> revision 2. 'svn rm' the file from the server and re-add it 
> (losing ancestry) 3. Some combination of svndump up to that 
> revision, import to new repo, redo that merge in new repo, 
> overwrite the revision file with new one 4. delete revision 
> file (seems like bad idea) 5. svn dump up to corrupt revision 
> and everything after bad revision, merge dumps, create new 
> repo, redo merge
> 
> Is there something else we missed? Which of these seems like 
> the safest/easiest?
> 
> 
> This e-mail, including any attached files, may contain 
> confidential and privileged information for the sole use of 
> the intended recipient. Any review, use, distribution, or 
> disclosure by others is strictly prohibited. If you are not 
> the intended recipient (or authorized to receive information 
> for the intended recipient), please contact the sender by 
> reply e-mail and delete all copies of this message.
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 


fsfsverify.tar.gz
Description: fsfsverify.tar.gz

RE: svn : problems with files starting with '-'

[Tony Sweeney]

The usual UNIX "trick" would be:

svn rename ./-MediacatController.php MediacatController.php

Does this not work for you?

Tony.

> -Original Message-
> From: João Pinheiro [mailto:joao.pinhe...@pontosi.pt] 
> Sent: 13 August 2010 10:24
> To: users@subversion.apache.org
> Subject: svn : problems with files starting with '-'
> 
> Hi,
> I'm using subversion version 1.6.12 in FreeBSD and I'm having 
> some difficulties with files that start with '-':
> 
> cm% svn rename -MediacatController.php MediacatController.php
> svn: invalid option character: M
> Type 'svn help' for usage.
> 
> cm% svn rename %2DMediacatController.php MediacatController.php
> svn: '%2DMediacatController.php' is not under version control
> 
> cm% svn rename '-MediacatController.php' MediacatController.php
> svn: invalid option character: M
> Type 'svn help' for usage.
> 
> Does anyone know a quick workaround for this?
> 
> Regards,
>  João Pinheiro
> 
> 
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: Subversion encountered a serious problem - during svn update

[Tony Sweeney]

That file has DOS line endings in it.  You can fix it using 'dos2unix
verify-revisions.sh'.  The Python file may need the same treatment.

Tony.

-Original Message-
From: Patrick Fletcher [mailto:patrick.fletc...@marquisware.com] 
Sent: 07 September 2010 18:00
To: 'Stefan Sperling'
Cc: users@subversion.apache.org
Subject: RE: Subversion encountered a serious problem - during svn
update

Thanks for super fast reply Stefan (yes, 4 exclamations)

> I've attached a helper script that you can use to run fsfsverify.py
across
multiple repositories.

I'm running windows here and I can't get this to work in Cygwin (please
excuse me if I'm just being ignorant - Unix/Python deficient)

*
patri...@desk28 ~/Desktop
$ ./verify-revisions.sh G:/Subversion/Repositories/eomis
./verify-revisions.sh: line 3: $'\r': command not found
./verify-revisions.sh: line 17: $'\r': command not found
./verify-revisions.sh: line 20: $'\r': command not found
./verify-revisions.sh: line 31: syntax error near unexpected token
`elif'
'/verify-revisions.sh: line 31: `elif which jot >/dev/null 2>/dev/null

*

Googling around, I cannot find flag explanations for fsfsverify.py, and
only
really see examples about using -f flag to fix a single revision
identified
by the separate svnadmin verify (which as you know didn't report
anything
for my repo).

> Also, which version of Subversion are you running on the server?

Originally we had 1.6.3 as you saw, but in the time since the last
question
(not the one you replied to) I installed 1.6.12 on both client and
server.
Did a full dump (93309 revs), and loaded into a newly created repo. I
believe that I read this was the "recommended" way of "upgrading" and
figured it couldn't hurt anything in my situation so I did it even
though it
says no more format updates until a 2 release.

> In general, please try to reproduce problems with the latest version
of
the software, always, on both clients and servers. We get quite a few
reports for old problems which have been fixed, but people missed the
fix
because they didn't upgrade.

Duly noted. I noticed my idiocy shortly after one of my other posts.
Thanks
again

Patrick Fletcher
Marquis Software Development
Business Phone: (850) 877-8864 x132
Business Fax: (850) 877-0359


-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Tuesday, September 07, 2010 11:50 AM
To: Patrick Fletcher
Cc: users@subversion.apache.org; 'Daniel Shahaf'; 'Andy Levy'
Subject: Re: Subversion encountered a serious problem - during svn
update

On Tue, Sep 07, 2010 at 11:19:21AM -0400, Patrick Fletcher wrote:
> I would really really appreciate anyone who has any information they 
> can give me on this? I have not had any reply except for the "please 
> don't attach images", which I replied to with full text explanation 
> and apology for my ignorance (sry again!!)...

I think your problem sounds like corrupted revisions, but I'm not sure.

Please try to verify each revision of the repository with fsfsverify.py.
http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/fsf
sver
ify.py

fsfsverify.py can find corruptions that svnadmin verify doesn't report.
If fsfsverify.py finds a corrupt revision, you can try to fix the
revision
file with the -f option. But keep a backup of it before attempting to
fix.

I've attached a helper script that you can use to run fsfsverify.py
across
multiple repositories.

Also, which version of Subversion are you running on the server?
The pictures attached to your first post contain a screenshot of
Subversion
reporting itself as 1.6.3. Are you using that on your server?
If so, upgrade to 1.6.12 ASAP!!! (yes, 3 exclamation marks)
1.6.3 has a known security issue that led to error messages similar to
what
you are seeing, if my memory isn't playing tricks on me.

In general, please try to reproduce problems with the lastest version of
the
software, always, on both clients and servers. We get quite a few
reports
for old problems which have been fixed, but people missed the fix
because
they didn't upgrade.

Thanks,
Stefan



__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Repo split across public/private networks

[Tony Butt]

On Wed, 2010-09-08 at 00:22 -0600, Adams, Brian M wrote:
> I have a project whose subversion repository needs to be split across 
> networks and I'm seeking ideas for how to best manage this.  There are 
> mailing list posts addressing public/private on the same server, but I didn't 
> find much relevant to cross-network... 
> 
> While the core of the project can be in an svn repo hosted on a public 
> network, some components must be retained in an svn repo hosted on a private 
> network, inaccessible from the public one.   While developers on the public 
> side need only work with public content, developers on the private side want 
> the private content to augment the public content as seamlessly as possible.  
> A few possible ideas:
> 
> 1.  As the project already manages all it's third-party libraries with svn 
> externals, we could create core repos on public and private sides, then 
> meta-packages on the respective networks, composed primarily of externals 
> which pick up the right pieces to assemble the public or private version of 
> the software.  For example if the repos were laid out as
>   * public/project/src
>   * public/project/openlibs
>   * private/project/closedlibs
> then there could be a public meta-package containing nothing but externals to 
> public/project/src and public/project/openlibs, whereas the private 
> meta-package would contain externals to all three components.  While this 
> seems straightforward,there are many more directories with public/private 
> versions or components,  it would require involved reorganization of content, 
> a more complex release process traversing and tagging the externals, and 
> additional complexity on the development team (or the tools they maintain).  
> The advantage is a single cohesive checkout.
> 
> 2.  We could revert to script-based management of our version control process 
> on the private network, for example, notionally: (1) svn co 
> public/project/core project/core; (2) cd project/local && 
> get_private_repo_parts.sh, which could augment the repo with the necessary 
> private components.  This defeats some of the appeal of using externals and 
> would probably require private developers to have a set of utilities to wrap 
> svn commands to make sure the private parts of the project/ directory get 
> traversed when doing any svn command.  That said, it's probably far simpler 
> than (1) and I suspect is how other projects with various levels of publicity 
> might manage their releases.
> 
> 3.  (Not possible to my knowledge) Notionally, the best way to manage this 
> might be for the public repo to contain "optional externals" which point to 
> the private repo.  In this scenario, developers on both networks would just 
> svn co public/project and for public users, those externals pointing to the 
> unreachable private network would timeout or could be disabled at checkout 
> time with a command line switch, whereas users on the private network would 
> get all parts.  I don't think this possible with current subversion 
> capability, but perhaps I'm wrong.  It's the closest concept to the way we'd 
> organize the repo in any case.
> 
> What other subversion features or approaches might I consider?
A variation of option 3 is to provide a name service alias so that the
externals accessed from the public network resolve to the public server,
and the same externals on the public server, when accessed from the
private network, resolve to the private server. To do this, a domain
name alias for the private server name could be placed in the public
network. This would require a high degree of structure overlap between
the 2 repositories to work.
> 
> Thanks,
> Brian
> 

-- 
Tony Butt 
CEA Technologies
Canberra

RE: Best way to "un-version control" a file?

[Tony Sweeney]

 

> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
> Sent: 23 September 2010 12:40
> To: David Huang
> Cc: Chris Albertson; users@subversion.apache.org
> Subject: Re: Best way to "un-version control" a file?
> 
> On Thu, Sep 23, 2010 at 12:43 AM, David Huang 
>  wrote:
> >
> > On Sep 22, 2010, at 8:21 PM, Chris Albertson wrote:
> >> But, I did not think until now that I should have excluded 
> files such 
> >> as core files and logs and autoconf's cache from version 
> controls.   
> >> I now know how to a global ignore and a ignore foe one 
> directory but 
> >> how to remove these files from version control once they 
> are already 
> >> there.     Is "svn rm" the best why?  But that will remove 
> them from 
> >> the working directory too.  I don't want that.
> >
> > svn rm --keep-local filename
> 
> Which is thoughtful, but does *NOT* get old versions of the 
> file out of the repository. Unfortunately, that's been 
> requested before, and has never gotten into working code that 
> I can find. The idea is called "obliterate", and it goes 
> against the basic design ideas of the creators of Subvresion: 
> a source control is supposed to keep all your source, not 
> allow obliteration whether accidental or deliberate by users.

Users, no; administrators, yes.  At the time Perforce added this it was, if I 
recall correctly, their number one feature request.

> 
> Obliterating it, as things stand, would require taking the 
> upstream repo offline, doing an "svnadmin dump | 
> svndumpfilter [arguments] | svnadmin load" set of operations, 
> and it's awkward.

See above.  This (well, the equivalent) was what you had to do in Perforce 
before they implemented 'obliterate'.

> 
> >> Next is these a way to make the ignore property for a 
> directory apply 
> >> to all sub dirs recursively.   The next project I want to 
> move to svn 
> >> is much larger and has many nested directories
> >
> > svn propset --recursive svn:ignore ignorepattern .
> 
> Also, the very nice "TortoiseSVN" gui is fabulous for doing 
> just such operations. It's my only excuse these days for 
> doing any Windows work with Subversion: the tool works really well.
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

Re: Best way to "un-version control" a file?

[Tony Butt]

On Fri, 2010-09-24 at 02:26 -0500, David Huang wrote:
> 
> On Sep 24, 2010, at 12:17 AM, Nico Kadel-Garcia wrote:
> 
> > On Thu, Sep 23, 2010 at 11:18 PM, Daniel Shahaf  
> > wrote:
> >> Les Mikesell wrote on Thu, Sep 23, 2010 at 12:27:40 -0500:
> >>> Am I wrong in thinking that similar accidents happen to everyone
> >>> eventually and that a feature to fix them would be desirable?
> >> 
> >> Yes, the feature has its use case.  And if you'd like to see it
> >> implemented yesterday, that's cool.  Just don't assume that everyone
> >> thinks the same way please.
> > 
> > Can you actually name anyone who thinks it's not a useful, or
> > potentially useful feature? Anyone?
> 
> I suspect what was meant is that not everyone thinks obliterate needs to be 
> "implemented yesterday" or that it's the "#1 request". I do think obliterate 
> would be useful, but I personally have not ever needed it in my 2 or 3 years 
> of administering an SVN repo, and don't forsee needing it in the future.
> 
Im about 6 years of managing a repository for a development team, we
have only really needed it once. On that occasion we were able to take
the repository down, dump it out, strip out the undesirable file, and
reload. Our repository has grown somewhat in size since then, and
certainly the dumpfile will be much larger (since time is a dimension
there), so it would be that much more painful to do if we had to.

There have probably been a handful of times when we would have liked to
obliterate some files, chiefly large binaries which were inadvertently
committed (against our usage policy), but it is not worth the fuss to
dump and reload to do this.

The number of times we might have obliterated by mistake, and had to
recover in some way - none. If obliterate becomes available, we would
want to be very very very careful in it's usage.
> Also, it's not like the SVN team has rejected the feature; the FAQ mentions 
> that it's planned: http://subversion.apache.org/faq.html#removal and there's 
> even a roadmap for it: 
> https://svn.apache.org/repos/asf//subversion/trunk/notes/obliterate/plan-milestones.html

-- 
Tony Butt 
CEA Technologies
Canberra, Australia

Re: Copy and Reduce the size of SVn repos

[Tony Sweeney]

On 03/08/15 16:42, Branko Čibej wrote:
> On 08.03.2015 09:35, Nico Kadel-Garcia wrote:
>> On Sat, Mar 7, 2015 at 11:57 PM, Rajesh Kumar  wrote:
>>> I have one Huge SVN repos which is around 1TB in terms of size. I have two
>>> requirement as follows and i would like to know the best approach to be
>>> followed to save time and effort.
>> According to the doctrine of "there shall be no obliterate command,
>> the record must be kept absolutely pristine at all costs, praise the
>> gospel of all history matters!",
> 
> 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
> 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
> 
> 
root@fractal:~ # p4 help obliterate

obliterate -- Remove files and their history from the depot

p4 obliterate [-y -A -b -a -h] file[revRange] ...

Obliterate permanently removes files and their history from the server.
(See 'p4 delete' for the non-destructive way to delete a file.)
Obliterate retrieves the disk space used by the obliterated files
in the archive and clears the files from the metadata that is
maintained by the server.  Files in client workspaces are not
physically affected, but they are no longer under Perforce control.

Obliterate is aware of lazy copies made when 'p4 integrate' creates
a branch, and does not remove copies that are still in use. Because
of this, obliterating files does not guarantee that the corresponding
files in the archive will be removed.

If the file argument has a revision, the specified revision is
obliterated.  If the file argument has a revision range, the
revisions in that range are obliterated.  See 'p4 help revisions'
for help.

By default, obliterate displays a preview of the results. To execute
the operation, you must specify the -y flag.

By default, obliterate will not process a revision which has been
archived. To include such revisions, you must specify the -A flag.

Obliterate has three flags that can improve performance:

The '-b' flag restricts files in the argument range to those that
are branched and are both the first revision and the head revision
This flag is useful for removing old branches while keeping files
of interest (files that were modified).

The '-a' flag skips the archive search and removal phase.  This
phase of obliterate can take a very long time for sites with big
archive maps (db.archmap).  However, file content is not removed;
if the file was a branch, then it's most likely that the archival
search is not necessary.  This option is safe to use with the '-b'
option.

The '-h' flag instructs obliterate not to search db.have for all
possible matching records to delete.  Usually, db.have is one of the
largest tables in a repository and consequently this search takes
a long time.  Do not use this flag when obliterating branches or
namespaces for reuse,  because the old content on any client
will not match the newly-added repository files.  Note that use of
the -h flag has the side-effect of cleaning the obliterated files
from client workspaces when they are synced.

If you are obliterating files in order to entirely remove a depot
from the server, and files in that depot have been integrated to
other depots, run 'p4 snap' first to break those linkages, so that
obliterate can remove the unreferenced archive files. If, instead,
you specify '-a' to skip the archive removal phase, then you will
need to specify '-f' when deleting the depot, since the presence
of the archive files will prevent the depot deletion.

'p4 obliterate' requires 'admin' access, which is granted by 'p4
protect'.

root@fractal:~ # 

As I recall, this was feature request #13 after Perforce was released, and was 
implemented the best part of 15 years ago.  As near as I can tell it's 
architecturally impossible to implement in Subversion as a consequence of some 
of the initial design choices.  Subversion has served me well, but this has 
been a glaring misfeature since its inception:

http://svn.haxx.se/dev/archive-2003-01/0364.shtml

Tony.

Re: Feature request: 'svn up --dry-run'

[Tony Sweeney]

On 04/03/15 20:27, Evan Driscoll wrote:

I'd like to put a feature request out there for a --dry-run option to 'svn up'.

There are two things that this would accomplish over 'svn stat --show-updates'.

First, it seems like a natural thing to do; in particular, 'merge'
supports --dry-run and after using Git for a while my mental model of
update is it's just a special case of merge. IMO at least, two ways of
doing the same thing isn't necessarily a bad thing.


Perforce supports exactly this.  In fact, for virtually every command 
which *does* something in Perforce, there is a '-n' option which says 
"don't actually do it, but show me what this command _would_ do".  It's 
surprisingly powerful.




But even more to the point, 'svn stat --show-updates' *doesn't work*
for many of the times when I want 'svn up --dry-run', because it
doesn't accept a -r argument. Here's a common scenario:

1. I have revision 1000 checked out and am editing foo.txt
2. Other people make a few commits to other files
3. I commit foo.txt as revision 1010
[note that I now have a mixed-revision working copy where foo.txt is
on 1010 and everything else on 1000]
4. Other people make more commits to files, e.g. up to 1020
5. I do something that makes svn complain about the fact that I'm on a
mixed-revision copy

Now I have two reasonable options to clear that error: update to the
current head (1020) or update to the most recent version of anything I
have checked out (1010). A lot of the time I want to do the *second*
of those two options, because it's more likely to just give me small
updates and less likely to update a file that will prompt a
45-minute-or-more rebuild. It's also less likely to result in merge
conflicts. (Yeah they might have to be dealt with eventually, but (i)
not necessarily and (ii) I might not want to deal with those later.)

So what I would *like* to do is something like:

6. See what would be changed if I update to 1010
7a. If it looks like it'll be a big update, just update to HEAD
7b. If it looks like a small update, update to 1010

But I don't know any way to do #6 in Subversion, and this is exactly
what 'svn up --dry-run' would provide.

(If there *is* actually a way to do #6, I'm all ears.)

Evan

Subversion Exception diff_editor.c 1626

[Tony Hailes]

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

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

In file
'D:\Development\SVN\Releases\TortoiseSVN-1.8.11\ext\subversion\subversion\libsvn_wc\diff_editor.c'
line 1626: internal malfunction
---
OK
---

Subversion 1.9.1 and SVNParentPath

[Tony Butt]

Problem: Cannot access svn repos using SVNParentPath and subversion
1.9.1

Environment:
Ubuntu 14.04, Apache 2.4.7, Subversion 1.9.1, mod_auth_kerb

Apache config snippet:



   DAV svn
   SVNParentPath /srv/svn/repos/
   SVNListParentPath on

   SVNIndexXSLT "/svnindex.xsl"

# Compression options
   AddOutputFilterByType DEFLATE text/html text/plain text/xml
   SetInputFilter DEFLATE

# Krb Authentication
   Include /etc/apache2/krb.conf

   AuthDBMType default
   AuthDBMGroupFile /srv/www/groupsdb
   
 Require group software hardware
 Require valid-user
   

   AuthZSVNAccessFile /srv/svn/access





I installed the subversion 1.9.0 RC a little while back on this machine,
all OK.
Installed subversion 1.9.0 release Monday, had to set
--enable-broken-httpd-auth
to build successfully. Went to the apache config and ensured that no
unauthenticated access was possible to the document root. All OK.

I installed subversion 1.9.1 yesterday, built and installed OK.
On testing repos access, I can browse to http://hostname/repos/ ,
but any attempt to access http://hostname/repos/name1
fails, with this message at the browser.

"Unauthorized This server could not verify that you are authorized to
access the document requested. Either you supplied the wrong credentials
(e.g., bad password), or your browser doesn't understand how to supply
the credentials required."

Reverting to Subversion 1.8.13, or 1.9.0 resolves this.
Changing the configuration top not use SVNParentPath, by specifying
individual repositories with SVNPath resolves this too.
Some interaction between the svnauthz changes and SVNParentPath seems to
be broken

Thanks


-- 
Tony Butt 
CEA Technologies


signature.asc
Description: This is a digitally signed message part

Re: Subversion 1.9.1 and SVNParentPath

[Tony Butt]

On Mon, 2015-09-07 at 10:20 +0200, Branko Čibej wrote:

> [Please keep the conversation on-list, others are interested in it, too.
> I'm replying privately, since I can't just make your private message
> public without your consent; but please follow up on the list, if you
> don't mind.]
> 
> On 07.09.2015 10:07, Tony Butt wrote:
> > On Mon, 2015-09-07 at 09:59 +0200, Branko Čibej wrote:
> >> On 07.09.2015 02:16, Tony Butt wrote:
> >>
> >>> On 07/09/15 10:10, Tony Butt wrote:
> >>>
> >>>>> # Compression options
> >>>>>AddOutputFilterByType DEFLATE text/html text/plain text/xml
> >>>>>SetInputFilter DEFLATE
> >>>>>
> >>>>> # Krb Authentication
> >>>>>Include /etc/apache2/krb.conf
> >>>>>
> >>>>>AuthDBMType default
> >>>>>AuthDBMGroupFile /srv/www/groupsdb
> >>>>>
> >>>>>  Require group software hardware
> >>>>>  Require valid-user
> >>>>>
> >>>>>
> >>>>>AuthZSVNAccessFile /srv/svn/access
> >>>>>
> >>>>>
> >>>>> 
> >>>>>
> >>>>>
> >>>>> I installed the subversion 1.9.0 RC a little while back on this
> >>>> machine,
> >>>>> all OK.
> >>>>> Installed subversion 1.9.0 release Monday, had to set
> >>>>> --enable-broken-httpd-auth
> >>>>> to build successfully. Went to the apache config and ensured
> >>>> that nobr...@wandisco.com
> >>>>> unauthenticated access was possible to the document root. All
> >>>> OK.
> >>>>> I installed subversion 1.9.1 yesterday, built and installed OK.
> >>>>> On testing repos access, I can browse to
> >>>> http://hostname/repos/ ,
> >>>>> but any attempt to access http://hostname/repos/name1
> >>>>> fails, with this message at the browser.
> >>>>> cea_sw_dev/
> >>>>> "Unauthorized This server could not verify that you are
> >>>> authorized to
> >>>>> access the document requested. Either you supplied the wrong
> >>>> credentials
> >>>>> (e.g., bad password), or your browser doesn't understand how to
> >>>> supply
> >>>>> the credentials required."
> >>>>>
> >>>>> Reverting to Subversion 1.8.13, or 1.9.0 resolves this.
> >>>>> Changing the configuration to not use SVNParentPath, by
> >>>> specifying
> >>>>> individual repositories with SVNPath resolves this too.
> >>>>> Some interaction between the svnauthz changes and SVNParentPath
> >>>> seems to
> >>>>> be broken
> >>>> When you upgraded Subversion, did you also restart httpd? (Using
> >>>> 'apachectl graceful' or 'apachectl restart' or reasonable
> >>>> equivalent.)
> >>>> br...@wandisco.com
> >>>> -- Brane
> >>>>
> >>> cea_sw_dev/
> >>> Sorry for the delayed reply, I have been off work sick for a while,
> >>> and am only just subscribing to the list.
> >>> Sorry also for the somewhat dodgy reply format too, working around
> >>> the non-subscription.
> >>>
> >>> Yes, I did restart httpd - I went through the sequence of changing
> >>> installed versions at least twice as well, restarting each time.
> >>>
> >>> I looked at the changelog for 1.9.1, and didn't see anything
> >>> obvious, but...
> >>>
> >>> I can easily test against our config if there is a change you want
> >>> tested - OTOH, it might be configuration or user error (unlikely,
> >>> but possible). I'm not new to subversion though, so I hope I covered
> >>> the obvious stuff...
> >>
> >> At the moment, considering another report, it seems that the problem
> >> stems from an interaction between Kerberos authentication and one of
> >> the recent security fixes in either httpd or Subversion (CVE-2015-3185
> >> or -3184). If that's the case, then it's probably not specific to
> >> 1.9.1 but exists in 1.9.0, 1.8.14 and 1.7.22 as well, always in
> >> combination with httpd-2.4.16.
> >>
> >> I'm trying to track this down but haven't had much success yet.
> >>
> >> -- Brane
> > I was able to test this on the same system, with Subversion 1.9.0,
> 
> Are you sure you were using 1.9.0, not one of the release candidates?

I'm fairly sure, but will double check shortly

> 
> >  and
> > 1.8.13 as well, and did not see the same problem.
> 
> 1.8.13 does not have the CVE-2015-3184 security fix.
> 
> > I don't have 1.8.14, but can build and test it if you like.
> 
> Please do!

I'll do that soon too

> 
> > I can probably also test against mod_auth_sasl, if that would help - we
> > run that on an older machine, and I should be able to copy the config.
> 
> It would be good to compare SASL and KRB, yes.

That will take a little more work, I'll reply when I have it done.

> 
> -- Brane


-- 
Tony Butt 
CEA Technologies


signature.asc
Description: This is a digitally signed message part

Re: Subversion 1.9.1 and SVNParentPath

[Tony Butt]

On Tue, 2015-09-08 at 09:41 +1000, Tony Butt wrote:

> On Mon, 2015-09-07 at 10:20 +0200, Branko Čibej wrote: 
> 
> > 
> > On 07.09.2015 10:07, Tony Butt wrote:
> > > On Mon, 2015-09-07 at 09:59 +0200, Branko Čibej wrote:
> > >> On 07.09.2015 02:16, Tony Butt wrote:
> > >>
> > >>> On 07/09/15 10:10, Tony Butt wrote:
> > >>>
> > >>>>> # Compression options
> > >>>>>AddOutputFilterByType DEFLATE text/html text/plain text/xml
> > >>>>>SetInputFilter DEFLATE
> > >>>>>
> > >>>>> # Krb Authentication
> > >>>>>Include /etc/apache2/krb.conf
> > >>>>>
> > >>>>>AuthDBMType default
> > >>>>>AuthDBMGroupFile /srv/www/groupsdb
> > >>>>>
> > >>>>>  Require group software hardware
> > >>>>>  Require valid-user
> > >>>>>
> > >>>>>
> > >>>>>AuthZSVNAccessFile /srv/svn/access
> > >>>>>
> > >>>>>
> > >>>>> 
> > >>>>>
> > >>>>>
> > >>>>> I installed the subversion 1.9.0 RC a little while back on this
> > >>>> machine,
> > >>>>> all OK.
> > >>>>> Installed subversion 1.9.0 release Monday, had to set
> > >>>>> --enable-broken-httpd-auth
> > >>>>> to build successfully. Went to the apache config and ensured
> > >>>> that nobr...@wandisco.com
> > >>>>> unauthenticated access was possible to the document root. All
> > >>>> OK.
> > >>>>> I installed subversion 1.9.1 yesterday, built and installed OK.
> > >>>>> On testing repos access, I can browse to
> > >>>> http://hostname/repos/ ,
> > >>>>> but any attempt to access http://hostname/repos/name1
> > >>>>> fails, with this message at the browser.
> > >>>>> cea_sw_dev/
> > >>>>> "Unauthorized This server could not verify that you are
> > >>>> authorized to
> > >>>>> access the document requested. Either you supplied the wrong
> > >>>> credentials
> > >>>>> (e.g., bad password), or your browser doesn't understand how to
> > >>>> supply
> > >>>>> the credentials required."
> > >>>>>
> > >>>>> Reverting to Subversion 1.8.13, or 1.9.0 resolves this.
> > >>>>> Changing the configuration to not use SVNParentPath, by
> > >>>> specifying
> > >>>>> individual repositories with SVNPath resolves this too.
> > >>>>> Some interaction between the svnauthz changes and SVNParentPath
> > >>>> seems to
> > >>>>> be broken
> > >>>> When you upgraded Subversion, did you also restart httpd? (Using
> > >>>> 'apachectl graceful' or 'apachectl restart' or reasonable
> > >>>> equivalent.)
> > >>>> br...@wandisco.com
> > >>>> -- Brane
> > >>>>
> > >>> cea_sw_dev/
> > >>> Sorry for the delayed reply, I have been off work sick for a while,
> > >>> and am only just subscribing to the list.
> > >>> Sorry also for the somewhat dodgy reply format too, working around
> > >>> the non-subscription.
> > >>>
> > >>> Yes, I did restart httpd - I went through the sequence of changing
> > >>> installed versions at least twice as well, restarting each time.
> > >>>
> > >>> I looked at the changelog for 1.9.1, and didn't see anything
> > >>> obvious, but...
> > >>>
> > >>> I can easily test against our config if there is a change you want
> > >>> tested - OTOH, it might be configuration or user error (unlikely,
> > >>> but possible). I'm not new to subversion though, so I hope I covered
> > >>> the obvious stuff...
> > >>
> > >> At the moment, considering another report, it seems that the problem
> > >> stems from an interaction between Kerberos authentication and one of
> > >> the recent security fixes in either httpd or Subversion (CVE-2015-3185
> > >>

Re: Subversion 1.9.1 and SVNParentPath

[Tony Butt]

On Tue, 2015-09-08 at 12:52 +1000, Tony Butt wrote:

> On Tue, 2015-09-08 at 09:41 +1000, Tony Butt wrote:
> 
> > On Mon, 2015-09-07 at 10:20 +0200, Branko Čibej wrote: 
> > 
> > > 
> > > On 07.09.2015 10:07, Tony Butt wrote:
> > > > On Mon, 2015-09-07 at 09:59 +0200, Branko Čibej wrote:
> > > >> On 07.09.2015 02:16, Tony Butt wrote:
> > > >>
> > > >>> On 07/09/15 10:10, Tony Butt wrote:
> > > >>>
> > > >>>>> # Compression options
> > > >>>>>AddOutputFilterByType DEFLATE text/html text/plain text/xml
> > > >>>>>SetInputFilter DEFLATE
> > > >>>>>
> > > >>>>> # Krb Authentication
> > > >>>>>Include /etc/apache2/krb.conf
> > > >>>>>
> > > >>>>>AuthDBMType default
> > > >>>>>AuthDBMGroupFile /srv/www/groupsdb
> > > >>>>>
> > > >>>>>  Require group software hardware
> > > >>>>>  Require valid-user
> > > >>>>>
> > > >>>>>
> > > >>>>>AuthZSVNAccessFile /srv/svn/access
> > > >>>>>
> > > >>>>>
> > > >>>>> 
> > > >>>>>
> > > >>>>>
> > > >>>>> I installed the subversion 1.9.0 RC a little while back on this
> > > >>>> machine,
> > > >>>>> all OK.
> > > >>>>> Installed subversion 1.9.0 release Monday, had to set
> > > >>>>> --enable-broken-httpd-auth
> > > >>>>> to build successfully. Went to the apache config and ensured
> > > >>>> that nobr...@wandisco.com
> > > >>>>> unauthenticated access was possible to the document root. All
> > > >>>> OK.
> > > >>>>> I installed subversion 1.9.1 yesterday, built and installed OK.
> > > >>>>> On testing repos access, I can browse to
> > > >>>> http://hostname/repos/ ,
> > > >>>>> but any attempt to access http://hostname/repos/name1
> > > >>>>> fails, with this message at the browser.
> > > >>>>> cea_sw_dev/
> > > >>>>> "Unauthorized This server could not verify that you are
> > > >>>> authorized to
> > > >>>>> access the document requested. Either you supplied the wrong
> > > >>>> credentials
> > > >>>>> (e.g., bad password), or your browser doesn't understand how to
> > > >>>> supply
> > > >>>>> the credentials required."
> > > >>>>>
> > > >>>>> Reverting to Subversion 1.8.13, or 1.9.0 resolves this.
> > > >>>>> Changing the configuration to not use SVNParentPath, by
> > > >>>> specifying
> > > >>>>> individual repositories with SVNPath resolves this too.
> > > >>>>> Some interaction between the svnauthz changes and SVNParentPath
> > > >>>> seems to
> > > >>>>> be broken
> > > >>>> When you upgraded Subversion, did you also restart httpd? (Using
> > > >>>> 'apachectl graceful' or 'apachectl restart' or reasonable
> > > >>>> equivalent.)
> > > >>>> br...@wandisco.com
> > > >>>> -- Brane
> > > >>>>
> > > >>> cea_sw_dev/
> > > >>> Sorry for the delayed reply, I have been off work sick for a while,
> > > >>> and am only just subscribing to the list.
> > > >>> Sorry also for the somewhat dodgy reply format too, working around
> > > >>> the non-subscription.
> > > >>>
> > > >>> Yes, I did restart httpd - I went through the sequence of changing
> > > >>> installed versions at least twice as well, restarting each time.
> > > >>>
> > > >>> I looked at the changelog for 1.9.1, and didn't see anything
> > > >>> obvious, but...
> > > >>>
> > > >>> I can easily test against our config if there is a change you want
> > > >>> tested - OTOH, it might be configuration or user e

RE: SVN and Active Directory

[Tony Butt]

We use saslauthd with a Kerberos backend to our AD servers, and it works very 
well. That assumes you are running a linux based Os, of course.
Tony Butt
CEA Technologies

From: jbl...@icloud.com [mailto:jbl...@icloud.com]
Sent: Wednesday, 20 April 2016 6:22 AM
To: Gronde, Christopher (Contractor)
Cc: users@subversion.apache.org
Subject: Re: SVN and Active Directory



From: jbl...@icloud.com<mailto:jbl...@icloud.com> [mailto:jbl...@icloud.com]
Sent: Tuesday, April 19, 2016 4:12 PM
To: Gronde, Christopher (Contractor) 
mailto:christopher.gro...@fincen.gov>>
Cc: users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: Re: SVN and Active Directory


On Apr 19, 2016, at 12:53 PM, Gronde, Christopher (Contractor) 
mailto:christopher.gro...@fincen.gov>> wrote:

Has anyone in here successfully integrated SVN with Active Directory for user 
authentication?  We are currently using FreeIPA and user account management is 
the bane of my existence.  If anyone has or knows of any documentation for 
integrating Active Directory with SVN (preferably 1.9 since we are going to 
upgrade to that version) that would be much appreciated.



I have, just recently in fact. The trick is to use SASL with LDAP. I only use 
authentication at this point and don't use AD groups for authorization.

I'm using a RHEL7 as my svn server which bundles SVN 1.7. I can't imagine the 
configuration of the server would be drastically different from 1.7 to 1.9.

So far the only burr in the saddle has been making sure the clients support 
SASL/PLAIN -- most do, but Eclipse with Subclipse was a failure.

As long as you're fine with passing credentials in cleartext, then this will 
work for you. If you need SSL encryption, then you will probably need to add 
Apache. Trying to get the RedHat-supplied svn and Apache components to work 
together was a non-starter, and trying to build everything from source on RHEL 
didn't work either.

On Apr 19, 2016, at 1:16 PM, Gronde, Christopher (Contractor) 
mailto:christopher.gro...@fincen.gov>> wrote:

Unfortunately I fear that SSL is going to be a requirement for us.  The client 
our users have been using is TortoiseSVN.  1.9 isn’t supplied by Red Hat so 
maybe that is easier to get to play well with apache than 1.7 was for you?


[please bottom post your responses]

We also use TortoiseSVN 1.9 and it supports SASL. It was only subclipse that 
caused grief.

I would suggest looking to a packager like wanDisco for your svn 1.9 server. 
They could probably help getting Subversion+Apache working without having to 
build from source. Also, since Apache 2.4 natively supports AD authentication, 
you might get everything you need without having to rely on RedHat.

RE: Get subversion python bindings on existing subversion setup

[Tony Sweeney]

From: kapila narang [mailto:kapilanar...@gmail.com]
Sent: 28 May 2013 12:08
To: users@subversion.apache.org
Subject: Get subversion python bindings on existing subversion setup

Hi,
   I have subversion 1.6.11 installed on redhat 64bit server  used since long. 
Seems to be installed using rpm/yum not from source.
Can you suggest me how i get svn python binding for existing setup without 
effective my current environment? everyone says of compiling from source, which 
i am not sure how can i do it in my case.

As root, execute 'yum install pysvn'.


Looking for help.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6362 - Release Date: 05/27/13

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: ECCN

[Tony Sweeney]

http://svn.haxx.se/dev/archive-2011-11/0260.shtml

Subversion itself does not seem to have an ECCN.  However, the Apache server, 
which forms part of many Subversion installations does.  It's 5D002

http://www.apache.org/licenses/exports/

Tony.


From: Khan, Sohail A UTRC [mailto:kha...@utrc.utc.com]
Sent: 12 July 2013 13:15
To: users@subversion.apache.org
Subject: ECCN

Does anyone know the ECCN for the following products?

Software Name

Version

svn

1.6.12

svn

1.7.4


Thank you!

Sohail Khan
UTRC IT Intern
Office: SC158K
Phone: (860) 610-7822


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2013.0.3349 / Virus Database: 3204/6481 - Release Date: 07/10/13

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Cannot tell where repository lives

[Tony Sweeney]

I think this may be possible with Apache rewrite rules.  It's possible that 
'newstuff' URLs redirect to a different server, rather than being served 
locally by mod_dav_svn.


From: Kerry Thurber [mailto:ker...@tucsonembedded.com]
Sent: 28 August 2013 17:52
To: users@subversion.apache.org
Subject: Cannot tell where repository lives

Hello,

I have a problem with my repository.  The person who created it is on vacation, 
and I have been tasked with adding some pre-commit hooks.

Well, I did, and they work.  But come to find out the structure has been 
changed.  The old structure is still in place, and responds to the hooks.  The 
new structure points to a URL on the same virtual machine, but all interaction 
with the new structure completely ignores the hooks.  For example:

http://mysvnserver/projectbase/newstuff is utterly immune to anything I put in 
the hooks directory.
http://mysvnserver/projectbase/oldstuff responds perfectly to the hooks I have 
put in place.

projectbase corresponds to the directory path 
"/tracsvn/projects/svn/projectbase" on the virtual machine.

My question is, how can this be?  Is it possible that oldstuff and newstuff 
somehow use separate repositories?  I couldn't find evidence of another 
repository on this virtual machine.  As per google, my method of looking was to 
search for "db" directories, and look inside of them to find fs-type files.  
(The one I found for the old stuff says that we're using fsfs.)  Is there a 
better way to do this?  Alternatively, can I somehow query the database to 
prove that this particular location does or does not contain "newstuff"?

The projectbase corresponding to "oldstuff" contains a "hooks" directory as 
well as dav, db and locks.  My version is 1.6.6 (r40053)

I appreciate any help you can give me.

Kerry Thurber
Software Engineer
Tucson Embedded Systems
(520) 271-3329


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3211/6614 - Release Date: 08/27/13

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: subversion load fails with “no such revision”

[Tony Sweeney]

There are at least four different versions of dumpfilter floating about the 
aether.  It would help to know which one you used, and how you used it.

Tony.


From: Harlan Harris [mailto:harlan.har...@gmail.com]
Sent: 30 August 2013 15:06
To: users@subversion.apache.org
Subject: Re: subversion load fails with “no such revision”

I still haven't been able to make any progress on this. If ServerFault and this 
mailing list aren't going to be adequate to solve the problem, could someone 
suggest an alternative? Thanks,

 -Harlan


On Thu, Aug 29, 2013 at 8:21 AM, Harlan Harris 
mailto:har...@harris.name>> wrote:
Hi. This is crossposted from 
ServerFault<http://serverfault.com/questions/534553/subversion-load-fails-with-no-such-revision>.
 I'm not subscribed to this list, so a cc would be appreciated. (Or feel free 
to just respond on ServerFault. So far it's got a couple of upvotes, but no 
responses.)


I'm trying to learn how to migrate a Subversion repo, and am running into an 
issue that doesn't make sense to me. I've used `svndumpfilter` to split out a 
sub-project, and have removed some path prefixes. Several hundred commits now 
import correctly, but then I'm getting the following error:

<<< Started new transaction, based on original revision 19190
 * editing path : branches/features/DynamicSource ... done.
 * editing path : branches/features/DynamicSource/src/build.properties 
... done.
 * editing path : 
branches/features/DynamicSource/src/client/default.htm ...done.
 * editing path : 
branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
 * editing path : 
branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
 * adding path : branches/features/DynamicSource/src/client/js/Enums.js 
...

OK, so I go into the dump file to look at revisions 19190 and 19098. First of 
all, revision 19098 _does_ exist in the dump file and was imported without a 
problem. Revision 19190 is a merge. Within 19190, here's that last file's info, 
which seems to be causing the issue:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Confusingly, revision 19100 does NOT exist in this filtered file. But the 
error's not referring to 19100, it's referring to 19098!

What do I do to get this file to load?

Thanks!



__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2013.0.3392 / Virus Database: 3211/6618 - Release Date: 08/28/13

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

svnserve crashes in libdispatch on OS X Mavericks (10.9) server

[Tony Piselli]

7fff95a99000 - 0x7fff95ae7fff  libcorecrypto.dylib (161.1) 
 /usr/lib/system/libcorecrypto.dylib
0x7fff95b3b000 - 0x7fff95b3cfff  libunc.dylib (28) 
<62682455-1862-36FE-8A04-7A6B91256438> /usr/lib/system/libunc.dylib
0x7fff95b3d000 - 0x7fff95b57fff  libdispatch.dylib (339.1.9) 
<46878A5B-4248-3057-962C-6D4A235EEF31> /usr/lib/system/libdispatch.dylib
0x7fff967c1000 - 0x7fff967c3ff3  libsystem_configuration.dylib (596.12) 
 
/usr/lib/system/libsystem_configuration.dylib
0x7fff96826000 - 0x7fff96830ff7  com.apple.bsd.ServiceManagement (2.0 - 
2.0) <2D27B498-BB9C-3D88-B05A-76908A8A26F3> 
/System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x7fff96e77000 - 0x7fff96f00ff7  libsystem_c.dylib (997.1.1) 
<61833FAA-7281-3FF9-937F-686B6F20427C> /usr/lib/system/libsystem_c.dylib
0x7fff9702b000 - 0x7fff97036ff7  com.apple.NetAuth (5.0 - 5.0) 
 
/System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0x7fff9710b000 - 0x7fff9710efff  com.apple.TCC (1.0 - 1) 
<32A075D9-47FD-3E71-95BC-BFB0D583F41C> 
/System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0x7fff9747f000 - 0x7fff9749bfff  libresolv.9.dylib (54) 
<11C2C826-F1C6-39C6-B4E8-6E0C41D4FA95> /usr/lib/libresolv.9.dylib
0x7fff974ec000 - 0x7fff97744ff1  com.apple.security (7.0 - 55471) 
<233831C5-C457-3AD5-AFE7-E3E2DE6929C9> 
/System/Library/Frameworks/Security.framework/Versions/A/Security
0x7fff980cb000 - 0x7fff9811dfff  libc++.1.dylib (120) 
<4F68DFC5-2077-39A8-A449-CAC5FDEE7BDE> /usr/lib/libc++.1.dylib
0x7fff98894000 - 0x7fff98894ff7  libkeymgr.dylib (28) 
<3AA8D85D-CF00-3BD3-A5A0-E28E1A32A6D8> /usr/lib/system/libkeymgr.dylib
0x7fff98d7a000 - 0x7fff98da1ff7  libsystem_network.dylib (241.3) 
<8B1E1F1D-A5CC-3BAE-8B1E-ABC84337A364> /usr/lib/system/libsystem_network.dylib
0x7fff99324000 - 0x7fff9937fffb  com.apple.AE (665.5 - 665.5) 
 
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x7fff9960d000 - 0x7fff99611fff  libsystem_stats.dylib (93.1.26) 
 /usr/lib/system/libsystem_stats.dylib
0x7fff99f28000 - 0x7fff99f9  com.apple.CoreServices.OSServices 
(600.4 - 600.4) <36B2B009-C35E-3F21-824E-E0D00E7808C7> 
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices

External Modification Summary:
  Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
  Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
  Calls made by all processes on this machine:
task_for_pid: 821
thread_create: 0
thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=94.8M resident=37.4M(39%) 
swapped_out_or_unallocated=57.4M(61%)
Writable regions: Total=31.6M written=172K(1%) resident=608K(2%) 
swapped_out=0K(0%) unallocated=31.0M(98%)
 
REGION TYPE  VIRTUAL
===  ===
Dispatch continuations 4096K
Kernel Alloc Once 4K
MALLOC 18.2M
MALLOC (admin)   16K
STACK GUARD56.0M
Stack  9316K
VM_ALLOCATE  28K
__DATA 3216K
__LINKEDIT 66.0M
__TEXT 28.9M
__UNICODE   544K
shared memory 4K
===  ===
TOTAL 185.8M

Should I enter this as a bug?

Thanks,

Tony Piselli
tpisell...@mac.com

RE: Files added to repository by others don't come down with 'svn update'

[Tony Sweeney]

For what it's worth, the FreeBSD ports for Subversion (i.e. the build harness 
and patches) are freely available via Subversion at the following URLs:

svn://svn0.us-east.freebsd.org/ports/head/devel/subversion
svn://svn0.us-east.freebsd.org/ports/head/devel/subversion16
svn://svn0.us-east.freebsd.org/ports/head/devel/subversion17

Tony.

-Original Message-
From: Branko Čibej [mailto:br...@wandisco.com] 
Sent: 19 January 2014 15:37
To: users@subversion.apache.org
Subject: Re: Files added to repository by others don't come down with 'svn 
update'

On 19.01.2014 09:06, Yuri wrote:
> In continuation of out previous discussion, I got another report that 
> another user got the same files in 'deleted' state, although he never 
> deleted them by hand. Same symptoms.

"Base deleted" is not the same as the file being deleted. It's been said 
before, but it'll happen if you update when a file was deleted in the 
repository, but modified in your working copy. This should result in a tree 
conflict.

> Look for the comment on Sat, 18 Jan 2014 20:56:33 -0800 in this PR:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=185261

I see here:
https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer.html

that FreeBSD uses (or perhaps suggests using) a variant of Subversion with 
FreeBSD-specific patches. The only reference I find to Subversion in this 
problem report is that there's "a Subversion problem of some sort." Hardly 
helpful

> (Previously I thought that I just did something wrong, or maybe 
> unconsciously hit 'resolved' option without remembering)
>
> I am pretty sure that 'svn update' marks certain files as 'deleted'
> without user ever doing 'svn delete' or resolving any conflict on them.
>
> Somebody needs to take a close look how is this is possible.

For starters, somebody can take the time to confirm that stock Subversion 
without FreeBSD-specific patches behaves the same way. Sorry if that sounds a 
bit untrustful, but frankly, I can't recall seeing the problem you report in 
any release version of Subversion, so I have my doubts.

-- Brane


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

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com 
__

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3658/6909 - Release Date: 12/10/13 
Internal Virus Database is out of date.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: expanding custom keywords in dump

[Tony Sweeney]

 

> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de] 
> Sent: 01 February 2014 09:24
> To: Subversion
> Subject: Re: expanding custom keywords in dump
> 
> Guten Tag Ben Reser,
> am Samstag, 1. Februar 2014 um 07:07 schrieben Sie:
> 
> > So if you're going to critique their technique[...]
> 
> I wasn't criticizing anything. Just thought that expanding 
> $FreeBSD$ may have been a feature the FreeBSD guys patched 
> into Subversion on their own, because some days ago it has 
> been mentioned that FreeBSD patches subversion to get some 
> features they need. If that is the case the questioner would 
> need more than just svndump expanding keywords, because it 
> would likely not support anything else than what svn clients 
> do now. 

It certainly appears to be the case that one of the FreeBSD patches is to 
expand this keyword in Subversion 1.6 and 1.7.  
The actual patches are available here:

svn://svn0.us-east.freebsd.org/ports/head/devel/subversion16
svn://svn0.us-east.freebsd.org/ports/head/devel/subversion17

They don't seem to have gotten round to putting this patch into the 1.8 port, 
though.

svn://svn0.us-east.freebsd.org/ports/head/devel/subversion

There is enough information at those locations to let you manually recreate 
their patch for your own platform, should you wish.  You probably don't need 
all of the patches, since most are specific to the FreeBSD ports tree build 
infrastructure, and you're unlikely to want their logging changes which appear 
to be intended to support their internal change management systems.

Tony.

> It was just a hint coming into my mind reading about 
> the problem, no need to overestimate.
> 
> 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
> 
> __
> This email has been scanned by the Symantec Email 
> Security.cloud service.
> For more information please visit 
> http://www.symanteccloud.com 
> __
> 
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4259 / Virus Database: 3681/7023 - Release 
> Date: 01/21/14 Internal Virus Database is out of date.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: expanding custom keywords in dump

[Tony Sweeney]

 

> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com] 
> Sent: 02 February 2014 06:42
> To: users@subversion.apache.org
> Subject: Re: expanding custom keywords in dump
> 
> On 02.02.2014 04:14, Nico Kadel-Garcia wrote:
> > On Sat, Feb 1, 2014 at 1:07 AM, Ben Reser  wrote:
> >
> >> Branko gave a perfectly reasonable answer.  Beyond that I honestly 
> >> don't get the point of these two emails.  FreeBSD uses keywords 
> >> because as an open source project they ship source.  Even more 
> >> importantly they have downstream projects (e.g. Apple uses 
> their find 
> >> command 
> >> 
> http://opensource.apple.com/source/shell_cmds/shell_cmds-175/find/mai
> >> n.c ).  I can't think of a better way of tracking 
> versioning for them 
> >> once the source leaves their version control system and 
> potentially goes into another.  Yes there are all sorts of 
> annoying bits about this.
> > If your build system has to rely on source control based fields, 
> > process the code in your build system. Putting the keyword 
> processing 
> > in the source control itself certainly dates back ti RCS 
> and CVS, and 
> > has been the bane of comparing source trees in working 
> copies, and of 
> > of actually reviewing the source control that will be used for 
> > building software. It profoundly interferes with generating 
> > replicatable code in multiple build or test environments.
> 
> You're totally missing the point of this thread. No-one said 
> anything about build systems; the original poster's 
> requirement is tracking upstream versions of files, not 
> complete source trees. No amount of *.h.in magic is going to do that.
> 
> Obviously, in an ideal world, one would be able to migrate 
> these kind of metadata between different VCS. Likewise 
> obviously, the world is not ideal, and in-file keywords are a 
> reasonable alternative if no other tooling can be devised. In 
> the case of Subversion->Perforce migration, one could argue 
> that it's Perforce's fault for not having an equivalent to 
> Subversion's properties that could store the source repo metadata.

http://www.perforce.com/perforce/r12.1/manuals/cmdref/attribute.html

> Compared to inventing a separate-but-parallel database for 
> maintaining these metadata, and all the surrounding tooling 
> that this implies, expanded keywords in the files themselves 
> appear positively benign, especially when they're not going 
> to change except from further upstream imports.
> 
> Last but not least ... Subversion does not expand keywords 
> unless explicitly told to. This was a conscious decision we 
> made to discourage exactly the kind of abuse you're griping 
> against. But you'll have a hard time to find a single VCS 
> glove that fits all potential users' feet.
> 
> -- Brane
> 
> 
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. br...@wandisco.com
> 
> __
> This email has been scanned by the Symantec Email 
> Security.cloud service.
> For more information please visit 
> http://www.symanteccloud.com 
> __
> 
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4259 / Virus Database: 3681/7023 - Release 
> Date: 01/21/14 Internal Virus Database is out of date.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Silently corrupted WC?

[Tony Sweeney]

 

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com] 
> Sent: 25 February 2014 22:53
> To: Chris
> Cc: users@subversion.apache.org
> Subject: Re: Silently corrupted WC?
> 
> On Tue, Feb 25, 2014 at 3:09 PM, Chris 
>  wrote:
> > Hi,
> >
> > I recently ran into an issue with subversion that I don't 
> know if it is a bug or something I'm not understanding, so I 
> figured I'd ask here in case I run into something similar in 
> the future.
> >
> > I'm running a Jenkins server for some ci-jobs for a 
> project. The server checks out the code from svn, builds and 
> runs etc. Due to some issues at corporate IT, we ran out of 
> disk on the jenkins machine. So the svn update failed as 
> expected. But somehow it modified the .svn-directory in a way 
> so that it thought that the WC was correct even though some 
> files had gotten mangled (some source files were just empty).
> > "svn status" said nothing was wrong and I even did "rm -rf" on the 
> > source directory followed by an update which of course just 
> took back 
> > the corrupted source files from .svn instead of downloading 
> them from 
> > the server. As I misinterpreted the compiler output I had, 
> it took me 
> > quite some time to realize my working copy was the root of 
> the problem 
> > and not something with compiler versions :)
> >
> > My question is if svn shouldn't catch this with some 
> checksum to warn me that my working copy is not to be 
> trusted? Or could I have had the extreme bad luck to have a 
> collision on such a checksum?
> > It is of course ok that things fail when we run out of 
> disk, but I get scared if svn doesn't detect that the WC is broken.
> >
> > The above happened with a 1.7.3 client. Due to corporate 
> IT, I can't run any more recent version at the moment.
> 
> Was / is it a native svn client (which one?), or an SVNKit (pure java
> implementation) version? They can have different behavior in 
> such edge cases. I'd expect an svn client to complain loudly 
> when running out of disk space during update, and to keep 
> complaining as long as the working copy is corrupt.

Jenkins uses SVNKit internally.  The SVNKit version will depend on the Jenkins 
version.

> 
> Now, you probably know this, but regardless of whether it is 
> a native client or SVNKit, 1.7.3 is *old* and contains many 
> bugs which were fixed in more recent releases. It's quite 
> possible that you've run into some bug that has long been 
> fixed (feel free to do some digging through the CHANGES log 
> [1] or the issue tracker [2]). Please try to convince your IT 
> department to at least go to the latest 1.7.x version (and if 
> possible to the latest 1.8 version, though that's a bit more 
> involved because it implies you running 'svn upgrade' on each 
> working copy).

Actually, not for Jenkins it doesn't.  It is possible to configure a default 
local workspace format for Jenkins to any of 1.4 through 1.7 Subversion 
workspace versions (as of Jenkins version 1.543).  Further, unlike native 
clients, SVNKit is workspace version agnostic; the higher SVNKit versions, on 
being asked to update an older workspace, fall back internally to the 
appropriate workspace compatibility code automatically and transparently.

Tony.

> 
> [1] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES
> [2] http://subversion.apache.org/reporting-issues.html
> 
> --
> Johan
> 
> __
> This email has been scanned by the Symantec Email 
> Security.cloud service.
> For more information please visit 
> http://www.symanteccloud.com 
> __
> 
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4335 / Virus Database: 3705/7093 - Release 
> Date: 02/14/14 Internal Virus Database is out of date.

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Copy the files between the branches witin the same repo and with saving the svn info about the operation.

[Tony Sweeney]

Look at 'svn merge'.  This does exactly what you want, from your description.

Tony.


From: Kamil Libich [mailto:kamil.lib...@gmail.com]
Sent: 07 May 2014 15:09
To: users@subversion.apache.org
Subject: Copy the files between the branches witin the same repo and with 
saving the svn info about the operation.

Hi,

I could not find any information neither in the archive nor in the svn book :-(

I'd like to ask you about the copying a file(s) from one repo branch to another 
branch of the repo. Although, seems to be trivial, please read the scenario 
below.

I've been working on the project which has a lot of changes which have to be 
deployed in very short periods of time; daily or sometimes twice a day. I do 
releases directly from the trunk.

Now, I heading the situation in which I have to work on the different software; 
still within the same project, but in different branch. Let call this new 
branch a trunk2.

I realised, that I have to slightly modify a lot of files belongs to trunk 
branch. Instead of doing ordinary copy operation and check in to the new branch 
with comment about its  provenance in the comment field (as I do when I have to 
copy one or two files only) I'd like to copy in the way that the information 
about from where the files were copied we maintain in svn automatically.

Can I do this?

Sumarising,
The present situation:
1. I check out the trunk branch
2. I check out the trunk2 branch
3. I do copy the files I want (under the OS, select and drag over)
4. I update the trunk2 branch with the information about the source of the 
files in the comment window during the update

The demanded situation:
How to do the copy (create a duplicate of the file in the different branch and 
still the same branch) whilst the information about the source of the copy will 
be automatically (not in comments field) maintained by SVN.
It will allow me to do the independent changes in two branches still 
maintaining the history with letting me know which file was derived from which 
file and when.

Cheers,
Kamil

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2014.0.4577 / Virus Database: 3931/7478 - Release Date: 05/11/14

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Extend E155021 message to include supported format version

[Tony Sweeney]

 

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de] 
> Sent: 03 July 2014 16:48
> To: Notes Jonny
> Cc: Branko Čibej; users@subversion.apache.org
> Subject: Re: Extend E155021 message to include supported 
> format version
> 
> On Thu, Jul 03, 2014 at 10:58:35AM +0100, Notes Jonny wrote:
> > I guess the other idea is to promise to only allow ".svn format"
> > updates every 5 years? I can't think that I've noticed any 
> > improvements since I've been using new formats..
> 
> The 1.8 format added support for local move tracking, for instance.
> http://subversion.apache.org/docs/release-notes/1.8.html#moves
> 
> > Do GIT repos suffer these same problems?
> 
> No, they don't. And neither do Subversion repositories (i.e 
> on the the server-side), which are fully backwards compatible.
> SVN working copies correspond more to the "git working tree" 
> rather than the git repository.
> 
> SVN working copies are not backwards compatible (yet) and 
> thus clients sharing working copies need to be updated in 
> lock-step. We know that this is problematic for some users, 
> however for now that's the situation.
> 
> SVNKit-based Subversion clients should be able to use older 
> working copy formats. Most Java-based clinets use SVNKit 
> instead of Subversion (SVNkit is a separate implementation 
> written in Java, see http://svnkit.com/).
> IIRC Jenkins uses SVNKit, so it should be able to work with 
> working copies in older formats.

This is correct.

> 
> __
> This email has been scanned by the Symantec Email 
> Security.cloud service.
> For more information please visit 
> http://www.symanteccloud.com 
> __
> 
> -
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3986/7774 - Release 
> Date: 07/01/14

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

RE: Regading SVN configuration

[Tony Sweeney]

Likely something went wrong with the previous step:

$ sudo svnserve -d --foreground -r /usr/local/svn/repos

That needs to still be running with no errors.


From: sir isac [mailto:sir.i...@gmail.com]
Sent: 18 July 2014 11:47
To: users@subversion.apache.org
Subject: Regading SVN configuration

Hello I am unable to  Authenticate a user from svn://Access via custom protocol 
to an svnserve server.

I am getting this error:

bipul@bipul-X550EA:~$ svn checkout 
svn://127.0.0.1/myproject --username jimmy
svn: E215004: Unable to connect to a repository at URL 
'svn://127.0.0.1/myproject'
svn: E215004: Authentication failed


I have gone through this tutorial.

http://odyniec.net/articles/ubuntu-subversion-server/


Thanking you

Bipul kumar

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7850 - Release Date: 07/14/14

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Usability enhancement to merge from combo to exclude current branch.

[Tony Rietwyk]

Hi, 

I am using TortoiseSVN version 1.8.8, Build 25755 - 64 Bit, with SVN 1.8.10
on Windows 7 64bit. 

It is great that Tortoise remembers the last repo selected in the merge from
combo.  In my use case, I am often moving patches between two major version
branches.  So I go in and merge from A to B.   Later I need to merge from B
to A.   So I click on the folder for A and select merge.   When the dialog
appears, A is selected.  In this case, it would be better to select the most
recent 'from folder' that is not equal to the current one being merged into.
A can still appear in the list, but B gets selected instead. 

I hope I've explained that enough.  

Regards, 

Tony

svnsync problems

[Tony Sweeney]

2.r366873/32681
count: 1
text: 367219 0 50 6336 95f7c627c997b8b4065db2d4cb4db53c 
1f15b1d8cea246d731676f43

b2df4c74a1710793 367218-7wnq/_d
props: 366873 32629 39 0 f2ea0bdf4310dae3aef66de358bcb0e1
cpath: 
/MIME/MADb/trunk/server/src/main/java/com/yoyodyne/madb/query/memory/CachedRowList.java

copyroot: 228442 /MIME/MADb

[root@uk-svn-1-new yoyodyne]#

The working slave looks as follows:

[root@us-svn-1 yoyodyne]# head -30 db/revs/367/367219
DELTA 366873 14907 1619
SVN??@

?=??h?&ng serialVersionUID = 1;
ENDREP
DELTA 366873 16539 1063
SVN?J?7?V?)|???"?Y?? ??private boolean hasMoreResults = 
trueif(results.size() <

requiredResults){

hasMoreResults = false;
}
hasMoreResults;
}
}
ENDREP
id: 1j-366873.0-228442.r367219/295
type: file
pred: 1j-366873.0-228442.r366873/30631
count: 1
text: 367219 81 183 2999 2880cca7c6c56dea580d5c212595846c 
dc0cc36f718b468fc08817

88900f096d5cd4913f 367218-7yyk/_e
props: 366873 30579 39 0 f2ea0bdf4310dae3aef66de358bcb0e1
cpath: 
/MIME/MADb/trunk/server/src/main/java/com/yoyodyne/madb/query/memory/DBServiceQueryThread.java

copyroot: 228442 /MIME/MADb

id: 1h-366873.0-228442.r367219/692
type: file
pred: 1h-366873.0-228442.r366873/32680
count: 1
text: 367219 0 50 6336 95f7c627c997b8b4065db2d4cb4db53c 
1f15b1d8cea246d731676f43

b2df4c74a1710793 367218-7yyk/_d
props: 366873 32628 39 0 f2ea0bdf4310dae3aef66de358bcb0e1
cpath: 
/MIME/MADb/trunk/server/src/main/java/com/yoyodyne/madb/query/memory/Cach

edRowList.java
copyroot: 228442 /MIME/MADb

[root@us-svn-1 yoyodyne]#

But on the failing slave:
[root@uk-svn-2-new yoyodyne]# head -30 db/revs/367/367219
id: 1j-366873.0-228442.r367219/0
type: file
pred: 1j-366873.0-228442.r366873/30632
count: 1
text: 367219 81 183 2999 2880cca7c6c56dea580d5c212595846c 
dc0cc36f718b468fc08817

88900f096d5cd4913f 367218-7wnt/_e
props: 366873 30580 39 0 f2ea0bdf4310dae3aef66de358bcb0e1
cpath: 
/MIME/MADb/trunk/server/src/main/java/com/yoyodyne/madb/query/memory/DBServiceQueryThread.java

copyroot: 228442 /MIME/MADb

id: 1h-366873.0-228442.r367219/395
type: file
pred: 1h-366873.0-228442.r366873/32681
count: 1
text: 367219 0 50 6336 95f7c627c997b8b4065db2d4cb4db53c 
1f15b1d8cea246d731676f43

b2df4c74a1710793 367218-7wnt/_d
props: 366873 32629 39 0 f2ea0bdf4310dae3aef66de358bcb0e1
cpath: 
/MIME/MADb/trunk/server/src/main/java/com/yoyodyne/madb/query/memory/CachedRowList.java

copyroot: 228442 /MIME/MADb

PLAIN
K 19
CSVQueryThread.java
V 37
file 1e-366873.0-228442.r366873/31862
K 18
CachedRowList.java
V 35
file 1h-366873.0-228442.r367219/395
K 25
DBServiceQueryThread.java
V 33
[root@uk-svn-2-new yoyodyne]#

Each time I've tries this the failure mode appears to be the same.  The 
initial 'DELTA <80> ENDREP' sections are missing from the copied 
over file, it starts with the 'id:' line directory.  Is there anything I 
can do to debug this further?


Tony.

Re: svnsync problems

[Tony Sweeney]

On 02/20/15 10:21, Philip Martin wrote:

You are making things very hard for yourself by running 1.6.11, it is
very old and no longer maintained, unless your distribution is
backporting fixes.  A newer version will have fewer bugs and better
performance.


You'll get no disagreement from me on that.  At my last shop we made 
sure to upgrade to the next major version any time the one we were 
running went out of maintenance.




1.6 has a hotcopy bug

   http://subversion.tigris.org/issues/show_bug.cgi?id=3596

the effects are hard to predict but one possibility is corrupt revisions
when committing to the hotcopy.  You could delete the file
db/rep-cache.db from the hotcopy and see if this fixes the problem.  In
1.8 the hotcopy bug is fixed, 1.8 also attempts to detect and avoid
problems caused by a corrupt rep-cache.db.


This was indeed the issue.  We have a cron job that runs every five 
minutes that wries a timestamp into a file and checks it in in order to 
exercise our CI server.  This is pretty much guaranteed to fire at least 
once during the hotcopy, ensuring that the rep cache will be 
inconsistent with the remainder of the hotcopy.  Truncating the hotcopy 
cache on the slave before starting the server allowed the svnsync to 
proceed as expected.


Thank you very, very much for your help,

Tony.



Tony Sweeney  writes:


Hi,

Mise en scene:

We have three Subversion servers, version 1.6.11 running on
CentOS6. One is the live master and and the others are hot standbys in
different datacenters. The intent is that these are kept in sync with
the master using svnsync from a post-commit hook.  One of the slaves
is already set up this way and has been since it was deployed by one
of my predecessors at this company.  This is syncing nicely.  The
other slave instance was also originally set up this way but was then
modified to instead use a block level filesystem mirroring technology,
again by one
of my predecessors.  We have since concluded that the
mirroringsolution was not sufficiently trustworthy, and so we would
like to put it back to the svnsync method that it had run in the past.
The live master has in excess of 366,000 revisions and new revisions
come in at ~500 commits/day.

One solution would be to simply create an empty repo, set the
necessary r0 revprops and hook scripts and sync from scratch.
However, we estimate that this would take 10-15 days due to the size
of the repository, so we would like to short-circuit this by starting
from a hotcopy.  We take hotcopies nightly, save them to a backup
server and 'svnadmin verify' them there.  I am trying to bring this
slave back on sync using the method described here:

http://www.cardinalpath.com/how-to-use-svnsync-to-create-a-mirror-backup-of-your-subversion-repository/

But using a hotcopy rather than a dump.

The master hotcopy is restored in the correct location on the slave
and the hook scripts fixed up using Puppet (master and slave
necessarily have different hook script setups).  Permissions are fixed
up to reflect that the hotcopy is taken as root but the server is
running under Apache.  I set the svn:sync-last-merged-rev revprop on
r0 to reflect the newest revision on the hotcopy.  At this point (or
so I thought) I should be able to replicate over the changes since
last night by running svnsync manually and then enable it in the hook
script.

The problem is that that the revisions seem to be corrupted on
transfer to this slave.

 From the master:

[root@uk-svn-1-new yoyodyne]# /usr/bin/svnsync --non-interactive --trust-server-
cert sync https://uk-svn-2-new.uk.yoyodyne.lan/svn/yoyodyne
--sync-username svnsync --sync-password  --source-username
svnsync --source-password  --config-dir
/repos/svn/yoyodyne/hooks/certs
Transmitting file data ..
Committed revision 367219.
Copied properties for revision 367219.
Transmitting file data .
Committed revision 367220.
Copied properties for revision 367220.
Transmitting file data .
Committed revision 367221.
Copied properties for revision 367221.
Transmitting file data .svnsync: Corrupt representation '367220 0 41 29949930e5
5f203ff7027917e765e6ca7d 2654a46e5fff1f98b747a77ebf600c10c895fbcc367219-7wnu/_6'
You have new mail in /var/spool/mail/root
[root@uk-svn-1-new yoyodyne]#

In fact, checking on the slave, they have all come across corrupt:

[root@uk-svn-2-new svn]# svnadmin verify -r 367200:HEAD /repos/svn/yoyodyne
* Verified revision 367200.
* Verified revision 367201.
* Verified revision 367202.
* Verified revision 367203.
* Verified revision 367204.
* Verified revision 367205.
* Verified revision 367206.
* Verified revision 367207.
* Verified revision 367208.
* Verified revision 367209.
* Verified revision 367210.
* Verified revision 367211.
* Verified revision 367212.
* Verified revision 367213.
* Verified revision 367214.
* Verified revision 367215.
* Verified revision 367216.
* Verified revision 367217.
* Verified revision 367218.
svnadmin: Corrupt re