Re: Question about authz file syntax.
On Fri, Feb 12, 2010 at 12:44 AM, David Brodbeck wrote: > Actually, I take that back, the manual says it's the *first* match: > "Another important fact is that the first matching rule is the one which gets > applied to a user." > (http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html) > This is actually incorrect. See this recent discussion on the dev mailinglist: http://svn.haxx.se/dev/archive-2010-01/0340.shtml The current documentation doesn't agree with how it actually behaves. The documentation will probably be fixed to describe the current behavior... I don't know if the behavior was different in 1.5 though. Johan
Website: please add some content from the old links page
Hi, it seems the old http://subversion.tigris.org/links.html page was not migrated to subversion.apache.org. While I can understand that it's quite a burden to maintain a lot of information about third party tools etc, I think that some of the content of that page should be added somewhere on the new apache site: e.g. links to sample hook scripts http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ Note that the page content is still reachable at http://svn.apache.org/viewvc/subversion/trunk/www/links.html?revision=884848&view=co&pathrev=900404 (thanks to the IRC folks on #svn for the hint :) Cri -- GPG/PGP Key-Id 0x943A5F0E -http://www.linux.it/~cri/cri.asc signature.asc Description: Digital signature
Subversion - Avoid Authentication for Public Repositories
Hi there For public (read-only to everyone repositories) such as example http://myrepository.com/Public users still get prompted with an authentication dialog., can we get rid of this, we have authenticated our subversion with LDAP, if I remove the "require valid -user" entry from subversion.conf, will it work Please suggest Regards Vishwanath Desk: +91 80 26588360 Extn: 48555
Re: Subversion - Avoid Authentication for Public Repositories
you will also On Fri, Feb 12, 2010 at 9:30 AM, Ramachandran, Vishwanath(IE10) < vishwanath.ramachand...@honeywell.com> wrote: > Hi there > > > > For public (read-only to everyone repositories) such as example > http://myrepository.com/Public users still get prompted with an > authentication dialog., can we get rid of this, we have authenticated our > subversion with LDAP, if I remove the “require valid –user” entry from > subversion.conf, will it work > you will also have to remove all auth related settings like AuthType and others; as far as I know just removing require valid-user will not work. -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://singhvishwajeet.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
Mail archive doesn't work
Hello, I can't see any message in FF while browsing mail archives. When I click message header a "Loading ..." box appears and nothing happens. http://mail-archives.apache.org/mod_mbox/subversion-announce/201001.mbox/browser Please, CC. BTW, are there any Subversion archives with ability to subscribe to individual threads (i.e. Google Groups or something)? -- anatoly t.
Re: Question about authz file syntax.
On Feb 12, 2010, at 1:27 AM, Johan Corveleyn wrote: > On Fri, Feb 12, 2010 at 12:44 AM, David Brodbeck > wrote: >> Actually, I take that back, the manual says it's the *first* match: >> "Another important fact is that the first matching rule is the one which >> gets applied to a user." >> (http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html) >> > > This is actually incorrect. See this recent discussion on the dev mailinglist: > http://svn.haxx.se/dev/archive-2010-01/0340.shtml > > The current documentation doesn't agree with how it actually behaves. > The documentation will probably be fixed to describe the current > behavior... > > I don't know if the behavior was different in 1.5 though. Ah, OK. So all the permission lines that apply to a user are ORed together? That would make sense, and wouldn't affect my setup because I'm explicitly naming all users who should have access and then blocking the rest with "* =". -- David Brodbeck System Administrator, Linguistics University of Washington
Maintaining large repositories
Hi, I have a repository that has been in use for well over a year and over this period the size on disk has grown to over 150 GB, I found that when running svnadmin dump, that the resulting dump file was at 46 GB on disk and then when loading the dump file into a new repository that the size on disk in the repository folder was 8 GB in total. What's disturbing is the drop in disk usage from 150 --> 46 --> 8 Gig. Does anyone have an explanation for this? Or rather is there a better way of freeing up disk space back to the OS? (we are using FS and not Berkley DB storage)
Re: Maintaining large repositories
On Fri, Feb 12, 2010 at 3:56 PM, Justin Connell wrote: > I have a repository that has been in use for well over a year and over this > period the size on disk has grown to over 150 GB, I found that when running > svnadmin dump, that the resulting dump file was at 46 GB on disk and then > when loading the dump file into a new repository that the size on disk in > the repository folder was 8 GB in total. > > What's disturbing is the drop in disk usage from 150 --> 46 --> 8 Gig. > > Does anyone have an explanation for this? > > Or rather is there a better way of freeing up disk space back to the OS? (we > are using FS and not Berkley DB storage) Generally speaking a dumpfile ought to be bigger than the repository. Are you sure you did not have some other files that had nothing to with SVN stored in the same filesystem location? Also, generally speaking, a dump load should produce an identical repository. A notable exception is when your version changes. For example, SVN 1.6 included a space saving feature called rep sharing that is allows duplicate items to only be stored one time. One of the earlier releases, perhaps 1.4?, included some zlib compression of contents that also saved space. So if you were coming from earlier versions and dumped and loaded into newer it would be expected to save space. The 150 GB repos to 46 GB dump does not sound right though. Was the dump produced with the --deltas option? That could explain it. A reduction from 150GB to 8 GB is not expected. Most people only see 10-20% savings from these changes. However, both rep-sharing and compression would be heavily influenced by the actual repository content. To answer what I think is your main question, it is not expected that you need to do ANY repository maintenance and it is not expected that a routine dump/load should cause disk space to be recovered. -- Thanks Mark Phippard http://markphip.blogspot.com/
Changing the "native" newline mode
Is there any way to change the native newline mode for a particular working copy? I'm checking out code in Linux, over a CIFS mount to a Windows machine where it's being used. This is much easier for me than any of the solutions involving Windows clients, but ends up with Unix line endings, leading to newline headaches. -- Glenn Maynard
RE: Changing the "native" newline mode
> Is there any way to change the native newline mode for a particular > working copy? > > I'm checking out code in Linux, over a CIFS mount to a Windows machine > where it's being used. This is much easier for me than any of the > solutions involving Windows clients, but ends up with Unix line > endings, leading to newline headaches. This is pretty well explained in the documentation book. Read about the svn:eol-style property. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.eol-style BOb
Re: Changing the "native" newline mode
On Feb 12, 2010, at 16:05, Bob Archer wrote: >> Is there any way to change the native newline mode for a particular >> working copy? >> >> I'm checking out code in Linux, over a CIFS mount to a Windows machine >> where it's being used. This is much easier for me than any of the >> solutions involving Windows clients, but ends up with Unix line >> endings, leading to newline headaches. > > This is pretty well explained in the documentation book. Read about the > svn:eol-style property. > > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.eol-style Bob, I think Glenn's saying that he has set svn:eol-style to native, and he's checking out on a UNIX OS but he wants the eol-style of the files to be native to Windows, not UNIX. Unfortunately, Glenn, I don't see a way to do that. svn export has an option for this, but svn checkout doesn't. --native-eol ARG : use a different EOL marker than the standard system marker for files with the svn:eol-style property set to 'native'. ARG may be one of 'LF', 'CR', 'CRLF' I used to work at a company where we had the same workflow. We decided to never use svn:eol-style native. Instead, we set svn:eol-style to LF, and configured our Windows editors to know how to deal with such files.
RE: Changing the "native" newline mode
> On Feb 12, 2010, at 16:05, Bob Archer wrote: > > >> Is there any way to change the native newline mode for a particular > >> working copy? > >> > >> I'm checking out code in Linux, over a CIFS mount to a Windows machine > >> where it's being used. This is much easier for me than any of the > >> solutions involving Windows clients, but ends up with Unix line > >> endings, leading to newline headaches. > > > > This is pretty well explained in the documentation book. Read about the > svn:eol-style property. > > > > http://svnbook.red-bean.com/nightly/en/svn- > book.html#svn.advanced.props.special.eol-style > > Bob, I think Glenn's saying that he has set svn:eol-style to native, and > he's checking out on a UNIX OS but he wants the eol-style of the files to > be native to Windows, not UNIX. > Ah I see. Then wouldn't he just specify svn:eol-style CRLF? Assuming he only every edits with Windows tools. Although I'm not sure why he wouldn't check out with a windows client. I'm not sure how connecting to a Linux machine to checkout to a folder mounted on a windows machine is easier than using the windows CLI. BOb
Re: Changing the "native" newline mode
On Fri, Feb 12, 2010 at 5:16 PM, Bob Archer wrote: > Ah I see. Then wouldn't he just specify svn:eol-style CRLF? Assuming he only > every edits with Windows tools. This isn't Windows-only code, and it's not code that only I'm touching. If someone's checking it out in Linux to compile in Linux normally, then it should have Unix line endings as usual. > Although I'm not sure why he wouldn't check out with a windows client. I'm > not sure how connecting to a Linux machine to checkout to a folder mounted on > a windows machine is easier than using the windows CLI. It's easier because it's a fully configured CLI that I already have running all the time, which does everything the way I want. I don't want to have to do half of my CLI work from a clumsy Cygwin window, especially since I have working copies in both Linux and Windows that I deal with simultaneously. > Instead, we set svn:eol-style to LF, and configured our Windows editors to > know how to deal with such files. Visual Studio just doesn't understand it. It'll load them and do basic editing fine, but copy/paste leads to mixed newlines. -- Glenn Maynard
Re: Changing the "native" newline mode
On Feb 12, 2010, at 16:32, Glenn Maynard wrote: >> Although I'm not sure why he wouldn't check out with a windows client. I'm >> not sure how connecting to a Linux machine to checkout to a folder mounted >> on a windows machine is easier than using the windows CLI. > > It's easier because it's a fully configured CLI that I already have > running all the time, which does everything the way I want. I don't > want to have to do half of my CLI work from a clumsy Cygwin window, > especially since I have working copies in both Linux and Windows that > I deal with simultaneously. Actually, doesn't cygwin also consider the native eol-style to be LF? I think if you want CRLF line endings, you have to use a "real" Windows client, not cygwin. Ryan Schmidt wrote: >> Instead, we set svn:eol-style to LF, and configured our Windows editors to >> know how to deal with such files. > > Visual Studio just doesn't understand it. It'll load them and do > basic editing fine, but copy/paste leads to mixed newlines. If you can't configure Visual Studio to understand LF line endings, and you cannot switch to an editor that understands LF line endings, then I agree you have a problem. I'm sorry, I don't have any more solutions. I do remember that years ago when we configured UltraEdit to understand LF line endings, there were four separate settings / checkboxes / radio buttons that had to be set a particular way on several different settings screens. It was a nightmare because one of our committers would inevitably forget to set one of the options and begin messing up the line endings.
RE: Changing the "native" newline mode
> > Although I'm not sure why he wouldn't check out with a windows client. > I'm not sure how connecting to a Linux machine to checkout to a folder > mounted on a windows machine is easier than using the windows CLI. > > It's easier because it's a fully configured CLI that I already have > running all the time, which does everything the way I want. I don't > want to have to do half of my CLI work from a clumsy Cygwin window, > especially since I have working copies in both Linux and Windows that > I deal with simultaneously. Use the native windows CLI. No clumsy Cygwin needed. But, to each his own. I would complain to MS about Studio mangling your line endings. Although my understanding was it supported Unix style line endings. BOb
Re: Changing the "native" newline mode
On Fri, Feb 12, 2010 at 6:23 PM, Bob Archer wrote: > Use the native windows CLI. No clumsy Cygwin needed. But, to each his own. What, CMD? That's an order of magnitude worse than Cygwin. > I would complain to MS about Studio mangling your line endings. Although my > understanding was it supported Unix style line endings. If Microsoft fixed problems that were pointed out to them, my life would be so much easier. Unfortunately, I'd have as much luck yelling my issues into the nearest sewer grate and hoping for help from a ninja turtle... -- Glenn Maynard
Re: Changing the "native" newline mode
Greetings, Glenn Maynard! >> Although I'm not sure why he wouldn't check out with a windows client. I'm >> not sure how connecting to a Linux machine to checkout to a folder mounted >> on a windows machine is easier than using the >> windows CLI. > It's easier because it's a fully configured CLI that I already have > running all the time, which does everything the way I want. I don't > want to have to do half of my CLI work from a clumsy Cygwin window, > especially since I have working copies in both Linux and Windows that > I deal with simultaneously. Cygwin checkout will give you LF-only line endings, just like what you are doing now. >> Instead, we set svn:eol-style to LF, and configured our Windows editors to >> know how to deal with such files. > Visual Studio just doesn't understand it. It'll load them and do > basic editing fine, but copy/paste leads to mixed newlines. Use AnkhSVN for example. Or native Windows build of Subversion. -- WBR, Andrey Repin (anrdae...@freemail.ru) 13.02.2010, <6:15> Sorry for my terrible english...
Re: Changing the "native" newline mode
Greetings, Glenn Maynard! > Is there any way to change the native newline mode for a particular > working copy? > I'm checking out code in Linux, over a CIFS mount to a Windows machine > where it's being used. This is much easier for me than any of the > solutions involving Windows clients, but ends up with Unix line > endings, leading to newline headaches. Don't do that. Check out it where it'll be used. -- WBR, Andrey Repin (anrdae...@freemail.ru) 13.02.2010, <6:14> Sorry for my terrible english...
Re: Changing the "native" newline mode
Greetings, Glenn Maynard! >> Use the native windows CLI. No clumsy Cygwin needed. But, to each his own. > What, CMD? That's an order of magnitude worse than Cygwin. First, CMD is quite powerful, if you know how to cook it. Second, http://jpsoft.com/ Third, I think Bob was referring to native Windows build of Subversion. Fourth, http://farmanager.com/. mc rest in peace, no way it could reach power of FAR even remotely. To say you the truth, FAR is the only program that hold me to the Windows. It can do everything (Yes, it can make you coffee) -- WBR, Andrey Repin (anrdae...@freemail.ru) 13.02.2010, <6:18> Sorry for my terrible english...
Re: Changing the "native" newline mode
On Fri, Feb 12, 2010 at 10:15 PM, Andrey Repin wrote: > Don't do that. Check out it where it'll be used. Telling people "don't do what you want to do; do what you don't want instead" is not helpful. > First, CMD is quite powerful, if you know how to cook it. It doesn't really matter how powerful it is. I've had fifteen years of practice to make me very efficient in Linux for commandline tasks. That's the reason I have a Linux box next to my Windows one: so I can use each for what they're good at. I'd recompile svn with a manual hack to change its notion of newlines before enduring CMD. -- Glenn Maynard
