Any way to tell what subversion version I'm connecting to?
From a SVN command line client, is there any way to tell what version of Subversion is running on the server?
RE: SVN 1.6.15 checkout fails on particular file
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Friday, January 14, 2011 4:37 PM To: KARR, DAVID (ATTSI) Cc: David Huang; users@subversion.apache.org Subject: Re: SVN 1.6.15 checkout fails on particular file KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 16:31:04 -0800: -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Friday, January 14, 2011 4:20 PM To: KARR, DAVID (ATTSI) Cc: David Huang; users@subversion.apache.org Subject: Re: SVN 1.6.15 checkout fails on particular file KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 14:18:12 -0800: -Original Message- From: David Huang [mailto:k...@azeotrope.org] Sent: Friday, January 14, 2011 1:29 PM To: KARR, DAVID (ATTSI) Cc: users@subversion.apache.org Subject: Re: SVN 1.6.15 checkout fails on particular file On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote: I then looked at the full local path this file would represent, and the entire path is 260 characters long. I would think if there's any threshold, it would be at 255, not 259. Any idea what's going on here? The usual maximum path length limit on Windows is indeed 259 (or 260 if you count the terminating NUL): See the Maximum Path Length Limitation section of http://msdn.microsoft.com/en- us/library/aa365247%28v=vs.85%29.aspx Hmm, then Eclipse/Subversion must be doing something special to avoid this problem. My resulting paths in my existing projects checked out in Eclipse are quite a bit longer than 259 characters. IIRC, it's use absolute paths instead of relative paths. I'm not sure what you mean. You're saying that Subversive in Eclipse is referencing absolute paths, but using the command line client is using relative paths? Assuming that's the distinction, is there some way I could use the command-line client in a different way that might avoid this problem? Pass absolute paths to the cmdline client when you invoke it :) (svn 1.7 will use absolute paths internally) Bingo. That did the trick. Thanks.
SVN 1.6.15 checkout fails on particular file
This is a continuation of my experiences described in the What SVN command-line client distro should I get to work properly with SVN 1.4.x on the server? subject. My SVN server is running version 1.4.x. I'm using the latest Subversive in Eclipse, but the connector associated with SVN 1.5.6. This works well enough in Eclipse. I installed SVN 1.6.15 from CollabNet. I created a new directory from the shell and did a checkout of two of the projects I have checked out in Eclipse. One of them completed successfully, but another one fails each time with an error like the following: svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file '...\.svn\tmp\text-base\svn-base': The system cannot find the path specified. I elided the full path to the file. I looked in the text-base directory being referenced here, and it's empty. I did a svn cleanup, and it chugged for a second and then went back to the prompt. I tried the checkout again, and it failed with the exact same error. I also tried changing into the directory and doing svn update, and that also failed with the same error. Any ideas?
RE: SVN 1.6.15 checkout fails on particular file
-Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Friday, January 14, 2011 11:35 AM To: KARR, DAVID (ATTSI) Cc: users@subversion.apache.org Subject: Re: SVN 1.6.15 checkout fails on particular file On Fri, Jan 14, 2011 at 7:35 PM, KARR, DAVID (ATTSI) dk0...@att.com wrote: This is a continuation of my experiences described in the What SVN command-line client distro should I get to work properly with SVN 1.4.x on the server? subject. My SVN server is running version 1.4.x. I'm using the latest Subversive in Eclipse, but the connector associated with SVN 1.5.6. This works well enough in Eclipse. I installed SVN 1.6.15 from CollabNet. I created a new directory from the shell and did a checkout of two of the projects I have checked out in Eclipse. One of them completed successfully, but another one fails each time with an error like the following: svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file '...\.svn\tmp\text-base\svn-base': The system cannot find the path specified. I elided the full path to the file. I looked in the text-base directory being referenced here, and it's empty. I did a svn cleanup, and it chugged for a second and then went back to the prompt. I tried the checkout again, and it failed with the exact same error. I also tried changing into the directory and doing svn update, and that also failed with the same error. Any ideas? Could it be that there are case-clashing filenames in that directory, which you are trying to checkout on a case-insensitive filesystem (since you are on Windows)? Perhaps someone committed two files to the repository that only differ in case, like readme.txt and README.TXT. If you try to check this out on a case-insensitive filesystem, it will fail. You should be able to see exactly what's in the repository by running svn ls $URL. Hmm. I think I found a big clue. When I do the checkout, I'm giving it an alternate name. The svn checkout doc is clear that this is legal. In other words, I'm doing svn checkout svn:... desiredname. I've tried doing this several times, and it almost always fails on trying to check out this particular file. I just tried doing the checkout again, but without the alternate name, and it completed without error. I then tried changing the checkout to use a simpler alternate name. I was using a name like projectname-branch. I then tried projectname-a. Both of these fail. If I instead use an alternate name of a, or projectname (using the original project name), or a-a, those all succeed. I then tried using an alternate name of projectnamexx. That fails with the same error. I then tried abcdefghijklmnopqr (actually all the iterations before that), and that succeeds, but abcdefghijklmnopqrs (one more letter) fails. I then looked at the full local path this file would represent, and the entire path is 260 characters long. I would think if there's any threshold, it would be at 255, not 259. Any idea what's going on here? Cheers, -- Johan
RE: SVN 1.6.15 checkout fails on particular file
-Original Message- From: David Huang [mailto:k...@azeotrope.org] Sent: Friday, January 14, 2011 1:29 PM To: KARR, DAVID (ATTSI) Cc: users@subversion.apache.org Subject: Re: SVN 1.6.15 checkout fails on particular file On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote: I then looked at the full local path this file would represent, and the entire path is 260 characters long. I would think if there's any threshold, it would be at 255, not 259. Any idea what's going on here? The usual maximum path length limit on Windows is indeed 259 (or 260 if you count the terminating NUL): See the Maximum Path Length Limitation section of http://msdn.microsoft.com/en- us/library/aa365247%28v=vs.85%29.aspx Hmm, then Eclipse/Subversion must be doing something special to avoid this problem. My resulting paths in my existing projects checked out in Eclipse are quite a bit longer than 259 characters.
RE: SVN 1.6.15 checkout fails on particular file
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Friday, January 14, 2011 4:20 PM To: KARR, DAVID (ATTSI) Cc: David Huang; users@subversion.apache.org Subject: Re: SVN 1.6.15 checkout fails on particular file KARR, DAVID (ATTSI) wrote on Fri, Jan 14, 2011 at 14:18:12 -0800: -Original Message- From: David Huang [mailto:k...@azeotrope.org] Sent: Friday, January 14, 2011 1:29 PM To: KARR, DAVID (ATTSI) Cc: users@subversion.apache.org Subject: Re: SVN 1.6.15 checkout fails on particular file On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote: I then looked at the full local path this file would represent, and the entire path is 260 characters long. I would think if there's any threshold, it would be at 255, not 259. Any idea what's going on here? The usual maximum path length limit on Windows is indeed 259 (or 260 if you count the terminating NUL): See the Maximum Path Length Limitation section of http://msdn.microsoft.com/en- us/library/aa365247%28v=vs.85%29.aspx Hmm, then Eclipse/Subversion must be doing something special to avoid this problem. My resulting paths in my existing projects checked out in Eclipse are quite a bit longer than 259 characters. IIRC, it's use absolute paths instead of relative paths. I'm not sure what you mean. You're saying that Subversive in Eclipse is referencing absolute paths, but using the command line client is using relative paths? Assuming that's the distinction, is there some way I could use the command-line client in a different way that might avoid this problem?
What SVN command-line client distro should I get to work properly with SVN 1.4.x on the server?
I work on Windows with Cygwin. In Eclipse, I can do SVN checkouts and updates with the SVN on our server, which is running SVN 1.4.x. I'm doing this with the latest Subversive and connector. I've been told that after SVN 1.4.x, the storage format changed, so doing checkouts and updates with a SVN client newer than 1.4.x would screw up the .svn directories. In fact, I think I've seen this happen. I tried doing an update with my SVN command-line client (I appear to have SVN 1.5.7, from CollabNet), in a project that I work on in Eclipse, and when I refreshed my Eclipse, it got so confused I eventually had to create a new workspace. Working in the old workspace gave me constant error dialogs from Subversive. I suppose it's possible this wasn't a storage format issue, but simply an issue with updating the SVN state outside of Subversive. I don't know. I don't attempt checkouts or updates from the command line anymore. Doing svn diff or other information queries works fine. Is there a SVN command-line version that would be safe to use for checkouts and updates that won't screw up my .svn tree or Subversive? I asked about this on the Subversive forum, but I'm having trouble getting a response.
RE: What SVN command-line client distro should I get to work properly with SVN 1.4.x on the server?
-Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Thursday, January 13, 2011 2:58 PM To: KARR, DAVID (ATTSI) Cc: Andy Levy; users@subversion.apache.org Subject: Re: What SVN command-line client distro should I get to work properly with SVN 1.4.x on the server? On Thu, Jan 13, 2011 at 14:07, KARR, DAVID (ATTSI) dk0...@att.com wrote: I work on Windows with Cygwin. In Eclipse, I can do SVN checkouts and updates with the SVN on our server, which is running SVN 1.4.x. I'm doing this with the latest Subversive and connector. I've been told that after SVN 1.4.x, the storage format changed, so doing checkouts and updates with a SVN client newer than 1.4.x would screw up the .svn directories. Over the network RA layers (http, svn, svn+ssh), client server versions can differ as long as they're both 1.x. A 1.0 client can talk to a 1.6 server, and vice versa. The *client-side* storage format has been changed in most 1.x releases, and it's a silent update, so if you're using multiple clients, all must be the same minor revision - you can't mix a 1.4 1.5 client on the same system, unless they operate on separate WCs. I suspect you're running into problems for at least one of the following reasons, if not both: 1) Your Eclipse plugin command-line client are not the same minor version of Subversion. 2) The differences introduced by Cygwin to trick the SVN client into thinking it's in a *NIX environment are conflicting with the real Windows client that you have in Eclipse. In fact, I think I've seen this happen. I tried doing an update with my SVN command-line client (I appear to have SVN 1.5.7, from CollabNet), in a project that I work on in Eclipse, and when I refreshed my Eclipse, it got so confused I eventually had to create a new workspace. Working in the old workspace gave me constant error dialogs from Subversive. I suppose it's possible this wasn't a storage format issue, but simply an issue with updating the SVN state outside of Subversive. I don't know. I don't attempt checkouts or updates from the command line anymore. Doing svn diff or other information queries works fine. Try dropping the Cygwin environment for a while and exclusively use Eclipse and the *native* Win32 client in the Windows Command Prompt. Your Subversive plugin must be based on the same Subversion version as your Win32 client. I included the fact that I'm using Cygwin just for completeness. The SVN client I'm using is not part of Cygwin, it's from CollabNet. The SVN version that claims to represent is 1.5.7, which is the SVN version that my Subversive connector claims to represent. That tells me that I shouldn't be having a problem. I guess I'll have to try again and see what happens. Perhaps it's not a problem with SVN version mismatches. I'll have to test this very carefully so I don't screw up my main workspace. I guess I'll have to create another one just for this test. The problem is that Subversive includes a bastardized version of what used to be called JavaSvn and that only reads/writes the SVN 1.4 working copy format. Change Subversive so that it is using JavaHL or the newer SVNKit and the problems will go away. I would update the command line client and the Subversive connector so that it is using the latest SVN 1.6.x version available. I'm currently using SVNKit 1.2.3 (for SVN 1.5.6) with Subversive. (I had said this was 1.5.7 earlier). If I plan to change this connector to use the latest SVNKit, do I first have to delete all of my checked-out projects and check them out again after changing the connector?
RE: What SVN command-line client distro should I get to work properly with SVN 1.4.x on the server?
-Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Thursday, January 13, 2011 3:44 PM To: KARR, DAVID (ATTSI) Cc: Andy Levy; users@subversion.apache.org Subject: Re: What SVN command-line client distro should I get to work properly with SVN 1.4.x on the server? On Thu, Jan 13, 2011 at 6:37 PM, KARR, DAVID (ATTSI) dk0...@att.com wrote: I'm currently using SVNKit 1.2.3 (for SVN 1.5.6) with Subversive. (I had said this was 1.5.7 earlier). If it was using SVNKit 1.2.3 then you would not be having a problem. You have to be using the JavaSvn connector that only supports 1.4. They still provide it because they paid to have some custom behaviors added around merge and a couple other places that they wanted. But these customizations were not maintained going forward. I don't get what you're saying. It's set to SVNKit 1.2.3. I know I had a problem when I tried to do a SVN update from the command line a while ago. When I refreshed in Eclipse it started giving me so many bizarre error dialogs that I concluded I had to recreate my workspace. It's possible this wasn't a version difference problem. Perhaps Subversive has trouble if you do anything with the .svn files outside of Eclipse. You might also check preferences. SVNKit is capable of supporting multiple formats. So SVNKit 1.2.3 can support the 1.4 and 1.5 formats. You may have a setting somewhere telling it to use the 1.4 format. I see no setting in the SVN preferences that says anything like this. If I plan to change this connector to use the latest SVNKit, do I first have to delete all of my checked-out projects and check them out again after changing the connector? No, the format will just be upgraded to the latest format. No need to checkout again and the upgrade is relatively quick. The only issue is that earlier clients will not be able to read it any more. If you upgrade them all to 1.6.x this will not be an issue. Ok.
RE: Why does SVN prompt me for a password every time, after a domain migration?
-Original Message- From: Kevin Grover [mailto:ke...@kevingrover.net] Sent: Monday, September 13, 2010 4:16 PM To: KARR, DAVID (ATTSI) Cc: users@subversion.apache.org Subject: Re: Why does SVN prompt me for a password every time, after a domain migration? Subversion caches that stuff in %APPDATA%\Subversion, I believe in a file called 'auth'. Can't test right now because I'm not on a Windows system at the moment. Perhaps the owner did not get updated and the new domain can't write the the directory/file? You can look around there. Possibly just delete the directory/file - however, other options and passwords will go away -- be reset to the default. I've found more interesting behavior. I was doing this work on the command line for a few minutes, supplying the manual --password command-line parameter. After I finished that work I went back to Eclipse and I later realized that I wasn't getting prompting from SVN anymore. I then went back to the command line and tried not supplying the --password parameter, and it worked fine. If I understand this correctly, when you supply a working password through either the command line or Subversive, neither should ask again. The command line appears to have stored it correctly, but Subversive did not. I then tried restarting Eclipse (just to be sure), and it's still not presenting the password dialog. On Mon, Sep 13, 2010 at 15:36, KARR, DAVID (ATTSI) dk0...@att.com wrote: A few days ago my login got moved from one Windows domain to another. I've had to deal with several problems as a result of that. One particular problem is having with SVN. For some reason SVN is prompting me for a password on every single operation it tries to do. This is tolerable in Eclipse (Subversive plugin), as I simply have to press Enter on the dialog each time, as it's preentered the name and password. However, it's worse from the command line. I can get it to work if I manually add --password ... to the command line. If I don't, the Cygwin Bash shell seems to get confused about how to handle the prompts. I have to use a non-Cygwin SVN. I never had to re-specify the password on every operation before the domain migration.
Does SVN 1.4.x not know about ancestry?
I am forced to work with a SVN version on our server that is quite old, approximately 1.4.x. I use the latest Subversive version, but with the connector version that works with 1.4.x on the server. This combination works, but I'd like to understand some of the details underlying this. I believe that one of the main features that is absent in 1.4.x with respect to the latest is ancestry, or merge history. Is that correct? So in either the SVN or Subversive documentation, any option or feature related to ancestry will not be applicable here? In the red book on Subversion, in the section on svn merge, there is the following statement: Unlike svn diff, the merge command takes the ancestry of a file into consideration when performing a merge operation. This is very important when you're merging changes from one branch into another and you've renamed a file on one branch but not the other. This is interesting, but nothing else is said about this. What exactly does this imply?
Problems merging from a Windows client to a SVN 1.3.1 server on Unix
I'm on Eclipse 3.5.2. I believe I have the latest version of Subversive (it's either 0.7.8 or 2.2.1, depending on what piece you're asking about). However, my SVN Connector is for version 1.5 (SVNKit 1.2.3), as I have to work with a SVN 1.3.1 server. If I use the latest connector version, it apparently causes errors with already merged when I try to do a merge to a freshly checked-out project. Now, I've checked out two versions of a project, one on the trunk, and one on a branch. I don't really need the first one, it's just for reference. After finishing the checkout, I right-click on the branch project and select Team-Merge. I browse in the SVN repo to the trunk and start the merge. After working for a long time, it finally fails with something like this: -- Merge status operation failed. Some of resources were not refreshed. svn: Working copy '...\Exception' locked; try performing 'cleanup' Errors occurred while refreshing resources with the local file system. - Exception is a directory. I've now done this several times, each time completely deleting the project I'm trying to merge to. This time I tried doing Cleanup from the Team menu before doing the merge. It made no difference. Although this is a very non-trivial project, with hundreds of source files and directories, this merge attempt fails at the same point each time, on that directory named Exception. What I now see is that when I go to the parent directory, the name of that directory is actually exception, both in my checked-out copy, and in the SVN repo browser. I don't know if this discrepancy is the cause of this problem or not. Another thought I had: Is anyone aware of any problems that existing way back in SVN 1.3.1 that would have caused problems with a Windows client, either due to line ending, case sensitivity, or any other issue?
Getting file already exists error for file that couldn't exist?
I'm using the Subversive plugin in Eclipse, but I think I need to understand the scope of the problem I'm getting just within Subversion. I created a file in my Eclipse workspace that I'm certain didn't exist before. I did a svn add through the plugin. I committed it. I got the following error: svn: File already exists: filesystem '/cm/websvn/db', transaction '128517-1', path 'path to the file I created' I then aborted the commit, reverted the add, deleted the file, did a svn update, created the file again, added it, and committed it, and I got the same error. What could be happening here?
RE: Getting file already exists error for file that couldn't exist?
-Original Message- From: KARR, DAVID (ATTSI) Sent: Friday, March 05, 2010 9:48 AM To: users@subversion.apache.org Subject: Getting file already exists error for file that couldn't exist? I'm using the Subversive plugin in Eclipse, but I think I need to understand the scope of the problem I'm getting just within Subversion. I created a file in my Eclipse workspace that I'm certain didn't exist before. I did a svn add through the plugin. I committed it. I got the following error: svn: File already exists: filesystem '/cm/websvn/db', transaction '128517-1', path 'path to the file I created' I then aborted the commit, reverted the add, deleted the file, did a svn update, created the file again, added it, and committed it, and I got the same error. What could be happening here? I browsed the SVN repo, and the file is there. However, when I do a svn update, it doesn't put the file in my workspace (and I now see a couple of other files from that directory that aren't showing up there). What do I have to do to force the update in that directory?
