SVN-Notify and such
Hi there, I am looking for a way to send email after each commit for my SVN server. There used to be page describing all options at: http://subversion.tigris.org/links.html#misc-utils I cannot find where this page moved. Basically I am looking for a light solution (do not send the output of UNIX diff in email). I have a websvn and a viewvc available. Thanks -- Mathieu
RE: svn:mergeinfo resurrecting from the dead
> Hi there, > > Are you using externals? > > Yes, we use externals both for importing code from other repos and also as > symbolic links within our repo, since our build system runs on Windows > which has no support for native symbolic links. > > Thanks! Ah... iirc this is a bug that happens when you have externals. Can you remove the externals and try it? You can always put them back later. BOb
[Press Release] WANdisco Gives Back to the Subversion Community
Profits from WANdisco Subversion Support Contract Sales Go Toward Subversion’s Continuing Development and Support the Activities of the Subversion community. http://svn.wandisco.com/WANdisco_Gives_Back_to_the_Subversion_Community
SVN Error
Hello, I am getting an error like this. I am using SVN 1.6.11 and Apache 2.2.14 svn: REPORT of '/!svn/vcc/default': Could not read response body: connection was closed by server I tried SVN checkout using file:/// method and it did not have any issues. Will changing "Timeout" in Apache configuration will help here? Best, Hemant Unstoppable..
RE: SVN Error
That would be the first thing I would do. What is the current timeout? Are you trying to use http or https? Regards, Tom From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com] Sent: Wednesday, May 19, 2010 10:58 AM To: users@subversion.apache.org Subject: SVN Error Hello, I am getting an error like this. I am using SVN 1.6.11 and Apache 2.2.14 svn: REPORT of '/!svn/vcc/default': Could not read response body: connection was closed by server I tried SVN checkout using file:/// method and it did not have any issues. Will changing "Timeout" in Apache configuration will help here? Best, Hemant Unstoppable..
Re: race condition on checkin immediately followed by a merge?
On Tue, May 18, 2010 at 1:20 AM, Bert Huijben wrote: >> Subversion uses a simple heuristic to determine if a file has >> changed. It is well documented in the source code but perhaps >> not so well known: >> >> If the size and time stamp of a file is the same as when checking >> out the file it is immediately considered as unchanged. We had a >> similar issue where an automatic script failed to commit an updated >> file. >> >> This is most easily resolved by adding a small delay between checking >> out and performing the modification. We used 2 seconds. You need to >> wait long enough for your operating system file time stamp to tick >> one step and on Windows this means about 2 seconds to be sure. > > On Windows and most operating systems this depends on the filesystem being > used. > > On NTFS you should never see issues like these as the timestamps have 100 > nanosecond precision. On FAT (including FAT32, but not including the newer > VFAT) however you *do* see this issue. > (On linux: Ext3 has 1 second precision and Ext4 has nanosecond precision. > HFS+ on the mac has 1 second precision) > > Subversion tries to compensate for 1 second precision filesystems, but this > is not guaranteed accurate for network filesystems and systems that use 2 > second precision. (It waits until the time changed to the next second before > returning from for these commands) Folks seem to be saying that this is an issue in the SVN client's working copy filesystem, not the SVN server's repository filesystem. Is that correct? What part of this process would be dependent on the filesystem's timestamp resolution: 1) Check out file n from srcurl rev 1000 to working copy 1, wc1 2) Pull the sole value out of n - an integer 3) Increment the integer 4) Check n back in to srcurl with the increased value to srcurl rev 1001 5) Check out file n from dsturl rev 1000 to a new working directory, wc2 (dsturl is a mirror of srcurl, but a little older) 6) svn merge from srcurl at rev 1000 into wc2 7) checkin modified wc2 to dsturl ? I'm guessing it's a matter of step 7 (near the beginning, when a freshness check is applied to n) seeing the same mtime and file size on file n as it had in step 5 (near the end, when n is written). Is that correct? Thanks!
Managing Product templates
Hi, We are currently branching into Subversion usage operating with VisualSVN Server (will upgrade to Enterprise when trials are complete) and a client side using TortoiseSVN. In general all very happy and things are all pretty seamless and obvious, but... I would like to introduce the concept of a "product" directory template that would be resident in each of our repositories. I guess at this point I should say that we are probably going to operate with multiple repositories where a repository is set up for each of our main "Projects". Then inside each of our repositories we would have many "products", each hopefully having a structure generated from our template. The reason I think we will operate in this fashion is because we will need to apply specific user security access rights to the "projects" and I am told by our IT administrators that this would be the simplest way of achieving this. Open to pointers on this too. I have managed to create the template structure (applying desired properties to the structure such as ignore patterns and logminsize etc) and then create new "products" in a repository based on the template simple copy function in a Tortoise repo-browser, not really rocket science.. But I am struggling to find a way of say importing this template into another repository and identify a mechanism, however manual, of keeping them in sync. I am trying to achieve as much as possible from a client interface as in general we do not have simple access to personnel with server access rights. I apologise if this is the wrong place to post this query but my web searching has not really managed to help so far I would appreciate any guidance, even if it is a pointer to another place to ask the question. Thanks for any help that can be given. Regards Steve Hutchinson FPGA Group Leader E-Mail :steven.hutchin...@mbda-systems.com This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Pre-commit hook problem
Hi, I have a svn 1.6.5 repository that I'm trying to implement a pre-commit hook on (below). I've started with the template, and changed it only slightly. #!/bin/sh REPOS="$1" TXN="$2" # Make sure that the log message contains some text. SVNLOOK=/opt/CollabNet_Subversion/bin/svnlook GREP=/bin/grep $SVNLOOK log -t "$TXN" "$REPOS" | \ $GREP "[a-zA-Z0-9]" > /dev/null || exit 1 # All checks passed, so allow the commit. exit 0 The paths are correct for my system, and I've successfully tested the functionality using existing revisions by replacing the -t flag with the -r flag for svnlook. The extension has been changed from .tmpl to .sh and the permissions for both the directory and the file are correct (executable by all). However, when I test this by committing a revision with no log message from my TortoiseSVN client (1.6.8, and svn 1.6.11), the commit happens no problem. Checking the TortoiseSVN docs says that server-side hook scripts should still work. I have no client side hook scripts. Any idea what I'm missing?? Any help is much appreciated. Julia Braman Robotic Systems Technology Branch (ER4) julia.m.bra...@nasa.gov
Re: Pre-commit hook problem
On Wed, May 19, 2010 at 11:48:21AM -0500, BRAMAN, JULIA M (JSC-ER711) wrote: > The extension has been changed from .tmpl to .sh Drop the .sh extension and it should work. The hook needs to be called "pre-commit". Stefan
Re: Pre-commit hook problem
On Wed, May 19, 2010 at 12:57, Stefan Sperling wrote: > On Wed, May 19, 2010 at 11:48:21AM -0500, BRAMAN, JULIA M (JSC-ER711) wrote: >> The extension has been changed from .tmpl to .sh > > Drop the .sh extension and it should work. > The hook needs to be called "pre-commit". Except on Windows (of course) where it needs to be .bat, .com or .exe
RE: Problem committing files starting with "."
Ryan, Thanks for the message. We got it resolved and your message jogged my memory a bit on what it could be. It was a Siteminder (single sign on) web agent that was blocking files starting with ".". We changed that config and the issue was resolved. Rob -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Tuesday, May 18, 2010 6:20 PM To: Brooks, Rob (Rob) Cc: users@subversion.apache.org Subject: Re: Problem committing files starting with "." On May 18, 2010, at 10:58, Brooks, Rob (Rob) wrote: > I'm having a problem committing files that start with "." This error doesn't > occur when committing any other files. > > The subversion server returns the following: > > Error: Server sent unexpected return value (500 Internal Server Error) in > response to > Error: PROPFIND request for ... Do you have a rule in your Apache conf file blocking requests to files beginning with "."?
Re: Managing Product templates
On 5/19/2010 11:34 AM, Hutchinson, Steve (UK) wrote: Hi, We are currently branching into Subversion usage operating with VisualSVN Server (will upgrade to Enterprise when trials are complete) and a client side using TortoiseSVN. In general all very happy and things are all pretty seamless and obvious, but... I would like to introduce the concept of a "product" directory template that would be resident in each of our repositories. I guess at this point I should say that we are probably going to operate with multiple repositories where a repository is set up for each of our main "Projects". Then inside each of our repositories we would have many "products", each hopefully having a structure generated from our template. The reason I think we will operate in this fashion is because we will need to apply specific user security access rights to the "projects" and I am told by our IT administrators that this would be the simplest way of achieving this. Open to pointers on this too. I have managed to create the template structure (applying desired properties to the structure such as ignore patterns and logminsize etc) and then create new "products" in a repository based on the template simple copy function in a Tortoise repo-browser, not really rocket science.. But I am struggling to find a way of say importing this template into another repository and identify a mechanism, however manual, of keeping them in sync. I am trying to achieve as much as possible from a client interface as in general we do not have simple access to personnel with server access rights. I apologise if this is the wrong place to post this query but my web searching has not really managed to help so far I would appreciate any guidance, even if it is a pointer to another place to ask the question. If you are planning to merge parts of files from template changes into other places as an ongoing process you might them all in the same repository, treating your "products" as branches so you can simply copy to get a new one, and merge changes into later revisions if you want. However, if you can arrange to put the common parts in separate files in a subdirectory, you can treat it like a component library that you pull into each of the product folders with an external reference. This reference can be pegged to a specific revision or tag, which can then be changed only want you want to a specific product to pick up a different revison of the component files. In the latter case it won't matter if the components are maintained in the same or a different repository. Note that you need admin access to create new repositories but client access is all you need to make branches or different subdirectories within one. -- Les Mikesell lesmikes...@gmail.com
RE: Managing Product templates
> We are currently branching into Subversion usage operating with VisualSVN > Server (will upgrade to Enterprise when trials are complete) and a client > side using TortoiseSVN. In general all very happy and things are all > pretty seamless and obvious, but... > > I would like to introduce the concept of a "product" directory template > that would be resident in each of our repositories. I guess at this point > I should say that we are probably going to operate with multiple > repositories where a repository is set up for each of our main "Projects". > Then inside each of our repositories we would have many "products", each > hopefully having a structure generated from our template. The reason I > think we will operate in this fashion is because we will need to apply > specific user security access rights to the "projects" and I am told by > our IT administrators that this would be the simplest way of achieving > this. Open to pointers on this too. Well... I'm not sure it would be any easier to manage security by repository for each project than by path. Of course, it depends. If they are thinking that security would be managed at the file system level then sure. But, if you are using path based authorization built into svn then I don't see a difference. > I have managed to create the template structure (applying desired > properties to the structure such as ignore patterns and logminsize etc) > and then create new "products" in a repository based on the template > simple copy function in a Tortoise repo-browser, not really rocket > science.. > > But I am struggling to find a way of say importing this template into > another repository and identify a mechanism, however manual, of keeping > them in sync. I am trying to achieve as much as possible from a client > interface as in general we do not have simple access to personnel with > server access rights. Well... once your product is set up... I think any changes you want to make to the structure will have to be done manually to that product. You can create a template in a repository and then dump it to a dump file. Whenever you want to create a new product you can load the dump file into a repository at a specific path. Of course, this will require access to the server. Or it could be set up as a script with a web front end of some type. You can also create a script that creates your structure imports it into svn, sets the properties, etc. This script can run on any client that has svn.exe on it. Once again, it is the sync piece that I really don't see a way to do once that product structure is already in place. Whether you use seperate repos or a single repo that has your defaults structure that is only there to copy to create new products. You could TRY to change the product template then merge it into each product. But frankly you would probably get a bunch of tree conflicts since those are the types of changes svn is very bad at merging in. > I apologise if this is the wrong place to post this query but my web > searching has not really managed to help so far I would appreciate any > guidance, even if it is a pointer to another place to ask the question. > Yea... I think you're in the right place... and it is a refreshing change from the daily why do I have all these mergeinfo properties question. ;) BOb
Subversion repo upgrade makes repository unusable.
Hi, I recently upgraded my subversion server from 1.4.6 to 1.6.11. The repos all seem to work correctly after this. I then try to upgrade a repo by issuing the svnadmin update command, and it produces no errors and says the update is complete. However, I am unable to open the repository after this. I get the following error when trying to open the repo: Could not open the requested SVN filesystem. I am using Apache, not SVNServe. I also upgraded my client to 1.6.11. Server is Windows 2003. Any help would be appreciated!
Re: Subversion repo upgrade makes repository unusable.
On Thu, May 20, 2010 at 12:55 AM, Michael Cole wrote: > Hi, I recently upgraded my subversion server from 1.4.6 to 1.6.11. The > repos all seem to work correctly after this. I then try to upgrade a repo by > issuing the svnadmin update command, and it produces no errors and says the > update is complete. However, I am unable to open the repository after this. > I get the following error when trying to open the repo: Could not open the > requested SVN filesystem. > > > > I am using Apache, not SVNServe. I also upgraded my client to 1.6.11. > Server is Windows 2003. Any help would be appreciated! > I hope you also upgraded Apache modules for Subversion and restarted Apache after you did that just a thought > > > > > > > > > > > -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
"Unreadable path encountered" running svn merge --reintegrate
I am trying to use the svn merge tracking in the SVN 1.6.11 client (server is running 1.6.4). I am getting this error when I try to reintegrate back into my trunk: svn: Unreadable path encountered; access denied I can do any other type of merge with no problem, just the -reintegrate is giving me this problem. Here is the sequence of commands I ran. My working copy was originally checked out from ^/project1/trunk. cd working_copy svn copy ^/project1/trunk ^/project1/branches/bugfix svn switch ^/project1/branches/bugfix svn commit -m "message" svn merge ^/project1/trunk svn switch ^/project1/trunk svn merge -reintegrate ^/project1/branches/bugfix . Any idea what's causing this problem with -reintegrate? Beverly Brown
svn diff issue: svn confuses files with dirs on hfsplus?
Hi! I encoutered a weird problem with subversion 1.6.6 & 1.6.9 on a 32 & 64bit Xubuntu 10.04: My working copies are located on a hfsplus partition which is shared across the Xubuntu Linux and MacOS on my development machine. For some strange reason, I cannot diff single files in any working copies on this partition: $> svn diff somefile svn: Can't open file 'somefile/.svn/entries': Permission denied Weirdly, running $> svn diff works well, however, and shows a diff of all files as expected. After checking out the same repository to an ext3 partition, _both_ commands work fine. Based on the error message above, I wonder why subversion confuses a single file with a directory? Why is it looking for .svn/entries that does obviously not exist? hfsplus is case insensitive, but I successfully used subversion on such a partition for quite a while before. I suppose, the hfsplus partition is not mounted correctly. These are the mount options I use in my fstab: UUID=... /media/Data hfsplus users,auto,exec,rw 0 0 Any ideas that might help me solve the problem? Georg smime.p7s Description: S/MIME Cryptographic Signature
RE: "Unreadable path encountered" running svn merge --reintegrate
> I am trying to use the svn merge tracking in the SVN 1.6.11 client (server > is running 1.6.4). > > I am getting this error when I try to reintegrate back into my trunk: > svn: Unreadable path encountered; access denied > You're not using a sparse checkout of your trunk are you? Are there paths that you don't have access to in your repository? BOb > I can do any other type of merge with no problem, just the -reintegrate is > giving me this problem. > > Here is the sequence of commands I ran. My working copy was originally > checked out from ^/project1/trunk. > > cd working_copy > svn copy ^/project1/trunk ^/project1/branches/bugfix > svn switch ^/project1/branches/bugfix > > > > svn commit -m "message" > svn merge ^/project1/trunk > since the copy> > > svn switch ^/project1/trunk > svn merge -reintegrate ^/project1/branches/bugfix . > > > Any idea what's causing this problem with -reintegrate? > > Beverly Brown
RE: "Unreadable path encountered" running svn merge --reintegrate
> I am trying to use the svn merge tracking in the SVN 1.6.11 client (server > is running 1.6.4). > > I am getting this error when I try to reintegrate back into my trunk: > svn: Unreadable path encountered; access denied > > I can do any other type of merge with no problem, just the -reintegrate is > giving me this problem. > > Here is the sequence of commands I ran. My working copy was originally > checked out from ^/project1/trunk. > > cd working_copy > svn copy ^/project1/trunk ^/project1/branches/bugfix > svn switch ^/project1/branches/bugfix > > > > svn commit -m "message" > svn merge ^/project1/trunk > since the copy> > > svn switch ^/project1/trunk > svn merge -reintegrate ^/project1/branches/bugfix . You actually used: svn merge --reintegrate ^/project1/branches/bugfix . BOb
RE: "Unreadable path encountered" running svn merge --reintegrate
No, we never do sparse checkouts. It's the whole tree or nothing. I don't think there would be any paths in the tree I don't have access to. I did the checkout, so everything in there should be accessible by me. All other commands work. The only one giving me this error is "svn merge --reintegrate". Beverly Brown -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, May 19, 2010 3:45 PM To: Brown, Beverly; users@subversion.apache.org Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > I am trying to use the svn merge tracking in the SVN 1.6.11 client (server > is running 1.6.4). > > I am getting this error when I try to reintegrate back into my trunk: > svn: Unreadable path encountered; access denied > You're not using a sparse checkout of your trunk are you? Are there paths that you don't have access to in your repository? BOb > I can do any other type of merge with no problem, just the -reintegrate is > giving me this problem. > > Here is the sequence of commands I ran. My working copy was originally > checked out from ^/project1/trunk. > > cd working_copy > svn copy ^/project1/trunk ^/project1/branches/bugfix > svn switch ^/project1/branches/bugfix > > > > svn commit -m "message" > svn merge ^/project1/trunk > since the copy> > > svn switch ^/project1/trunk > svn merge -reintegrate ^/project1/branches/bugfix . > > > Any idea what's causing this problem with -reintegrate? > > Beverly Brown
RE: "Unreadable path encountered" running svn merge --reintegrate
> --reintegrate > > > I am trying to use the svn merge tracking in the SVN 1.6.11 client > (server > > is running 1.6.4). > > > > I am getting this error when I try to reintegrate back into my trunk: > > svn: Unreadable path encountered; access denied > > > > You're not using a sparse checkout of your trunk are you? > > Are there paths that you don't have access to in your repository? > > No, we never do sparse checkouts. It's the whole tree or nothing. > > I don't think there would be any paths in the tree I don't have access > to. I did the checkout, so everything in there should be accessible by > me. All other commands work. The only one giving me this error is "svn > merge --reintegrate". > > Beverly Brown Are there perhaps mergeinfo properties in your project that point to no longer existing paths? BOb
RE: "Unreadable path encountered" running svn merge --reintegrate
Yes, why? Is that improper syntax? I tried without the "." at the end first and then put it in there in case it was confused about the desitnation. Beverly -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, May 19, 2010 3:47 PM To: Brown, Beverly; users@subversion.apache.org Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > I am trying to use the svn merge tracking in the SVN 1.6.11 client (server > is running 1.6.4). > > I am getting this error when I try to reintegrate back into my trunk: > svn: Unreadable path encountered; access denied > > I can do any other type of merge with no problem, just the -reintegrate is > giving me this problem. > > Here is the sequence of commands I ran. My working copy was originally > checked out from ^/project1/trunk. > > cd working_copy > svn copy ^/project1/trunk ^/project1/branches/bugfix > svn switch ^/project1/branches/bugfix > > > > svn commit -m "message" > svn merge ^/project1/trunk > since the copy> > > svn switch ^/project1/trunk > svn merge -reintegrate ^/project1/branches/bugfix . You actually used: svn merge --reintegrate ^/project1/branches/bugfix . BOb
RE: "Unreadable path encountered" running svn merge --reintegrate
You need two dashes... not one. Probably a typo on your email but just wanted to check. > -Original Message- > From: Brown, Beverly [mailto:beverly.br...@stratus.com] > Sent: Wednesday, May 19, 2010 3:52 PM > To: Bob Archer; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > > Yes, why? Is that improper syntax? > > I tried without the "." at the end first and then put it in there in > case it was confused about the desitnation. > > Beverly > > -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Wednesday, May 19, 2010 3:47 PM > To: Brown, Beverly; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge > --reintegrate > > > I am trying to use the svn merge tracking in the SVN 1.6.11 client > (server > > is running 1.6.4). > > > > I am getting this error when I try to reintegrate back into my trunk: > > svn: Unreadable path encountered; access denied > > > > I can do any other type of merge with no problem, just the > -reintegrate is > > giving me this problem. > > > > Here is the sequence of commands I ran. My working copy was originally > > checked out from ^/project1/trunk. > > > > cd working_copy > > svn copy ^/project1/trunk ^/project1/branches/bugfix > > svn switch ^/project1/branches/bugfix > > > > > > > > svn commit -m "message" > > svn merge ^/project1/trunk > > > since the copy> > > > > svn switch ^/project1/trunk > > svn merge -reintegrate ^/project1/branches/bugfix . > > You actually used: > > svn merge --reintegrate ^/project1/branches/bugfix . > > > > BOb
RE: "Unreadable path encountered" running svn merge --reintegrate
It would be incredibly helpful if svn printed out the path it didn't like. Beverly -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, May 19, 2010 3:45 PM To: Brown, Beverly; users@subversion.apache.org Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > I am trying to use the svn merge tracking in the SVN 1.6.11 client (server > is running 1.6.4). > > I am getting this error when I try to reintegrate back into my trunk: > svn: Unreadable path encountered; access denied > You're not using a sparse checkout of your trunk are you? Are there paths that you don't have access to in your repository? BOb > I can do any other type of merge with no problem, just the -reintegrate is > giving me this problem. > > Here is the sequence of commands I ran. My working copy was originally > checked out from ^/project1/trunk. > > cd working_copy > svn copy ^/project1/trunk ^/project1/branches/bugfix > svn switch ^/project1/branches/bugfix > > > > svn commit -m "message" > svn merge ^/project1/trunk > since the copy> > > svn switch ^/project1/trunk > svn merge -reintegrate ^/project1/branches/bugfix . > > > Any idea what's causing this problem with -reintegrate? > > Beverly Brown
RE: "Unreadable path encountered" running svn merge --reintegrate
Yes, it was a typo in my email. I used two dashes. Beverly -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, May 19, 2010 4:00 PM To: Brown, Beverly; users@subversion.apache.org Subject: RE: "Unreadable path encountered" running svn merge --reintegrate You need two dashes... not one. Probably a typo on your email but just wanted to check. > -Original Message- > From: Brown, Beverly [mailto:beverly.br...@stratus.com] > Sent: Wednesday, May 19, 2010 3:52 PM > To: Bob Archer; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > > Yes, why? Is that improper syntax? > > I tried without the "." at the end first and then put it in there in > case it was confused about the desitnation. > > Beverly > > -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Wednesday, May 19, 2010 3:47 PM > To: Brown, Beverly; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge > --reintegrate > > > I am trying to use the svn merge tracking in the SVN 1.6.11 client > (server > > is running 1.6.4). > > > > I am getting this error when I try to reintegrate back into my trunk: > > svn: Unreadable path encountered; access denied > > > > I can do any other type of merge with no problem, just the > -reintegrate is > > giving me this problem. > > > > Here is the sequence of commands I ran. My working copy was originally > > checked out from ^/project1/trunk. > > > > cd working_copy > > svn copy ^/project1/trunk ^/project1/branches/bugfix > > svn switch ^/project1/branches/bugfix > > > > > > > > svn commit -m "message" > > svn merge ^/project1/trunk > > > since the copy> > > > > svn switch ^/project1/trunk > > svn merge -reintegrate ^/project1/branches/bugfix . > > You actually used: > > svn merge --reintegrate ^/project1/branches/bugfix . > > > > BOb
RE: "Unreadable path encountered" running svn merge --reintegrate
No, I just double-checked. There are two paths in svn:mergeinfo and both still exist. The only svn:mergeinfo properties are at the root of the working copy (I did svn pg svn:mergeinfo -R of both the trunk and the branch just to be sure). Beverly -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, May 19, 2010 3:53 PM To: Brown, Beverly; users@subversion.apache.org Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > --reintegrate > > > I am trying to use the svn merge tracking in the SVN 1.6.11 client > (server > > is running 1.6.4). > > > > I am getting this error when I try to reintegrate back into my trunk: > > svn: Unreadable path encountered; access denied > > > > You're not using a sparse checkout of your trunk are you? > > Are there paths that you don't have access to in your repository? > > No, we never do sparse checkouts. It's the whole tree or nothing. > > I don't think there would be any paths in the tree I don't have access > to. I did the checkout, so everything in there should be accessible by > me. All other commands work. The only one giving me this error is "svn > merge --reintegrate". > > Beverly Brown Are there perhaps mergeinfo properties in your project that point to no longer existing paths? BOb
RE: "Unreadable path encountered" running svn merge --reintegrate
Well... I'm stumped. Can you just do a standard merge like we did before merge tracking. Might be the only way to get it done without going crazy? > -Original Message- > From: Brown, Beverly [mailto:beverly.br...@stratus.com] > Sent: Wednesday, May 19, 2010 4:01 PM > To: Bob Archer; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > > No, I just double-checked. There are two paths in svn:mergeinfo and both > still exist. The only svn:mergeinfo properties are at the root of the > working copy (I did svn pg svn:mergeinfo -R of both the trunk and the > branch just to be sure). > > Beverly > > -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Wednesday, May 19, 2010 3:53 PM > To: Brown, Beverly; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge > --reintegrate > > > --reintegrate > > > > > I am trying to use the svn merge tracking in the SVN 1.6.11 client > > (server > > > is running 1.6.4). > > > > > > I am getting this error when I try to reintegrate back into my > trunk: > > > svn: Unreadable path encountered; access denied > > > > > > > You're not using a sparse checkout of your trunk are you? > > > > Are there paths that you don't have access to in your repository? > > > > No, we never do sparse checkouts. It's the whole tree or nothing. > > > > I don't think there would be any paths in the tree I don't have access > > to. I did the checkout, so everything in there should be accessible by > > me. All other commands work. The only one giving me this error is "svn > > merge --reintegrate". > > > > Beverly Brown > > Are there perhaps mergeinfo properties in your project that point to no > longer existing paths? > > BOb
RE: "Unreadable path encountered" running svn merge --reintegrate
Yes, I can do everything else with no problem and will revert back to that to get the job done. I'd really like to be able to use the merge tracking, though. One question - could this have anything to do with filenames that have spaces in them? I'm searching my tree now trying to find an inaccessible path using find . -type f |xargs sum > /dev/null It's showing a filename in a .svn/text-base as "No such file or directory" sum: ./path/.svn/text-base/filename: No such file or directory sum: with: No such file or directory sum: spaces: No such file or directory sum: in: No such file or directory sum: it.pdf.svn-base: No such file or directory This is probably unlikely since all other svn commands work just fine, but just thought I'd ask. Beverly -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, May 19, 2010 4:05 PM To: Brown, Beverly; users@subversion.apache.org Subject: RE: "Unreadable path encountered" running svn merge --reintegrate Well... I'm stumped. Can you just do a standard merge like we did before merge tracking. Might be the only way to get it done without going crazy? > -Original Message- > From: Brown, Beverly [mailto:beverly.br...@stratus.com] > Sent: Wednesday, May 19, 2010 4:01 PM > To: Bob Archer; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > > No, I just double-checked. There are two paths in svn:mergeinfo and both > still exist. The only svn:mergeinfo properties are at the root of the > working copy (I did svn pg svn:mergeinfo -R of both the trunk and the > branch just to be sure). > > Beverly > > -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Wednesday, May 19, 2010 3:53 PM > To: Brown, Beverly; users@subversion.apache.org > Subject: RE: "Unreadable path encountered" running svn merge > --reintegrate > > > --reintegrate > > > > > I am trying to use the svn merge tracking in the SVN 1.6.11 client > > (server > > > is running 1.6.4). > > > > > > I am getting this error when I try to reintegrate back into my > trunk: > > > svn: Unreadable path encountered; access denied > > > > > > > You're not using a sparse checkout of your trunk are you? > > > > Are there paths that you don't have access to in your repository? > > > > No, we never do sparse checkouts. It's the whole tree or nothing. > > > > I don't think there would be any paths in the tree I don't have access > > to. I did the checkout, so everything in there should be accessible by > > me. All other commands work. The only one giving me this error is "svn > > merge --reintegrate". > > > > Beverly Brown > > Are there perhaps mergeinfo properties in your project that point to no > longer existing paths? > > BOb
Re: svn diff issue: svn confuses files with dirs on hfsplus?
On Wed, May 19, 2010 at 15:40, Georg Kunz wrote: > Hi! > > I encoutered a weird problem with subversion 1.6.6 & 1.6.9 on a 32 & 64bit > Xubuntu 10.04: My working copies are located on a hfsplus partition which is > shared across the Xubuntu Linux and MacOS on my development machine. For > some strange reason, I cannot diff single files in any working copies on > this partition: > > $> svn diff somefile > svn: Can't open file 'somefile/.svn/entries': Permission denied > > Weirdly, running > > $> svn diff > > works well, however, and shows a diff of all files as expected. > > After checking out the same repository to an ext3 partition, _both_ commands > work fine. Based on the error message above, I wonder why subversion > confuses a single file with a directory? Why is it looking for .svn/entries > that does obviously not exist? > > hfsplus is case insensitive, but I successfully used subversion on such a > partition for quite a while before. I suppose, the hfsplus partition is not > mounted correctly. These are the mount options I use in my fstab: > > UUID=... /media/Data hfsplus users,auto,exec,rw 0 0 > > Any ideas that might help me solve the problem? Subversion works just fine on Macs. There are several people on this list using it, including the maintainer of the MacPorts Subversion package, IIRC. I suspect your issue is not HFS+ and Subversion, it's that you're using the HFS+ partition with the Linux client. You can't safely share a single working copy between users and/or operating systems because (in your example) things done "the Linux way" when you're logged into Xubuntu won't work when you're using a client running on MacOS, expecting things to be done "the MacOS way". Subversion is not significantly aware of what happens at the filesystem level (and actually it's APR doing the heavy lifting, not Subversion itself), so it won't do a lot of checking to decide "I'm running on Linux, but it's an HFS+ partition, so I have to do things in this way instead of what I would do for ETX3."
RE: "Unreadable path encountered" running svn merge --reintegrate
> Yes, I can do everything else with no problem and will revert back to > that to get the job done. I'd really like to be able to use the merge > tracking, though. > > One question - could this have anything to do with filenames that have > spaces in them? I'm searching my tree now trying to find an inaccessible > path using > > find . -type f |xargs sum > /dev/null > > It's showing a filename in a .svn/text-base as "No such file or > directory" > > sum: ./path/.svn/text-base/filename: No such file or directory > sum: with: No such file or directory > sum: spaces: No such file or directory > sum: in: No such file or directory > sum: it.pdf.svn-base: No such file or directory > > This is probably unlikely since all other svn commands work just fine, > but just thought I'd ask. I really am not sure. However, having a problem in the .svn folder could be indicitive of a corrupted working copy. Have you tried to run a cleanup on it? Or... try to do a clean checkout of trunk. Personally, I don't use switch. I check out trunk/branches to new folders as I need them. I think it is cleaner and I don't need to remember what path the working copy is currently pointing to. BOb
Re: svn diff issue: svn confuses files with dirs on hfsplus?
Hi Andy thanks for the reply. See below. On 05/19/2010 10:14 PM, Andy Levy wrote: On Wed, May 19, 2010 at 15:40, Georg Kunz wrote: Hi! I encoutered a weird problem with subversion 1.6.6& 1.6.9 on a 32& 64bit Xubuntu 10.04: My working copies are located on a hfsplus partition which is shared across the Xubuntu Linux and MacOS on my development machine. For some strange reason, I cannot diff single files in any working copies on this partition: $> svn diff somefile svn: Can't open file 'somefile/.svn/entries': Permission denied Weirdly, running $> svn diff works well, however, and shows a diff of all files as expected. After checking out the same repository to an ext3 partition, _both_ commands work fine. Based on the error message above, I wonder why subversion confuses a single file with a directory? Why is it looking for .svn/entries that does obviously not exist? hfsplus is case insensitive, but I successfully used subversion on such a partition for quite a while before. I suppose, the hfsplus partition is not mounted correctly. These are the mount options I use in my fstab: UUID=... /media/Data hfsplus users,auto,exec,rw 0 0 Any ideas that might help me solve the problem? Subversion works just fine on Macs. There are several people on this list using it, including the maintainer of the MacPorts Subversion package, IIRC. Sure, I never doubted that and I used it on a Mac for a long time. I suspect your issue is not HFS+ and Subversion, it's that you're using the HFS+ partition with the Linux client. You can't safely share a single working copy between users and/or operating systems because (in your example) things done "the Linux way" when you're logged into Xubuntu won't work when you're using a client running on MacOS, expecting things to be done "the MacOS way". To be precise here: the partition is shared to allow access from both OSes, but ALL development stuff, i.e., all svn operations, are done under Xubuntu only. So I don't share actually working copies across OSes and svn clients. Subversion is not significantly aware of what happens at the filesystem level (and actually it's APR doing the heavy lifting, not Subversion itself), so it won't do a lot of checking to decide "I'm running on Linux, but it's an HFS+ partition, so I have to do things in this way instead of what I would do for ETX3." Since I don't share working copies across OSes, Subversion doesn't need to do such checks in my case. I am already getting the error when doing a fresh checkout on Linux to the hfsplus partition and then doing a svn diff on an arbitrary file. It also does not make a difference if I actually change this file or not. So I am wondering why Subversion or APR does not like hfsplus? Georg smime.p7s Description: S/MIME Cryptographic Signature
Trying to revive a repo
We were backing up the repository files, but not a dump. We lost the server and we're trying to restore the repo. When we run a svnadmin verify, we get this back... * Verified revision 0. svnadmin: Revision file lacks trailing newline The files are all there, and they seem fine... How do we go about trying to fix the issue? Any ideas would be greatly appreciated! Thanks.
RE: "Unreadable path encountered" running svn merge --reintegrate
I tried with a fresh working copy and got the same results. Beverly -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, May 19, 2010 4:21 PM To: Brown, Beverly; users@subversion.apache.org Subject: RE: "Unreadable path encountered" running svn merge --reintegrate > Yes, I can do everything else with no problem and will revert back to > that to get the job done. I'd really like to be able to use the merge > tracking, though. > > One question - could this have anything to do with filenames that have > spaces in them? I'm searching my tree now trying to find an inaccessible > path using > > find . -type f |xargs sum > /dev/null > > It's showing a filename in a .svn/text-base as "No such file or > directory" > > sum: ./path/.svn/text-base/filename: No such file or directory > sum: with: No such file or directory > sum: spaces: No such file or directory > sum: in: No such file or directory > sum: it.pdf.svn-base: No such file or directory > > This is probably unlikely since all other svn commands work just fine, > but just thought I'd ask. I really am not sure. However, having a problem in the .svn folder could be indicitive of a corrupted working copy. Have you tried to run a cleanup on it? Or... try to do a clean checkout of trunk. Personally, I don't use switch. I check out trunk/branches to new folders as I need them. I think it is cleaner and I don't need to remember what path the working copy is currently pointing to. BOb
How to change default svn-commit.tmp contents
Hi all! I would like to change default contents of commit message from 'svn status' output to add 'svn diff' output. How can this be achieved? I have already tried setting editor-cmd in ~/.subversion/config to "svn diff >> svn-commit.tmp && mcedit" and it partially works, but creates diff against previous revision, not HEAD. Any suggestions? Thank you very much, b.
Re: How to change default svn-commit.tmp contents
On Wed, May 19, 2010 at 20:08, Bostjan Skufca wrote: > Hi all! > > I would like to change default contents of commit message from 'svn status' > output to add 'svn diff' output. How can this be achieved? > > I have already tried setting editor-cmd in ~/.subversion/config to "svn diff >>> svn-commit.tmp && mcedit" and it partially works, but creates diff > against previous revision, not HEAD. > > Any suggestions? What is your reason for putting a diff in the log? It's redundant & a poor use of space.
Re: How to change default svn-commit.tmp contents
On Thu, May 20, 2010 at 10:08 AM, Bostjan Skufca wrote: > Hi all! > > I would like to change default contents of commit message from 'svn status' > output to add 'svn diff' output. How can this be achieved? > > I have already tried setting editor-cmd in ~/.subversion/config to "svn diff >>> svn-commit.tmp && mcedit" and it partially works, but creates diff > against previous revision, not HEAD. > > Any suggestions? 1) Try running an update first. 2) If you're committing a file, and the diff between the working copy and previous is not identical to the diff between working and HEAD, that would indicate an out of date working copy, and I would expect you should get an error. 3) Can I ask why you are trying to include the diff in the log message? Cheers, Daniel B.
Re: How to change default svn-commit.tmp contents
I should have known that the first thing to surface would be "why" and not "the answer". But your question, Daniel, was polite at least :) If you pay attention to the command line in editor-cmd setting you can notice that content is appended. Therefore it is positioned below the -- This line and everything below... There are times when changes to certain files are accumulating over the days and when I hit "svn ci" I would like to get a glimpse of those changes. Of course you can do it in another terminal, and for larger changesets I definitely do so. But for smaller changesets it is just very convenient to see right away what was changed. Now, the 'update-first' seemed reasonable but it does not solve the issue. Will look deeper into it tomorrow. Thanks for your assistance, b. On 20 May 2010 02:17, Daniel Becroft wrote: > On Thu, May 20, 2010 at 10:08 AM, Bostjan Skufca wrote: > > Hi all! > > > > I would like to change default contents of commit message from 'svn > status' > > output to add 'svn diff' output. How can this be achieved? > > > > I have already tried setting editor-cmd in ~/.subversion/config to "svn > diff > >>> svn-commit.tmp && mcedit" and it partially works, but creates diff > > against previous revision, not HEAD. > > > > Any suggestions? > > 1) Try running an update first. > > 2) If you're committing a file, and the diff between the working copy > and previous is not identical to the diff between working and HEAD, > that would indicate an out of date working copy, and I would expect > you should get an error. > > 3) Can I ask why you are trying to include the diff in the log message? > > Cheers, > Daniel B. >
Re: How to change default svn-commit.tmp contents
On Thu, May 20, 2010 at 10:40 AM, Bostjan Skufca wrote: > I should have known that the first thing to surface would be "why" and not > "the answer". But your question, Daniel, was polite at least :) > > If you pay attention to the command line in editor-cmd setting you can > notice that content is appended. Therefore it is positioned below the -- > This line and everything below... > There are times when changes to certain files are accumulating over the days > and when I hit "svn ci" I would like to get a glimpse of those changes. Of > course you can do it in another terminal, and for larger changesets I > definitely do so. But for smaller changesets it is just very convenient to > see right away what was changed. Ah, good point. I don't use the command-line to commit, so wasn't aware of this. > Now, the 'update-first' seemed reasonable but it does not solve the issue. > Will look deeper into it tomorrow. How did the update-first not solve the issue? What is the diff producing and what are you expecting? Is it different or the same as running a standard 'svn diff' from the command-line. As I understand it, the revisions specified in the diff output (ie on the '---' and '+++' lines) should be the revision currently checked out (ie reported by the 'svn update'). I've never seen (revision HEAD) specified in the diff output, since HEAD is continually a moving target. > Thanks for your assistance, > b. > > > > > On 20 May 2010 02:17, Daniel Becroft wrote: >> >> On Thu, May 20, 2010 at 10:08 AM, Bostjan Skufca wrote: >> > Hi all! >> > >> > I would like to change default contents of commit message from 'svn >> > status' >> > output to add 'svn diff' output. How can this be achieved? >> > >> > I have already tried setting editor-cmd in ~/.subversion/config to "svn >> > diff >> >>> svn-commit.tmp && mcedit" and it partially works, but creates diff >> > against previous revision, not HEAD. >> > >> > Any suggestions? >> >> 1) Try running an update first. >> >> 2) If you're committing a file, and the diff between the working copy >> and previous is not identical to the diff between working and HEAD, >> that would indicate an out of date working copy, and I would expect >> you should get an error. >> >> 3) Can I ask why you are trying to include the diff in the log message? >> >> Cheers, >> Daniel B. > >
Re: "Unreadable path encountered" running svn merge --reintegrate
On May 19, 2010, at 15:10, Brown, Beverly wrote: > One question - could this have anything to do with filenames that have > spaces in them? I'm searching my tree now trying to find an inaccessible > path using > > find . -type f |xargs sum > /dev/null > > It's showing a filename in a .svn/text-base as "No such file or > directory" > > sum: ./path/.svn/text-base/filename: No such file or directory > sum: with: No such file or directory > sum: spaces: No such file or directory > sum: in: No such file or directory > sum: it.pdf.svn-base: No such file or directory That's because find and xargs won't work with files with spaces in their names unless you tell them to use something other than the space as their default delimiter, for example the null character: find . -type f -print0 | xargs -0 sum > /dev/null
RE: SVN Error
Thanks Tom. I am using http and not https. I noticed "Timeout 300" in conf/extra/httpd-default.conf - but it is not getting called (include) in httpd.conf. So I will play around with it. Best, Hemant Unstoppable.. From: Thomas Loy [mailto:thomas@cbeyond.net] Sent: Wednesday, May 19, 2010 8:50 PM To: Wadhavankar, Hemant; users@subversion.apache.org Subject: RE: SVN Error That would be the first thing I would do. What is the current timeout? Are you trying to use http or https? Regards, Tom From: Wadhavankar, Hemant [mailto:hemant.wadhavan...@lsi.com] Sent: Wednesday, May 19, 2010 10:58 AM To: users@subversion.apache.org Subject: SVN Error Hello, I am getting an error like this. I am using SVN 1.6.11 and Apache 2.2.14 svn: REPORT of '/!svn/vcc/default': Could not read response body: connection was closed by server I tried SVN checkout using file:/// method and it did not have any issues. Will changing "Timeout" in Apache configuration will help here? Best, Hemant Unstoppable..
Re: race condition on checkin immediately followed by a merge?
Hi Dan, Dan Stromberg wrote: > On Tue, May 18, 2010 at 1:20 AM, Bert Huijben wrote: > >>> Subversion uses a simple heuristic to determine if a file has >>> changed. It is well documented in the source code but perhaps >>> not so well known: >>> >>> If the size and time stamp of a file is the same as when checking >>> out the file it is immediately considered as unchanged. We had a >>> similar issue where an automatic script failed to commit an updated >>> file. >>> >>> This is most easily resolved by adding a small delay between checking >>> out and performing the modification. We used 2 seconds. You need to >>> wait long enough for your operating system file time stamp to tick >>> one step and on Windows this means about 2 seconds to be sure. >> On Windows and most operating systems this depends on the filesystem being >> used. >> >> On NTFS you should never see issues like these as the timestamps have 100 >> nanosecond precision. On FAT (including FAT32, but not including the newer >> VFAT) however you *do* see this issue. >> (On linux: Ext3 has 1 second precision and Ext4 has nanosecond precision. >> HFS+ on the mac has 1 second precision) >> >> Subversion tries to compensate for 1 second precision filesystems, but this >> is not guaranteed accurate for network filesystems and systems that use 2 >> second precision. (It waits until the time changed to the next second before >> returning from for these commands) Yes, IIRC we saw this problem on a network mounted directory which explains the 2 second jitter. > Folks seem to be saying that this is an issue in the SVN client's > working copy filesystem, not the SVN server's repository filesystem. > Is that correct? I may have misinterpreted your original problem. What I explained results in files not being committed at all! Your problem seems that a successful commit is not immediately available. Correct? > What part of this process would be dependent on the filesystem's > timestamp resolution: > > 1) Check out file n from srcurl rev 1000 to working copy 1, wc1 > 2) Pull the sole value out of n - an integer > 3) Increment the integer Here is where you'd need to wait a small amount of time before updating the file. > 4) Check n back in to srcurl with the increased value to srcurl rev 1001 > 5) Check out file n from dsturl rev 1000 to a new working directory, > wc2 (dsturl is a mirror of srcurl, but a little older) > 6) svn merge from srcurl at rev 1000 into wc2 > 7) checkin modified wc2 to dsturl > > ? > > I'm guessing it's a matter of step 7 (near the beginning, when a > freshness check is applied to n) seeing the same mtime and file size > on file n as it had in step 5 (near the end, when n is written). Is > that correct? I think that it is only in step 3, e.g. when doing the original update on the file, that you can stumble onto the file-not-changed heuristics. The svn merge will most probably work as expected. What server setup are you using? svnserve or Apache? Are you using write-through proxy with replication to read-only mirrors? Re-reading your description it seems that it is step 6 that fails (no new revision to merge). Since both server solutions are multi-threaded it might be that the processing of the commit in step (4) above has not been fully completed (and mirrored?) in time for when you initiate step (6). What kind of timing do you have between the steps? I would guess that 1-2-3-4 and 5-6-7 are fairly fast and that there may be some time N between steps 4 and 5? Regards /Daniel Widenfalk
