AW: 1.7 compatibility issue

[Becker, Thomas]

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

 

As reported by Ivan he fixed this issue in r1151177.

 

Thanks!

 

Regards,

  Thomas

 



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

 

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

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

 

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

 

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

 

http-library = neon

 

At the bottom.

 


-- 
Thanks

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



 

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

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


.

AW: My Backup Script

[Markus Schaber]

Hi, Andreas,

Von: Andreas Krey [mailto:a.k...@gmx.de]
 
> On Tue, 26 Jul 2011 13:55:17 +, Les Mikesell wrote:
> ...
> > How could it possibly be up to date if there has been a commit since
> > the last time it was updated?
> 
> Because the commit came from my WC. My WC was up to date before the
> commit, and the only things that change have been in my WC already, so
> there is no possible way my WC can not be up to date.

That assumption is wrong, I guess. As far as I know, commit hooks can
modify the commit. (This behavior is discouraged, but nevertheless it is
possible.



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

Re: SVN 1.7 SVNParentPath broken

[Stefan Sperling]

On Tue, Jul 26, 2011 at 11:13:24AM +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.
> 
> 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
> >  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.

Mario,

Did you check what your Apache server logs say when the problem happens?
You already quoted this error: "Could not open the requested SVN filesystem".
Is there any more information in the server logs that might shed some
light on it?

Without more information I would suppose that this is a problem in
your setup until we get confirmation of this problem from someone else.

Re: disable security hole in svn+ssh?

[Ulrich Eckhardt]

On Wednesday 27 July 2011, Andy Canfield wrote:
> I was trying to get http, svn, and svn+ssh to work.

Just one thing: Why? Why do you want more than one protocol? I could imagine 
read-only HTTP and read-write HTTPS, but that's the only reason for multiple 
access methods I could imagine.


> Consider these commands:
> *ssh k...@example.com
>  rm -rf /data/svn/subdoc*
> They do nothing; user 'kids' has no right to see anything inside the
> /data/svn directory, which is owned by www-data and readable (and
> writable) only by that user.
> 
> But consider these commands:
> *mkdir t
>  cd t
>  svn checkout svn+ssh://example.com/data/svn/subdoc
>  svn delete *
> **svn commit*
> These will post a revision deleting everything in the repository.

Not true, they will create a new revision in the repository and that revision 
is empty. ;^) No need to check out for that either, you can pass URLs to "svn 
delete". No data loss either, all earlier revisions are still present and 
unchanged. I agree that such a revision is disturbing though, but not a fatal 
data loss.

Anyhow, if you are using svn+ssh, you are only tunnelling the svn network 
protocol through an SSH connection. This is achieved by starting an svnserve 
process through SSH. svnserve itself will use direct file access to the 
repository. So, if you can do that and you can simply log in with a shell 
using SSH, then your security hole is that users have direct access to the 
files that make up a repository using an SSH shell.

If, as you claim, users don't have file access to the repo via SSH, then you 
have some privilege escalation in between, probably using SUID executables.

Summary: There is no security hole in SVN that you didn't drill yourself, 
either using the wrong permissions on the repository or using SUID 
executables.


> And this second set of commands relies only on 'kids' being able to log
> in to the server; they need not have any permission to do anything in
> Subversion!

The "permission [..] in Subversion" only exists in the actually used server 
like Apache or svnserve (even though the svnserve configs are stored in the 
repo folder). With the file access method, you need file-level access to the 
repo anyway, so any "permissions" could only be considered a suggestion 
anyway.


> Is there any way to modify things on the server to disable the svn+ssh:
> protocol without disabling either standard ssh or the svn: protocol?

Disable the file-level access to the repository for users, only allow access 
to servers. If you need encryption, you could restrict access to using HTTPS 
or restrict access via svn to connections from localhost. In the latter case, 
users would have to SSH into the machine and work there or, better, create a 
tunnel.

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.
**

AW: strange merge conflict wrt. keywords

[Becker, Thomas]

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

 

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

 

Regards,

  Thomas

 



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

 

Hi,

 

We encountered a strange merge conflict:

 

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

 

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

 

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

 

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

 

My questions now are:

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

-  How could the substituted keyword get into the repository?

 

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

 

