WriteAttributes permission required to commit in v1.7.8 but not v1.6.17
Hi all; We have been using v1.6.17 as a rudimentary change monitoring system for certain Windows server config files, for a few years now (a nightly script emails the output of `svn status` if not empty). I have been looking at the possibility of upgrading this to v1.7.8 (the first 1.7.x release I have tried), but it appears that committing now requires the 'WriteAttributes' permission on each file. It did not in v1.6.17. Granting the WriteAttributes permission just for this purpose is awkward, at best (particularly given that many of the files I am monitoring are owned by the abominable 'NT SERVICE\TrustedInstaller' account). In any case, if I do actually take ownership and grant this permission to the file, svn.exe appears to try to change the file creation date to 01/01/1601 and set the 'N' attribute (which appears to stand for 'Not indexed'). Why does it need to do this in v1.7.8 but not v1.6.17? Is it an oversight, or part of some new operation I am not aware of? Surely the act of committing shouldn't /change/ the file it is committing, should it? A good working example (on Windows Server 2008 R2, if you have Microsoft.NET v3.5 installed) is at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default. This file is owned by TrustedInstaller, with Administrators having Read/Execute only. In v1.6.17, `svn commit` will succeed but, in v1.7.8, `svn commit` will throw `Cannot set file ... read-write: Access is denied`. I have attached Procmon64 exports showing the commit operation on this file in v1.6.17 (svn1617.csv), v1.7.8 with the normal permissions (svn178_restricted.csv) and once again after I had granted WriteAttributes to the file (svn178_allowed.csv). The pertinent entries from above (transposed for easier reading) are below: -- from svn178_restricted.csv - Time= 12:25:19.3938787 Process Name= svn.exe PID = 292 Operation = CreateFile Path= C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default Result = ACCESS DENIED Detail = Desired Access: Write Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a -- from svn178_allowed.csv - Time = 13:02:26.6088387 Process Name = svn.exe PID = 384 Operation= SetBasicInformationFile Path = C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default Result = SUCCESS Detail = CreationTime: 01/01/1601 00:00:00, LastAccessTime: 01/01/1601 00:00:00, LastWriteTime: 01/01/1601 00:00:00, ChangeTime: 01/01/1601 00:00:00, FileAttributes: AN The condensed results of `svn --version` from both versions are as follows: svn, version 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 (SlikSvn/1.6.17) X64 compiled Jun 3 2011, 07:48:11 Copyright (C) 2000-2009... The following repository access (RA) modules are available: ra_neon, ra_svn, ra_local, ra_serf svn, version 1.7.8-SlikSvn-1.7.8-X64 (SlikSvn/1.7.8) X64 compiled Jan 11 2013, 16:31:23 Copyright (C) 2012... The following repository access (RA) modules are available: ra_neon, ra_svn, ra_local, ra_serf Can anyone shed some light on this? Regards J "Time of Day","Process Name","PID","Operation","Path","Result","Detail" "13:02:25.8023178","svn.exe","384","CreateFile","C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default","SUCCESS","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened" "13:02:25.8023387","svn.exe","384","QueryNetworkOpenInformationFile","C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default","SUCCESS","CreationTime: 13/07/2009 20:46:44, LastAccessTime: 13/07/2009 20:46:44, LastWriteTime: 10/06/2009 21:22:49, ChangeTime: 27/02/2013 13:02:03, AllocationSize: 01/01/1601 00:00:00, EndOfFile: 01/01/1601 00:00:00, FileAttributes: A" "13:02:25.8023506","svn.exe","384","CloseFile","C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default","SUCCESS","" "13:02:25.8104473","svn.exe","384","CreateFile","C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default","SUCCESS","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened" "13:02:25.8104649","svn.exe","384","QueryNetworkOpenInformationFile","C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.default","SUCCESS","CreationTime: 13/07/2009 20:46:44, LastAccessTime: 13/07/2009 20:46:44, LastWriteTime: 10/06/2009 21:22:49, ChangeTime: 2
Re: Is SVN-1.6.12 compatible with Rhel6u2?
Thanks for the suggestion. But, the Rhel5u6(production server) runs perfectly fine. My problems are while running Collabnet-svn-1.6.12 on Rhel6u2. On Tue, Feb 26, 2013 at 5:23 PM, Nico Kadel-Garcia wrote: > On Tue, Feb 26, 2013 at 11:35 AM, Kriparam Faraday > wrote: > > Hi, > > I just stood up an exact replica of a collabnet subversion > > server(version=1.6.12 and configured to run as apache subversion). I have > > enabled ssl(using an existing ssl cert from the production box). > > > > I am able to access the server using my browsers or svn clients like > > smartSVN or TortoiseSVN. But, when I hit refresh(F5) on the repo-browser > of > > TortoiseSVN client, I see an error like this: > > "Server sent unexpected return value (400 Bad Request) in response to > > OPTIONS request for > https://xx.xx.xx.xx/xx/ad/test-repo1/branches/newname"; > > > > I am not able to reproduce this error on the production server. The only > > difference between the production and this backup is: > > (1) Production is on a Rhel5u6 and the backup is on Rhel6u2. I was not > able > > to find any OS compatibility document for svn-1.6.12 > > RedHat's copy of subversion is out of date on RHEL. You're quite > welcome to my updated versions published at repoforge in the "extras" > repositories, or my tools for building Subversoin 1.6.20 and 1.7.8 > RPM's available at: > > https://github.com/nkadel/subversion-1.6.20-srpm/ > https://github.com/nkadel/subversion-1.7.8-srpm/ > > > (2) Production has a valid ssl certificate. Backup is using the ssl > > certificate from production. > > > > These are the logs I see: > > ssl_request_log > > [25/Feb/2013:07:53:42 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "OPTIONS > > /xx/ad/test-repo1/branches/newname HTTP/1.1" 300 > > > > ssl_access_log > > xx.xx.xx.xx - - [25/Feb/2013:07:53:42 -0500] "OPTIONS > > /xx/ad/test-repo1/branches/newname HTTP/1.1" 400 300 > > > > ssl_error_log > > [Mon Feb 25 07:53:42 2013] [error] [client xx.xx.xx.xx] request failed: > > error reading the headers > > > > after this failure, I get subsequent failure log like the following > until I > > restart the client: > > > > ssl_request_log > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "OPTIONS > > /xx/ad/test-repo1/trunk HTTP/1.1" 401 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "OPTIONS > > /xx/ad/test-repo1/trunk HTTP/1.1" 196 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/trunk HTTP/1.1" 702 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1" 414 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1" 465 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/trunk HTTP/1.1" 702 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1" 414 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1" 465 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/trunk HTTP/1.1" 702 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1" 465 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1" 1329 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA "REPORT > > /xx/ad/test-repo1/trunk HTTP/1.1" 112 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/trunk HTTP/1.1" 702 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1" 465 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1" 430 > > [25/Feb/2013:09:21:46 -0500] xx.xx.xx.xx TLSv1 DHE-RSA-AES256-SHA > "PROPFIND > > /xx/ad/test-repo1/!svn/bc/4/trunk HTTP/1.1" 1298 > > > > ssl_access_log > > xx.xx.xx.xx - - [25/Feb/2013:09:21:46 -0500] "OPTIONS > > /xx/ad/test-repo1/trunk HTTP/1.1" 401 401 > > xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] "OPTIONS > > /xx/ad/test-repo1/trunk HTTP/1.1" 200 196 > > xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] "PROPFIND > > /xx/ad/test-repo1/trunk HTTP/1.1" 207 702 > > xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] "PROPFIND > > /xx/ad/test-repo1/!svn/vcc/default HTTP/1.1" 207 414 > > xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] "PROPFIND > > /xx/ad/test-repo1/!svn/bln/4 HTTP/1.1" 207 465 > > xx.xx.xx.xx - username1 [25/Feb/2013:09:21:46 -0500] "PROPFIND > > /xx/ad/test-repo1/trunk HTTP/1.1" 207 702 > > xx.xx.xx.xx - username1 [25/Feb/201
Severe Problem with one repo
Hi, I am using Subversion 1.6.12 (r955767 on an Ubuntu server. SVN has been up and running a long time and had very few, if any, problems. Last week I needed to make for new repos. Three went just fine. The fourth has been a problem. Here is a history of what happened and what I did. I used svnadmin and created the repo on the server. Using TortoiseSVN I checked it out to my Win7 desktopy. I created trunk,tags and branches folders and committed them to the repo. Then I took all the production code from our ubuntu server and copied it into a subdirectory named public inside the trunk directory. Everything went as expected until this point. Then I tried to commit all this code to the repo. It failed due to lack of disk space. This turned out to be correct, I freed up disk space deleted the repo directory and started the whole process again. This time when I went to commit all the code I got a Cannot write to the prototype revision file of transaction '1-5' becasuse a previous reperesntation is currently being written by another process. I again deleted everything restarted the server, restarted my desktop. It still did not work. I looked through the code I was trying to upload and found that at one point it must have been part of some repo because in many subdirectories there were .svn folders. On my desktop I deleted them all. This time I deleted and restarted everything and even used different folder and directory names, I still get an error. Commit failed Cannot write to the prototype revision file fo the transaction '1-1' becasuse a previous reperesntation is currently being written by another process. Where do I go from here? Scott
Re: Severe Problem with one repo
Scott Miller wrote on Wed, Feb 27, 2013 at 10:26:20 -0800: > Then I tried to commit all this code to the repo. It failed due to lack of > disk space. This turned out to be correct, I freed up disk space deleted > the repo directory and started the whole process again. This time when I > went to commit all the code I got a Cannot write to the prototype revision > file of transaction '1-5' becasuse a previous reperesntation is currently > being written by another process. > Did it say "by another process" or "by this process"? > > I again deleted everything restarted the server, restarted my desktop. It > still did not work. > > I looked through the code I was trying to upload and found that at one > point it must have been part of some repo because in many subdirectories > there were .svn folders. On my desktop I deleted them all. > > This time I deleted and restarted everything and even used different folder > and directory names, I still get an error. Commit failed > Cannot write to the prototype revision file fo the transaction '1-1' > becasuse a previous reperesntation is currently being written by another > process. > Did it say "by another process" or "by this process"? Asking because you repeated the "becasuse" and "reperesntation" typoes twice, which indicates you copied the error message from your mail rather than from your stderr.
Re: Severe Problem with one repo
It did say by another process both times. > Did it say "by another process" or "by this process"? > > > > > I again deleted everything restarted the server, restarted my desktop. > It > > still did not work. > > > > I looked through the code I was trying to upload and found that at one > > point it must have been part of some repo because in many subdirectories > > there were .svn folders. On my desktop I deleted them all. > > > > This time I deleted and restarted everything and even used different > folder > > and directory names, I still get an error. Commit failed > > Cannot write to the prototype revision file fo the transaction '1-1' > > becasuse a previous reperesntation is currently being written by another > > process. > > > > Did it say "by another process" or "by this process"? > > Asking because you repeated the "becasuse" and "reperesntation" typoes > twice, which indicates you copied the error message from your mail > rather than from your stderr. > >
Re: Severe Problem with one repo
Scott Miller wrote on Wed, Feb 27, 2013 at 10:26:20 -0800: > Hi, > > I am using Subversion 1.6.12 (r955767 on an Ubuntu server. SVN has been > up and running a long time and had very few, if any, problems. Last week I > needed to make for new repos. Three went just fine. > > The fourth has been a problem. Here is a history of what happened and what > I did. > > I used svnadmin and created the repo on the server. > > Using TortoiseSVN I checked it out to my Win7 desktopy. I created > trunk,tags and branches folders and committed them to the repo. Then I > took all the production code from our ubuntu server and copied it into a > subdirectory named public inside the trunk directory. Everything went as > expected until this point. > > Then I tried to commit all this code to the repo. It failed due to lack of > disk space. This turned out to be correct, I freed up disk space deleted > the repo directory and started the whole process again. This time when I > went to commit all the code I got a Cannot write to the prototype revision > file of transaction '1-5' becasuse a previous reperesntation is currently > being written by another process. > > > I again deleted everything restarted the server, restarted my desktop. It Does "restart" mean "apachectl -k restart", "reboot", or something else? Do you happen to have multiple versions of libapr (ignore libapr-util)? Are all repositories on the same filesystem and mount point? Is it a local or network mount? > still did not work. > > I looked through the code I was trying to upload and found that at one > point it must have been part of some repo because in many subdirectories > there were .svn folders. On my desktop I deleted them all. > > This time I deleted and restarted everything and even used different folder > and directory names, I still get an error. Commit failed > Cannot write to the prototype revision file fo the transaction '1-1' > becasuse a previous reperesntation is currently being written by another > process. > > Where do I go from here? > > Scott
Re: Tagging svn:externals
> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Tuesday, February 26, 2013 6:12 PM > Subject: Re: Tagging svn:externals > > On Tue, Feb 26, 2013 at 4:29 PM, BRM wrote: >> >>> How can a script possibly know the correct tag for an external target >>> which is currently pointing at the trunk in a repository that permits >>> concurrent operations? >> >> In my example, it would simply update, then pull the revision number to > generate the peg >> revision information in the svn:externals data, essentially: >> >> ^/somePath@r1829 -r 1829 >> >> The "1829" portion is easily scriptable to find. > > But that's not what I want. I want the externals in tags to point to > previously tagged component versions. Without forcing that to be > committed to the trunk or encouraging copying to tags from a workspace > that doesn't match any trunk commit. From that description, it'll have to be a manual process that you run from within your working copy. Just update the svn:externals appropriately and then do an "svn update". You can test whatever you like without committing. >> As you can probably guess, I'm a big fan of "trunk is > prestine"; mostly because I'm a >> big fan of doing things in a very structured, deterministic way. > > I'm a fan of not cluttering the repository with unnecessary branches, > and in making it simple for everyone involved to pick up each others' > changes sooner rather than later. And in getting determinism through > consistent tagging, and only using release tags where determinism > matters. So if you don't need a branch, delete it. Personally I do an "svn del" on any branch that I no longer need - whether abandoned or reintegrated. This keeps the branch list short, and (more importantly) relevant. The nice thing with Subversion is that you can still get to all those old branches. >> You seem to be wanting >> that determinism. It'd be interesting to see what a big fan of > "trunk is dirty" would say >> for how to do the same thing; but somehow I suspect you can't do it > while maintaining >> the determinism. > > The question is just about what would be considered "best practice" in > where/how that change between an unpinned external and one pointing to > a separately released tagged version should happen. I don't think > whether the ongoing work is a branch or trunk matters. As long there > is continuing (possibly concurrent) development in the location before > you make the tag, you have to decide whether to (a) make another > branch just to hold this change, (b) commit the change back to the > development location, then undo it after the tag copy, (c) copy to the > tag from a modified working copy, or (d) change it in the tag, > violating the 'tags never change' convention? I personally don't > like the idea of tagging from a modified working copy because of the > possibility that other changes with no history can accidentally be > brought along. Let me propose this: For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes. You'll have to decide how you want bug fixes to be interacted with; but that will provide what you've been describing. For developers, they can do whatever you like. Again, as I've noted it comes down to what policies you want your team to follow. Ben
Re: Tagging svn:externals
On Wed, Feb 27, 2013 at 4:14 PM, BRM wrote: >> >> But that's not what I want. I want the externals in tags to point to >> previously tagged component versions. Without forcing that to be >> committed to the trunk or encouraging copying to tags from a workspace >> that doesn't match any trunk commit. > > From that description, it'll have to be a manual process that you run from > within your working copy. > Just update the svn:externals appropriately and then do an "svn update". > You can test whatever you like without committing. Everything is built by jenkins and has to come from the repository. Things in uncommitted workspaces aren't necessarily repeatable. >> I'm a fan of not cluttering the repository with unnecessary branches, >> and in making it simple for everyone involved to pick up each others' >> changes sooner rather than later. And in getting determinism through >> consistent tagging, and only using release tags where determinism >> matters. > > So if you don't need a branch, delete it. > Personally I do an "svn del" on any branch that I no longer need - whether > abandoned or reintegrated. > This keeps the branch list short, and (more importantly) relevant. > The nice thing with Subversion is that you can still get to all those old > branches. That's a not-so-nice thing too. The repo is growing at about 10 gigs/year. While I realize that extra tags/branches are a very small part of the problem I don't want to encourage unnecessary clutter until there is some reasonable way to reorganize and actually remove things. >> The question is just about what would be considered "best practice" in >> where/how that change between an unpinned external and one pointing to >> a separately released tagged version should happen. I don't think >> whether the ongoing work is a branch or trunk matters. As long there >> is continuing (possibly concurrent) development in the location before >> you make the tag, you have to decide whether to (a) make another >> branch just to hold this change, (b) commit the change back to the >> development location, then undo it after the tag copy, (c) copy to the >> tag from a modified working copy, or (d) change it in the tag, >> violating the 'tags never change' convention? I personally don't >> like the idea of tagging from a modified working copy because of the >> possibility that other changes with no history can accidentally be >> brought along. > > Let me propose this: > > For QA, let them do a simple modified working copy to get the svn:externals > where you want them; but then they are not allowed to commit or make other > changes. Won't work - it has to be committed somewhere or it won't be built. -- Les Mikesell lesmikes...@gmail.com
Re: Tagging svn:externals
> From: Les Mikesell > To: BRM > Cc: "users@subversion.apache.org" > Sent: Wednesday, February 27, 2013 5:30 PM > Subject: Re: Tagging svn:externals > > On Wed, Feb 27, 2013 at 4:14 PM, BRM wrote: >>> >>> But that's not what I want. I want the externals in tags to point to >>> previously tagged component versions. Without forcing that to be >>> committed to the trunk or encouraging copying to tags from a workspace >>> that doesn't match any trunk commit. >> From that description, it'll have to be a manual process that you run > from within your working copy. >> Just update the svn:externals appropriately and then do an "svn > update". >> You can test whatever you like without committing. > Everything is built by jenkins and has to come from the repository. > Things in uncommitted workspaces aren't necessarily repeatable. ,,, >> Let me propose this: >> >> For QA, let them do a simple modified working copy to get the svn:externals > where you want them; but then they are not allowed to commit or make other > changes. > > Won't work - it has to be committed somewhere or it won't be built. Perhaps then you need a different tool. For example, git-svn[1] is might be what you want. When something is ready for QA it is pushed to a git repository for Jenkins to pick up. How you change the externals in the process I'm not sure; but it would at least give you a trackable repository that would mimick a modified working copy. Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch, but still want to track it in the repository somehow. Ben [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Re: Tagging svn:externals
On Wed, Feb 27, 2013 at 4:44 PM, BRM wrote: >> >> Won't work - it has to be committed somewhere or it won't be built. > > Perhaps then you need a different tool. > For example, git-svn[1] is might be what you want. > > When something is ready for QA it is pushed to a git repository for Jenkins > to pick up. > How you change the externals in the process I'm not sure; but it would at > least give you > a trackable repository that would mimick a modified working copy. > > Otherwise I think you're out of luck if you don't want to (i) commit to > trunk, or (ii) create a branch, > but still want to track it in the repository somehow. No, I think the choices are to tag from the working copy or commit a change after making the tag. But neither seem like the tool is designed to do what I'd expect to be a common operation cleanly. -- Les Mikesell lesmikes...@gmail.com
