Subversion Apache2.2 LDAPS authentication failed
Hi, OS: Redhat Linux Subversion: 1.5.0 Apache: 2.2.17 OpenLDAP: 2.3.27 httpd.conf: ... LDAPSharedCacheSize 20 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 DAV svn SVNParentPath /home/svnroot/repository AuthzSVNAccessFile /home/svnroot/repository/svn_access_file AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative off AuthLDAPURL "ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectClass=*)" SS L AuthName "Subversion.resository" Require valid-user ... Apache error_log: [Thu Feb 24 16:48:00 2011] [debug] mod_authnz_ldap.c(403): [client 10.1.85.181] [25242] auth_ldap a uthenticate: using URL ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectCl ass=*) [Thu Feb 24 16:48:00 2011] [info] [client 10.1.85.181] [25242] auth_ldap authenticate: user jinjian kang authentication failed; URI /svn [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server] ping master.ldap.ebupt.com is OK. My FTP LDAPS authentication is OK as below: server:master.ldap.ebupt.com port:636 Enable SSL:checked Base DN:ou=staff,dc=ebupt,dc=com anonymous bind:checked Search Filter:(objectClass=*) User DN attribute:uid Search scope:subtree Thanks. Jin Jiankang
Re: Problem when config SVN to the root of a sub domain name
On Feb 24, 2011, at 07:10, 曹振华 wrote: > I want to set 'svn.x.com' as the root of a svn repository, so I use apache's > directive to make all request to this sub domain forward to svn > system, and It performs well when just reading from web interface. But I got > problem with commitment, The error log shows below: > > [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] (20014)Internal error: > Can't open file '/usr/local/svn/repos/error/format': No such file or directory > [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not fetch resource > information. [500, #0] > [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not open the > requested SVN filesystem [500, #2] > [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not open the > requested SVN filesystem [500, #2] > > -- > I then found Problems can be resolve if I use directive, > and visit 'svn.xxx.com/repos' as the root of repository, could someone tell > me why and what is the cause of this problem? There are several possible issues when trying to use "" to serve repositories. Using a different location like "" works around these. If you don't want to do that, then you'll have to tackle the issues. For example, some clients will request paths that don't exist, like /favicon.ico and /robots.txt. What happens when they do? Does it produce a lot of errors, such as the ones you see above? You may want to install Alias directives for each of these possible URLs and do something better with them, either redirect them to actual files, or make them generate a more immediate error that would not clog your logs. The error you've shown above says that someone or something is trying to access a repository called "error". Presumably you do not have a repository by that name. Do you perhaps have a global rule that is redirecting errors to such a URL? If so, make that rule not apply to this virtual host.
Re: ^M Appends to every line?
On Feb 24, 2011, at 12:44, Christopher D Haakinson wrote: > I opened the file in notepad and added a couple blank lines under my exit 0 > and it worked!! How weird is that? Sounds normal to me. I text file is not a text file, according to UNIX definitions, if it does not end with a newline.
Re: TortoiseSVN 1.7 test drive
On Thu, Feb 24, 2011 at 09:00:54PM +0100, Gunnar Dalsnes wrote: > Hi, > > I'm was taking TortoiseSVN-1.6.99.20920-dev-x64-svn-1.7.0-dev.msi > for a test drive today, and here is my experience. > > Converting my WC failed: > Insufficient NODES rows for 'e:\svn\my app > name\.svn\tmp\wcng\src\Tools\SomeProject\SomeFile.cs'. Try a > 'Cleanup'. Cleanup did not help (as always). > > No worries, did a clean checkout. Surprisingly, everything seems to > work very well:-) It generally works reasonably well (and has for most of the time since 1.6 was branched). However, if you poke around a lot you'll soon run into edge cases that are broken. A lot of them are already listed in the issue tracker: http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_milestone=1.7.0 http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_milestone=1.7-consider > > But I'm wondering, are there any plans in 1.7 for supporting sharing > pristines between several WC's? I'm not aware of such plans. It will probably come after 1.7. See the above lists of issues. We have to concentrage on those before adding more functionality, otherwise the release will never get done... > I wish I could (in config file) specify a shared location for pristines. > Ref-counts + deleting unrefed pristines would have to be ignored in > this case I guess, > since ref-counts can't easily be tracked back to the WC's from the > shared pristine, since WC's can be moved or simply deleted. > But I would not mind. Hard drive is cheap but network traffic is > not, and I would easily trade:-) > > If no one is looking into this, I'm considering adding such feature > as I described. Great! Help is always very welcome. You might want to look at the recent threads on dev@ discussing pristines to get an idea about the current state of things. > BTW: For fun, I tried deleting all files in the pristine. Diff of a > changed file did "work", but showed an empty before-file (strangely, > I had expected a file not found error). Then I tried a revert of a > changed file. This failed with file not found in pristine (as > expected). The problem is, the file disappeared (maybe not a bug) > but worse, the WC was no longer recognized as a WC, not even after > restoring the pristine. Possibly, the wc.db became corrupt or > locked, I don't know, at least it worked again when I restored a > backup of wc.db. Scary bug me thinks. The WC should not become > corrupt just because some file in pristine is missing. Ideally, it > should ask to download the missing file, but I guess that's asking > too much:-) Can you write a small script that drives the svn command line client to automate this process and trigger the problem? That would help a lot. We could then log it into the issue tracker and someone will eventually look at it closely. > PS: These errors may be specific to TortoiseSVN, thou I have a > feeling they are not. Most likely not, no.
TortoiseSVN 1.7 test drive
Hi, I'm was taking TortoiseSVN-1.6.99.20920-dev-x64-svn-1.7.0-dev.msi for a test drive today, and here is my experience. Converting my WC failed: Insufficient NODES rows for 'e:\svn\my app name\.svn\tmp\wcng\src\Tools\SomeProject\SomeFile.cs'. Try a 'Cleanup'. Cleanup did not help (as always). No worries, did a clean checkout. Surprisingly, everything seems to work very well:-) But I'm wondering, are there any plans in 1.7 for supporting sharing pristines between several WC's? I wish I could (in config file) specify a shared location for pristines. Ref-counts + deleting unrefed pristines would have to be ignored in this case I guess, since ref-counts can't easily be tracked back to the WC's from the shared pristine, since WC's can be moved or simply deleted. But I would not mind. Hard drive is cheap but network traffic is not, and I would easily trade:-) If no one is looking into this, I'm considering adding such feature as I described. BTW: For fun, I tried deleting all files in the pristine. Diff of a changed file did "work", but showed an empty before-file (strangely, I had expected a file not found error). Then I tried a revert of a changed file. This failed with file not found in pristine (as expected). The problem is, the file disappeared (maybe not a bug) but worse, the WC was no longer recognized as a WC, not even after restoring the pristine. Possibly, the wc.db became corrupt or locked, I don't know, at least it worked again when I restored a backup of wc.db. Scary bug me thinks. The WC should not become corrupt just because some file in pristine is missing. Ideally, it should ask to download the missing file, but I guess that's asking too much:-) PS: These errors may be specific to TortoiseSVN, thou I have a feeling they are not. Regards, Gunnar Dalsnes
Re: ^M Appends to every line?
It's possible that the eol-style has nothing to do with this, because before I added the style, my script was still failing and complaining about the EOF as well as EOL errors... Running your od command yields the following on the last 3 lines: 620 s t t i m e . . . . " \r \n \r \n 640 \r \n e x i t 0 650 so it is missing \n ... I opened the file in notepad and added a couple blank lines under my exit 0 and it worked!! How weird is that? Thanks for your help! It's been much appreciated. |> | From: | |> >-| |David Chapman | >-| |> | To:| |> >-| |Christopher D Haakinson/Raleigh/IBM@IBMUS | >-| |> | Cc:| |> >-| |users@subversion.apache.org | >-| |> | Date: | |> >-| |02/24/2011 01:28 PM | >-| |> | Subject: | |> >-| |Re: ^M Appends to every line? | >-| On 2/24/2011 9:55 AM, Christopher D Haakinson wrote: > > I'd like someone to explain how this small shell script, which works > fine, gets corrupted simply by creating a new file and copy/pasting > the text in it. Here's what I'm doing: > > 1) I have a test shell script that runs fine. Here's the content: > <- start > lock="/tmp/deleteme" > if [ -f $lock ] > then > echo "Lock file exists. Wait until it's gone to proceed. ." > while [ -f $lock ] > do > echo "Waiting for lockfile to be removed. ." > sleep 1s > done > echo "Now creating lock file" > echo "locked" > $lock > else > echo "No lock file found. Creating it. ." > echo "locked" > $lock > fi > echo "Lets try this again, hopefully for the last time" > exit 0 > <-- end > > 2) I copy this entire script from notepad in windows into a new file > named test2.sh, also in notepad. > 3) Using TortoiseSVN, I add test2.sh into my project > 4) I commit the changes to the server > 5) On my linux server, I run: svn update ... to get the test2.sh file > 6) Now when I try to run it I get this: > syntax error: unexpected end of file > > > Now, this is the most simple task I could think of doing, and this > doesn't work. I've also tried creating the new shell script with > Komodo EDIT with the same results. > > This occurs even though I've tried adding svn:eol-style from both my > linux server and my windows wrx... I'm lost!! > In Notepad, can you move your cursor below the last line of text in the file? If not, there won't be a newline after the final line. Under Linux, try "od -c test2.sh | more" and verify that there is a "\n" at the very end of the listing. If not, you'll need to add one in Notepad, Komodo, or your favorite Linux editor. I have no idea why you would see this problem only with "svn:eol-style" defined (if in fact this is the problem). -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, C
Re: ^M Appends to every line?
On 2/24/2011 9:55 AM, Christopher D Haakinson wrote: I'd like someone to explain how this small shell script, which works fine, gets corrupted simply by creating a new file and copy/pasting the text in it. Here's what I'm doing: 1) I have a test shell script that runs fine. Here's the content: <- start lock="/tmp/deleteme" if [ -f $lock ] then echo "Lock file exists. Wait until it's gone to proceed. ." while [ -f $lock ] do echo "Waiting for lockfile to be removed. ." sleep 1s done echo "Now creating lock file" echo "locked" > $lock else echo "No lock file found. Creating it. ." echo "locked" > $lock fi echo "Lets try this again, hopefully for the last time" exit 0 <-- end 2) I copy this entire script from notepad in windows into a new file named test2.sh, also in notepad. 3) Using TortoiseSVN, I add test2.sh into my project 4) I commit the changes to the server 5) On my linux server, I run: svn update ... to get the test2.sh file 6) Now when I try to run it I get this: syntax error: unexpected end of file Now, this is the most simple task I could think of doing, and this doesn't work. I've also tried creating the new shell script with Komodo EDIT with the same results. This occurs even though I've tried adding svn:eol-style from both my linux server and my windows wrx... I'm lost!! In Notepad, can you move your cursor below the last line of text in the file? If not, there won't be a newline after the final line. Under Linux, try "od -c test2.sh | more" and verify that there is a "\n" at the very end of the listing. If not, you'll need to add one in Notepad, Komodo, or your favorite Linux editor. I have no idea why you would see this problem only with "svn:eol-style" defined (if in fact this is the problem). -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: ^M Appends to every line?
I'd like someone to explain how this small shell script, which works fine, gets corrupted simply by creating a new file and copy/pasting the text in it. Here's what I'm doing: 1) I have a test shell script that runs fine. Here's the content: <- start lock="/tmp/deleteme" if [ -f $lock ] then echo "Lock file exists. Wait until it's gone to proceed. ." while [ -f $lock ] do echo "Waiting for lockfile to be removed. ." sleep 1s done echo "Now creating lock file" echo "locked" > $lock else echo "No lock file found. Creating it. ." echo "locked" > $lock fi echo "Lets try this again, hopefully for the last time" exit 0 <-- end 2) I copy this entire script from notepad in windows into a new file named test2.sh, also in notepad. 3) Using TortoiseSVN, I add test2.sh into my project 4) I commit the changes to the server 5) On my linux server, I run: svn update ... to get the test2.sh file 6) Now when I try to run it I get this: syntax error: unexpected end of file Now, this is the most simple task I could think of doing, and this doesn't work. I've also tried creating the new shell script with Komodo EDIT with the same results. This occurs even though I've tried adding svn:eol-style from both my linux server and my windows wrx... I'm lost!! |> | From: | |> >| |Les Mikesell | >| |> | To:| |> >| |users@subversion.apache.org | >| |> | Date: | |> >| |02/24/2011 11:27 AM | >| |> | Subject: | |> >| |Re: ^M Appends to every line? | >| On 2/24/2011 10:02 AM, Christopher D Haakinson wrote: > OK, so I've been testing out the svn:eol-style prop and it appears to > work, but it seems like an awful lot of work for such a simple issue. > > Is there something server-side I can setup to ensure that all files > contain the correct eol style? No, the server can't possibly know what is right either for any particular file or for any particular client platform. But, your client configs control auto-props which can sometimes do the right thing automatically on the client side. Unfortunately those have to match filename patterns that won't necessarily correspond to the file content or use. > Also I've noticed that my shell scripts are now failing with an EOF > error? Does this mean that there's a style setting for the end of file too?? No, that probably is related to some other error or parsing issue in the file. -- Les Mikesell lesmikes...@gmail.com <><>
Re: ^M Appends to every line?
Linux is the final home for these scripts. Currently I'm still in testing mode, so the shell script I am trying is very simple, only a few lines with a while loop, which is why I thought there may be something like svn:eof-style to handle the EOF properly too.. |> | From: | |> >| |David Chapman | >| |> | To:| |> >| |Christopher D Haakinson/Raleigh/IBM@IBMUS | >| |> | Cc:| |> >| |Ryan Schmidt , users@subversion.apache.org | >| |> | Date: | |> >| |02/24/2011 11:22 AM | >| |> | Subject: | |> >| |Re: ^M Appends to every line? | >| On 2/24/2011 8:02 AM, Christopher D Haakinson wrote: > > OK, so I've been testing out the svn:eol-style prop and it appears to > work, but it seems like an awful lot of work for such a simple issue. > > Is there something server-side I can setup to ensure that all files > contain the correct eol style? > > > Also I've noticed that my shell scripts are now failing with an EOF > error? Does this mean that there's a style setting for the end of file > too?? > > > You can define a pre-commit hook script that looks at the file name and then verifies the property is present. These are described in the Subversion book. Multi-platform work is an awful lot of work; it is not as simple as it seems. Heuristics to determine whether a file is "plain text" can fail, with catastrophic results. File transfers done carelessly will corrupt binary files; in integrated circuit design the OASIS geometry file format has an "almost text" string defined solely to catch this error. If you try to use the same text files across platforms, things will fail unless *every* tool you use - all editors, all file analysis software, all file transfer programs - deals with mixed or "wrong platform" line ending styles properly. This is a high standard that has never been met in my experience. I haven't seen script errors related to end of file; Windows no longer puts a ^Z at the end of files, so you shouldn't need to strip that out. Have you done an octal dump of the scripts to see what is at the end of the files? On which platform are they failing - Windows or Linux? -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA <><>
RE: Merge Conflict on Windows with eol-style & mergeinfo properties
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: Thursday, February 24, 2011 1:47 AM > To: Varnau, Steve (Neoview) > Cc: users@subversion.apache.org > Subject: Re: Merge Conflict on Windows with eol-style & mergeinfo > properties > > On Thu, Feb 24, 2011 at 12:56 AM, Varnau, Steve (Neoview) > wrote: > > Hi, > > > > I could not find this issue in the issue tracker. We're trying to > keep the > > svn:mergeinfo properties on top-level directories, but I found a few > text > > files in our repository that have the property. When a merge is done > that > > should be just a branch synch-up merge, the files are marked as > conflicted, > > and the entire file is one big conflict, as if it is an EOL character > > problem. > > > > All of the files that are marked as conflicted have in common two > > properties. They have an svn:mergeinfo, and they have svn:eol-style = > > native. Both branches have the same svn:eol-style value. The text > file that > > did not have an svn:eol-style property merged just fine. > > > > When the files are edited (Tortoise "Edit conflicts") it shows no > conflicts > > -- merge with no problem. Looking at the files, there are no EOL > character > > differences. Both sides (left & right files, and both sides of the > working > > conflict file) have CRLF. > > > > The files also merge fine on Linux. > > The files also merge fine if given the option to ignore end-of-line. > > The problem occurs whether the merge is done via Tortoise or command- > line on > > Windows. > > Svn version 1.6.15. > > > > Somehow it seems to be giving up merging these files only when there > is a > > svn:mergeinfo property. > > > > I will try to just remove the mergeinfo property on all the files, > but > > wondered if this is a general bug. > > I think this is the following issue: > > http://subversion.tigris.org/issues/show_bug.cgi?id=3657 - dav update > report handler in skelta mode can cause spurious conflicts > > (this issue previously had another summary: "phantom svn:eol-style > changes cause spurious merge text conflicts", which may sound more > recognizable, but this was later changed when they found out more > about the issue). > > It describes more or less the same situation: a merge with some prop > change which happens together with a text change, and the entire file > is marked as conflicted. I've run into this situation myself a couple > of times (I then just resolved the conflict by choosing "theirs-full" > or something, after having assured myself that this was indeed the > issue). > > It's fixed in svn trunk, so scheduled to be in the upcoming 1.7 > release. AFAIK, it's not currently nominated for backport to 1.6. > > Cheers, > -- > Johan Yes, that does appear to be the one! Thank you. -Steve
Re: ^M Appends to every line?
On 2/24/2011 10:02 AM, Christopher D Haakinson wrote: OK, so I've been testing out the svn:eol-style prop and it appears to work, but it seems like an awful lot of work for such a simple issue. Is there something server-side I can setup to ensure that all files contain the correct eol style? No, the server can't possibly know what is right either for any particular file or for any particular client platform. But, your client configs control auto-props which can sometimes do the right thing automatically on the client side. Unfortunately those have to match filename patterns that won't necessarily correspond to the file content or use. Also I've noticed that my shell scripts are now failing with an EOF error? Does this mean that there's a style setting for the end of file too?? No, that probably is related to some other error or parsing issue in the file. -- Les Mikesell lesmikes...@gmail.com
Re: ^M Appends to every line?
On 2/24/2011 8:02 AM, Christopher D Haakinson wrote: OK, so I've been testing out the svn:eol-style prop and it appears to work, but it seems like an awful lot of work for such a simple issue. Is there something server-side I can setup to ensure that all files contain the correct eol style? Also I've noticed that my shell scripts are now failing with an EOF error? Does this mean that there's a style setting for the end of file too?? You can define a pre-commit hook script that looks at the file name and then verifies the property is present. These are described in the Subversion book. Multi-platform work is an awful lot of work; it is not as simple as it seems. Heuristics to determine whether a file is "plain text" can fail, with catastrophic results. File transfers done carelessly will corrupt binary files; in integrated circuit design the OASIS geometry file format has an "almost text" string defined solely to catch this error. If you try to use the same text files across platforms, things will fail unless *every* tool you use - all editors, all file analysis software, all file transfer programs - deals with mixed or "wrong platform" line ending styles properly. This is a high standard that has never been met in my experience. I haven't seen script errors related to end of file; Windows no longer puts a ^Z at the end of files, so you shouldn't need to strip that out. Have you done an octal dump of the scripts to see what is at the end of the files? On which platform are they failing - Windows or Linux? -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: ^M Appends to every line?
OK, so I've been testing out the svn:eol-style prop and it appears to work, but it seems like an awful lot of work for such a simple issue. Is there something server-side I can setup to ensure that all files contain the correct eol style? Also I've noticed that my shell scripts are now failing with an EOF error? Does this mean that there's a style setting for the end of file too?? |> | From: | |> >| |Ryan Schmidt | >| |> | To:| |> >| |David Chapman | >| |> | Cc:| |> >| |Nico Kadel-Garcia , users@subversion.apache.org | >| |> | Date: | |> >| |02/23/2011 09:04 PM | >| |> | Subject: | |> >| |Re: ^M Appends to every line? | >| On Feb 23, 2011, at 19:48, David Chapman wrote: > On 2/23/2011 4:44 PM, Nico Kadel-Garcia wrote: >> On Wed, Feb 23, 2011 at 11:39 AM, Les Mikesell wrote: >>> Short version: set the svn:eol-style property to native on the files where >>> you want subversion to manage line endings. Your client may have a list of >>> file suffixes where this would be set automatically. >> But in general, avoid it. If you're in a mixed platform environment, >> and you are tweaking files back and forth in end-of-line settings when >> you check them out in UNIX versis checking them out in Windows, you >> are in for a *world* of hurt. This is a source of enormous confusion >> for programmers when it works right, on one system, but not on the >> other due to local re-writing. >> >> If you're on the UNIX or Linux sides, the "dos2unix" and "unix2dos" >> utilities are available with almost every distribution. For Windows, >> there are other tools, including the same tools under CygWin. > > Uh, no. Use of "svn:eol-style" avoids a world of hurt - programmers do not have to run a script *every* time they check out a file. Requiring users to run a script to fix line endings in every sandbox is a recipe for disaster. > > "dos2unix" and "unix2dos" are precisely the kind of local rewriting you want to avoid. Some have the view that setting svn:eol-style to native is a problem; perhaps that's what Nico meant. Certainly, it would be a problem (wouldn't work as designed) if you check out a working copy on a platform with one eol convention (e.g. Mac OS X) and move that working copy to an OS with a different eol convention (e.g. Windows). If that is something you plan to do, the alternative is to still use svn:eol-style but set it to a specific eol style instead -- for example LF. Then you would have to configure all your editors on all platforms to use that line ending style.* * Actually it does not matter if the editor decided, for example, to completely convert the file from, say, LF to CRLF line endings. On commit, your Subversion client would notice the change and convert it back to just LF before submitting it to the repository. The situation Subversion won't handle for you, and will a
Re: path based authorization, how to handle folder name with whitespace in auth file
Hi, yep indeed this was the first thing I tried. Thanks for all the replies. simply using [myrepo:/foo bar] works. The error was an unnecessary space in the declaration of the user group @G_special_group So a simple typo. Thank you all again. Necati On Wed, Feb 23, 2011 at 6:03 PM, Daniel Shahaf wrote: > Necati Mercan wrote on Wed, Feb 23, 2011 at 14:12:19 +0100: >> How do I specify a folder with whitespaces in its name? Tried single >> quotes, double quotes, %20 but to be honest it is irritating. > > Have you tested just > > [/foo bar] > > ? >
Problem when config SVN to the root of a sub domain name
I want to set 'svn.x.com' as the root of a svn repository, so I use apache's directive to make all request to this sub domain forward to svn system, and It performs well when just reading from web interface. But I got problem with commitment, The error log shows below: [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] (20014)Internal error: Can't open file '/usr/local/svn/repos/error/format': No such file or directory [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not fetch resource information. [500, #0] [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not open the requested SVN filesystem [500, #2] [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not open the requested SVN filesystem [500, #2] -- I then found Problems can be resolve if I use directive, and visit 'svn.xxx.com/repos' as the root of repository, could someone tell me why and what is the cause of this problem? Thanks! Best Regards, Ben Cao
Re: Compile Subversion 1.6.5 on SLES 11.1
On Thu, Feb 24, 2011 at 11:45:04AM +0100, Sperling Stefan wrote: > On Thu, Feb 24, 2011 at 11:07:35AM +0100, Stutz Oliver wrote: > > Hi Stefan, > > > > Thanks for your many replies. > > > > The Reason why i want to doit like that is because SLES 11.1 > > Subversion from the repository is not available. (We use a company > > internal SLES repository which is under specific company restrictions > > & security policies) but if you can confirm to me that the packages > > provided in the email will work on 11.1 without an upgrade to 11.2 or > > 11.3 > > > There doesn't seem to be any SLES 11.2 or later release. > SLES 11.1 is the latest (it's labelled as "SLES 11 service pack 1" > on the novell website). > > There aren't any separate Subversion package repositories for point > releases of any SLES version on the build service. > I suppose that's because all the point releases seem to contain is > security and bug fixes. Browsing the release notes for 11.1 at > http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP1/ > there don't seem to be any changes that would prevent subversion > packages compiled for SLES 11 to stop working on SLES 11.1. > The list at > http://en.opensuse.org/openSUSE:Build_Service_supported_build_targets > doesn't list SLES 11.1 separately either. > > > I would be very happy (it would be awesome and safe worktime). > > Not only does it save time, it also makes it easier to get important > bugfixes quickly. The packages on the build service are kept up-to-date. > Whenever a new Subversion release is made, there will be a corresponding > update on the buildservice a few days later (and especially fast if the > new Subversion release fixes security issues). You can receive this update > via yast just like any other update. I forgot to mention one thing: You might also want to check if using packages from the buildservice has any effect on support agreements with Novell. I don't know anything about that, because I'm not a Novell employee nor a SUSE developer. I'm just helping out with maintaining the packages created by the buildservice. Those packages eventually end up in new SLES distribution releases, but I have no idea what Novell's policy is on support for packages from the buildservice for existing SLES releases. The same concerns about support might apply to self-compiled binaries, BTW. It's even possible that Novell prefers that customers use buildservice binaries instead of compiling their own. But I don't know. Ask them :) Novel is likely to independently backport security fixes to the Subversion release they're suppoting. So you should only use buildservice packages if they contains fixes for problems that affect you and which standard SLES 11 updates do not provide fixes for. I suppose this is the case as you'd otherwise not try to compile your own binaries in the first place.
Re: Compile Subversion 1.6.5 on SLES 11.1
On Thu, Feb 24, 2011 at 11:07:35AM +0100, Stutz Oliver wrote: > Hi Stefan, > > Thanks for your many replies. > > The Reason why i want to doit like that is because SLES 11.1 > Subversion from the repository is not available. (We use a company > internal SLES repository which is under specific company restrictions > & security policies) but if you can confirm to me that the packages > provided in the email will work on 11.1 without an upgrade to 11.2 or > 11.3 There doesn't seem to be any SLES 11.2 or later release. SLES 11.1 is the latest (it's labelled as "SLES 11 service pack 1" on the novell website). There aren't any separate Subversion package repositories for point releases of any SLES version on the build service. I suppose that's because all the point releases seem to contain is security and bug fixes. Browsing the release notes for 11.1 at http://www.novell.com/linux/releasenotes/x86_64/SUSE-SLES/11-SP1/ there don't seem to be any changes that would prevent subversion packages compiled for SLES 11 to stop working on SLES 11.1. The list at http://en.opensuse.org/openSUSE:Build_Service_supported_build_targets doesn't list SLES 11.1 separately either. > I would be very happy (it would be awesome and safe worktime). Not only does it save time, it also makes it easier to get important bugfixes quickly. The packages on the build service are kept up-to-date. Whenever a new Subversion release is made, there will be a corresponding update on the buildservice a few days later (and especially fast if the new Subversion release fixes security issues). You can receive this update via yast just like any other update.
Re: Compile Subversion 1.6.5 on SLES 11.1
Hi Stefan, Thanks for your many replies. The Reason why i want to doit like that is because SLES 11.1 Subversion from the repository is not available. (We use a company internal SLES repository which is under specific company restrictions & security policies) but if you can confirm to me that the packages provided in the email will work on 11.1 without an upgrade to 11.2 or 11.3 I would be very happy (it would be awesome and safe worktime). Thanks, Oliver >>> Stefan Sperling 2/24/2011 10:29 am >>> On Thu, Feb 24, 2011 at 07:50:51AM +0100, Stutz Oliver wrote: > Hello everybody, > > I have problems compiling Subversion with Apache support on SLES 11.1 it says > the zlib should be compiled with -fPIC flag. It is the version which came > with subversion which i have intalled into /opt/zlib isn't this supposed to > be working alright? Can maybe somebody give me a good Guide which has all the > steps in it or tell me what i'am doing wrong? I have read the "-fPIC" Error > Site from Gentoo because this was the site google was spitting out but i seem > to have lack of understanding about the makefiles and where to place this > -fPIC argument if it is really required. > > Thanks already for the help provided. > > /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: > /opt/zlib/lib/libz.a(deflate.o): relocation R_X86_64_32S against `.rodata' > can not be used when making a shared object; recompile with -fPIC > /opt/zlib/lib/libz.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1 No idea. Any reason you're not using the latest Subversion binaries from the OpenSUSE/SLES buildservice (apart from the fact that it seems to be down at the moment)? Those binaries are maintained by SUSE developers with help from other people (including myself), have been automatically packaged and tested and are ready to be installed via yast. They are of the same quality as can be expected from the Subversion packages that ship on the distribution media. If you are going to go through the effort of building your own binaries, 1.6.5 seems like an odd choice. You might as well try to build 1.6.15 which is the current stable release. Based on previous e-mail correspondence with you and/or an agreement reached with you, we consider ourselves authorized to contact you via unsecured e-mail. Warning: (a) E-mails can involve SUBSTANTIAL RISKS, e.g. lack of confidentiality, potential manipulation of contents and/or sender's address, incorrect recipient (misdirection), viruses etc. We assume no responsi-bility for any loss or damage resulting from the use of e-mails. We recommend in particular that you do NOT SEND ANY SENSITIVE INFORMATION, that you do not include details of the previous message in any reply, and that you enter e-mail address(es) manually every time you write an e-mail. (b) As a matter of principle, we do NOT accept any ORDERS, revocations of orders or authorizations, blocking of credit cards, etc., sent by e-mail Should such an e-mail nevertheless be received, we are not obliged to act on or respond to the e-mail. Please notify us immediately if you received this e-mail by mistake or if you do not wish to receive any further e-mail correspondence. If you have received this e-mail by mistake, please completely delete it (and any attachments) and do not forward it or inform any other person of its contents.
Re: Compile Subversion 1.6.5 on SLES 11.1
On Thu, Feb 24, 2011 at 10:29:24AM +0100, Stefan Sperling wrote: > Any reason you're not using the latest Subversion binaries from the > OpenSUSE/SLES buildservice (apart from the fact that it seems to be down at > the moment)? Looks like they've fixed it. Here's a link to latest Subversion packages for SLE 11: https://build.opensuse.org/package/binaries?package=subversion&project=devel%3Atools%3Ascm%3Asvn&repository=SLE_11 If you add the repository linked from this page to yast you can install the packages via yast.
Re: Merge Conflict on Windows with eol-style & mergeinfo properties
On Thu, Feb 24, 2011 at 12:56 AM, Varnau, Steve (Neoview) wrote: > Hi, > > I could not find this issue in the issue tracker. We’re trying to keep the > svn:mergeinfo properties on top-level directories, but I found a few text > files in our repository that have the property. When a merge is done that > should be just a branch synch-up merge, the files are marked as conflicted, > and the entire file is one big conflict, as if it is an EOL character > problem. > > All of the files that are marked as conflicted have in common two > properties. They have an svn:mergeinfo, and they have svn:eol-style = > native. Both branches have the same svn:eol-style value. The text file that > did not have an svn:eol-style property merged just fine. > > When the files are edited (Tortoise “Edit conflicts”) it shows no conflicts > -- merge with no problem. Looking at the files, there are no EOL character > differences. Both sides (left & right files, and both sides of the working > conflict file) have CRLF. > > The files also merge fine on Linux. > The files also merge fine if given the option to ignore end-of-line. > The problem occurs whether the merge is done via Tortoise or command-line on > Windows. > Svn version 1.6.15. > > Somehow it seems to be giving up merging these files only when there is a > svn:mergeinfo property. > > I will try to just remove the mergeinfo property on all the files, but > wondered if this is a general bug. I think this is the following issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3657 - dav update report handler in skelta mode can cause spurious conflicts (this issue previously had another summary: "phantom svn:eol-style changes cause spurious merge text conflicts", which may sound more recognizable, but this was later changed when they found out more about the issue). It describes more or less the same situation: a merge with some prop change which happens together with a text change, and the entire file is marked as conflicted. I've run into this situation myself a couple of times (I then just resolved the conflict by choosing "theirs-full" or something, after having assured myself that this was indeed the issue). It's fixed in svn trunk, so scheduled to be in the upcoming 1.7 release. AFAIK, it's not currently nominated for backport to 1.6. Cheers, -- Johan
Re: Shared/Common files in SVN
On Thu, Feb 24, 2011 at 08:46:27AM +0100, Marco Burato wrote: > >Have you seen this helper script? It might help. > >https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py > > > >Having a feature like this in core svn would be nice, of course. > >And it has in fact been discussed before. But nobody has stepped up yet > >to finish the proposed design and implement it. > > > >See this mail and follow-ups (click on the tiny>> arrows next to the > >word "Thread" in the top-right corner to see them): > >http://mail-archives.apache.org/mod_mbox/subversion-dev/200911.mbox/%3cpine.bso.4.62.0911190340420.23...@uruz.rola.local%3E > > I see, so this feature is planned and is called "views", it was > proposed more than a year ago. > The script seems to do the trick but it can't be used with clients > like TortoiseSVN. Yes, that's the current situation. However, it's not fair to say that it cannot be used with clients like TortoiseSVN. The script requires a command line client to operate, but what it does to a working copy is of course compatible with other clients, including TortoiseSVN.
Re: Compile Subversion 1.6.5 on SLES 11.1
On Thu, Feb 24, 2011 at 07:50:51AM +0100, Stutz Oliver wrote: > Hello everybody, > > I have problems compiling Subversion with Apache support on SLES 11.1 it says > the zlib should be compiled with -fPIC flag. It is the version which came > with subversion which i have intalled into /opt/zlib isn't this supposed to > be working alright? Can maybe somebody give me a good Guide which has all the > steps in it or tell me what i'am doing wrong? I have read the "-fPIC" Error > Site from Gentoo because this was the site google was spitting out but i seem > to have lack of understanding about the makefiles and where to place this > -fPIC argument if it is really required. > > Thanks already for the help provided. > > /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: > /opt/zlib/lib/libz.a(deflate.o): relocation R_X86_64_32S against `.rodata' > can not be used when making a shared object; recompile with -fPIC > /opt/zlib/lib/libz.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1 No idea. Any reason you're not using the latest Subversion binaries from the OpenSUSE/SLES buildservice (apart from the fact that it seems to be down at the moment)? Those binaries are maintained by SUSE developers with help from other people (including myself), have been automatically packaged and tested and are ready to be installed via yast. They are of the same quality as can be expected from the Subversion packages that ship on the distribution media. If you are going to go through the effort of building your own binaries, 1.6.5 seems like an odd choice. You might as well try to build 1.6.15 which is the current stable release.