Regards,

  Thomas

 





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

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



 

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

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


.

Sparse checkout error.

[Pierre Best]

While trying to do a sparse checkout in TortoiseSvn (version TortoiseSVN
1.6.99, Build 21709 - 64 Bit , 2011/07/22 16:21:33) I got the following
error message.

 

Subversion Exception! 

io. Subversion encountered a serious problem. r Please take the time to
report this on the Subversion mailing list (users@subversion.apache.org)
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.orgimailing-lists.html 

Subversion reported the following: 

In file 

'D:\ Development\ SVN\TortoiseSVN\ ext\ subversion\ subversion\ libsvn_
wc wc_db.c* line 6617: assertion failed
(svn_dirent_is_absolute(local_abspath)) 

OK

 

 


___
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

Web site: checkout or export?

[Andy Canfield]

We're doing a web site. The whole site will be under revision control 
using Subversion.


So there are at least three of these: my working copy, the repository, 
and the working web site.


How do I get a working web site? By export? or by checkout?

+ After we 'svn checkout', If we need to change something on the working 
web site, we can 'svn commit' to get the changes into the repository. 
Using 'svn export' we would have to make the changes on a working copy, 
then commit, then 'svn export' again.


+ After we 'svn checkout', whenever a new version is in the repository 
we can 'svn update' and get only the updated files. If we have to use 
'svn export' it will give us ALL of the files.


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


Advice?

Re: disable security hole in svn+ssh?

[Nico Kadel-Garcia]

On Wed, Jul 27, 2011 at 12:06 AM, Andy Canfield
 wrote:
> I was trying to get http, svn, and svn+ssh to work.

Dude. Pick one. Getting all three to play nicely together is destablilizing.


> HERE IT IS USING HTTP:
>     svn info http://athol/svn/subdoc
> Authentication realm:  Athol Subversion Repository
> Password for 'andy':
> Path: subdoc
> URL: http://athol/svn/subdoc
> Repository Root: http://athol/svn/subdoc
> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
> Revision: 4
> Node Kind: directory
> Last Changed Author: andy
> Last Changed Rev: 4
> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)

Hold it right there. You're providing password based repository access
via HTTP, not HTTPS? Please rethink this unless you *want* the
passwords for this repository to be quite insecure and sniffable,
especially if you're using normal user login passwords.

Also note. For HTTP access from Linux and UNIX systems, the default
behavior is to store the password, in cleartext, in
$HOME/.subversioon/. *That* is a longstanding security issue that I've
been ranting about for *years*. Subversion 1.6.x, very reasonably, now
asks for permission before doing that, But if you're using the same
password authenticatoin for svn+ssh://, http://, https://, and svn://
based access, you're now writing your password in plain text. locally.
svn+ssh:// doesn't recored that plain text password, http:// and
htps:// do.

> HERE IT IS USING SVN:
>     svn info svn://athol/subdoc
> Authentication realm:  Subversion svnserve
> Password for 'andy':
> Path: subdoc
> URL: svn://athol/subdoc
> Repository Root: svn://athol/subdoc
> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
> Revision: 4
> Node Kind: directory
> Last Changed Author: andy
> Last Changed Rev: 4
> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)

Again. Unencrypted passwords, unless you're using something like SASL.
Do not use this for normal user passwords.

> HERE IS THE PROBLEM USING SVN+SSH:
>     svn info svn+ssh://athol/data/svn/subdoc
> The authenticity of host 'athol (192.168.1.113)' can't be established.
> ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7.
> Are you sure you want to continue connecting (yes/no)? yes
> kids@athol's password:
> Path: subdoc
> URL: svn+ssh://athol/data/svn/subdoc
> Repository Root: svn+ssh://athol/data/svn/subdoc
> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
> Revision: 4
> Node Kind: directory
> Last Changed Author: andy
> Last Changed Rev: 4
> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)
>
> What's 'worse' about it? Well, 'kids' is a valid user name on the server;

Which it need not be. The gudebook does not make this clear enough:
For users who have normal shell access *anyway*, many sites do use
this approach and simply set the repository to be manged with group
access to designated users. But in the "we don't want people to need
shell access to use svn+ssh", you need to set up something like an SSH
key on a shared account with forced commands, typically with this kind
of URL.

