RE: Subversion repository config problem
-Original Message- From: Tony Butt [mailto:tony.b...@cea.com.au] Sent: 10 November 2011 07:15 To: Cooke, Mark Cc: users@subversion.apache.org Subject: RE: Subversion repository config problem On Thu, 2011-11-10 at 06:59 +, Cooke, Mark wrote: The second problem is that we run trac, and (as recommended by the trac project) use post-commit hooks to log repository changes into the trac timeline. This fails when svn+ssh:// is used, as the process owner does not have permission to use trac-admin in that way. ...as a trac user (but being a windoze shop, not svn+ssh) I was wondering, is this a fundamental trac problem or a local configuration issue? If it is trac then it should be reported to trac-users too... Normally your svn+ssh process runs as the user who's credentials were supplied. Trac-admin does not allow general users to do much of anything on a linux box, not sure about windows. Forgive my *nix noob status but is that not due to the local security configuration, I do not think that is built in to the trac code itself? Professional versions of windoze can be configured for security but the defaults are much more relaxed than *nix (AFAIK)! I would say it was a fundamental trac problem, resulting from a collision of 2 sets of assumptions for security. That is, svnserve will run as a local, authenticated user for security, audit trail, etc. trac-admin will only update the timeline (or make any other change) if it is superuser (or somesuch). ...or perhaps just the assumption that if you are using http(s) for trac you will be doing the same with svn and from the same user. Hmm, thinking about it, there should be no reason for the httpd user to run trac-admin except for this, so putting the code in trac-admin was perhaps a design mistake? There might be a way to configure trac-admin to allow anyone to make those changes, but that exposes the trac installation to greater risk. ...so one solution would be to split the update code out of trac-admin so that can be made available without exposing the more powerful admin functionality? I think this might be worth a ticket at t.e.o... Sigh - I will just strongly suggets to our engineers that they use http:// protocol only, most do already. Tony ~ mark c
Upgrading repo without using svnserve
This may be a stupid question, but I'm using svn (via TortoiseSVN and client 1.16.16) to a file-based repo (i.e. no subversion server). When I try to re-integrate a branch, I get Retrieval of merginfo unsupported. Searches for this say I need to upgrade the repo with svnadmin --upgrade - but svnadmin is part of svnserver, which I don't use. Do I have to install svnserve (or just svnadmin) to do this (then uninstall svnserve if I don't want to continue with it?)
Re: Upgrading repo without using svnserve
2011/11/10 Richard Boyce rich...@weathermead.co.uk: This may be a stupid question, but I'm using svn (via TortoiseSVN and client 1.16.16) to a file-based repo (i.e. no subversion server). When I try to re-integrate a branch, I get Retrieval of merginfo unsupported. Searches for this say I need to upgrade the repo with svnadmin --upgrade - but svnadmin is part of svnserver, which I don't use. Do I have to install svnserve (or just svnadmin) to do this (then uninstall svnserve if I don't want to continue with it?) Only svnadmin. Note, that TortoiseSVN 1.7 includes command-line tools in it. Or you can download the command line tools from here: http://sourceforge.net/projects/win32svn/files/ Best regards, Konstantin Kolinko
Re: Upgrading repo without using svnserve
On 11/10/2011 12:05 AM, Richard Boyce wrote: This may be a stupid question, but I'm using svn (via TortoiseSVN and client 1.16.16) to a file-based repo (i.e. no subversion server). When I try to re-integrate a branch, I get Retrieval of merginfo unsupported. Searches for this say I need to upgrade the repo with svnadmin --upgrade - but svnadmin is part of svnserver, which I don't use. Do I have to install svnserve (or just svnadmin) to do this (then uninstall svnserve if I don't want to continue with it?) svnadmin is a command-line executable. I don't know how TortoiseSVN is packaged, but you do not have to go through svnserve to use svnadmin. You can either install svnadmin.exe by itself (if possible) or install the svnserve package, then use only svnadmin.exe. Not knowing which DLLs are needed to run svnadmin.exe, I can't tell you how much to delete afterwards, but I would expect that you can leave everything in place. If TortoiseSVN insists on going through svnserve.exe, you should be able to delete just that. It may be better to ask this question on the TortoiseSVN list. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: Upgrading repo without using svnserve
On Thu, Nov 10, 2011 at 08:05:59AM +, Richard Boyce wrote:
This may be a stupid question, but I'm using svn (via TortoiseSVN
and client 1.16.16) to a file-based repo (i.e. no subversion
server). When I try to re-integrate a branch, I get Retrieval of
merginfo unsupported.
Searches for this say I need to upgrade the repo with svnadmin
--upgrade - but svnadmin is part of svnserver, which I don't use.
Do I have to install svnserve (or just svnadmin) to do this (then
uninstall svnserve if I don't want to continue with it?)
Re-install tortoissvn 1.7.1 and make sure to pick the
'install command line tools' option during install.
This will provide svnadmin in the cmd.exe text console.
Then run 'svnadmin upgrade REPOS_PATH' ('upgrade', not '--upgrade').
Renaming on-the-fly?
Hello! I want to check out an open source project (obviously from a *nix file system) using the same name differing only in case for two different files , which results in a conflict on windows. As I'm not a committer to the project, I cannot rename the file in the repository, so can I tell svn to rename it while checking it out? Kind regards Peter
Checkout including externals is getting the head revision instead of specified one
Hello, since I am using svn, version 1.7.1 (r1186859) compiled Oct 22 2011, 10:53:27 I got the problem that when I checkout some code that is using externals with a special specified revision of that external to be checked out svn checks out the head revision in stead of the specified revision number. When I use svn update after checkout on that trunk than the revision of that external is corrected. I am not shure if this is a subversion bug or if anything is wrong on my system. Reproduction: 1. Checkout a trunk that is using an external with a special revision number e.g.: svn:externals -r 10163 ^/path destination 2. Check if that external was checked out with revision 10163 or if it was checked out with head revision Due to that it is recommended that the revision 10163 is not the head revision 3. Update the trunk containing the external code in the working copy using svn update 4. Check if the revision is now the right one -- Mit freundlichen Grüßen / Kind regards Dipl.-Inform. (FH) Bastian Holtermann Softwareentwicklung / Software Development Tel: +49 2339 9232997 Fax: +49 2339 120656 E-Mail: b.holterm...@sorel.de mailto:%22b.holterm...@sorel.de%22 URL: www.sorel.de http://www.sorel.de SOREL GmbH Mikroelektronik Jahnstr. 36 D-45549 Sprockhövel Geschäftsführer: Dipl.-Ing. Georg Bicher Amtsgericht Essen HRB 15326 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Network Share Checkouts
Hi All I am trying to compile a best practice guide for my organisation's Subversion users. I am now thinking about the issue of checking out to a network drive. It looks like over the years this has generated a number of issues for the community. So I would be very interest to hear if this has caused anyone any problems? Anyone know of any problems? What is the general consensus around this? Thanks Mark The information contained in this message (and any attachments) may be confidential and is intended for the sole use of the named addressee. Access, copying, alteration or re-use of the e-mail by anyone other than the intended recipient is unauthorised. If you are not the intended recipient please advise the sender immediately by returning the e-mail and deleting it from your system. This information may be exempt from disclosure under Freedom Of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to the Information Officer. The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by CableWireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
Error found
I found this error: --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion \libsvn_wc\adm_ops.c' line 177: assertion failed (status == svn_wc__db_status_normal || status == svn_wc__db_status_added) --- Aceptar ---
Re: Error found
Am 10.11.2011 10:07, schrieb JESUS LUNAR PEREZ: Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message Please consider those two parts of the quest, too. Without knowing what you did, there is no way for a developer to reproduce the error, unless they happen to come across it by chance. Reporting a known error over and over without adding any information is only causing useless work and not getting any bugs fixed. Sorry! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: Checkout including externals is getting the head revision instead of specified one
Bastian Holtermann / SOREL GmbH b.holterm...@sorel.de writes: I got the problem that when I checkout some code that is using externals with a special specified revision of that external to be checked out svn checks out the head revision in stead of the specified revision number. Agreed, that is a bug. I've raised issue 4053: http://subversion.tigris.org/issues/show_bug.cgi?id=4053 -- Philip
Re: Error found
Ulrich Eckhardt ulrich.eckha...@dominolaser.com writes: Am 10.11.2011 10:07, schrieb JESUS LUNAR PEREZ: Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message Please consider those two parts of the quest, too. Without knowing what you did, there is no way for a developer to reproduce the error, unless they happen to come across it by chance. Reporting a known error over and over without adding any information is only causing useless work and not getting any bugs fixed. Indeed. It looks like issue http://subversion.tigris.org/issues/show_bug.cgi?id=4042 but with the limited information provided we can only guess. -- Philip
Re: merge problem. impossible to revert deleted file
Gunnar Dalsnes har...@online.no writes: REM change this to the dir you are running the script from set wd=c:/temp/test svnadmin create repo svn mkdir file:///%wd%/repo/trunk -m test svn co file:///%wd%/repo/trunk trunk1 svn co file:///%wd%/repo/trunk trunk2 trunk2 is an empty directory at r1 svn copy trunk1 file:///%wd%/repo/branch -m branch svn co file:///%wd%/repo/branch branch pushd branch md dir1 pushd dir1 echo file2.txt popd svn add * svn commit -m test popd pushd trunk1 svn update md dir1 pushd dir1 echo file1.txt popd svn add * svn commit -m test popd pushd trunk2 svn merge file:///%wd%/repo/branch@4 REM tree conflict svn resolve --accept=working dir1 Did you miss a step? trunk2 is still an empty directory at r1, how can that cause a conflict. svn up REM Updating '.': REMA dir1\file1.txt REM It says dir1\file1.txt is added, but it's nowhere to be seen dir dir1 svn status dir1 svn resolve --accept=working dir1 svn revert dir1\file1.txt REM Nope, file is still deleted. Impossible to undelete it. popd popd ---end script--- Another small issue: svn merge don't seem to like backslash in file urls: C:\temp\test\trunk2svn merge file:///C:\temp\test\trunk2/repo/branch@4 svn: E180001: Unable to connect to a repository at URL file:///C:%5Ctemp%5Ctest %5Ctrunk2/repo/branch' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository file:///C:%5Ctemp%5Ctest%5Ctrunk2/repo/ branch' Otoh, svn co and svn mkdir etc. seems to work with backslash in file urls. thanks, Gunnar Dalsnes -- Philip
WC database corruption (1.7.1)
Having just done a couple of commits (after an update), I did some work on a file then went to commit again (no 2nd. update) and TortoiseSVN reported no changes. A command line 'svn status .' is giving me: svn: E200030: database disk image is malformed svn: E200030: database disk image is malformed Er. Can I recover from this? Do you want any diagnostics from it (the SQLite d/b)? -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Re: Network Share Checkouts
On Thursday, November 10, 2011, markw ma...@hmgcc.gsi.gov.uk wrote: Hi All I am trying to compile a best practice guide for my organisation's Subversion users. I am now thinking about the issue of checking out to a network drive. It looks like over the years this has generated a number of issues for the community. So I would be very interest to hear if this has caused anyone any problems? - The big issue is storing a repository on a network drive and having everyone access it via the file:// protocol. That is a bad idea . On many Unix systems, your home directory is a network drive, and on Windows systems, the My Directory is a share. So, doing a checking out on a network is not that rare and may be the only way you can do a check out. -- David Weintraub -- David Weintraub qazw...@gmail.com
Re: WC database corruption (1.7.1)
Neil Bird n...@jibbyjobby.co.uk writes: Having just done a couple of commits (after an update), I did some work on a file then went to commit again (no 2nd. update) and TortoiseSVN reported no changes. A command line 'svn status .' is giving me: svn: E200030: database disk image is malformed svn: E200030: database disk image is malformed Er. Can I recover from this? Do you want any diagnostics from it (the SQLite d/b)? Never seen that before. If you have the sqlite3 tool then you can try sqlite3 .svn/wc.db pragma integrity_check which may give more information. -- Philip
Re: Network Share Checkouts
On Thu, Nov 10, 2011 at 7:21 AM, David Weintraub qazw...@gmail.com wrote: On Thursday, November 10, 2011, markw ma...@hmgcc.gsi.gov.uk wrote: Hi All I am trying to compile a best practice guide for my organisation's Subversion users. I am now thinking about the issue of checking out to a network drive. It looks like over the years this has generated a number of issues for the community. So I would be very interest to hear if this has caused anyone any problems? - The big issue is storing a repository on a network drive and having everyone access it via the file:// protocol. That is a bad idea . On many Unix systems, your home directory is a network drive, and on Windows systems, the My Directory is a share. So, doing a checking out on a network is not that rare and may be the only way you can do a check out. CIFS checkouts used to be *horrible* for large working copies of many thousands of files in one directory. This has allegedly gotten vastly better with recent releases. (I did significant testing with CIFS 2.x to see if that helped, it didn't). I used to have to keep a checked out working copy that people could replicate from to gain a 100-fold speed improvement over normal checkouts on CIFS. On NFS, it it was no faster to check out than to replicate. There are risks of people all working inside the same working copy: They can be editing a file when you're in the midst of committing your changes, a good reason to maintain *distinct* branches. If you need. The ideal behavior of commits being atomic becomes imperiled if someone else can edit a file while you're committing it. (This could be worse: I had huge issues with an impolite person who would view files with vi while I edited and tried to commit with Emacs, and when he quit it would *revert my changes* in the working copy. vi is for editing, less is for viewing!) Windows versus UNIX style end-of-line also becomes important. The svn:eol style for files in a shared repository will behave differently on Windows boxes accessing a CIFS share from a UNIX or Linux box via Samba than the UNIX or Linux box will provide with local or NFS access to exactly the same working copy if that is set. Also, naming conventions become important, becuase CIFS does not support multiple files that only differ in capitalization for the same name, but a UNIX or Linux access to the same working copy will handle it merrily if the access is direct or NFS based. I spent a *lot* of time explaining this to verious people trying to use multiple platform shared access, and running headlong into the problems they thought they'd cleverly worked around. It became an adventure to explain why svn:eol should be deprecated, preferably with a claw hammer.
Re: Network Share Checkouts
On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia nka...@gmail.com wrote: I spent a *lot* of time explaining this to verious people trying to use multiple platform shared access, and running headlong into the problems they thought they'd cleverly worked around. It became an adventure to explain why svn:eol should be deprecated, preferably with a claw hammer. Ummm, no. Using other ways of move files across systems that need eol-munging shouldn't have been considered in the first place. There's a long, long history. -- Les Mikesell lesmikes...@gmail.com
Re: Network Share Checkouts
On Thu, Nov 10, 2011 at 8:46 AM, Les Mikesell lesmikes...@gmail.com wrote: On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia nka...@gmail.com wrote: I spent a *lot* of time explaining this to verious people trying to use multiple platform shared access, and running headlong into the problems they thought they'd cleverly worked around. It became an adventure to explain why svn:eol should be deprecated, preferably with a claw hammer. Ummm, no. Using other ways of move files across systems that need eol-munging shouldn't have been considered in the first place. There's a long, long history. Les, moving wasn't the problem. Inheritance was. People who'd not paid attention to their CVS-Subversion migrations, or inconsistently laid defaults and inherited svn:eol settings of any kind were alarmed when their working copy accessed in Linux for compilation, but managed with TortoiseSVN for the superior management GUI, proceeded to have real end-of-line management problems. And this is *precisely* the sort of issue that can occur with shared network drives. It's especially an issue with files get added or imkported and a different svn:eol policy gets set, and then you have to *change* it. on the fly. This kind of clean-up whackiness is why constintly setting the EOL as a matter of document type, not local operating system, is so useful.
Modified (properties only)
Hi Whenever we merge to, or reintegrate from, our branches, one particular file is always merged with the comment 'Modified (properties only)'. We seldom change this file. Is there anything I can do to stop this happening? We are running svn 1.6.17. Best regards David
AW: Unable to delete directory in repository, server version 1.7.1
I can confirm that. Deleting is only possible if the user has write permnissions on the ENTIRE path. / top/subdir/mypath In order to delete mypath, the user needs write permission on / /top/subdir /top/subdir /top/subdir/mypath With an 1.6.x server, write access to /top and above were not necessary. I could not find any documentation about this changed behavior. Next, it is not really what we want. I don't want to give all users write access on the entire tree up to the rootfolder just to enable them to svn delete their own files and folders.
Re: WC database corruption (1.7.1)
Around about 10/11/11 13:21, Philip Martin typed ... pragma integrity_check I'd done that, but it doesn't mean anything to me! *** in database main *** On tree page 40898 cell 60: 2nd reference to page 325 On tree page 40898 cell 60: Child page depth differs On tree page 40898 cell 61: Child page depth differs rowid 14277 missing from index sqlite_autoindex_PRISTINE_1 rowid 14278 missing from index sqlite_autoindex_PRISTINE_1 wrong # of entries in index sqlite_autoindex_PRISTINE_1 rowid 45935 missing from index I_NODES_PARENT rowid 45935 missing from index sqlite_autoindex_NODES_1 rowid 45936 missing from index I_NODES_PARENT rowid 45936 missing from index sqlite_autoindex_NODES_1 rowid 469 missing from index I_NODES_PARENT rowid 469 missing from index sqlite_autoindex_NODES_1 rowid 470 missing from index I_NODES_PARENT rowid 470 missing from index sqlite_autoindex_NODES_1 rowid 471 missing from index I_NODES_PARENT rowid 471 missing from index sqlite_autoindex_NODES_1 rowid 472 missing from index I_NODES_PARENT rowid 472 missing from index sqlite_autoindex_NODES_1 wrong # of entries in index I_NODES_PARENT wrong # of entries in index sqlite_autoindex_NODES_1 -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Authz permisison problem after upgrade from 1.6.16 to 1.7.1
Hi *, I have an really interesting case here, which looks to me like an bug. The behavior started after the upgrade of our SVN server from 1.6.16 to 1.7.1. We use a windows server (SVNSERVE) here, I haven't tested this on Apache. The scenario: We have a source code tree, which lives let's say under /trunk/testApp In the SVN root, we have some more folders, such as /branches We also have a build server, who checks the source out into his local WC. After the successful build, the build server sets an tag under /tags/buildserver/testApp Which he does by means of svn copy (I can provide the exact command, if neceassary). This works, if I configure the access control file like this: [/tags] Buildserver = rw * = r [/trunk] Buildserver = rw * = r [/] Buildserver = rw * = r It does no longer work (the svn copy command fails with access denied) when I add /branches to the access configuration: [/tags] Buildserver = rw * = r [/trunk] Buildserver = rw * = r [/branches] * = r [/] Buildserver = rw * = r It starts to work again, if I give the buildserver explicit write access to [/branches]. == Please note, that /branches is not affected by the copy, neither as source, nor as the target. == This looks like a clear bug to me. Again, I were not able to found any documentation about such changes in the access control logic. Is there some documentation around about these new features of svn 1.7? JensG
AW: Unable to delete directory in repository, server version 1.7.1
Correction: In order to delete mypath, the user needs write permission on / /top /top/subdir /top/subdir/mypath -Ursprüngliche Nachricht- Von: Jens Geyer [mailto:j...@vsx.net] Gesendet: Donnerstag, 10. November 2011 16:56 An: Bostjan Skufca; users@subversion.apache.org Betreff: AW: Unable to delete directory in repository, server version 1.7.1 I can confirm that. Deleting is only possible if the user has write permnissions on the ENTIRE path. / top/subdir/mypath In order to delete mypath, the user needs write permission on / /top /top/subdir /top/subdir/mypath With an 1.6.x server, write access to /top and above were not necessary. I could not find any documentation about this changed behavior. Next, it is not really what we want. I don't want to give all users write access on the entire tree up to the rootfolder just to enable them to svn delete their own files and folders.
AW: Modified (properties only)
Is there anything I can do to stop this happening? If it is a file, you can AFAIK safely remove the mergeinfo property from the file . JensG
Re: merge problem. impossible to revert deleted file
On 10.11.2011 12:26, Philip Martin wrote: Gunnar Dalsneshar...@online.no writes: REM change this to the dir you are running the script from set wd=c:/temp/test svnadmin create repo svn mkdir file:///%wd%/repo/trunk -m test svn co file:///%wd%/repo/trunk trunk1 svn co file:///%wd%/repo/trunk trunk2 trunk2 is an empty directory at r1 Not sure what you mean, but it checkout the emtpty trunk into two dirs trunk1 and trunk2. I tested the script again to be sure, copy/pasted from this mail, and it do reproduce the problem as described. Note that some email readers may mess up the echo (removing the ) during copy/paste. svn copy trunk1 file:///%wd%/repo/branch -m branch svn co file:///%wd%/repo/branch branch pushd branch md dir1 pushd dir1 echo file2.txt popd svn add * svn commit -m test popd pushd trunk1 svn update md dir1 pushd dir1 echo file1.txt popd svn add * svn commit -m test popd pushd trunk2 svn merge file:///%wd%/repo/branch@4 REM tree conflict svn resolve --accept=working dir1 Did you miss a step? No, nothing is missed, but it seems this line is useless (but harmless). The problem appears regardless. trunk2 is still an empty directory at r1, how can that cause a conflict. Yes, just ignore that line. svn up REM Updating '.': REMA dir1\file1.txt REM It says dir1\file1.txt is added, but it's nowhere to be seen dir dir1 svn status dir1 svn resolve --accept=working dir1 svn revert dir1\file1.txt REM Nope, file is still deleted. Impossible to undelete it. popd popd ---end script--- Another small issue: svn merge don't seem to like backslash in file urls: C:\temp\test\trunk2svn merge file:///C:\temp\test\trunk2/repo/branch@4 svn: E180001: Unable to connect to a repository at URL file:///C:%5Ctemp%5Ctest %5Ctrunk2/repo/branch' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository file:///C:%5Ctemp%5Ctest%5Ctrunk2/repo/ branch' Otoh, svn co and svn mkdir etc. seems to work with backslash in file urls. thanks, Gunnar Dalsnes
Re: Network Share Checkouts
On Thu, Nov 10, 2011 at 8:13 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Thu, Nov 10, 2011 at 8:46 AM, Les Mikesell lesmikes...@gmail.com wrote: On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia nka...@gmail.com wrote: I spent a *lot* of time explaining this to verious people trying to use multiple platform shared access, and running headlong into the problems they thought they'd cleverly worked around. It became an adventure to explain why svn:eol should be deprecated, preferably with a claw hammer. Ummm, no. Using other ways of move files across systems that need eol-munging shouldn't have been considered in the first place. There's a long, long history. Les, moving wasn't the problem. Inheritance was. People who'd not paid attention to their CVS-Subversion migrations, or inconsistently laid defaults and inherited svn:eol settings of any kind were alarmed when their working copy accessed in Linux for compilation, but managed with TortoiseSVN for the superior management GUI, proceeded to have real end-of-line management problems. And this is *precisely* the sort of issue that can occur with shared network drives. It's especially an issue with files get added or imkported and a different svn:eol policy gets set, and then you have to *change* it. on the fly. This kind of clean-up whackiness is why constintly setting the EOL as a matter of document type, not local operating system, is so useful. I'm not sure I see a point here. There are lots of things that you have to get right or things won't work, and this is one of them. We can't change history and pretend that text is the same on every system even though the difference looks like a mistake in retrospect. --- Les Mikesell lesmikes...@gmail.com
Re: WC database corruption (1.7.1)
Neil Bird n...@jibbyjobby.co.uk writes: *** in database main *** On tree page 40898 cell 60: 2nd reference to page 325 On tree page 40898 cell 60: Child page depth differs On tree page 40898 cell 61: Child page depth differs rowid 14277 missing from index sqlite_autoindex_PRISTINE_1 rowid 14278 missing from index sqlite_autoindex_PRISTINE_1 wrong # of entries in index sqlite_autoindex_PRISTINE_1 rowid 45935 missing from index I_NODES_PARENT rowid 45935 missing from index sqlite_autoindex_NODES_1 rowid 45936 missing from index I_NODES_PARENT rowid 45936 missing from index sqlite_autoindex_NODES_1 rowid 469 missing from index I_NODES_PARENT rowid 469 missing from index sqlite_autoindex_NODES_1 rowid 470 missing from index I_NODES_PARENT rowid 470 missing from index sqlite_autoindex_NODES_1 rowid 471 missing from index I_NODES_PARENT rowid 471 missing from index sqlite_autoindex_NODES_1 rowid 472 missing from index I_NODES_PARENT rowid 472 missing from index sqlite_autoindex_NODES_1 wrong # of entries in index I_NODES_PARENT wrong # of entries in index sqlite_autoindex_NODES_1 Interesting! I've never seen a corrupt SQLite database before. It seems as if the corruption is restricted to the indices so it may be recoverable. It may be as simple as sqlite .svn/wc.db reindex nodes sqlite .svn/wc.db reindex pristine but I don't know if that will work. If it doesn't then it may be possible to copy, drop, replace the tables. This may not work either as the index corruption may simply be the visible effect of larger corruption. sqlite3 .svn/wc.db select sql from sqlite_master where name='NODES' sqlite3 .svn/wc.db select sql from sqlite_master where name='I_NODES_PARENT' will show you the SQL for the table and index that need to be recreated. Make a backup copy of wc.db before going further! Create a duplicate table NODES_COPY: sqlite3 .svn/wc.db CREATE TABLE NODES_COPY ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_relpath TEXT NOT NULL, op_depth INTEGER NOT NULL, parent_relpath TEXT, repos_id INTEGER REFERENCES REPOSITORY (id), repos_path TEXT, revision INTEGER, presence TEXT NOT NULL, moved_here INTEGER, moved_to TEXT, kind TEXT NOT NULL, properties BLOB, depth TEXT, checksum TEXT REFERENCES PRISTINE (checksum), symlink_target TEXT, changed_revision INTEGER, changed_date INTEGER, changed_author TEXT, translated_size INTEGER, last_mod_time INTEGER, dav_cache BLOB, file_external TEXT, PRIMARY KEY (wc_id, local_relpath, op_depth) ) Copy NODES into NODES_COPY sqlite3 .svn/wc.db insert into NODES_COPY select * from NODES Drop and recreate NODES: sqlite3 .svn/wc.db drop table NODES sqlite3 .svn/wc.db CREATE TABLE NODES ( wc_id INTEGER NOT NULL REFERENCES WCROOT (id), local_relpath TEXT NOT NULL, op_depth INTEGER NOT NULL, parent_relpath TEXT, repos_id INTEGER REFERENCES REPOSITORY (id), repos_path TEXT, revision INTEGER, presence TEXT NOT NULL, moved_here INTEGER, moved_to TEXT, kind TEXT NOT NULL, properties BLOB, depth TEXT, checksum TEXT REFERENCES PRISTINE (checksum), symlink_target TEXT, changed_revision INTEGER, changed_date INTEGER, changed_author TEXT, translated_size INTEGER, last_mod_time INTEGER, dav_cache BLOB, file_external TEXT, PRIMARY KEY (wc_id, local_relpath, op_depth) ) sqlite3 .svn/wc.db create index I_NODES_PARENT on NODES (wc_id, parent_relpath, op_depth) Copy NODES_COPY into NODES: sqlite3 .svn/wc.db insert into NODES select * from NODES_COPY Drop table NODES_COPY: sqlite3 .svn/wc.db drop table NODES_COPY Then you need to do something similar for PRISTINE, although this time there is no extra index: sqlite3 .svn/wc.db select sql from sqlite_master where name='PRISTINE' Create PRISTINE_COPY Copy PRISTINE into PRISTINE_COPY Drop and recreate PRISTINE Copy PRISTINE_COPY into PRISTINE Drop PRISTINE_COPY -- Philip
RE: Modified (properties only)
If it is a file, you can AFAIK safely remove the mergeinfo property from the file . Thanks, it is a file. I have removed the property in the trunk. I then merged the trunk into my branch whereupon I got a conflict for that file. So I just deleted the mergeinfo property in the branch, marked the file as resolved and committed the branch. Not sure if that was the right thing to do. It may reoccur next time I merge, I guess. David
Re: AW: Unable to delete directory in repository, server version 1.7.1
Jens Geyer j...@vsx.net writes: I can confirm that. Deleting is only possible if the user has write permnissions on the ENTIRE path. / top/subdir/mypath In order to delete mypath, the user needs write permission on / /top/subdir /top/subdir /top/subdir/mypath With an 1.6.x server, write access to /top and above were not necessary. I could not find any documentation about this changed behavior. Next, it is not really what we want. I don't want to give all users write access on the entire tree up to the rootfolder just to enable them to svn delete their own files and folders. I can't reproduce this, or your other authz problem, on my Linux machine: $ cat repo/conf/svnserve.conf [general] auth-access = write anon-access = password-db = passwd authz-db = authz $ cat repo/conf/authz [/A/B] pm = rw [/] * = r $ svn ls -R --username pm svn://localhost/repo A/ A/B/ X/ X/Y/ $ svn cp -mm --username pm svn://localhost/repo/X/Y svn://localhost/repo/A/B/C Committed revision 12. $ svn rm -mm --username pm svn://localhost/repo/A/B/C Committed revision 13. $ svn rm -mm --username pm svn://localhost/repo/A/B svn: E220004: Access denied $ svn cp -mm --username pm svn://localhost/repo/X/Y svn://localhost/repo/A/C svn: E220004: Access denied I wonder if there is an upper/lower case problem somewehere in your authz file? Or perhaps in the Subversion authz code? -- Philip
Re: Renaming on-the-fly?
On Nov 10, 2011, at 02:43, P.N. wrote: I want to check out an open source project (obviously from a *nix file system) using the same name differing only in case for two different files , which results in a conflict on windows. As I'm not a committer to the project, I cannot rename the file in the repository, so can I tell svn to rename it while checking it out? No; explain to a committer of that project how they can fix it.
Re: AW: Unable to delete directory in repository, server version 1.7.1
On Thu, Nov 10, 2011 at 05:25:27PM +, Philip Martin wrote: I wonder if there is an upper/lower case problem somewehere in your authz file? Or perhaps in the Subversion authz code? If so, this is likely due to the change in case-awareness we made in 1.7: file:///home/stsp/svn/svn-site/publish/docs/release-notes/1.7.html#case-sensitive-authz
Re: Network Share Checkouts
On Nov 10, 2011, at 07:27, Nico Kadel-Garcia wrote: Windows versus UNIX style end-of-line also becomes important. The svn:eol style for files in a shared repository will behave differently on Windows boxes accessing a CIFS share from a UNIX or Linux box via Samba than the UNIX or Linux box will provide with local or NFS access to exactly the same working copy if that is set. I spent a *lot* of time explaining this to verious people trying to use multiple platform shared access, and running headlong into the problems they thought they'd cleverly worked around. It became an adventure to explain why svn:eol should be deprecated, preferably with a claw hammer. Every time you bring this up I have to point out that what you're talking about applies only when a file's svn:eol-style property is set to native. It does not apply when svn:eol-style is set to another value, such as LF or CRLF, nor does it apply if svn:eol-style is not set. I would strongly advise users to set svn:eol-style of their text files to LF or CRLF as appropriate, to avoid the problem of getting inconsistent line endings in the file due to using different editors with different settings or on different platforms. Using svn:eol-style native is also fine, so long as you understand that working copies should not be shared among operating systems with different line ending styles. Also, naming conventions become important, becuase CIFS does not support multiple files that only differ in capitalization for the same name, but a UNIX or Linux access to the same working copy will handle it merrily if the access is direct or NFS based. Case conflicts are an issue you'll want to avoid if you have Mac users too, since the default Mac filesystem is case-insensitive too, just like on Windows.
Re: Network Share Checkouts
On Nov 10, 2011, at 03:08, markw wrote: I am trying to compile a best practice guide for my organisation's Subversion users. I am now thinking about the issue of checking out to a network drive. It looks like over the years this has generated a number of issues for the community. So I would be very interest to hear if this has caused anyone any problems? Anyone know of any problems? What is the general consensus around this? My experience is that you might run into some performance problems that may or may not be significant, and you may run into permissions issues that may completely prevent working copies from being usable for you.
Re: AW: Unable to delete directory in repository, server version 1.7.1
Stefan Sperling s...@elego.de writes: On Thu, Nov 10, 2011 at 05:25:27PM +, Philip Martin wrote: I wonder if there is an upper/lower case problem somewehere in your authz file? Or perhaps in the Subversion authz code? If so, this is likely due to the change in case-awareness we made in 1.7: file:///home/stsp/svn/svn-site/publish/docs/release-notes/1.7.html#case-sensitive-authz http://subversion.apache.org/docs/release-notes/1.7.html#case-sensitive-authz -- Philip
Checkout time after svnserve restart
Hi, I´m wondering about the checkout time of our svnserver. The first checkout after restarting svnserve (or httpd) is very slow. An example of one of our big projects: First checkout: 00:08:01 / 481 secs second: 00:02:00 / 120 secs third: 00:02:01 / 121 secs I´ve this problem with the svn- and the http protocol. Actually I´m testing which protocol is the fastest. Any ideas according this behavior? Creates subversion any cache files? Thanks, Stefan (-) Stefan Lock (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Pallaswiesenstraße 174 - 64293 Darmstadt, (-) Tel: +49 (0) 6151 969 96 17, Fax: +49 (0) 6151 969 96 29 (-) mailto:l...@signal7.de, www.signal7.de (-) Amtsgericht Darmstadt, HRB 6833 (-) Geschäftsführer: Robert Krüger, Frank Peters, Jochen Strunk
Re: Checkout time after svnserve restart
There's in-memory caching, and more so in 1.7, but no on-disk cache files. See the 1.7 release notes. On Thursday, November 10, 2011 8:49 PM, Stefan Lock l...@signal7.de wrote: Hi, I´m wondering about the checkout time of our svnserver. The first checkout after restarting svnserve (or httpd) is very slow. An example of one of our big projects: First checkout: 00:08:01 / 481 secs second: 00:02:00 / 120 secs third: 00:02:01 / 121 secs I´ve this problem with the svn- and the http protocol. Actually I´m testing which protocol is the fastest. Any ideas according this behavior? Creates subversion any cache files? Thanks, Stefan (-) Stefan Lock (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Pallaswiesenstraße 174 - 64293 Darmstadt, (-) Tel: +49 (0) 6151 969 96 17, Fax: +49 (0) 6151 969 96 29 (-) mailto:l...@signal7.de, www.signal7.de (-) Amtsgericht Darmstadt, HRB 6833 (-) Geschäftsführer: Robert Krüger, Frank Peters, Jochen Strunk
Re: AW: Unable to delete directory in repository, server version 1.7.1
Well, in my case, it is all lower-case all the time. Is there any other way to double check this? I checked with svn ls ... every component of path to be lower case, and it was. authz file is also in lower case completely. Still, delete as described before does not work. It is 32 bit system, maybe this has something to do with it. Jens, are you also using 32bit? b. On 10 November 2011 18:58, Philip Martin philip.mar...@wandisco.com wrote: Stefan Sperling s...@elego.de writes: On Thu, Nov 10, 2011 at 05:25:27PM +, Philip Martin wrote: I wonder if there is an upper/lower case problem somewehere in your authz file? Or perhaps in the Subversion authz code? If so, this is likely due to the change in case-awareness we made in 1.7: file:///home/stsp/svn/svn-site/publish/docs/release-notes/1.7.html#case-sensitive-authz http://subversion.apache.org/docs/release-notes/1.7.html#case-sensitive-authz -- Philip
1st checkout of my life = network connection closed unexpectedly
hello, I recently bought a synology NAS (DS110J). I would like to use subversion, so I installed SVN on the NAS, following this tutorial: [URL=http://forum.synology.com/wiki/index.php/Step-by-step_guide_to_installing_Subversion#Test_the_operation_of_Subversion_on_your_Diskstation]http://forum.synology.com/wiki/index.php/Step-by-step_guide_to_installing_Subversion#Test_the_operation_of_Subversion_on_your_Diskstation[/URL]. I opened the port 3690 in TCP and UDP in my livebox, and in the NAS (incoming outgoing connections), but the result is always the same when trying to achieve the checkout step of the tutorial : SVN : network connection closed unexpectedly the line I enter is that one : svn co svn://my address at dyndns:3690/svn_eclipse/home/olivier/Documents/svn_SMS later, I deactivated the NAS firewall, and also those of my linux desktop computer. same result. can you help me? olivier PS : I tried to use a SVN iPhone client , but with the same error. is my checkout command true(the directory of my SMS project in the NAS is : /volume1/svn_eclipse/SMS)
Re: 1st checkout of my life = network connection closed unexpectedly
svn://my address at dyndns:3690/svn_eclipse What is the IP of the NAS on your LAN? it has to work at svn:// 192.168.1.105/ first, before you can get to it from the net via your DynDNS url. Once you verified that you can connect from a PC on your LAN... check your internet device eg cable/DSL router (login as admin @ 192.168.1.1)? You may need to create a 'Service' for 'SVN'=3960-3960, often under 'Gaming'. (example IPs)
Re: 1st checkout of my life = network connection closed unexpectedly
hi the local IP is 192.168.1.66, and the internet one is xxx.dyndns.org (where xxx is my name). I tried with the local IP and I obtain the same result. so we can try to make it work first : I agree with you. and I thank you for your quick answer. olivier ps: I already have open the port 3960 in my box (TCP+UDP) is it the port 3960 or 3690?
Re: 1st checkout of my life = network connection closed unexpectedly
On Nov 10, 2011, at 20:40, olivier SAINT-EVE wrote: the local IP is 192.168.1.66, and the internet one is xxx.dyndns.org (where xxx is my name). I tried with the local IP and I obtain the same result. so we can try to make it work first : I agree with you. and I thank you for your quick answer. olivier ps: I already have open the port 3960 in my box (TCP+UDP) is it the port 3960 or 3690? The port is 3690. Geoff made a typo in his reply. Can you verify that the svnserve process is actually running on the synology nas? Assuming you have shell access to the synology nas, can you ssh to it and run the svn co command there -- can it talk to itself? What if you telnet [synology-nas-ip] 3690 -- what response do you get?
Re: 1st checkout of my life = network connection closed unexpectedly
hello ryan good idea! indeed it can't talk to himself (with the command svn co svn://localhost/svn_eclipse/SMS test3, from the NAS and where test3 doesn't exist. I obtain the same error message. maybe the rights are incorrects?
Re: 1st checkout of my life = network connection closed unexpectedly
On Nov 10, 2011, at 22:13, olivier SAINT-EVE wrote: indeed it can't talk to himself (with the command svn co svn://localhost/svn_eclipse/SMS test3, from the NAS and where test3 doesn't exist. I obtain the same error message. maybe the rights are incorrects? I don't know; could be. What does the telnet test say? Does the svnserve error log say anything interesting?
Re: 1st checkout of my life = network connection closed unexpectedly
hello, here is the result of telnet : [olivier@centos ~]$ telnet 192.168.1.66 3690 Trying 192.168.1.66... Connected to 192.168.1.66. Escape character is '^]'. Connection closed by foreign host. I can't figure out if it's a good message or not. for svnserve I didn't found the log file.Must I activate it?how? thanks Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
Re: 1st checkout of my life = network connection closed unexpectedly
On Thu, Nov 10, 2011 at 11:56 PM, lolveley lolve...@laposte.net wrote: hello, here is the result of telnet : [olivier@centos ~]$ telnet 192.168.1.66 3690 Trying 192.168.1.66... Connected to 192.168.1.66. Escape character is '^]'. Connection closed by foreign host. I can't figure out if it's a good message or not. for svnserve I didn't found the log file.Must I activate it?how? thanks That is a typical message from telnet; I only used svn:// protocol once or twice so I'm not much help there... To make sure, did you create a repository (svn_eclipse?) and loaded something into it (SMS)? Can you ssh onto the NAS and run # svn ls svn://localhost/svn_eclipse/**SMS ? It should give you some output about the contents of SMS.
