path based authorization, how to handle folder name with whitespace in auth file
Hi, if this is an accidental double post, my apologizes. I'm using svn-version 1.4.6, apache version 2.2.8 on an ubuntu 8.04 LTS. On the client side, mostly win xp with tortoisesvn. The setup is using https and path-based-authorization and everything was working fine. Users are separated into different groups, not everyone has access everywhere and on every repository. The situation at hand. In the authorization file dav_svn.authz: [myrepo:/] @G_everyone= @G_general_myrepo_group=rw [myrepo:/foobar] @G_special=rw This setup worked until foobar got renamed into foo bar. I want to give also the @G_special access to the folder foo bar. How do I specify a folder with whitespaces in its name? Tried single quotes, double quotes, %20 but to be honest it is irritating. Simply don't know truly how the modules and apache interact and work, therefore no clue how to specify the path in the auth-file. Trial and error didn't work, searching for the topic also didn't provide answers that work. Or I just made a typo somewhere. It must be something simple. I hope you can help me or point me to documentation that covers the necessary topics. Thank you in advance, Necati Mercan
SVN: Out of memory when committing
Hello, I've just began in a new job and, due to the repo organization, I've found a problem I didn't have before. I'm using the command line version of svn: svn, version 1.6.15 (SlikSvn/1.6.15) WIN32 compiled Dec 17 2010, 14:03:07 I am getting the Out of memory - terminating application message when checking in, without any regard to size of working copy or changes. I have got to the point of knowing what cause it; the repo goes kind of: / ├──j │ ├──1 │ │ ├──release │ │ └──trunk │ ├──2 │ └──3 └──l ├──l1 │ ├──release │ ├──trunk │ ├──v5 │ └──v6 ├──l2 └──l3 I have a local copy of some of it, with the same structure (beginning at root), for example: C:\repo ├──j │ └──1 │ └──trunk └──l └──l1 └──trunk Now I want to make big changes to l/l1, so I cd /repo/l/l1; svn co .../repo/l/l1/trunk my_trunk, change whatever, cd into my_trunk, and the checkin will fail as described. Workarounds: 1) put aside trunk, rename my_trunk to trunk and check in 2) move my_trunk out of the local repository (ie. into /tmp/my_trunk) and commit that. Related, AFAICS, to issue 3540http://subversion.tigris.org/issues/show_bug.cgi?id=3540. I'd say it's a P2 more than a P3, as I have found it every time I have committed. Any easier way? Changing the repo is not an option, but some change in how i keep the working copy could be possible... Regards, Óscar
path-based authorization, whitespace in foldername
Hi, I'm using svn-version 1.4.6, apache version 2.2.8 on an ubuntu 8.04 LTS. On the client side, mostly win xp with tortoisesvn. The setup is using https and path-based-authorization and everything was working fine. Users are separated into different groups, not everyone has access everywhere and on every repository. The situation at hand. In the authorization file dav_svn.authz: [myrepo:/] @G_everyone= @G_general_myrepo_group=rw [myrepo:/foobar] @G_special=rw This setup worked until foobar got renamed into foo bar. I want to give also the @G_special access to the folder foo bar. How do I specify a folder with whitespaces in its name? Tried single quotes, double quotes, %20 but to be honest it is irritating. Simply don't know truly how the modules and apache interact and work, therefore no clue how to specify the path in the auth-file. It must be something simple. I hope you can help me or point me to documentation that covers the necessary topics. Thank you in advance, Necati Mercan
Shared/Common files in SVN
Hi, i'd like to propose a new feature/improvement to SVN. Some users have projects that share some files, usually the layout would be something like this: \Common \Project1 \Project2 \Project3 When working on a project, the developer needs to checkout the Project directory and also the Common directory, which contains the files shared between the projects. This can't be directly handled by SVN in a single checkout, there are workarounds but they have limitations: 1) Double checkout Using this method the developer have to checkout the Project dir and the Common dir separately. This means that they also have to ensure they're checking out the same revision from both, and they also need to handle commit/updates between them. In other words they must do everything manually with the risk of doing something wrong with revisions. 2) Files / library copy This consists on making copy of the shared files in the project dir, or make a library for them and copy it to the project directory The library approach seems to be the the best solution but there are situations in which this can't be done, for example if a shared file is an header. Also, if the shared files must be edited this means the developer have to checkout the Common dir any way and edit the project to use it while testing, and finally to rebuild the library and copy it to the project. 3) Externals The externals method is near the solution, it consists in adding an external directory inside the project which points to the Common dir. The main problem is that externals are not in sync with the main checkout, they refer to HEAD revision by default, or a specific revision. To checkout a past revision of the project the only solution is to use a specific revision in externals. This means that after committing a change to the common files the externals revision in the project must be manually updated. Possible solutions: 1) Improved sparse directories Sparse directories would be a solution, but they only work varying the depth of the checkout. If we could add a property or something to specify which directories must be included in the checkout than it would work as needed. 2) Improved externals Externals problem is that they don't follow the revision of their parent. By specifying an option like -r BASE in the svn:externals property it would be possible to do so, solving the problem. I'd like to hear some considerations by experienced users, to understand if there are other solutions or some drawbacks in the proposed ones. References: http://stackoverflow.com/questions/135361/subversion-and-shared-files-across-repositories-projects http://stackoverflow.com/questions/4917328/svn-shared-checkout-folders http://stackoverflow.com/questions/1411681/source-control-products-that-support-linked-shared-files http://stackoverflow.com/questions/249787/sharing-files-in-svn http://stackoverflow.com/questions/909598/how-the-shared-files-linked-files-in-vss-can-be-migrated-to-a-subversion-reposi http://svn.haxx.se/users/archive-2005-02/1135.shtml -- Marco Burato
Re: Shared/Common files in SVN
On Wed, Feb 23, 2011 at 02:04:15PM +0100, Marco Burato wrote: 1) Improved sparse directories Sparse directories would be a solution, but they only work varying the depth of the checkout. If we could add a property or something to specify which directories must be included in the checkout than it would work as needed. 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
^M Appends to every line?
I have SVN up and running and things are working well, except when editing shell scripts from windows. My server is RHEL5-based and I will have clients connecting from linux and windows. Linux commits work great, and even some times from windows. However some times I commit a file from Windows(running tortoiseSVN and Komodo EDIT) it corrupts the script and adds ^M to the end of every line, often times ruining the structure of the file too. Is there a way to disable this or do I have to run a dos2unix script after every commit to remove them?
Re: ^M Appends to every line?
On 2/23/2011 8:19 AM, Christopher D Haakinson wrote: I have SVN up and running and things are working well, except when editing shell scripts from windows. My server is RHEL5-based and I will have clients connecting from linux and windows. Linux commits work great, and even some times from windows. However some times I commit a file from Windows(running tortoiseSVN and Komodo EDIT) it corrupts the script and adds ^M to the end of every line, often times ruining the structure of the file too. Is there a way to disable this or do I have to run a dos2unix script after every commit to remove them? Look up propset and eol-style. In particular, in the [auto-props] section of my configuration file I have a number of lines of the form *.c = svn:eol-style=native *.txt = svn:eol-style=native *.pl = svn:eol-style=native;svn:executable I do this both in Windows and in Linux so that I don't have files with only ^J when I check them out under Windows. You can also add this property manually after the files are committed: svn propset svn:eol-style=native file1 file2 ... Since you are seeing ^M now, you will need to do this manually for the affected files. Other useful commands: svn proplist file svn propget svn:eol-style file where file is the name of the file you are looking at. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: path based authorization, how to handle folder name with whitespace in auth file
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] ?
Using svn+ssh with only 1 ssh account can I have multiple svn accounts?
I only have 1 ssh account in a server that I don't control and I access svn using svn+ssh (again, only way to access it). Still, is it possible to have multiple svn users? I don't want for all commits to come from my ssh user... (i'm guessing it's not possible, that's why I'm asking :) )
Re: Using svn+ssh with only 1 ssh account can I have multiple svn accounts?
On Wed, Feb 23, 2011 at 05:54:39PM -, cifroes wrote: I only have 1 ssh account in a server that I don't control and I access svn using svn+ssh (again, only way to access it). Still, is it possible to have multiple svn users? I don't want for all commits to come from my ssh user... (i'm guessing it's not possible, that's why I'm asking :) ) It is possible as long as you use ssh public key authentication. See the book here: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
RE: Using svn+ssh with only 1 ssh account can I have multiple svn accounts?
OK, I configured it and it's working OK with that configuration. My problem now is with authz configuration. Can I control path access to specific users in this environment? I ask because I tried and I'm always getting access denied: - I set my tunnel user to user1 - svnserve.conf has anon and auth-access to none - authz has [/] user1 = rw And when I try to update/commit I get authorization failed. Is this impossible in this environment or am I doing something wrong? thanks -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Wed 2/23/2011 6:12 PM To: cifroes Cc: users@subversion.apache.org Subject: Re: Using svn+ssh with only 1 ssh account can I have multiple svn accounts? On Wed, Feb 23, 2011 at 05:54:39PM -, cifroes wrote: I only have 1 ssh account in a server that I don't control and I access svn using svn+ssh (again, only way to access it). Still, is it possible to have multiple svn users? I don't want for all commits to come from my ssh user... (i'm guessing it's not possible, that's why I'm asking :) ) It is possible as long as you use ssh public key authentication. See the book here: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
Welcome Atlassian Crowd and Apache users.
The latest 2.0 version of the Crowd Apache Connector is available but only for Centos and RedHat. Clearvision is considering investing time to build the 2.0 version for Windows or Ubuntu but we want your feedback. Please take 30 seconds to vote which platform you would like to see supported next http://www.surveymonkey.com/s/65686X5.
Re: path based authorization, how to handle folder name with whitespace in auth file
On Feb 23, 2011, at 07:12, Necati Mercan wrote: I'm using svn-version 1.4.6, apache version 2.2.8 on an ubuntu 8.04 LTS. Please upgrade; 1.4.x and earlier are not supported anymore.
Merge Conflict on Windows with eol-style mergeinfo properties
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. -Steve
Re: path-based authorization, whitespace in foldername
On Wed, Feb 23, 2011 at 5:20 AM, Necati Mercan bonnechance.m...@googlemail.com wrote: Hi, I'm using svn-version 1.4.6, apache version 2.2.8 on an ubuntu 8.04 LTS. On the client side, mostly win xp with tortoisesvn. The setup is using https and path-based-authorization and everything was working fine. Users are separated into different groups, not everyone has access everywhere and on every repository. The situation at hand. In the authorization file dav_svn.authz: [myrepo:/] @G_everyone= @G_general_myrepo_group=rw [myrepo:/foobar] @G_special=rw This setup worked until foobar got renamed into foo bar. I want to give also the @G_special access to the folder foo bar. How do I specify a folder with whitespaces in its name? Tried single quotes, double quotes, %20 but to be honest it is irritating. Simply don't know truly how the modules and apache interact and work, therefore no clue how to specify the path in the auth-file. Can't you just not use folders with spaces in the names? You can avoid a world of scripting and software management pain by not doing this.
Re: ^M Appends to every line?
On 2/23/2011 4:44 PM, Nico Kadel-Garcia wrote: On Wed, Feb 23, 2011 at 11:39 AM, Les Mikeselllesmikes...@gmail.com wrote: On 2/23/2011 10:19 AM, Christopher D Haakinson wrote: I have SVN up and running and things are working well, except when editing shell scripts from windows. My server is RHEL5-based and I will have clients connecting from linux and windows. Linux commits work great, and even some times from windows. However some times I commit a file from Windows(running tortoiseSVN and Komodo EDIT) it corrupts the script and adds ^M to the end of every line, often times ruining the structure of the file too. Is there a way to disable this or do I have to run a dos2unix script after every commit to remove them? Long version: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.file-portability 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. My two cents (and one million lines of code) worth... -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: ^M Appends to every line?
As others have mentioned, you need to set svn:eol-style on files that MUST have particular line endings. For example, shell scripts and Makefiles MUST have Unix line endings. DOS Batch files MUST have Windows line endings. You might need to check everything out, clean it up, and set the property on it. I have a pre-commit hook and one of the things you can do is to force users to set a property to a particular value on specified files. If the property isn't on the file, you can't commit the change. You can get it from here: http://db.tt/H3o1i7S. If you're using Ant, take a look at the FixCRNL task when you do your builds. On Wed, Feb 23, 2011 at 11:19 AM, Christopher D Haakinson cdhaa...@us.ibm.com wrote: I have SVN up and running and things are working well, except when editing shell scripts from windows. My server is RHEL5-based and I will have clients connecting from linux and windows. Linux commits work great, and even some times from windows. However some times I commit a file from Windows(running tortoiseSVN and Komodo EDIT) it corrupts the script and adds ^M to the end of every line, often times ruining the structure of the file too. Is there a way to disable this or do I have to run a dos2unix script after every commit to remove them? -- David Weintraub qazw...@gmail.com
Re: ^M Appends to every line?
On Wed, Feb 23, 2011 at 8:48 PM, David Chapman dcchap...@acm.org wrote: On 2/23/2011 4:44 PM, Nico Kadel-Garcia wrote: On Wed, Feb 23, 2011 at 11:39 AM, Les Mikeselllesmikes...@gmail.com 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. My two cents (and one million lines of code) worth... Not when the same working working copy is accessible from both Linux or UNIX, and Windows, as is commonplace in a mixed platform environment. If your working copies on each platform are distinct, you should be able to get away with it. But hit the same checked out Windows repository with TortoiseSVN and CygWin, and suddenly you're in a world of hurt again with the non-binary handling of EOL. Some text editors will autoparse it for you, but it can get extremely nasty, and I've had to clean up some serious messes this way. The messes are aggravated by the lack of the obliterate function, to entirely strip out erroneously configured file additions, and the difficulty running diff operations against files that have been stored and had their EOL settings updated and their contents revised. It really messes with svn diff operations before and after the change.
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 abort the commit with an error message, is if your editor decides to save a file with mixed line endings. Such editors are broken IMHO. UltraEdit is an example of an editor we used which was broken in this way, unless you remembered to change a particular preference setting. NOT using svn:eol-style at all will remove all eol checks that Subversion does, and if you are using multiple editors on multiple platforms, you will most probably end up with files of mixed line ending styles. THAT is a recipe for disaster.
Re: Subverion 1.7 Centralized Metadata Storage
(2011/02/22 17:18), Ulrich Eckhardt wrote: On Tuesday 22 February 2011, Nguyen Vu Hung (VNC) wrote: * This way makes svn git-like :), my first impression is that: subversion will be distributed, not centralized :) SVN has one .svn directory in every (versioned) child directory of a working copy. This has the effect that every child directory of a working copy is itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a single place to store this. This is a handy replacement for svn export function. Backward compatibility with 1.6 is another big concern who wants to upgrade from 1.6 or maintaining an ecosystem of both 1.6 and 1.7
Re: ^M Appends to every line?
On 2/23/11 8:03 PM, Nico Kadel-Garcia wrote: 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. My two cents (and one million lines of code) worth... Not when the same working working copy is accessible from both Linux or UNIX, and Windows, as is commonplace in a mixed platform environment. There are lots of ways to cause trouble. My opinion is that if it hurts, don't do it. And that will hurt. If your working copies on each platform are distinct, you should be able to get away with it. But hit the same checked out Windows repository with TortoiseSVN and CygWin, and suddenly you're in a world of hurt again with the non-binary handling of EOL. Some text editors will autoparse it for you, but it can get extremely nasty, and I've had to clean up some serious messes this way. More things that hurt - and to avoid. But setting eol-style native and using normal, native tools on each OS isn't one of them. The messes are aggravated by the lack of the obliterate function, to entirely strip out erroneously configured file additions, and the difficulty running diff operations against files that have been stored and had their EOL settings updated and their contents revised. It really messes with svn diff operations before and after the change. Any time you use dos2unix or the like it is going to be a change in every line and will screw up any concept of version differences. If svn does it internally, you don't have that problem. -- Les Mikesell lesmikes...@gmail.com
Re: Subverion 1.7 Centralized Metadata Storage
On Thu, Feb 24, 2011 at 12:16 PM, Nguyen Vu Hung (VNC) vuh...@vinicorp.com.vn wrote: (2011/02/22 17:18), Ulrich Eckhardt wrote: On Tuesday 22 February 2011, Nguyen Vu Hung (VNC) wrote: * This way makes svn git-like :), my first impression is that: subversion will be distributed, not centralized :) SVN has one .svn directory in every (versioned) child directory of a working copy. This has the effect that every child directory of a working copy is itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a single place to store this. This is a handy replacement for svn export function. Backward compatibility with 1.6 is another big concern who wants to upgrade from 1.6 or maintaining an ecosystem of both 1.6 and 1.7 How will this be any different from maintaining an ecosystem of 1.5 and 1.6? Cheers, Daniel B.
Re: ^M Appends to every line?
On Wed, 2011-02-23 at 20:03 -0600, Ryan Schmidt wrote: On Feb 23, 2011, at 19:48, David Chapman wrote: On 2/23/2011 4:44 PM, Nico Kadel-Garcia wrote: On Wed, Feb 23, 2011 at 11:39 AM, Les Mikesell wrote: Short version: set the svn:eol-style property to native on the files where you want subversion to manage line endings. Your client may have a list of file suffixes where this would be set automatically. But in general, avoid it. If you're in a mixed platform environment, and you are tweaking files back and forth in end-of-line settings when you check them out in UNIX versis checking them out in Windows, you are in for a *world* of hurt. This is a source of enormous confusion for programmers when it works right, on one system, but not on the other due to local re-writing. If you're on the UNIX or Linux sides, the dos2unix and unix2dos utilities are available with almost every distribution. For Windows, there are other tools, including the same tools under CygWin. Uh, no. Use of svn:eol-style avoids a world of hurt - programmers do not have to run a script *every* time they check out a file. Requiring users to run a script to fix line endings in every sandbox is a recipe for disaster. dos2unix and unix2dos are precisely the kind of local rewriting you want to avoid. Some have the view that setting svn:eol-style to native is a problem; perhaps that's what Nico meant. Certainly, it would be a problem (wouldn't work as designed) if you check out a working copy on a platform with one eol convention (e.g. Mac OS X) and move that working copy to an OS with a different eol convention (e.g. Windows). If that is something you plan to do, the alternative is to still use svn:eol-style but set it to a specific eol style instead -- for example LF. Then you would have to configure all your editors on all platforms to use that line ending style.* * Actually it does not matter if the editor decided, for example, to completely convert the file from, say, LF to CRLF line endings. On commit, your Subversion client would notice the change and convert it back to just LF before submitting it to the repository. The situation Subversion won't handle for you, and will abort the commit with an error message, is if your editor decides to save a file with mixed line endings. Such editors are broken IMHO. UltraEdit is an example of an editor we used which was broken in this way, unless you remembered to change a particular preference setting. Another example is emacs (the one true ring (um) editor). But only if there were mixed line endings to begin with. NOT using svn:eol-style at all will remove all eol checks that Subversion does, and if you are using multiple editors on multiple platforms, you will most probably end up with files of mixed line ending styles. THAT is a recipe for disaster. I have in the past tried to use a smb exported share form a unix box on a windows client. Don't do that, nothing but trouble. -- Tony Butt tony.b...@cea.com.au CEA Technologies
Compile Subversion 1.6.5 on SLES 11.1
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. http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1chap=3#doc_chap2 Code Listing 6.1: A sample error message libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC .libs/assert.o: could not read symbols: Bad value This means that the file assert.o was not compiled with the -fPIC flag, which it should. When you fix this kind of error, make sure only objects that are used in shared libraries are compiled with -fPIC. Here is my workstep of course i have fixed already many of the library issues which i hadn't installed on the system eg. RSA_new ect. /configure --prefix=/opt/subversion --with-ssl --with-zlib=/opt/zlib make all *skipped* /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/utf_validate.lo -c subversion/libsvn_subr/utf_validate.c /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/validate.lo -c subversion/libsvn_subr/validate.c /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/version.lo -c subversion/libsvn_subr/version.c /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/win32_crashrpt.lo -c subversion/libsvn_subr/win32_crashrpt.c /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/win32_crypto.lo -c subversion/libsvn_subr/win32_crypto.c /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include -o subversion/libsvn_subr/win32_xlate.lo -c subversion/libsvn_subr/win32_xlate.c /bin/sh /tmp/subversion/subversion-1.6.5/libtool --tag=CC --silent --mode=compile gcc -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -g -O2 -pthread -I./subversion/include -I./subversion -I/tmp/subversion/subversion-1.6.5/apr/include -I/tmp/subversion/subversion-1.6.5/apr-util/include -I/tmp/subversion/subversion-1.6.5/neon/src -I/opt/subversion/include/neon -I/tmp/subversion/subversion-1.6.5/sqlite-amalgamation -I/opt/zlib/include
Re: Shared/Common files in SVN
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. Marco Burato
