RE: SVN Authentication fail
> authz was modified to create a group including and > the following line was added, as well: > > [repository: /svn] > > @ = rw > I don't use svnserve but Apache instead. However, I believe the authorizations files have the same format (if that's not the case, please ignore the rest of the message). That [repository: /svn] looks wrong to me. Since you have started svnserve with the path to the repository I believe that that line should just be [/], because the daemon knows already where the repository is. [groups] devel = user1, user2 [/] @devel = rw Could you post the entire authz file? Giulio Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851VAT Reg No 778499447
Reusing authz file between SVNPath & SVNParentPath
Hi, I am using Apache mod_dav_svn and mod_authz_svn for authorization (authentication performed with mod_auth_ldap). The same Apache server is used to serve multiple repositories using SVNParentPath, so in the block I have DAV svn SVNParentPath C:\repositories AuthzSVNAccessFile C:\repositories\authz and the content of the authz file goes something like: [groups] ... [/] # default is read-only for all repositories * = r [repA:/] auth-stuff-for-repA [repB:/] auth-stuff-for-repB ... this setup works great when users access http://server/svn/repX but in addition I want to allow "shortcut URLs" to several repositories (e.g. http://svn.projA.org/), so I have (in the same Apache configuration) multiple virtual hosts with ServerName svn.projX.org and with: DAV svn SVNPath C:\repositories\repX AuthzSVNAccessFile C:\repositories\authz >From what I understand, when accessing via a virtual host, all requests will be matched against the [/] block in the authz file, since mod_dav_svn assumes the authz file specified is specific for the repository being served (which is what happens in the described configuration). The question: is there a way to reuse the same authz file in both cases? (SVNParentPath & SVNPath) maybe some directive that I can add to the virtual host location block telling mod_dav_svn to match all requests to "repX" and not "/"? Thanks! (and sorry for the long post..) Itamar O.
javahl.jar missing in 1.6.2 rpm
In the RPM available for the subversion client on Collabnet, there is a shared lib for javahl, but no jar file. There is no obvious information on downloading the jar file elsewhere on the apache or collabnet site that I've been able to find up to this point. I assume that I'm missing something, but what?
Re: javahl.jar missing in 1.6.2 rpm
On Fri, May 14, 2010 at 8:34 AM, Benson Margulies wrote: > In the RPM available for the subversion client on Collabnet, there is > a shared lib for javahl, but no jar file. There is no obvious > information on downloading the jar file elsewhere on the apache or > collabnet site that I've been able to find up to this point. I assume > that I'm missing something, but what? We don't distribute it because most apps that use JavaHL package the JAR in their app and just need the native binaries provided elsewhere. For example, Subclipse packages it inside it's Eclipse plugin. NetBeans does the equivalent. Many web apps that use JavaHL include it inside their WAR etc. It is fairly trivial to build. Just pull the src folder into your package and build it. Of course the JAR is also platform independent, so it does not matter where you build it or get it. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: javahl.jar missing in 1.6.2 rpm
OK. The Fisheye people think you're going to hand it out. I'll point out to them the error of their ways. On Fri, May 14, 2010 at 10:04 AM, Mark Phippard wrote: > On Fri, May 14, 2010 at 8:34 AM, Benson Margulies > wrote: >> In the RPM available for the subversion client on Collabnet, there is >> a shared lib for javahl, but no jar file. There is no obvious >> information on downloading the jar file elsewhere on the apache or >> collabnet site that I've been able to find up to this point. I assume >> that I'm missing something, but what? > > We don't distribute it because most apps that use JavaHL package the > JAR in their app and just need the native binaries provided elsewhere. > For example, Subclipse packages it inside it's Eclipse plugin. > NetBeans does the equivalent. Many web apps that use JavaHL include > it inside their WAR etc. > > It is fairly trivial to build. Just pull the src folder into your > package and build it. > > Of course the JAR is also platform independent, so it does not matter > where you build it or get it. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ >
Re: SVN Migration using tar only, is this possible (without dump or hotcopy)?
Thanks for the response. It sounds like it would be better to move the corrupt repos to another *nix (instead of windows). My new plan is to move the corrupt SVN 1.4.0 repos (on the FreeBSD 6.1- RELEASE machine)via TAR + NFS to a Red Hat Linux 5.3 box (with SVN 1.4.0). If I can get them there and hooked up in the same state they are in now, that's good enough. svnadmin verify fails with this message "malformed representation header". From what i've read about it... " There is no fix without possible data loss. The only thing we could do is dump the repository till the repository is Ok then use svnadmin dump --incremental -r :HEAD You can examinie the broken revision with svnlook." any suggestions related to the tar + transfer between the freebsd and red has linux box would be appreciated. On May 13, 11:08 pm, Ryan Schmidt wrote: > On May 13, 2010, at 10:47, Bob Archer wrote: > > >> I would love to upgrade from version 1.4.0 (r21228) but a number of > >> repos error out when I attempt to dump/svnhotcopy/svnsync I encounter > >> errors. > > >> At this point we are just going to run a legacy 1.4.0 server (on my > >> destination server) and the latest visual svn (and just start from > >> scratch with all new repos). My goal is to just move these old repos > >> to the destination server by whatever means possible (and as of right > >> now... the aforementioned commands aren't working). > > > Ouch. Have you tried to just upgrade your existing servers to 1.6.11? The > > newer version of dump or hotcopy or svnsync might work without upgrading > > the old repository. Of course you can upgrade it inplace using svnadmin > > upgrade. But, if that fails you will need to restore the repo... (I expect) > > > As far as just moving the repository folders from one to the other... I'd > > say give it a shot. Most of what I have read and heard is that will work if > > you are staying on the same OS and architecture but has problems if you try > > to move from one to the other... for example, Linux to Windows... not > > recommended without using dump/load. > > He already stated that he is moving from FreeBSD to Windows Server. > > I would strongly advise correcting the problems encountered by svnadmin > verify before attempting to move the repository to a different server. The > fact that svnadmin verify does not complete successfully is a pretty good > indicator that the repository *is* corrupt at this point, and moving to a new > machine will, at best, leave the repository as corrupt as it is now.
Sparse Directories and svn switch
Hi all, I was wondering if there was some way to get svn switch to work with sparse directories. What I'm seeing when I use svn switch in a checkout where I've used --set-depth on a subfolder to limit the size of the checkout is that svn switch seems to reset all the depth to infinity. What I expected/would like is that the depths would be sticky and I could expand them later if needed. I am using svn version 1.6.5 For ex. something like: svn co .../trunk svn update --set-depth empty folder1/large_unneeded_folder svn switch .../branch/my_branch then recursively downloads all the files in large_unneeded_folder and depth on that folder is no infinity. Interestingly when I switch to the same repository path that doesn't happen. i.e. svn co .../trunk svn update --set-depth empty folder1/large_unneeded_folder svn switch .../trunk doesn't download all the files in large_unneeded_folder Is this the expected behavior and if so is there anyway to get svn switch to preserve the depths? Thanks! Tim
One JNI Usage Bug in Java binding
Dear Subversion Users:
My JNI bug detector (Jinn) found several bugs in the JavaHL. I'd like
to hear your opinion about the bug before filing all the bugs. The bug
appears the Line 774 in the following slice of source files.
subversion/bindings/javahl/native/CreateJ.cpp
634 jobject
635 CreateJ::NotifyInformation(const svn_wc_notify_t *wcNotify)
636 {
754static jmethodID add_mid = 0;
757add_mid = env->GetMethodID(clazz, "add", "(Ljava/lang/Object;)Z");
774env->CallObjectMethod(jranges, add_mid, jrange);
The "add" method at Line 757 returns a Java boolean value, but the JNI
function at Line 774 expects that the "add" method returns a Java
reference. This usage violates usage rules in JNI specifcation.
"You should replace type in CallMethod with the Java type of the
method you are calling (or use one of the actual method calling
routine names from the table) and replace NativeType with the
corresponding native type for that routine."
[http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp4256]
I propose the following patch:
Index: subversion/bindings/javahl/native/CreateJ.cpp
===
--- subversion/bindings/javahl/native/CreateJ.cpp (revision 944458)
+++ subversion/bindings/javahl/native/CreateJ.cpp (working copy)
@@ -771,7 +771,7 @@
if (JNIUtil::isJavaExceptionThrown())
POP_AND_RETURN_NULL;
- env->CallObjectMethod(jranges, add_mid, jrange);
+ env->CallBooleanMethod(jranges, add_mid, jrange);
if (JNIUtil::isJavaExceptionThrown())
POP_AND_RETURN_NULL;
Regards,
Byeong
Re: One JNI Usage Bug in Java binding
Thanks for the patch. Would you mind reposting this to the dev@ list?
On Fri, May 14, 2010 at 5:14 PM, Byeongcheol Lee wrote:
> Dear Subversion Users:
>
> My JNI bug detector (Jinn) found several bugs in the JavaHL. I'd like
> to hear your opinion about the bug before filing all the bugs. The bug
> appears the Line 774 in the following slice of source files.
>
> subversion/bindings/javahl/native/CreateJ.cpp
>
> 634 jobject
> 635 CreateJ::NotifyInformation(const svn_wc_notify_t *wcNotify)
> 636 {
>
> 754 static jmethodID add_mid = 0;
>
> 757 add_mid = env->GetMethodID(clazz, "add",
> "(Ljava/lang/Object;)Z");
>
> 774 env->CallObjectMethod(jranges, add_mid, jrange);
>
>
> The "add" method at Line 757 returns a Java boolean value, but the JNI
> function at Line 774 expects that the "add" method returns a Java
> reference. This usage violates usage rules in JNI specifcation.
>
> "You should replace type in CallMethod with the Java type of the
> method you are calling (or use one of the actual method calling
> routine names from the table) and replace NativeType with the
> corresponding native type for that routine."
> [http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp4256]
>
> I propose the following patch:
>
> Index: subversion/bindings/javahl/native/CreateJ.cpp
> ===
> --- subversion/bindings/javahl/native/CreateJ.cpp (revision 944458)
> +++ subversion/bindings/javahl/native/CreateJ.cpp (working copy)
> @@ -771,7 +771,7 @@
> if (JNIUtil::isJavaExceptionThrown())
> POP_AND_RETURN_NULL;
>
> - env->CallObjectMethod(jranges, add_mid, jrange);
> + env->CallBooleanMethod(jranges, add_mid, jrange);
> if (JNIUtil::isJavaExceptionThrown())
> POP_AND_RETURN_NULL;
>
> Regards,
> Byeong
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: SVN Migration using tar only, is this possible (without dump or hotcopy)?
On May 14, 2010, at 12:17, Stonebraker wrote: > svnadmin verify fails with this message "malformed representation > header". From what i've read about it... > " There is no fix without possible data loss. > The only thing we could do is dump the repository till the repository > is Ok then use > svnadmin dump --incremental -r :HEAD > You can examinie the broken revision with svnlook." You should give fsfsverify a try. http://svn.haxx.se/users/archive-2006-12/0786.shtml
Re: Filenames with non-ASCII characters
On May 14, 2010, at 07:40, Rodrigo Montenegro wrote: > On Thu, May 13, 2010 at 22:42, Ryan Schmidt wrote: >> On May 13, 2010, at 12:29, Rodrigo Montenegro wrote: >> >>> I am trying to block the users committing files with non-ASCII characters >>> in their names during the pre-commit hook script, but when I get the list >>> of files being committed with "svnlook changed" the filenames are >>> completely messed up. >>> >>> For example, a file named "ação.txt" when committed, has the string "A >>> trunk/a?\195?\167?\195?\163o1.txt" returned by the "svnlook changed" >>> command. >>> >> >> >> If you want to see the filenames as proper UTF-8 strings, you need to set >> the LANG environment variable to the proper value for your system. >> > > Well, I did: > export LANG=pt_BR.UTF-8 and I got the same results. > > The previous set of LANG was en_US.UTF-8. > > Should I recompile subversion after set LANG to pt_BR ? Recompiling is not necessary. Where are you setting LANG? In this case, you should be setting it in your pre-commit hook script. Remember to Reply All so this discussion takes place on the mailing list, not in private email.
