Re: svndumpfilter woes

2014-02-07 Thread Ian Wiles
Hi Markus,

Thanks. I ran verify and everything passed. which is good, so I assume it's 
recoverable somehow. I'm going to try a fresh dump and see if that helps. 
For now I've loaded the last few revisions which is enough for me to be 
getting on with until I figure out how to stop svndumpfilter ignoring me.

Cheers,
Ian

On Friday, February 7, 2014 8:06:49 PM UTC+13, Markus Schaber wrote:
>
> Hi, Ian, 
>
> I think that you should try to check / consider two scenarios: 
>
> - Repository corruption: Maybe the existing repository contains 
>   Inconsistent data for some reason. You should try to check 
>   "svnadmin verify" on the repository, this will find most 
>   kinds of corruption. 
>
> - Hardware failure: The data reading from the harddisk or your 
>   RAM may be broken, and occasionally flip some bits. This may 
>   be the case on the existing server, as well as on the 
>   destination machine. 
>
>
>
>
> Best regards 
>
> Markus Schaber 
>
> CODESYS® a trademark of 3S-Smart Software Solutions GmbH 
>
> Inspiring Automation Solutions 
>  
> 3S-Smart Software Solutions GmbH 
> Dipl.-Inf. Markus Schaber | Product Development Core Technology 
> Memminger Str. 151 | 87439 Kempten | Germany 
> Tel. +49-831-54031-979 | Fax +49-831-54031-50 
>
> E-Mail: m.sc...@codesys.com  | Web: codesys.com | CODESYS 
> store: store.codesys.com 
> CODESYS forum: forum.codesys.com 
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | 
> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 
> Von: Ian Wiles [mailto:ian.alexa...@googlemail.com ] 
> Gesendet: Freitag, 7. Februar 2014 06:29 
> An: subversi...@googlegroups.com  
> Cc: us...@subversion.apache.org ; 
> tscho...@am-soft.de 
> Betreff: Re: svndumpfilter woes 
>
>
>
> On Thursday, February 6, 2014 10:42:24 PM UTC+13, Thorsten Schöning wrote: 
> Guten Tag Ian Wiles, 
> am Donnerstag, 6. Februar 2014 um 09:39 schrieben Sie: 
>
> > It's a problem since trying to load the dump in the new 
> > repo is failing on some binary files so I can't load the repo at 
> > all. 
>
> If that's the only reason you want to get rid of the files in your 
> dump, you may provide the error message and fix this error because SVN 
> should be able to load even large binaries. 
>
> > svndumpfilter exclude --pattern "*.ncb" < orignal_dmp.fil > 
> filtered_dmp.fil 
>
> May this get translated to /*.ncb only and therefore doesn't get 
> applied recursively? Maybe you need something like **/*.ncb. 
>
> 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 
>
> Hi Thorsten , thanks for the response. 
>
> My main concern at the moment is just loading the dump file and the errors 
> are preventing that. It would be good to filter out the binaries, but its 
> not a priority just now. 
> The error I get is a hash checksum failure, and only on binary files: 
>
>  * editing path : MyFile.ncb ...svnadmin: E200014: Checksum mismatch 
> for '/MyFile.ncb': 
>expected:  ab27603550fc52585bd6e98c6d7d0b6c 
>  actual:  f52642a0cc3186a7da837569fcde32a1 
>
>
> A re-dump didn't seem to help much. In fact I split up the dumps by 
> revision in a bid to fix the problem, but then I got a failure earlier in 
> the repository around revision 2xx. In fact whatever dump file I take seems 
> to fail to load at some point due to a binary file checksum mismatch, which 
> is pretty frustrating. 
>
> Cheers, 
> Ian 
>


Re: Re: define files structure in svn (CAD PDM)

2014-02-07 Thread Roberto Bartola
Lorenz Wrote:

>

>Roberto Bartola wrote:
>
>>Hi all,
>>I'm trying to use svn as a PDM for CAD files.
>>
>>( http://en.wikipedia.org/wiki/Product_data_management )
>>
>>It looks working fine but I'd like to do better.
>>
>>-1 structure
>>In my CAD I can create an assembly which is a file where I assembly many
>>parts or subassemblies.
>>Is it possible to create a structure (it could be a txt file) where svn
>>reads the parts which belongs to the assembly, so to commit, update, lock
>> the files linked to the "father"?
>>[...]
>
>>-2 folders
>>To keep ordered my repository I'd like to keep a folders structure (for
>>example steel-parts; plastic-parts; rubber-parts ) but when inporting
>>the project I'd like to keep the files all in a single level.
>>Is it possible?
>[...]
>
>have a look at file externals
>--
>
>Lorenz

Thank you Lorenz for reply.
Searching in internet I had found externals but I was not able to manage it
for my purposes.
Could you please make me an example on how to design it?

Thank you

-- 
-
Hello world !
Roberto was here !


'assertion failed' while updating

2014-02-07 Thread hbogaards
Hello All,

I ran into an subversion exception, while updating my working copy.