svn+ssh://svn@sitename/svn/reponame/

That "svn" user can be set to have no valid shell, with its shell set
to something like "/sbin/nologin". This is actually quite common for
system services to have no valid shell. This is how the "apache" or
"www-data" user is usually set up.

> 'kids' can ssh into the server. But 'kids' has no authorization to access
> any Subversion repository in any way. To me this means that svn+ssh is a
> GIGANTIC security hole.

See above. That "forced command" bit is really important for systems
where you don't want subverson authorized users to have shell access.
I've actually had extensive battles about this sort of thing with
sites where the internal policy was "as long as they're in, we already
trust them with shell on such servers".

This is actually tied to a subtler, longstanding deficit in
Subversion: a dedicated shell for an "svn" user. I've attempted myself
to integrate this sort of thing into the "rssh" toolkit used for rsync
access.


> Consider these commands:
>     ssh k...@example.com
>     rm -rf /data/svn/subdoc
> They do nothing; user 'kids' has no right to see anything inside the
> /data/svn directory, which is owned by www-data and readable (and writable)
> only by that user.

Only if you're using the "shared account" access method to svn+ssh,
where the URL includes the username or otherwise successfully forces
access to have that username. If you're doing the unfortunately common
approach of normal user accounts with shared group access to the
Subversion repository, you can scrub the database clean. It's one of
the reasons I *hate* that normal user account method. The same sort of
thing occurs in CVS repositories: it allows a considerable amount of
relocation and behind the scenes editing of Subversion repositories,
and is one of the ways to flush oversized binaries, such as DVD
images, that soo

Re: Web site: checkout or export?

[Ryan Schmidt]

On Jul 27, 2011, at 06:46, Andy Canfield wrote:

> We're doing a web site. The whole site will be under revision control using 
> Subversion.
> 
> So there are at least three of these: my working copy, the repository, and 
> the working web site.
> 
> How do I get a working web site? By export? or by checkout?
> 
> + After we 'svn checkout', If we need to change something on the working web 
> site, we can 'svn commit' to get the changes into the repository. Using 'svn 
> export' we would have to make the changes on a working copy, then commit, 
> then 'svn export' again.
> 
> + After we 'svn checkout', whenever a new version is in the repository we can 
> 'svn update' and get only the updated files. If we have to use 'svn export' 
> it will give us ALL of the files.
> 
> - Using 'svn checkout', the working web site will have the subversion control 
> files in the .svn subdirectory, which might be a security hole.
> 
> Advice?

The .svn directories needn't be a security hole; you can configure your web 
server to not serve their contents, or even not acknowledge their existence. In 
my httpd.conf I have:

RedirectMatch 404 .*/\.svn(/|$)


You should also look into SVN::Notify::Mirror:

http://search.cpan.org/perldoc?SVN::Notify::Mirror

Svnsync

[Onno van der Straaten]

Hi all,
I'm trying to synsync a repository. I have done this in the past but it
seems I have forgotten how to do this. From my notes I understand that I
need to initialize the svnsync on the target repository. So I ssh to the
target machine that has the target repos and issue the following command
svnsync init file:///path_to_my_repos/
svnsync: Try 'svnsync help' for more info
svnsync: Not enough arguments provided

The help information does not give enough clues on what is missing. I'm
pretty sure I have used the exact same command succesfully in the past but I
must be wrong.

The path is correct because I can succesfully do svnsync info on the path.
But it seems that is not enough anymore for the initialize.

The repository is 1.5.1 by the way.
Thanks and Regards,
Onno

Re: Sparse checkout error.

[Stefan Sperling]

On Wed, Jul 27, 2011 at 09:13:09AM +0100, Pierre Best wrote:
> While trying to do a sparse checkout in TortoiseSvn (version TortoiseSVN
> 1.6.99, Build 21709 - 64 Bit , 2011/07/22 16:21:33) I got the following
> error message.

Hi Pierre,

This looks like a bug in Subversion.

Your bug report does not include enough information so that others
can independently reproduce it.

Can you describe in more detail what sparse checkout process triggered this?

