RE: Users cannot reliably view SVN log messages remotely
I got past the issue and wanted to post my solution here for other SVN admins/users. HTH. I've got a distant user who cannot reliably view the SVN log messages Using TortoiseSVN. If he 'refreshes', he can view the SVN log messages fine. Also, checkouts work fine. Other users at his (distant) site seem to have the same issue, but I can't reproduce the issue here and haven't heard of similar issues from other sites. From inspecting the Apache logs, I found that the user's client was in an invalid state. Somehow it was sending the server requests for revisions that did not modify any files in the selected directory. For example, Revision 2688 does not exist on Path/To/Directory, but this was in the access_log: REPORT /svn/RepoName/!svn/bc/2688/Path/To/Directory HTTP/1.1 404 247 His TSVN client was also displaying revision 2689 in the Show Log windows. After asking the user to disable log caching and clear his saved data he was able to view the log messages again without clicking 'refresh' and the invalid revision 2689 disappeared from his TSVN window. Provider encountered an error while streaming a REPORT response. [500, #0] A failure occurred while driving the update report editor [500, #103] Error writing base64 data: Software caused connection abort [500, #103] As for these other error messages, I'm still not sure the reason but there's no pressing need to investigate at the moment. If I find a solution later I'll make sure to post it here for everyone. Best, Shaun
Users cannot reliably view SVN log messages remotely
Hi all, I've got a distant user who cannot reliably view the SVN log messages Using TortoiseSVN. If he 'refreshes', he can view the SVN log messages fine. Also, checkouts work fine. Other users at his (distant) site seem to have the same issue, but I can't reproduce the issue here and haven't heard of similar issues from other sites. We're using Apache, and I did notice that the Apache logs occasionally shows the below errors and wonder if there is a known explanation or solution: Provider encountered an error while streaming a REPORT response. [500, #0] A failure occurred while driving the update report editor [500, #103] Error writing base64 data: Software caused connection abort [500, #103] I've checked the Subversion FAQ, and think the fix there does not apply since my users are on Windows. Does anyone know how to resolve these errors? I'm suspecting a network issue, so my next thing to try is to increase the Apache timeout in httpd.conf. My hunch is that this won't solve the issue, so if anyone has additional ideas to try I'd really appreciate it. Thanks! Shaun
RE: Users cannot reliably view SVN log messages remotely
I've checked the Subversion FAQ, and think the fix there does not apply since my users are on Windows. Does anyone know how to resolve these (...Sent this out too quickly... I meant to say:) We're not serving from a MacOS X 10.4 machine, so I don't think the FAQ applies here.
RE: How to best manage authorization after tag/branch creation?
Do you need to restrict READ access to the branch or tag, or do you simply want to restrict COMMIT access. Thanks for the response. We need both, but restricting read access is the main concern at the moment. So far, I only know of AuthUserFile for controlling read access. If you just want to restrict commit access, you can use a pre-commit hook to kill a commit transaction if the user who doesn't have permission attempts to change a tag or branch. Good to know. I'll check into the script you've mentioned. At the moment, we've removed read access to /tags for most users. But this is not a good long term solution. By the way, there's also a way to configure Apache httpd to use LDAP instead of a regular text file. This means that users will have access to your Subversion repository based upon their Windows or Unix account and that users will automatically get logins and have their access removed when they get hired or move on. That's something we'll definitely consider. We have some other quirks with account management to sort out first :) Best, Shaun
RE: How to best manage authorization after tag/branch creation?
Do you need to restrict READ access to the branch or tag, or do you simply want to restrict COMMIT access. Thanks for the response. We need both, but restricting read access is the main concern at the moment. So far, I only know of AuthUserFile for controlling read access. If you just want to restrict commit access, you can use a pre-commit hook to kill a commit transaction if the user who doesn't have permission attempts to change a tag or branch. Good to know. I'll check into the script you've mentioned. At the moment, we've removed read access to /tags for most users. But this is not a good long term solution. I should say we've removed both read and write access to /tags for most users. By the way, there's also a way to configure Apache httpd to use LDAP instead of a regular text file. This means that users will have access to your Subversion repository based upon their Windows or Unix account and that users will automatically get logins and have their access removed when they get hired or move on. That's something we'll definitely consider. We have some other quirks with account management to sort out first :) Best, Shaun
RE: How to best manage authorization after tag/branch creation?
The usual issue is making sure people outside the project are prevented from reading the code. You might not want people in your project making changes on tags and branches, but there usually isn't a security issue if they see the code on the branches and tags. Our issue is handling multiple companies doing development on the same project. Various restrictions (e.g. licensing) prevent us from sharing all project files with everyone involved. It's a tricky use case. We also have additional considerations which require us to control project read access within a project even within the same company. The only way you can prevent people from reading your code is to setup httpd configuration. pre-commit hooks can't do this and there's no pre-checkout hook. Yeah, was afraid of that... However, changing httpd configuration is tricky since it involves having root access on the httpd server and being able to at least bounce the server when the permissions get changed. Yes. Perhaps if there was a pre-checkout hook it'd be possible to create a homegrown admin tool. Or perhaps if Subversion had a feature to natively manage access control within a repository then no Apache changes would be needed in the first place. Either way, some automation would be useful here but it may not be possible to implement. By the way, there's also a way to configure Apache httpd to use LDAP instead of a regular text file. This means that users will have access to your Subversion repository based upon their Windows or Unix account and that users will automatically get logins and have their access removed when they get hired or move on. That's something we'll definitely consider. We have some other quirks with account management to sort out first :) When your development team gets bigger than a dozen people, you start having people come and go all the time. That makes it difficult to keep the httpd configuration up to date. It just becomes easier if this becomes more automated. Or at least someone else's problem when a new developer doesn't have access to Subversion. I completely agree, and will be using that argument to push for it (or at least the first part :)
RE: How to best manage authorization after tag/branch creation?
Our issue is handling multiple companies doing development on the same project. Various restrictions (e.g. licensing) prevent us from sharing all project files with everyone involved. It's a tricky use case. We also have additional considerations which require us to control project read access within a project even within the same company. So, you have a branch for each company, and that's why you need specific read permissions on each branch? If that's the case, I can see why you want to restrict reading privileges on a per-branch basis. How do you handle branching and tags in that case? Do you branch branches and tags off the company branches? We're rolling like this at the moment. We have a top-level 'main' project folder which is for us only. We use path-based authorization to restrict access here for our users. We've also added another top-level folder 'product' which is a subset copy of 'main.' Every company involved in the product does development in 'product/trunk'. We use path-based authorization to remove read access from the trunk before development work begins. As tags or branches are created for the product, and as new top-level product directories are created we'll need to add a pre-commit hook to remind people to edit httpd.conf for path- based authorization. We've considered removing the restricted source code From the product folder, but the reason for leaving it is because product-specific changes to the restricted code are needed. I'd love to hear any ideas or improvements. Thanks!
RE: How to best manage authorization after tag/branch creation?
When your development team gets bigger than a dozen people, you start having people come and go all the time. That makes it difficult to keep the httpd configuration up to date. It just becomes easier if this becomes more automated. Or at least someone else's problem when a new developer doesn't have access to Subversion. I completely agree, and will be using that argument to push for it (or at least the first part :) And that's why you use LDAP or another alternative authentication method. BTW, Subversion does support groups as part of the path-based authentication. I don't know how that interacts with LDAP if at all, but that might be something to investigate or perhaps add support for. Thanks Ben. That's good to know. Best, Shaun
RE: How to best manage authorization after tag/branch creation?
If you need to control access to the code you can do things such as: - only allow the developers that need access access to the whole project Yep, we do this. There are still some restricted areas in some projects though. - setup a secondary tags namespace for special binary only information - have the build mechanism push the binaries to a special binary tag by the same name - use svn:externals to reference the binary releases instead of source releases. Yes, I think binary releases of restricted modules is a very good idea. It's a slow process, but I think pushing for this will help a lot. There's a perception that binary releases of restricted source code is not necessary if product-specific changes are needed to the code. Just copy the source code to the product folder and restrict it in httpd.conf. I'm working on this... Also, while we don't use svn:externals currently, it looks like it would be useful for handling binary releases of restricted code. Thanks for that!
RE: How to best manage authorization after tag/branch creation?
If you need to control access to the code you can do things such as: - only allow the developers that need access access to the whole project Yep, we do this. There are still some restricted areas in some projects though. - setup a secondary tags namespace for special binary only information - have the build mechanism push the binaries to a special binary tag by the same name - use svn:externals to reference the binary releases instead of source releases. Yes, I think binary releases of restricted modules is a very good idea. It's a slow process, but I think pushing for this will help a lot. There's a perception that binary releases of restricted source code is not necessary if product-specific changes are needed to the code. Just copy the source code to the product folder and restrict it in httpd.conf. I'm working on this... Also, while we don't use svn:externals currently, it looks like it would be useful for handling binary releases of restricted code. Thanks for that! Let me try to say that a bit better. Binaries are always created for the restricted source code. The need to include the restricted source code in the product directory is debatable. Treating the restricted source code as a full-fledged project with it's own top-level directory would help. If a product-specific change is needed to the restricted code, create a branch under it's directory, store the binary during release, and reference the binary in the product folder with svn:externals. That's a bit more clear, I think.
How to best manage authorization after tag/branch creation?
Hello all, We've configured Apache to restrict access to certain directories on our trunk (n.b. via AuthUserFile in httpd.conf). The problem is now I've created a tag from our trunk and found that the permissions don't 'automatically' transfer during creation of the tag. Obviously, this is because the AuthUserFile is a text file and needs to be edited manually :). But, is there an admin tool to help with this basic task to avoid accidentally providing full access to a tag (or branch)? Hopefully, Subversion provides some type of 'smart branch/tag creation' which can inherit permissions from the source directory. Please let me know of the best way to do this. Thanks, Shaun
How to determine high-level SVN actions from low-level Apache logs?
Hello all, I'd like to inspect the Apache log files (e.g. access_log) to determine SVN activities such as commit, update, svnsync, etc. How can I do this? Thanks, Shaun
RE: How to determine high-level SVN actions from low-level Apache logs?
Hi Mark, Thanks for the info - I'll try to get this option added to our server. Right now, all I have is access_log. Is there a way to get the same info from access_log? Regards, Shaun -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Thursday, October 07, 2010 1:53 PM To: Shaun Pinney Cc: users@subversion.apache.org Subject: Re: How to determine high-level SVN actions from low-level Apache logs? On Thu, Oct 7, 2010 at 4:46 PM, Shaun Pinney shaun.pin...@bil.konicaminolta.us wrote: I'd like to inspect the Apache log files (e.g. access_log) to determine SVN activities such as commit, update, svnsync, etc. How can I do this? The best way to do this is to configure Subversion's high-level operational logging. If you use CollabNet Subversion Edge for your server it configures Apache to record these logs automatically and you can access them via a web UI. It also offers daily log rotation and automated log cleanup See: http://www.open.collab.net/products/subversion/whatsnew.html If you want to configure this feature for your own server it is documented in the book: http://svnbook.red- bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extr a.logging -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: How to determine high-level SVN actions from low-level Apache logs?
-Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Thursday, October 07, 2010 1:53 PM On Thu, Oct 7, 2010 at 4:46 PM, Shaun Pinney shaun.pin...@bil.konicaminolta.us wrote: I'd like to inspect the Apache log files (e.g. access_log) to determine SVN activities such as commit, update, svnsync, etc. How can I do this? The best way to do this is to configure Subversion's high-level operational logging. If you use CollabNet Subversion Edge for your server it configures Apache to record these logs automatically and you can access them via a web UI. It also offers daily log rotation and automated log cleanup See: http://www.open.collab.net/products/subversion/whatsnew.html If you want to configure this feature for your own server it is documented in the book: http://svnbook.red- bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extr a.logging (sorry for the earlier top post...) Hi Mark, Thanks for the info - I'll try to get this option added to our server. Right now, all I have is access_log. Is there a way to get the same info from access_log? Regards, Shaun