I was in the process of re-arranging the project structure, while a
colleague was developing new features.
So I had moved (svn move) a lot of directories and files.

I am running Windows 7, 64bit with TortoiseSVN 1.8.4 64bit
SVN Server is version 1.6.13 (not under my control).

The dialog shows:
---
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.4\ext\subversion\subversion\libsvn_wc\wc_db_update_move.c'
 line 809: assertion failed (move_dst_revision == expected_move_dst_revision
||
 status == svn_wc__db_status_not_present)
---
OK   
---




--
View this message in context: 
http://subversion.1072662.n5.nabble.com/assertion-failed-while-updating-tp186984.html
Sent from the Subversion Users mailing list archive at Nabble.com.


"tunnel-user" on apache2 dav vvn

2014-02-07 Thread Axel Kittenberger
Hello,

do you know of a way to set a "tunnel user" using apache2 dav svn similar
to --tunnel-user when accessing via ssh?

That is using one common user to write on the file system but having
another username appear in the svn logs?

I want the username authenticated via apache2 using pwauth to appear in svn
logs, but I cannot reasonly change the physical userid of apache2 on the
fly.

Kind regards, Axel


"tunnel-user" on Apache2 Dav Svn

2014-02-07 Thread Axel Kittenberger
Hello!

Do you know of a way to set a "tunnel user" using apache2 dav svn similar
to --tunnel-user when accessing via ssh?

That is using one common user to write on the file system but having
another username appear in the svn logs?

I want the username authenticated via apache2 using pwauth to appear in svn
logs, but I cannot reasonly change the physical userid of apache2 on the
fly.

Kind regards, Axel


Re: "tunnel-user" on apache2 dav vvn

2014-02-07 Thread Mark Phippard
On Fri, Feb 7, 2014 at 6:17 AM, Axel Kittenberger  wrote:

> Hello,
>
> do you know of a way to set a "tunnel user" using apache2 dav svn similar
> to --tunnel-user when accessing via ssh?
>
> That is using one common user to write on the file system but having
> another username appear in the svn logs?
>
> I want the username authenticated via apache2 using pwauth to appear in
> svn logs, but I cannot reasonly change the physical userid of apache2 on
> the fly.
>
>

Apache already works the way you describe.  You do not need a tunnel user,
and one is not supported anyway.

httpd runs as a user, and all OS level read/write is by that user.  It
needs to have permissions to the repository files on disks.  Apache
authenticates users however you have configured it, and the svn:author is
set based on the authenticated user.


-- 
Thanks

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


RE: svndumpfilter woes

2014-02-07 Thread Bob Archer
Are you streaming to disk, then loading from disk? You might want to just 
directly pump the dump stream into the load. Just an idea.

From: Ian Wiles [mailto:ian.alexander.wi...@googlemail.com]
Sent: Friday, February 07, 2014 3:04 AM
To: subversion_us...@googlegroups.com
Cc: Ian Wiles; users@subversion.apache.org; m.scha...@codesys.com
Subject: Re: svndumpfilter woes

Hi Markus,

Thanks. I ran verify and everything passed. which is good, so I assume it's 
recoverable somehow. I'm going to try a fresh dump and see if that helps. For 
now I've loaded the last few revisions which is enough for me to be getting on 
with until I figure out how to stop svndumpfilter ignoring me.

Cheers,
Ian

On Friday, February 7, 2014 8:06:49 PM UTC+13, Markus Schaber wrote:
Hi, Ian,

I think that you should try to check / consider two scenarios:

- Repository corruption: Maybe the existing repository contains
  Inconsistent data for some reason. You should try to check
  "svnadmin verify" on the repository, this will find most
  kinds of corruption.

- Hardware failure: The data reading from the harddisk or your
  RAM may be broken, and occasionally flip some bits. This may
  be the case on the existing server, as well as on the
  destination machine.




Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.sc...@codesys.com | Web: codesys.com 
| CODESYS store: store.codesys.com
CODESYS forum: forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Von: Ian Wiles [mailto:ian.alexa...@googlemail.com]
Gesendet: Freitag, 7. Februar 2014 06:29
An: subversi...@googlegroups.com
Cc: us...@subversion.apache.org; tscho...@am-soft.de
Betreff: Re: svndumpfilter woes



On Thursday, February 6, 2014 10:42:24 PM UTC+13, Thorsten Schöning wrote:
Guten Tag Ian Wiles,
am Donnerstag, 6. Februar 2014 um 09:39 schrieben Sie:

> It's a problem since trying to load the dump in the new
> repo is failing on some binary files so I can't load the repo at
> all.

If that's the only reason you want to get rid of the files in your
dump, you may provide the error message and fix this error because SVN
should be able to load even large binaries.

> svndumpfilter exclude --pattern "*.ncb" < orignal_dmp.fil > filtered_dmp.fil

May this get translated to /*.ncb only and therefore doesn't get
applied recursively? Maybe you need something like **/*.ncb.

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

Hi Thorsten , thanks for the response.

