Re: Can I prevent a file from being modified?
Guten Tag David Myers, am Samstag, 16. Juli 2011 um 22:14 schrieben Sie: > Please help me clarify this so as I can propose the use of a subversion > to my colleagues, and give eloquent and correct answers to any of their > queries. First of all, nothing is committed automatically by default and therefore can not be committed by accident. Even in your described scenario of accidently changing a file which shouldn't have changed, it doesn't get committed automatically. One has to commit the file as a separate process. It may be possible that the changed file gets committed by accident with other changes which should get committed, but this depends on your repository layout and therefore can be prevented by proper layout. So, do you really need the administrative overhead of making the file read only? If you really want it read only, I would just use path based authorization with a group which consists of all users which normally modify the files in question, therefore have granted write permissions and after they agree that nor further modification is needed, change write to read permissions. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.pathbasedauthz Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig Telefon: Potsdam: 0331-743881-0 E-Mail: tschoen...@am-soft.de Web: http://www.am-soft.de AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Subversion: via Apache
On 07/18/2011 09:34 AM, Geoff Hoffman wrote: Test your config with -t Option "-t" on what command line? "-t" for svnserve means "tunnel"; svnadmin and svn have no -t option.
Re: Subversion: via Apache
On 7/18/2011 3:43 AM, Andy Canfield wrote: On 07/18/2011 09:34 AM, Geoff Hoffman wrote: Test your config with -t Option "-t" on what command line? "-t" for svnserve means "tunnel"; svnadmin and svn have no -t option. This thread is about "Subversion: via Apache", so the Apache commandline :) Usage: httpd [-D name] [-d directory] [-f file] [-C "directive"] [-c "directive"] [-k start|restart|graceful|graceful-stop|stop] [-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S] Options: [...] -t : run syntax check for config files
Re: Subversion: list of respositories
On 07/18/2011 09:35 AM, Andy Levy wrote: Please Reply to All to keep discussion on the list. List convention is to bottom-post and quote inline. Please do not top-post. On Sun, Jul 17, 2011 at 22:29, Andy Canfield wrote: If I set up http://example.com/svn to be a way to use apache to communicate with the svn service on the example.com server then is pointing my browser to "http://example.com/svn"; supposed to give me some kind of web page? Because I do not remember seeing anything about that in the book. You're looking for SVNParentPath. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html My entry in httpd.conf contains an SVNParentPath line. I thought I sent that to you. Here (again) is the diff: *... diff httpd.conf.good httpd.conf.subversion 127c127 < #LoadModule dav_module libexec/apache2/mod_dav.so --- > LoadModule dav_module libexec/apache2/mod_dav.so 154c154 < #LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so --- > LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so 1501a1502,1515 > > # This spells out where the subversion repositories go > > DAV svn > # any "/svn/foo" URL will map to a repository /var/svn/foo > SVNParentPath /var/svn > # how to authenticate a user > AuthType Digest > AuthName "Subversion repository" > AuthDigestDomain /svn/ > AuthUserFile /etc/svn-auth-file > # only authenticated users may access the repository > Require valid-user > * On 07/17/2011 07:07 PM, Andy Levy wrote: On Sun, Jul 17, 2011 at 02:06, Andy Canfield wrote: How do you get a list of repositories from svnserver? The only way I can figure out is: sshusern...@example.com sudo bash ls -ld /var/svn/* And, of course, this makes an assumption about where on the server the repositories are located. There 'ought' to be an easier way. There is, but only if you serve via Apache.
Re: Subversion: list of respositories
On 07/18/2011 09:36 AM, Nico Kadel-Garcia wrote: On Sun, Jul 17, 2011 at 8:07 AM, Andy Levy wrote: On Sun, Jul 17, 2011 at 02:06, Andy Canfield wrote: How do you get a list of repositories from svnserver? The only way I can figure out is: ssh usern...@example.com sudo bash ls -ld /var/svn/* And, of course, this makes an assumption about where on the server the repositories are located. There 'ought' to be an easier way. There is, but only if you serve via Apache. Even then, it won't find repositories that are not built into the Apache layout or the elevant "parent" directory. I would think that it looks at SVNParentPath and tries to treat every subdirectory of that as a repository.
Re: Subversion: list of respositories
On Mon, Jul 18, 2011 at 4:56 AM, Andy Canfield wrote: > > > On 07/18/2011 09:36 AM, Nico Kadel-Garcia wrote: >> >> On Sun, Jul 17, 2011 at 8:07 AM, Andy Levy wrote: >>> >>> On Sun, Jul 17, 2011 at 02:06, Andy Canfield >>> wrote: How do you get a list of repositories from svnserver? The only way I can figure out is: ssh usern...@example.com sudo bash ls -ld /var/svn/* And, of course, this makes an assumption about where on the server the repositories are located. There 'ought' to be an easier way. >>> >>> There is, but only if you serve via Apache. >> >> Even then, it won't find repositories that are not built into the >> Apache layout or the elevant "parent" directory. > > I would think that it looks at SVNParentPath and tries to treat every > subdirectory of that as a repository. Not quite. It's not "every subdirectory", it's "every child directory". That means it will not descend into subdirectories of subdirectories, fir example, so they all need to be right there in /var/svn. Also, while symlinks to other locations may be acceptable to the mod_dav_svn module, the repositories need to be accessible to the "apache" user. This can get adventuresome if you're running svnserve or svn+ssh access without a devault svn+ssh user, used in parallel to Apache.
Re: Subversion: via Apache
On Mon, Jul 18, 2011 at 4:50 AM, Dave Huang wrote: > On 7/18/2011 3:43 AM, Andy Canfield wrote: >> >> On 07/18/2011 09:34 AM, Geoff Hoffman wrote: >>> >>> Test your config with -t >> >> Option "-t" on what command line? "-t" for svnserve means "tunnel"; >> svnadmin and svn have no -t option. > > This thread is about "Subversion: via Apache", so the Apache commandline :) > > Usage: httpd [-D name] [-d directory] [-f file] > [-C "directive"] [-c "directive"] > [-k start|restart|graceful|graceful-stop|stop] > [-v] [-V] [-h] [-l] [-L] [-t] [-T] [-S] > Options: > [...] > -t : run syntax check for config files Some httpd setups provide this in the init script, an "/etc/init.d/httpd configtest" option. Be careful to tease out the actual init options used by your init script: Debian hides a lot of them in /etc/default/apache2, for example.
Re: Subversion: list of respositories
> I would think that it looks at SVNParentPath and tries to treat every > > subdirectory of that as a repository. > > Not quite. It's not "every subdirectory", it's "every child > directory". That means it will not descend into subdirectories of > subdirectories, fir example, so they all need to be right there in > /var/svn. Also, while symlinks to other locations may be acceptable to > the mod_dav_svn module, the repositories need to be accessible to the > "apache" user. This can get adventuresome if you're running svnserve > or svn+ssh access without a devault svn+ssh user, used in parallel to > Apache. > While links are acceptable to mod_dav_svn, they won't appear in the repository listing. Note that you need the SVNListParent On statement in your Apache config to get a listing of the repositories. In 1.7 I've committed a small change to list symlinks to directories which will be part of 1.7. Bye, Erik.
When integrate with Apache, how to set subversion access with DOMAINNAME\UserName?
Hi, all I'm using subversion integrated with apache 2.2 with LDAP authorization on Windows 2003, the config of subversion in apache httpd.conf looks like this: DAV svn SVNParentPath "D:/SvnRepositories" SVNListParentPath On SVNReposName "Subversion Repositories" SVNIndexXSLT "/SvnStyle/svnindex.xsl" SVNAutoversioning On AuthType Basic AuthName "Subversion Repositories" AuthBasicProvider ldap AuthzLDAPAuthoritative off AuthLDAPBindDN "CN=SCMbot,OU=lab,DC=domainname,DC=com" AuthLDAPBindPassword "password" AuthLDAPURL "ldap://dc.domainname.com:389/DC=domainname,DC=com? sAMAccountName?sub?(objectClass=*)" None Require valid-user AuthzSVNAccessFile "D:\SvnRepositories\svnaccess.authz" This configuration works find, but when we access subversion repository, we can only use user name only; by example, I can access it with my domain account name "xinfli", but when I use "domainname \xinfli", it will failed. This is not a problem for intranet subversion using, but we need publish the code repository to internet with Microsoft Forefront Threat Management Gateway, every time we access subversion code repository, FF TMG will add domain name for user name by default (When been asked user name, I inputted "xinfli", but FF TMG will change it to "domainname\xinfli", and this will failed to access subversion). I did not find how to disable FF TMG to add domain name, So I hope I can find a way to set subversion to be access with "DOMAINNAME \UserName" account name format. Does someone has any suggestion? appreciate for any help. Thanks.
Re: Fwd: [Tony Butt: Trials with memcached]
On Sat, 2011-07-09 at 15:02 +0200, Stefan Fuhrmann wrote: > On 08.07.2011 01:56, Daniel Shahaf wrote: > > FYI from users@ > > > > - Forwarded message from Tony Butt - > > Date: Wed, 6 Jul 2011 15:20:27 +1000 > >> We are running subversion 1.6.17 on a vmware hosted server. We recently > >> reconfigured the server to give 4 virtual CPUs (up from 1), and a > >> significant amount of memory. > >> > >> In order to spruce up our performance a little, I looked into the use of > >> memcached with subversion again, found the correct config parameter, and > >> set it up. Our server is running Ubuntu 10.04, Apache 2.2. Access > >> mechanism is http (of course). The client used is running Ubuntu 11.04, > >> and svn commandline (1.6.17 also) > >> > >> The results were interesting, to say the least. > >> > And the sad thing that these results are in line with > what can be expected in 1.6. That's why the whole > caching code has been reworked in 1.7. > >> Checkout of a tree, about 250M in size: > >> > >> Without memcached, 1 1/2 to 2 minutes, varies with server load > >> With memcached, 12 minutes (!) > >> > >> Update of the same tree, > >> Without memcached, 9 seconds > >> With memcached, 14 seconds - repeated several times, similar results. > You can expect all similarly structured repositories > to show similar performance patterns. Only for very > different content and usage patterns, there might be > a performance improvement (see below). > >> I am not sure what anyone else's experience is, but we will not be > >> enabling memcached for subversion any time soon. > I will try to answer that with some indication towards > what you may try and when that might aid performance > in 1.6 and 1.7. But first, let me give you some technical > background because there is obviously no simple > recipe for making things fast in 1.6. > > The key factors here is latency and trade-off. To read > a userfile@rev from the repository, the back-end has to > follow a short chain of objects (roughly: rev->offset in repo > file, userfile -> last change, last change -> offset in repo file, > chain of deltas to combine). All that data will ultimately > come from disk. > > Most servers boast large amounts of file system cache > that can be accessed in < 0.1ms. SVN itself will cache > the index information used at the beginning of the lookup > chain in in its application memory. By default, only the > user file deltas need to be read (from file system cache), > decompressed and combined into the original content. > > For typical files < 100k, only 5 or less of these delta > blocks need to be read while the index / admin info > at the beginning of the lookup chain contains also about > 5 steps which can often be satisfied directly from internal > caches, i.e. are "for free". So, the default in 1.6 is < 1ms > for reading the data plus come CPU load from unzipping it. > > With memcached, the picture changes and parts of that > can be considered a design flaw in 1.6. All index objects > will be stored in the memcached, i.e. accessing them is > no longer for free. OTOH, reconstructed user-file content > will no be cached, i.e. no need to reconstruct it from > deltas over and over again. So, we traded 3 or 4 file > cache reads plus unzip CPU load for ~5 memcached reads. > > But the latter involves a TCP/IP communication between > processes with latencies 2+ times that of the file system > cache. To make things worse, memcached seems to > shut off for a few seconds when being hammered with > a large number of requests in a short period of time > (I observed that behavior under Ubuntu 9.04). To mitigate > that, i.e. have *some* process to answer your requests, > start 3 or 4 of them. They all will end up with redundant > information. > Without understanding the details, that is similar to what I thought must be happening. Since it is fairly simple to switch in/out memcached, I will try again when we go to 1.7. Thanks for the thoughtful response - Tony Butt > So, when can memcached be useful in 1.6? > > * when the file system cache in ineffective (repositories >on NFS-like shares) > * disk (NAS) latency is higher than TCP/IP latency > * large external memcached servers are available >compared to usable file system cache on the SVN >server machine > * huge repositories where the combined amount of >frequently requested information is larger than what >the file system cache can buffer. > > For 1.7, things are quite different. Memcached will only > be used for user file content - not the many admin objects > needed to access it. Hence, the trade-off should always > be 1 TCP/IP lookup vs. multiple file cache accesses. > > Moreover, the svn server itself can cache those full texts > - effectively eliminating all latencies. Combined with > many improvements to the caching logic, all c/o > operations should be strictly limited by client I/O. > > Hope that lengthy explanation helps! > > -- Stefan^2. -- Tony Butt CEA
Re: svnserve serving svn repos with questions
2011/7/18 Thorsten Schöning : > Guten Tag David Mehler, > am Samstag, 16. Juli 2011 um 18:46 schrieben Sie: > >> I'm wanting to ensure encryption of data while traveling from the >> server to the client so am looking in to cyrus-sasl, though not >> finding what i'm looking for. > > What exactly are you missing? > > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.svnserve.sasl And is there any reason not to use svn+ssh:// or https:// >> I'm also needing to separate users. For example, user1 has access to >> only repos1 while user2 has only access to repos2 but not repos1. >> Under their respective repos' each user can commit their own projects >> and manage them. > > This is easy, each repository has it's own user configuration per > default and per repository you can use path based access control, if > needed. > > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.svnserve.auth > >> I would have gone with an svn+ssh access, but don't want to give out >> system accounts, and none of my user's want their repos visible to an >> httpd server so apache is out. > > How about creating new users just for svn access? Else, a simple VPN > using OpenVPN could be solution, too, depending on how you trust your > users etc. Oh, my! You don't have to give system accounts!!! You use a shared account, called "svn", for write access. The URL's would be "svn+ssh://svn@hostname/reponame", and you'd use SSH keys with a "command" option, as documented at http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks.fixedcmd. There's a missing option in the documentation, the "--root" option. For a set of shared SVN repostories at "/var/svn/", the saved keys would look something like this: command="svnserve -t --tunnel-user=username --root=/var/svn",no-port-forwarding,no-agent-forw arding,no-X11-forwarding,no-pty TYPE1 KEY1 usern...@example.com The repo at /var/svn/repo1 would be accessed with the URL svn+ssh://svn@hostname/repo1/ > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning > AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig > > Telefon: Potsdam: 0331-743881-0 > E-Mail: tschoen...@am-soft.de > Web: http://www.am-soft.de > > AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam > Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow > >
Re: svnserve serving svn repos with questions
[ Accidentally replied only to Thorsten, sending to list. ] 2011/7/18 Nico Kadel-Garcia : > 2011/7/18 Thorsten Schöning : >> Guten Tag David Mehler, >> am Samstag, 16. Juli 2011 um 18:46 schrieben Sie: >> >>> I'm wanting to ensure encryption of data while traveling from the >>> server to the client so am looking in to cyrus-sasl, though not >>> finding what i'm looking for. >> >> What exactly are you missing? >> >> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.svnserve.sasl > > And is there any reason not to use svn+ssh:// or https:// > >>> I'm also needing to separate users. For example, user1 has access to >>> only repos1 while user2 has only access to repos2 but not repos1. >>> Under their respective repos' each user can commit their own projects >>> and manage them. >> >> This is easy, each repository has it's own user configuration per >> default and per repository you can use path based access control, if >> needed. >> >> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.svnserve.auth >> >>> I would have gone with an svn+ssh access, but don't want to give out >>> system accounts, and none of my user's want their repos visible to an >>> httpd server so apache is out. >> >> How about creating new users just for svn access? Else, a simple VPN >> using OpenVPN could be solution, too, depending on how you trust your >> users etc. > > Oh, my! You don't have to give system accounts!!! You use a shared > account, called "svn", for write access. > > The URL's would be "svn+ssh://svn@hostname/reponame", and you'd use > SSH keys with a "command" option, as documented at > http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks.fixedcmd. > > There's a missing option in the documentation, the "--root" option. > For a set of shared SVN repostories at "/var/svn/", the saved keys > would look something like this: > > command="svnserve -t --tunnel-user=username > --root=/var/svn",no-port-forwarding,no-agent-forw > arding,no-X11-forwarding,no-pty TYPE1 KEY1 usern...@example.com > > The repo at /var/svn/repo1 would be accessed with the URL > svn+ssh://svn@hostname/repo1/ > >> >> Mit freundlichen Grüßen, >> >> Thorsten Schöning >> >> -- >> Thorsten Schöning >> AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig >> >> Telefon: Potsdam: 0331-743881-0 >> E-Mail: tschoen...@am-soft.de >> Web: http://www.am-soft.de >> >> AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam >> Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow >> >> >
Re: Subversion: list of respositories
On Mon, Jul 18, 2011 at 7:10 AM, Erik Huelsmann wrote: > >> I would think that it looks at SVNParentPath and tries to treat every >> >> > subdirectory of that as a repository. >> >> Not quite. It's not "every subdirectory", it's "every child >> directory". That means it will not descend into subdirectories of >> subdirectories, fir example, so they all need to be right there in >> /var/svn. Also, while symlinks to other locations may be acceptable to >> the mod_dav_svn module, the repositories need to be accessible to the >> "apache" user. This can get adventuresome if you're running svnserve >> or svn+ssh access without a devault svn+ssh user, used in parallel to >> Apache. > > While links are acceptable to mod_dav_svn, they won't appear in the > repository listing. Note that you need the SVNListParent On statement in > your Apache config to get a listing of the repositories. > In 1.7 I've committed a small change to list symlinks to directories which > will be part of 1.7. > > Bye, > Erik. Cool, but be careful with those. If you have SELinux enabled and the repositories are elsewhere, for example on a separate disk for bulky repositories, you may need to review your SELinux settings to enable httpd access to the separate location. And oh, dear lord, if someone starts putting symlinks in the reponame/conf/ or reponame/hooks/, can you have adventures. (See http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=767435, which was only recently fixed and the fix isn't in most public Subversion releases.)
Re: Subversion: list of respositories
The simple trick to user rights I use is to make the repo owned by www-data to give Apache access and use group permissions for svn+SSH. I'm not sure if acl's work or not. I always viewed svn as just being a method to interact with individual repos... it really has no clue what is going on outside of its own world. To handle this issue, I made a wrapper script for svnadmin that parses the input and output and logs to an SQL database which I then access through Apache to build a display list of repos (and change logs). Matt Matthew Beals Michigan Technological University Department of Atmospheric Sciences 1400 Townsend Drive B019a Fisher Hall Houghton, MI 49931 mjbe...@mtu.edu Nico Kadel-Garcia wrote: On Mon, Jul 18, 2011 at 4:56 AM, Andy Canfield wrote: > > > On 07/18/2011 09:36 AM, Nico Kadel-Garcia wrote: >> >> On Sun, Jul 17, 2011 at 8:07 AM, Andy Levy wrote: >>> >>> On Sun, Jul 17, 2011 at 02:06, Andy Canfield >>> wrote: How do you get a list of repositories from svnserver? The only way I can figure out is: ssh usern...@example.com sudo bash ls -ld /var/svn/* And, of course, this makes an assumption about where on the server the repositories are located. There 'ought' to be an easier way. >>> >>> There is, but only if you serve via Apache. >> >> Even then, it won't find repositories that are not built into the >> Apache layout or the elevant "parent" directory. > > I would think that it looks at SVNParentPath and tries to treat every > subdirectory of that as a repository. Not quite. It's not "every subdirectory", it's "every child directory". That means it will not descend into subdirectories of subdirectories, fir example, so they all need to be right there in /var/svn. Also, while symlinks to other locations may be acceptable to the mod_dav_svn module, the repositories need to be accessible to the "apache" user. This can get adventuresome if you're running svnserve or svn+ssh access without a devault svn+ssh user, used in parallel to Apache.
Re: Subversion: via Apache
I have requested our system administrator re-install Apache and all it's mod_dav modules and tell me the distribution versions of everything. After it gets done I can re-test. In the meantime I can hope to get svn talking to svnserve via port 3690. So far failed on permissions, but more testing tomorrow.
Re: Subversion: list of respositories
On 7/18/2011 6:47 AM, Matthew Beals wrote: The simple trick to user rights I use is to make the repo owned by www-data to give Apache access and use group permissions for svn+SSH. I'm not sure if acl's work or not. I always viewed svn as just being a method to interact with individual repos... it really has no clue what is going on outside of its own world. To handle this issue, I made a wrapper script for svnadmin that parses the input and output and logs to an SQL database which I then access through Apache to build a display list of repos (and change logs). Viewvc works nicely as a web browser front end to show the repos and browse contents and logs, but then you need a straightforward mapping of the viewvc URL to one for svn - which is easy to arrange if they are all under the same top-level directory. -- Les Mikesell lesmikes...@gmail.com
Re: Subversion: list of respositories
On Jul 18, 2011, at 03:53, Andy Canfield wrote: > On 07/18/2011 09:35 AM, Andy Levy wrote: >> On Sun, Jul 17, 2011 at 22:29, Andy Canfield wrote: >> >>> If I set up http://example.com/svn >>> to be a way to use apache to communicate >>> with the svn service on the example.com server then is pointing my browser >>> to >>> "http://example.com/svn"; >>> supposed to give me some kind of web page? >>> Because I do not remember seeing anything about that in the book. >>> >> You're looking for SVNParentPath. >> >> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html > My entry in httpd.conf contains an SVNParentPath line. Then yes, http://example.com/svn/ shows you a listing of all repositories.
Re: libsvn_ra_serf\util.c - line 2141: assertion failed (*rel_path != NULL)
On Mon, Jul 18, 2011 at 21:15, Mat Berchtold wrote: > I’m using the nightly build > (TortoiseSVN-1.6.99.21696-dev-x64-svn-1.7.0-dev.msi) of tortoisesvn and > encounter the following error when using the Show Log or Repository Browser > function: > > libsvn_ra_serf\util.c - line 2141: assertion failed (*rel_path != NULL) > > The complete error text can be seen in this screenshot: > http://imageshack.us/photo/my-images/36/svnerror.png/ > > > > This only happens with one repository. With the same repository > updates/commits are working as expected. > > On the server side there is Apache 2.2 and svn-1.7.0-beta1-win32.zip Rather than post an image which is not searchable and could disappear from imageshack at any time, you can press Ctrl-C on any pop-up in Windows like this and it will copy everything to your clipboard in plain text. You can then paste that text into your email and it will be seen in full and kept in archives forever.
Re: libsvn_ra_serf\util.c - line 2141: assertion failed (*rel_path != NULL)
Hold on, where did you get beta1 binaries from? It hasn't been released. Andy Levy wrote on Mon, Jul 18, 2011 at 22:14:37 -0400: > On Mon, Jul 18, 2011 at 21:15, Mat Berchtold wrote: > > I’m using the nightly build > > (TortoiseSVN-1.6.99.21696-dev-x64-svn-1.7.0-dev.msi) of tortoisesvn and > > encounter the following error when using the Show Log or Repository Browser > > function: > > > > libsvn_ra_serf\util.c - line 2141: assertion failed (*rel_path != NULL) > > > > The complete error text can be seen in this screenshot: > > http://imageshack.us/photo/my-images/36/svnerror.png/ > > > > > > > > This only happens with one repository. With the same repository > > updates/commits are working as expected. > > > > On the server side there is Apache 2.2 and svn-1.7.0-beta1-win32.zip > > Rather than post an image which is not searchable and could disappear > from imageshack at any time, you can press Ctrl-C on any pop-up in > Windows like this and it will copy everything to your clipboard in > plain text. You can then paste that text into your email and it will > be seen in full and kept in archives forever.
libsvn_ra_serf\util.c - line 2141: assertion failed (*rel_path != NULL)
I'm using the nightly build (TortoiseSVN-1.6.99.21696-dev-x64-svn-1.7.0-dev.msi) of tortoisesvn and encounter the following error when using the Show Log or Repository Browser function: libsvn_ra_serf\util.c - line 2141: assertion failed (*rel_path != NULL) The complete error text can be seen in this screenshot: http://imageshack.us/photo/my-images/36/svnerror.png/ This only happens with one repository. With the same repository updates/commits are working as expected. On the server side there is Apache 2.2 and svn-1.7.0-beta1-win32.zip Regards, Mat