If you have time it would be great if you could create a local repository
with tortoisesvn ("Create Repository here"), add some folders and then try
to reproduce the problem (use a file:// URL to access the repository).
Then let us know what the repository structure looks like, and in
which way you checked things out. This way it will be easier for others
to trigger the crash. Thanks!

> Subversion Exception! 
> 
> io. Subversion encountered a serious problem. r Please take the time to
> report this on the Subversion mailing list (users@subversion.apache.org)
> 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.orgimailing-lists.html 
> 
> Subversion reported the following: 
> 
> In file 
> 
> 'D:\ Development\ SVN\TortoiseSVN\ ext\ subversion\ subversion\ libsvn_
> wc wc_db.c* line 6617: assertion failed
> (svn_dirent_is_absolute(local_abspath)) 

Re: Svnsync

[Stefan Sperling]

On Wed, Jul 27, 2011 at 02:24:42PM +0200, Onno van der Straaten wrote:
> Hi all,
> I'm trying to synsync a repository. I have done this in the past but it
> seems I have forgotten how to do this. From my notes I understand that I
> need to initialize the svnsync on the target repository. So I ssh to the
> target machine that has the target repos and issue the following command
> svnsync init file:///path_to_my_repos/
> svnsync: Try 'svnsync help' for more info
> svnsync: Not enough arguments provided

svnsync init expects 2 URLs:
  usage: svnsync initialize DEST_URL SOURCE_URL

You are missing either the DEST_URL or the SOURCE_URL.

AW: Web site: checkout or export?

[Markus Schaber]

Hi, Andy,

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

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

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

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

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


Mit freundlichen Grüßen

Markus Schaber

___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Entwicklung
Memminger Str. 151 | 87439 Kempten | 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

Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | 
Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915

Re: Svnsync

[Onno van der Straaten]

Thanks, I got it.

On Wed, Jul 27, 2011 at 2:31 PM, Stefan Sperling  wrote:

> On Wed, Jul 27, 2011 at 02:24:42PM +0200, Onno van der Straaten wrote:
> > Hi all,
> > I'm trying to synsync a repository. I have done this in the past but it
> > seems I have forgotten how to do this. From my notes I understand that I
> > need to initialize the svnsync on the target repository. So I ssh to the
> > target machine that has the target repos and issue the following command
> > svnsync init file:///path_to_my_repos/
> > svnsync: Try 'svnsync help' for more info
> > svnsync: Not enough arguments provided
>
> svnsync init expects 2 URLs:
>  usage: svnsync initialize DEST_URL SOURCE_URL
>
> You are missing either the DEST_URL or the SOURCE_URL.
>

svnsync

[Phil Pinkerton]

A local SVN "expert" tells me svnsync is all I need with regards to
moving several (about 2 hundred) repositories from a Unix server to a
Linux server even though there are mixed versions of SVN.

Some are 1.5x others are 1.6.x (all are FSFS).and the destination
server will have
1.6.17 svn installed ( Subversion Edge )

Is it possible it is as simple as say doing an SFTP of all the Unix
Repositories to the Linux server then running svnsync on each repo ?

any one done this successfully I am a bit of a skeptic when a task of
this magnitude ids described as being too simple. WE are taking about
several repos many well over 4GB



-- 
" The fundamental principle here is that the justification for a
physical concept lies exclusively in its clear and unambiguous
relation to the facts that it can be experienced"   AE

Please Feed and Educate the Children... it's the least any of us can do.

Re: SVN 1.7 SVNParentPath broken

[Mario Brandt]

Hi Stefen,
of cause you can have the error log information. But I doubt it helps more.

http://pastebin.com/N2TKddyE  <--- log from the alpha
http://pastebin.com/rvsq4hDM   <--- log from current beta

As I told the module tries to open the parent path as a repo which it isn't.


Cheers
Mario

> Did you check what your Apache server logs say when the problem happens?
> You already quoted this error: "Could not open the requested SVN filesystem".
> Is there any more information in the server logs that might shed some
> light on it?
>
> Without more information I would suppose that this is a problem in
> your setup until we get confirmation of this problem from someone else.
>

Re: svnsync

[Mark Phippard]

On Wed, Jul 27, 2011 at 10:12 AM, Phil Pinkerton wrote:

> A local SVN "expert" tells me svnsync is all I need with regards to
> moving several (about 2 hundred) repositories from a Unix server to a
> Linux server even though there are mixed versions of SVN.
>
> Some are 1.5x others are 1.6.x (all are FSFS).and the destination
> server will have
> 1.6.17 svn installed ( Subversion Edge )
>
> Is it possible it is as simple as say doing an SFTP of all the Unix
> Repositories to the Linux server then running svnsync on each repo ?
>
> any one done this successfully I am a bit of a skeptic when a task of
> this magnitude ids described as being too simple. WE are taking about
> several repos many well over 4GB
>

If the existing repositories are FSFS, you could actually just move the
repositories to the new server and use them.  IOW, just copy the repository
folder to the new server.

svnsync is a good option if you do not want any downtime, otherwise, I would
use svnadmin dump/load over svnsync.  It will run faster but you should have
the repositories offline while doing it.  Where as with svnsync you could
still be using the old repository until the new one is ready.

Do not forget to recreate your hook scripts in the new repositories if you
are using any.

-- 
Thanks

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

Re: SVN 1.7 SVNParentPath broken

[Stefan Sperling]

On Wed, Jul 27, 2011 at 04:14:16PM +0200, Mario Brandt wrote:
> Hi Stefen,
> of cause you can have the error log information. But I doubt it helps more.
> 
> http://pastebin.com/N2TKddyE  <--- log from the alpha
> http://pastebin.com/rvsq4hDM   <--- log from current beta
> 
> As I told the module tries to open the parent path as a repo which it isn't.

What happens if you switch your  to something like
?

Svn Searcher

[Phil Pinkerton]

Anyone have experience installing and using Svn Searcher ?

http://svn-search.sourceforge.net/

I have a client that would like to do Repository Searches.

-- 
" The fundamental principle here is that the justification for a
physical concept lies exclusively in its clear and unambiguous
relation to the facts that it can be experienced"   AE

Please Feed and Educate the Children... it's the least any of us can do.

Re: Svn Searcher

[vishwajeet singh]

On Wed, Jul 27, 2011 at 8:48 PM, 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.
>

Yes I have done that.


>
> --
> " The fundamental principle here is that the justification for a
> physical concept lies exclusively in its clear and unambiguous
> relation to the facts that it can be experienced"   AE
>
> Please Feed and Educate the Children... it's the least any of us can do.
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

Re: Svn Searcher

[Phil Pinkerton]

What platform did you install it on (Linux, Unix, Windows ) ?
Was it installed on the Server , Cliient both ?
Any issues or concerns, is it working ? How well ?
Easy to install and use ?
Any external dependencies and or Apache issues ?
What about Security ( affects svn ACL , LDAP ??)

Any feedback would be appreciated.


On Wed, Jul 27, 2011 at 11:20 AM, vishwajeet singh  wrote:
>
>
> On Wed, Jul 27, 2011 at 8:48 PM, 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.
>
> Yes I have done that.
>
>>
>> --
>> " The fundamental principle here is that the justification for a
>> physical concept lies exclusively in its clear and unambiguous
>> relation to the facts that it can be experienced"   AE
>>
>> Please Feed and Educate the Children... it's the least any of us can do.
>
>
>
> --
> Vishwajeet Singh
> +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
> Twitter: http://twitter.com/vishwajeets | LinkedIn:
> http://www.linkedin.com/in/singhvishwajeet
>



-- 
" The fundamental principle here is that the justification for a
physical concept lies exclusively in its clear and unambiguous
relation to the facts that it can be experienced"   AE

Please Feed and Educate the Children... it's the least any of us can do.

Re: Svn Searcher

[vishwajeet singh]

On Wed, Jul 27, 2011 at 8:56 PM, Phil Pinkerton wrote:

> What platform did you install it on (Linux, Unix, Windows ) ?
>

I did it on windows and linux


> Was it installed on the Server , Cliient both ?
>

It's web based hence no install required on client side


> Any issues or concerns, is it working ? How well ?
>

No issues as such it's great product, just that it's not being maintained
from long time, support is scarce


> Easy to install and use ?
>

It can get tricky as there are two parts one indexer and other is webapp


> Any external dependencies and or Apache issues ?
>
You need tomcat


> What about Security ( affects svn ACL , LDAP ??)
>

svn ACL works on linux but not on windows


> Any feedback would be appreciated.
>
>
I hope that helps.


>
> On Wed, Jul 27, 2011 at 11:20 AM, vishwajeet singh 
> wrote:
> >
> >
> > On Wed, Jul 27, 2011 at 8:48 PM, 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.
> >
> > Yes I have done that.
> >
> >>
> >> --
> >> " The fundamental principle here is that the justification for a
> >> physical concept lies exclusively in its clear and unambiguous
> >> relation to the facts that it can be experienced"   AE
> >>
> >> Please Feed and Educate the Children... it's the least any of us can do.
> >
> >
> >
> > --
> > Vishwajeet Singh
> > +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
> > Twitter: http://twitter.com/vishwajeets | LinkedIn:
> > http://www.linkedin.com/in/singhvishwajeet
> >
>
>
>
> --
> " The fundamental principle here is that the justification for a
> physical concept lies exclusively in its clear and unambiguous
> relation to the facts that it can be experienced"   AE
>
> Please Feed and Educate the Children... it's the least any of us can do.
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

Re: svnsync

[Nico Kadel-Garcia]

On Wed, Jul 27, 2011 at 10:12 AM, Phil Pinkerton  wrote:
> A local SVN "expert" tells me svnsync is all I need with regards to
> moving several (about 2 hundred) repositories from a Unix server to a
> Linux server even though there are mixed versions of SVN.
>
> Some are 1.5x others are 1.6.x (all are FSFS).and the destination
> server will have
> 1.6.17 svn installed ( Subversion Edge )

It's an efficient and graceful way to move them, one where you can
presynchronize the data ahead of time and update it. You can also
review your layouts. and see if there are repositories to merge,
split, or discard at this time.

svnsync does not bring along the local hook and configuration files,
but only the repository contents. You'ld have to transfer them
separately, but this is often safer.

> Is it possible it is as simple as say doing an SFTP of all the Unix
> Repositories to the Linux server then running svnsync on each repo ?

There are profound dangers of doing this. It's a database on the back
end. If someone adds one commit that you missed, or you copied one
file before it was completely written to the database, you've
corrupted your replica. This is why people are so careful to lock
their old repositories read-only, mirror the material carefully, and
only when they're finished do they activate the mirror repository.
This is also all built into WanDisco's commercial multi-hosting tools.

> any one done this successfully I am a bit of a skeptic when a task of
> this magnitude ids described as being too simple. WE are taking about
> several repos many well over 4GB

Which, by modern standards, is quite modest.

By the way: use "rsync" instead of "sftp", in order to be able to
restart things if interrupted.

> --
> " The fundamental principle here is that the justification for a
> physical concept lies exclusively in its clear and unambiguous
> relation to the facts that it can be experienced"   AE
>
> Please Feed and Educate the Children... it's the least any of us can do.
>

Re: My Backup Script

[Daniel Shahaf]

Markus Schaber wrote on Wed, Jul 27, 2011 at 09:37:38 +0200:
> Hi, Andreas,
> 
> Von: Andreas Krey [mailto:a.k...@gmx.de]
>  
> > On Tue, 26 Jul 2011 13:55:17 +, Les Mikesell wrote:
> > ...
> > > How could it possibly be up to date if there has been a commit since
> > > the last time it was updated?
> > 
> > Because the commit came from my WC. My WC was up to date before the
> > commit, and the only things that change have been in my WC already, so
> > there is no possible way my WC can not be up to date.
> 
> That assumption is wrong, I guess. As far as I know, commit hooks can
> modify the commit. (This behavior is discouraged, but nevertheless it is
> possible.
> 

Modifying the txn handed to the hook is discouraged because it's not
possible to communicate the changes to the client, so its working copy
becomes inconsistent with the repository.

It's trickier but possible to write a hook that inspects the provided
txn, /recreates/ it (possibly with modifications), commits /that/, and
then rejects the originally-provided txn.  The client working copy is
consistent and will remain consistent after an 'svn up' (which will
merge cleanly or conflict, as usual).

> 
> 
> 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

Re: svnsync

[Daniel Shahaf]

Mark Phippard wrote on Wed, Jul 27, 2011 at 10:16:10 -0400:
> On Wed, Jul 27, 2011 at 10:12 AM, Phil Pinkerton wrote:
> 
> > A local SVN "expert" tells me svnsync is all I need with regards to
> > moving several (about 2 hundred) repositories from a Unix server to a
> > Linux server even though there are mixed versions of SVN.
> >
> > Some are 1.5x others are 1.6.x (all are FSFS).and the destination
> > server will have
> > 1.6.17 svn installed ( Subversion Edge )
> >
> > Is it possible it is as simple as say doing an SFTP of all the Unix
> > Repositories to the Linux server then running svnsync on each repo ?
> >
> > any one done this successfully I am a bit of a skeptic when a task of
> > this magnitude ids described as being too simple. WE are taking about
> > several repos many well over 4GB
> >
> 
> If the existing repositories are FSFS, you could actually just move the
> repositories to the new server and use them.  IOW, just copy the repository
> folder to the new server.
> 

And make sure /not/ to copy rep-cache.db that way.  SQLite doesn't
promise that the resulting db will be valid or consistent.

Re: SVN 1.7 SVNParentPath broken

[Mario Brandt]

Hi Stefan,
> What happens if you switch your  to something like
> ?

that did the trick. Than it works with SVNParentPath. I wonder why it
doesn't work like before with just / in the location container. :-/

Mario

Re: SVN 1.7 SVNParentPath broken

[Rob van Oostrum]

On Wed, Jul 27, 2011 at 4:41 PM, Mario Brandt  wrote:
> Hi Stefan,
>> What happens if you switch your  to something like
>> ?
>
> that did the trick. Than it works with SVNParentPath. I wonder why it
> doesn't work like before with just / in the location container. :-/
>
> Mario
>

Probably because you have a default site at / that takes precedence
when Apache parses its config.

Re: SVN 1.7 SVNParentPath broken

[Mario Brandt]

Hi all,
thanks for your help.

> Probably because you have a default site at / that takes precedence
> when Apache parses its config.


Different to 1.6 with 1.7 I had to set the document root the same as
SVNParentPath. Now it works again with 


Cheers
Mario

Re: svnsync

[Ryan Schmidt]

On Jul 27, 2011, at 14:44, Daniel Shahaf wrote:
> Mark Phippard wrote on Wed, Jul 27, 2011 at 10:16:10 -0400:
>> If the existing repositories are FSFS, you could actually just move the
>> repositories to the new server and use them.  IOW, just copy the repository
>> folder to the new server.
> 
> And make sure /not/ to copy rep-cache.db that way.  SQLite doesn't
> promise that the resulting db will be valid or consistent.

In what way should one copy rep-cache.db, then?

Re: svnsync

[Daniel Shahaf]

Ryan Schmidt wrote on Wed, Jul 27, 2011 at 16:07:46 -0500:
> On Jul 27, 2011, at 14:44, Daniel Shahaf wrote:
> > Mark Phippard wrote on Wed, Jul 27, 2011 at 10:16:10 -0400:
> >> If the existing repositories are FSFS, you could actually just move the
> >> repositories to the new server and use them.  IOW, just copy the repository
> >> folder to the new server.
> > 
> > And make sure /not/ to copy rep-cache.db that way.  SQLite doesn't
> > promise that the resulting db will be valid or consistent.
> 
> In what way should one copy rep-cache.db, then?

http://www.sqlite.org/backup.html

svn_sqlite__hotcopy()

sqlite3 old.db .dump | sqlite3 new.db
(this creates the new.db from scratch, it needn't (shouldn't?) have the
schema already filled in)

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

[Daniel Shahaf]

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
* Making sure you can access that repository
* Either: rm -rf the repository, and recreate it using 1.7.0-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

Thanks!

Daniel

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

Re: SVN 1.7 SVNParentPath broken

[Daniel Shahaf]

Tony Butt wrote on Thu, Jul 28, 2011 at 11:52:14 +1000:
> 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.

Yes, it is, thanks.  (mod_dav_svn sometimes logs more information than
it presents to the client.)