My main concern at the moment is just loading the dump file and the errors are 
preventing that. It would be good to filter out the binaries, but its not a 
priority just now.
The error I get is a hash checksum failure, and only on binary files:

 * editing path : MyFile.ncb ...svnadmin: E200014: Checksum mismatch for 
'/MyFile.ncb':
   expected:  ab27603550fc52585bd6e98c6d7d0b6c
 actual:  f52642a0cc3186a7da837569fcde32a1


A re-dump didn't seem to help much. In fact I split up the dumps by revision in 
a bid to fix the problem, but then I got a failure earlier in the repository 
around revision 2xx. In fact whatever dump file I take seems to fail to load at 
some point due to a binary file checksum mismatch, which is pretty frustrating.

Cheers,
Ian


Re: "tunnel-user" on apache2 dav vvn

2014-02-07 Thread Axel Kittenberger
Thank you for that information ;-)
Kind regards, Axel


Re: Redirect Triggered Relocate for Non-Root Checkout

2014-02-07 Thread Ben Reser
On 2/7/14, 8:27 AM, Shane Anderson wrote:
> So, I ask: Why can't the svn update figure this out?  The redirect has the 
> root
> URL in it, with '/trunk' added, and knows the working copies old root URL, so
> couldn't it just remove the '/trunk' from the redirected/new URL and still do
> the relocate (just as if it had done the command above?)

Already slated to be in 1.8.6:
* fix automatic relocate for wcs not at repository root (r1541638 et al)



Redirect Triggered Relocate for Non-Root Checkout

2014-02-07 Thread Shane Anderson
I apologize if this has been reported before, or if it's in the wrong 
place, but I was wondering if this issue is considered a bug:


I've recent moved a bunch of SVN repositories from one server to 
another, with some additional URL path changes.  I've set up permanent 
redirects from the old to the new, which does well for general HTTP(S) 
access/browsing.


My hope was that when I update a working copy, the redirect would 
perform the relocate automatically, or at least help the user do so 
(with a prompt.)  This actually does appear to work well if the working 
copy was checked out from the root of the repository.


My problem is that (per convention) I have the trunk/tags/branches at 
the root and usually checkout the /trunk, so most of my working areas 
are not checked out at the root.  So, for an 'svn update' I get:



c:\svn>svn --version
svn, version 1.8.5 (r1542147)
   compiled Nov 24 2013, 13:00:38 on x86-microsoft-windows

c:\svn>svn update dfis
Updating 'dfis':
Redirecting to URL 'https://new.server.com/svn/public/dfis/trunk':
svn: E155024: Invalid relocation destination: 
'https://new.server.com/svn/public/dfis' (does not point to target)



But I can simply do this (keep in mind c:\svn\dfis is the /trunk)


c:\svn\dfis>svn relocate https://old.koronisbiotech.com/public/svn/dfis 
https://new.server.com/svn/public/dfis



and things work just fine.

So, I ask: Why can't the svn update figure this out?  The redirect has 
the root URL in it, with '/trunk' added, and knows the working copies 
old root URL, so couldn't it just remove the '/trunk' from the 
redirected/new URL and still do the relocate (just as if it had done the 
command above?)


This seems to me like an easy/straightforward modification and would 
save me (and many others) lots of time.   Personally, I can write a 
script to do this using the output of 'svn info' and my knowledge of 
what I've moved, but I can't easily get everyone able to run these sorts 
of scripts.  Having the a non-root checkout redirect relocate the root 
seems ideal to me--it follows the users standard flow and they can be 
(almost) none-the-wiser.


Cheers!

-Shane


svn upgrade fails with failed assertion

2014-02-07 Thread dclist
I'm trying to upgrade a very old svn repo but the command is failing.

% svn upgrade .
svn:
/build/buildd/subversion-1.7.5/subversion/libsvn_subr/dirent_uri.c:1518:
uri_skip_ancestor: Assertion `svn_uri_is_canonical(parent_uri, ((void
*)0))' failed.
[1]3298 abort  svn upgrade .


Can anyone tell me what I'm doing wrong?


Re: svn upgrade fails with failed assertion

2014-02-07 Thread Philip Martin
dclist  writes:

> I'm trying to upgrade a very old svn repo but the command is failing.

"working copy" rather than "repo".

>
> % svn upgrade .
> svn:
> /build/buildd/subversion-1.7.5/subversion/libsvn_subr/dirent_uri.c:1518:
> uri_skip_ancestor: Assertion `svn_uri_is_canonical(parent_uri, ((void
> *)0))' failed.
> [1]3298 abort  svn upgrade .
>
>
> Can anyone tell me what I'm doing wrong?

1.7.5 is old, a couple of fixes in more recent 1.7.x may be relevant:

 User-visible changes:
  - Client- and server-side bugfixes:
* fix assertion on urls of the form 'file://./' (r1516806)

  - Client-side bugfixes:
* upgrade: fix an assertion when used with pre-1.3 wcs (r1530849)


-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*


RE: svn upgrade fails with failed assertion

2014-02-07 Thread Bob Archer
> I'm trying to upgrade a very old svn repo but the command is failing.
> 
> % svn upgrade .
> svn: /build/buildd/subversion-
> 1.7.5/subversion/libsvn_subr/dirent_uri.c:1518: uri_skip_ancestor: Assertion
> `svn_uri_is_canonical(parent_uri, ((void *)0))' failed.
> [1]    3298 abort      svn upgrade .
> 
> 
> Can anyone tell me what I'm doing wrong?

I don't know, but 1.7 is up to 1.7.14... 1.7.5 is pretty old.

Also, have you tried to dump and load?



Multiple SVN repos with single server?

2014-02-07 Thread Tom Malia
I've been using Apache to proide HTTP access to several different SVN
repository directories on a single server for about 10 years.

I'm moving everything to a new server and I was considering using SVNSERVE
in place of or in addition to Apache for access to the repositories.

 

Is it possible to server multiple SVN repositories.. Where I mean completely
different SVN directories. not separate folders within a single SVN repo.
using SVNSERVE on a single server?  If so, how?

 

Also, is there any issue with running both SVNSERVE and Apache to provide
both SVN protocol and HTTP protocol access to the same SVN repos at the same
time?

 

Thanks in advance,

Tom



Re: Multiple SVN repos with single server?

2014-02-07 Thread Ben Reser
On 2/7/14, 11:57 AM, Tom Malia wrote:
> Is it possible to server multiple SVN repositories…. Where I mean completely
> different SVN directories… not separate folders within a single SVN repo… 
> using
> SVNSERVE on a single server?  If so, how?

svnserve -d -r /var/svn

Where each folder in /var/svn is a separate repository.  Then you access each
repo with: svn://svn.example.com/reponame where reponame is the name of the
folder for the repo in /var/svn.

For that matter you could do something (very silly) like -r / and then everyone
would have to know the path on your server to reach the repo e.g.
svn://svn.example.com/var/svn

You can create nested structures this way as well.  However, on important bit
to remember is for authz svnserve uses the full path under the root for the
reponame (including the slash) whereas mod_dav_svn uses only the directory the
repo is in.  That's because mod_dav_svn doesn't support arbitrary structures
like svnserve does.



Re: Multiple SVN repos with single server?

2014-02-07 Thread Mauricio Tavares
On Fri, Feb 7, 2014 at 2:57 PM, Tom Malia  wrote:
> I've been using Apache to proide HTTP access to several different SVN
> repository directories on a single server for about 10 years.
>
> I'm moving everything to a new server and I was considering using SVNSERVE
> in place of or in addition to Apache for access to the repositories.
>
> Is it possible to server multiple SVN repositories Where I mean completely
> different SVN directories... not separate folders within a single SVN repo...
> using SVNSERVE on a single server?  If so, how?
>
  That is what we do here, but they are completely (configs,
directories, access, users) independent from each other. Database
included, but then again we are lazy and used sqlite. ;)

>
>
> Also, is there any issue with running both SVNSERVE and Apache to provide
> both SVN protocol and HTTP protocol access to the same SVN repos at the same
> time?
>
>
>
> Thanks in advance,
>
> Tom


RE: Multiple SVN repos with single server?

2014-02-07 Thread Bob Archer
> I've been using Apache to proide HTTP access to several different SVN
> repository directories on a single server for about 10 years.
> I'm moving everything to a new server and I was considering using SVNSERVE
> in place of or in addition to Apache for access to the repositories.

Sure... but I would question why you would want to do this. You are just making 
more work for yourself and I don't see any advantage to providing both 
protocols. 

If you are looking for simpler management/upgrades I highly recommend 
Subversion Edge. It's free and make things simple to setup and manage.


> 
> Is it possible to server multiple SVN repositories.. Where I mean completely
> different SVN directories. not separate folders within a single SVN repo.
> using SVNSERVE on a single server?  If so, how?
> 
> Also, is there any issue with running both SVNSERVE and Apache to provide
> both SVN protocol and HTTP protocol access to the same SVN repos at the
> same time?
> 
> Thanks in advance,
> Tom


RE: Multiple SVN repos with single server?

2014-02-07 Thread Tom Malia
Thanks,  it's sssooo obvious now!


-Original Message-
From: Ben Reser [mailto:b...@reser.org] 
Sent: Friday, February 07, 2014 3:04 PM
To: Tom Malia; users@subversion.apache.org
Subject: Re: Multiple SVN repos with single server?

On 2/7/14, 11:57 AM, Tom Malia wrote:
> Is it possible to server multiple SVN repositories.. Where I mean 
> completely different SVN directories. not separate folders within a 
> single SVN repo. using SVNSERVE on a single server?  If so, how?

svnserve -d -r /var/svn

Where each folder in /var/svn is a separate repository.  Then you access
each repo with: svn://svn.example.com/reponame where reponame is the name of
the folder for the repo in /var/svn.

For that matter you could do something (very silly) like -r / and then
everyone would have to know the path on your server to reach the repo e.g.
svn://svn.example.com/var/svn

You can create nested structures this way as well.  However, on important
bit to remember is for authz svnserve uses the full path under the root for
the reponame (including the slash) whereas mod_dav_svn uses only the
directory the repo is in.  That's because mod_dav_svn doesn't support
arbitrary structures like svnserve does.



RE: Multiple SVN repos with single server?

2014-02-07 Thread Tom Malia
I'm the first to admit I'm no expert... so I would not be surprised or
offended to find I was asking for something really stupic.

My logic for supporting both protocols is, my understanding is that SVN
protocol can be substantially faster and I was planning to use this both as
the preferred protocol for dedicated SVN Clients and for maintenance
processes like SVNSYNC and SVNRDUMP.  While, having access to the repos via
HTTP give me more universal access for myself and my clients when we just
need to read files potentially from locations that don't have any SVN client
installed and/or which are blocking access to locations through anything
other than HTTP protocols.

When I looked at Subversion edge and played with it a little it looked
really easy for setting up a completely new subversion server environment
with new repositories.  It wasn't immediately obvious to me how I
would/could "attach" edge to existing repositories.  I didn't really like
installing a completely separate Subversion, Apache stack when I already
have an apache and tomcat server running and figured I could just use what I
had already.

Again my lack of experience and knowledge here are probably painfully
obvious to everyone but me on these subjects ignorance is NOT always
bliss.


-Original Message-
From: Bob Archer [mailto:bob.arc...@amsi.com] 
Sent: Friday, February 07, 2014 3:11 PM
To: Tom Malia; users@subversion.apache.org
Subject: RE: Multiple SVN repos with single server?

> I've been using Apache to proide HTTP access to several different SVN 
> repository directories on a single server for about 10 years.
> I'm moving everything to a new server and I was considering using 
> SVNSERVE in place of or in addition to Apache for access to the
repositories.

Sure... but I would question why you would want to do this. You are just
making more work for yourself and I don't see any advantage to providing
both protocols. 

If you are looking for simpler management/upgrades I highly recommend
Subversion Edge. It's free and make things simple to setup and manage.


> 
> Is it possible to server multiple SVN repositories.. Where I mean 
> completely different SVN directories. not separate folders within a single
SVN repo.
> using SVNSERVE on a single server?  If so, how?
> 
> Also, is there any issue with running both SVNSERVE and Apache to 
> provide both SVN protocol and HTTP protocol access to the same SVN 
> repos at the same time?
> 
> Thanks in advance,
> Tom



RE: Multiple SVN repos with single server?

2014-02-07 Thread Bob Archer
We switched from svn:// to http:// and didn't see any pref difference. Then 
again, I didn't benchmark it.  That said, we don't do any path based 
authorization and that may be the difference.

I prefer edge mostly for the inclusion of the management console, the WebView, 
and the push button updates. But to each his own.

Yes, it is entirely possible to just point Edge to existing repos and have it 
server them. 

That said, the answer to your question is yes, you can have mod_dav_svn and 
svnserver both serving the same repos. For svnserve to serve multiple, afaik, 
they need to all be rooted at the same location and you use the -d switch to 
specify that root location.

> -Original Message-
> From: Tom Malia [mailto:tomma...@ttdsinc.com]
> Sent: Friday, February 07, 2014 4:18 PM
> To: Bob Archer; users@subversion.apache.org
> Subject: RE: Multiple SVN repos with single server?
> 
> I'm the first to admit I'm no expert... so I would not be surprised or 
> offended
> to find I was asking for something really stupic.
> 
> My logic for supporting both protocols is, my understanding is that SVN
> protocol can be substantially faster and I was planning to use this both as 
> the
> preferred protocol for dedicated SVN Clients and for maintenance processes
> like SVNSYNC and SVNRDUMP.  While, having access to the repos via HTTP
> give me more universal access for myself and my clients when we just need
> to read files potentially from locations that don't have any SVN client 
> installed
> and/or which are blocking access to locations through anything other than
> HTTP protocols.
> 
> When I looked at Subversion edge and played with it a little it looked really
> easy for setting up a completely new subversion server environment with
> new repositories.  It wasn't immediately obvious to me how I would/could
> "attach" edge to existing repositories.  I didn't really like installing a
> completely separate Subversion, Apache stack when I already have an
> apache and tomcat server running and figured I could just use what I had
> already.
> 
> Again my lack of experience and knowledge here are probably painfully
> obvious to everyone but me on these subjects ignorance is NOT always
> bliss.
> 
> 
> -Original Message-
> From: Bob Archer [mailto:bob.arc...@amsi.com]
> Sent: Friday, February 07, 2014 3:11 PM
> To: Tom Malia; users@subversion.apache.org
> Subject: RE: Multiple SVN repos with single server?
> 
> > I've been using Apache to proide HTTP access to several different SVN
> > repository directories on a single server for about 10 years.
> > I'm moving everything to a new server and I was considering using
> > SVNSERVE in place of or in addition to Apache for access to the
> repositories.
> 
> Sure... but I would question why you would want to do this. You are just
> making more work for yourself and I don't see any advantage to providing
> both protocols.
> 
> If you are looking for simpler management/upgrades I highly recommend
> Subversion Edge. It's free and make things simple to setup and manage.
> 
> 
> >
> > Is it possible to server multiple SVN repositories.. Where I mean
> > completely different SVN directories. not separate folders within a
> > single
> SVN repo.
> > using SVNSERVE on a single server?  If so, how?
> >
> > Also, is there any issue with running both SVNSERVE and Apache to
> > provide both SVN protocol and HTTP protocol access to the same SVN
> > repos at the same time?
> >
> > Thanks in advance,
> > Tom



Showing unmerged revisions within a range

2014-02-07 Thread Kyle Sluder
I created a branch (4.0.x) from trunk. Work progressed on trunk and was
selectively merged down to the 4.0.x branch.

The intent was to do our next release off this branch and then kill it.
Subsequent releases would come from the trunk (or branches thereof).

Unfortunately plans changed, and we needed to clone the 4.0.x branch to
produce a 4.0.2 branch. Subsequent changes were made on the trunk and
merged individually to each branch.

We've since released 4.0.2, and so I want to kill the 4.0.2 branch.
Before doing that, I want to ensure that all changes which were merged
from the trunk to the 4.0.2 branch also made it to the 4.0.x branch.

I tried the following:

% svn log --stop-on-copy ${Repository Root}/branches/4.0.2
[ ...snip... ]

r202859 | kyle | 2014-01-29 11:50:48 -0800 (Wed, 29 Jan 2014) | 2 lines

% svn info
Path: .
URL: ${Repository Root}/branches/4.0.x

% svn mergeinfo -r202859:HEAD --show-revs=eligible $Repository
Root}/branches/4.0.2 .
svn: E195008: Revision range is not allowed


Why does mergeinfo say "revision range is not allowed" when "svn help
mergeinfo" lists --revision under "Valid options"?

Is there another way to do what I want?

--Kyle Sluder


RE: Showing unmerged revisions within a range

2014-02-07 Thread Bob Archer
> I created a branch (4.0.x) from trunk. Work progressed on trunk and was
> selectively merged down to the 4.0.x branch.
> 
> The intent was to do our next release off this branch and then kill it.
> Subsequent releases would come from the trunk (or branches thereof).
> 
> Unfortunately plans changed, and we needed to clone the 4.0.x branch to
> produce a 4.0.2 branch. Subsequent changes were made on the trunk and
> merged individually to each branch.
> 
> We've since released 4.0.2, and so I want to kill the 4.0.2 branch.
> Before doing that, I want to ensure that all changes which were merged from
> the trunk to the 4.0.2 branch also made it to the 4.0.x branch.
> 
> I tried the following:
> 
> % svn log --stop-on-copy ${Repository Root}/branches/4.0.2 [ ...snip... ]
> 
> r202859 | kyle | 2014-01-29 11:50:48 -0800 (Wed, 29 Jan 2014) | 2 lines
> 
> % svn info
> Path: .
> URL: ${Repository Root}/branches/4.0.x
> 
> % svn mergeinfo -r202859:HEAD --show-revs=eligible $Repository
> Root}/branches/4.0.2 .
> svn: E195008: Revision range is not allowed
> 
> 
> Why does mergeinfo say "revision range is not allowed" when "svn help
> mergeinfo" lists --revision under "Valid options"?

The help says:

(some commands also take ARG1:ARG2 range)

Did you not get what you wanted without specifying a range?

Hmm... I just tried it and didn't get that error:

svn mergeinfo -r6000:HEAD --show-revs eligible 
http://myserver/svn/manage/MyAppRootName/v7.5.4
r60148
r60155
r60156
r60157
r60158

I'm using 1.8.4.

BOb



Re: Showing unmerged revisions within a range

2014-02-07 Thread Kyle Sluder
On Fri, Feb 7, 2014, at 03:37 PM, Bob Archer wrote:
> The help says:
> 
> (some commands also take ARG1:ARG2 range)
> 
> Did you not get what you wanted without specifying a range?

Hmm, that looks promising:

% svn mergeinfo --show-revs=eligible -r202859 ${Repository
Root}/branches/4.0.2
r202880
r202890
[ ... snip ... ]


And if I replace the "…branches/4.0.2" with "…trunk", I can see all the
revisions that haven't been merged from trunk yet.


> I'm using 1.8.4.

Ah, relevant information I should have included: I'm using svn 1.7.10
(the version bundled with the latest stable release of Xcode).


Thanks for the assistance,
--Kyle Sluder


Re: Showing unmerged revisions within a range

2014-02-07 Thread Kyle Sluder
On Fri, Feb 7, 2014, at 04:18 PM, Kyle Sluder wrote:
> And if I replace the "…branches/4.0.2" with "…trunk", I can see all the
> revisions that haven't been merged from trunk yet.

Hmm, I spoke too soon:

% svn mergeinfo --show-revs=eligible -r202859 ${Repository Root}/trunk
r200832
r200833
r200836
r200837
[ ... snip ...]

Notice that -r200832 is much earlier than the r202859 argument which was
passed on the command line.

My wild guess is that r200832 was merged to trunk sometime after
r202859? I don't know. Searching the commit log history turns up no such
results.

--Kyle Sluder


Re: svndumpfilter woes

2014-02-07 Thread Ian Wiles

Hi Bob,

I'm dumping then loading, the reason is I'm moving from one PC to another. 
I could load over the network, but the dump file is nearly 40GB.

Cheers,
Ian

On Saturday, February 8, 2014 3:37:58 AM UTC+13, Bob Archer wrote:
>
>  Are you streaming to disk, then loading from disk? You might want to 
> just directly pump the dump stream into the load. Just an idea.
>
>  
>   
> *From:* Ian Wiles [mailto:ian.alexa...@googlemail.com ] 
> *Sent:* Friday, February 07, 2014 3:04 AM
> *To:* subversi...@googlegroups.com 
> *Cc:* Ian Wiles; us...@subversion.apache.org ; 
> m.sc...@codesys.com 
> *Subject:* Re: svndumpfilter woes
>  
>  
>  
> Hi Markus,
>  
>  
>  
> Thanks. I ran verify and everything passed. which is good, so I assume 
> it's recoverable somehow. I'm going to try a fresh dump and see if that 
> helps. For now I've loaded the last few revisions which is enough for me to 
> be getting on with until I figure out how to stop svndumpfilter ignoring me.
>  
>  
>  
> Cheers,
>  
> Ian
>
> On Friday, February 7, 2014 8:06:49 PM UTC+13, Markus Schaber wrote:
>
> Hi, Ian, 
>
> I think that you should try to check / consider two scenarios: 
>
> - Repository corruption: Maybe the existing repository contains 
>   Inconsistent data for some reason. You should try to check 
>   "svnadmin verify" on the repository, this will find most 
>   kinds of corruption. 
>
> - Hardware failure: The data reading from the harddisk or your 
>   RAM may be broken, and occasionally flip some bits. This may 
>   be the case on the existing server, as well as on the 
>   destination machine. 
>
>
>
>
> Best regards 
>
> Markus Schaber 
>
> CODESYS® a trademark of 3S-Smart Software Solutions GmbH 
>
> Inspiring Automation Solutions 
>  
> 3S-Smart Software Solutions GmbH 
> Dipl.-Inf. Markus Schaber | Product Development Core Technology 
> Memminger Str. 151 | 87439 Kempten | Germany 
> Tel. +49-831-54031-979 | Fax +49-831-54031-50 
>
> E-Mail: m.sc...@codesys.com | Web: codesys.com | CODESYS store: 
> store.codesys.com 
> CODESYS forum: forum.codesys.com 
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | 
> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 
> Von: Ian Wiles [mailto:ian.alexa...@googlemail.com] 
> Gesendet: Freitag, 7. Februar 2014 06:29 
> An: subversi...@googlegroups.com 
> Cc: us...@subversion.apache.org; tscho...@am-soft.de 
> Betreff: Re: svndumpfilter woes 
>
>
>
> On Thursday, February 6, 2014 10:42:24 PM UTC+13, Thorsten Schöning wrote: 
> Guten Tag Ian Wiles, 
> am Donnerstag, 6. Februar 2014 um 09:39 schrieben Sie: 
>
> > It's a problem since trying to load the dump in the new 
> > repo is failing on some binary files so I can't load the repo at 
> > all. 
>
> If that's the only reason you want to get rid of the files in your 
> dump, you may provide the error message and fix this error because SVN 
> should be able to load even large binaries. 
>
> > svndumpfilter exclude --pattern "*.ncb" < orignal_dmp.fil > 
> filtered_dmp.fil 
>
> May this get translated to /*.ncb only and therefore doesn't get 
> applied recursively? Maybe you need something like **/*.ncb. 
>
> 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 
>
> Hi Thorsten , thanks for the response. 
>
> My main concern at the moment is just loading the dump file and the errors 
> are preventing that. It would be good to filter out the binaries, but its 
> not a priority just now. 
> The error I get is a hash checksum failure, and only on binary files: 
>
>  * editing path : MyFile.ncb ...svnadmin: E200014: Checksum mismatch 
> for '/MyFile.ncb': 
>expected:  ab27603550fc52585bd6e98c6d7d0b6c 
>  actual:  f52642a0cc3186a7da837569fcde32a1 
>
>
> A re-dump didn't seem to help much. In fact I split up the dumps by 
> revision in a bid to fix the problem, but then I got a failure earlier in 
> the repository around revision 2xx. In fact whatever dump file I take seems 
> to fail to load at some point due to a binary file checksum mismatch, which 
> is pretty frustrating. 
>
> Cheers, 
> Ian 
>


Re: Multiple SVN repos with single server?

2014-02-07 Thread Ben Reser
On 2/7/14, 1:28 PM, Bob Archer wrote:
> We switched from svn:// to http:// and didn't see any pref difference. Then 
> again, I didn't benchmark it.  That said, we don't do any path based 
> authorization and that may be the difference.

svnserve will be faster if you're committing a lot of files.  DAV splits your
commit up into multiple PUTs and then has to wait for the server to say that
each PUT has succeeded before continuing.  The svnserve protocol once it goes
into an edit drive just streams the changes to the server and the server only
responds if there's an error or the edit drive is finished.  Neither of these
protocols can use parallelism with sending commits at current since the
filesystem backend can't handle it.  But once we resolve this DAV should be
able to support this which will help lower this cost since multiple round trips
can be made at the same time.

DAV with more recent versions of Subversion on the client and server side may
be faster than svnserve due to skelta mode on checkout, update, switch and
diff.  In the past DAV would send a report which included the structure and
content of the files.  With skelta mode DAV will send the structure (and
possibly properties) but leave the content to separate GET requests.  The
Subversion client can make multiple GET requests at the same time, resulting in
parallel downloads.  If the server can't saturate your network this may result
in faster downloads.  Additionally, if you're far away from the server these
GET requests can be cached unlike the REPORT requests which really could not
be.  The svn protocol is still sending file content as a single stream and
can't parallelize the downloads nor is there any sort of caching capability.
There's more info on skelta mode in the 1.8 release notes:
https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default

Depending on your network environment your mileage may vary.  If you really
want to know what's faster then you'll need to try it.  If you're very close to
the server (thus having low latency) you may not notice much difference at all.

As Bob has already said there really is nothing stopping you from running both.
 However, there is one big reason that nobody has mentioned.  If you want to
get great performance out of the server and you don't have trivial small
repositories you should be configuring the memory cache.  httpd and svnserve
can share a cache if you use memcache, but I believe you'll have better luck if
you just use a per process memory cache that can't be shared between servers.
You can find some details on this from the 1.7 release notes:
https://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning

One major piece of advice is if you are running httpd, use a threaded MPM
(worker or event) as opposed to the prefork MPM.  The threaded MPMs will use
fewer processes and thus you'll be able to configure a larger cache and since
all threads under the same process can share that cache you'll have higher hit
rates.



Re: Showing unmerged revisions within a range

2014-02-07 Thread Ben Reser
On 2/7/14, 4:28 PM, Kyle Sluder wrote:
> % svn mergeinfo --show-revs=eligible -r202859 ${Repository Root}/trunk
> r200832
> r200833
> r200836
> r200837
> [ ... snip ...]
> 
> Notice that -r200832 is much earlier than the r202859 argument which was
> passed on the command line.
> 
> My wild guess is that r200832 was merged to trunk sometime after
> r202859? I don't know. Searching the commit log history turns up no such
> results.

Unfortunately the -r option on mergeinfo in 1.7 doesn't do anything.
http://subversion.tigris.org/issues/show_bug.cgi?id=4199

This is fixed in 1.8.0 and newer.  I'd suggest installing a build of 1.8.5:
https://subversion.apache.org/packages.html#osx

Also be careful mergeinfo needs a source and a target.  You're only providing a
single argument there which will be treated as your source and your current
working copy will be used to determine the target.

What's not clear to me is why you're using the revision range the way you are.
 Your goal is to make sure anything that was merged to 4.0.2 was also merged to
4.0.x.  So I'd probably do the following:

svn mergeinfo --show-revs=merged $REPO/trunk $REPO/branches/4.0.2 >
merged-4.0.2.txt
svn mergeinfo --show-revs=merged $REPO/trunk $REPO/branches/4.0.x >
merged-4.0.x.txt
diff -u 4.0.2.txt 4.0.x.txt

If you get + lines from the diff output that's changes that were merged to
4.0.x that weren't merged to 4.0.2 (which is likely ok).  If you get - lines
then you've got changes merged to 4.0.2 that weren't merged to 4.0.x.  That is
likely the things you were looking for.  If 4.0.x and 4.0.2 weren't branched
off the same point then you'll have some spurious differences.  For instance if
4.0.x has been made off a new revision of trunk than 4.0.2 was then you'll see
changes merged from trunk to 4.0.2 that are included since they were made
before the branch point, in which case you can safely ignore revisions that
exist before the branch point (you see to know how to find the branch point
with --stop-on-copy so I won't repeat that).

This might be a good use for the revision range on the mergeinfo to exclude the
changes merged to from 4.0.x but you appear to be trying to use the branch
point for 4.0.2 which isn't what you'd want.  Unless of course 4.0.2 is newer
than 4.0.x but it doesn't sound like that's the case.

Finally, save yourself some trouble and learn the ^/ syntax:
https://subversion.apache.org/docs/release-notes/1.5.html#externals-relative-urls


Re: Showing unmerged revisions within a range

2014-02-07 Thread Ben Reser
On 2/7/14, 10:45 PM, Ben Reser wrote:
> Finally, save yourself some trouble and learn the ^/ syntax:
> https://subversion.apache.org/docs/release-notes/1.5.html#externals-relative-urls

And it's clearly too late since I linked to the wrong relative URL release
note.  I meant:
https://subversion.apache.org/docs/release-notes/1.6.html#repository-root-relative-urls