Re: R: troubles running on Win 7 x64
I'm using and accessing the same server on another vm running window 7 32 bit on the same virtual host. Same firewall, same network, same everything ... Inviato da iPad Il giorno 28/feb/2011, alle ore 05:26, Branko Čibej ha scritto: > On 26.02.2011 20:42, Paolo Di Pietro wrote: >> Sorry for having posted the wrong mailing list. >> >> By the way, I tried both http:// and https:// with the same result. >> >> With svn:// the error is slightly different: it says 'can't connect to host' >> >> Any help? >> >> Paolo >> >> >> -Messaggio originale- >> Da: Branko Čibej [mailto:br...@xbc.nu] Per conto di Branko Cibej >> Inviato: sabato 26 febbraio 2011 20:29 >> A: d...@subversion.apache.org >> Oggetto: Re: troubles running on Win 7 x64 >> >> On 26.02.2011 12:36, Paolo Di Pietro wrote: >>> Hi all, >>> >>> I just downloaded latest x64 version and try to installi it on my win 7 >>> x64 running on a wmvare workstation. >>> >>> TortoiseSVN 1.6.12, Build 20536 - 64 Bit , 2010/11/24 20:59:01 >>> Subversion 1.6.15, apr 1.3.8 apr-utils 1.3.9 neon 0.29.5 OpenSSL >>> 0.9.8p 16 Nov 2010 zlib 1.2.3 >>> >>> No problem with the installation, but after restarting it is not able to >>> connect to the server. >>> The server is sunning on another machine on the network, and I can connect >>> with my other installations running on windows 7 x32 running on the same >>> vmware. >>> >>> There is no apparent error, but the repo browser option have been there, >>> with no answer, all over the night. >>> On the same time, I saw a lot of traffic from my NAS, traffic going back to >>> normal usage after I killed the repo browser process. >>> >>> I also installed the same x64 version on the host machine, a quadcore x64 >>> workstation running Win/ ultimate. >>> In this case I cannot connect to the server, but the response was >>> different, giving the following message. >>> >>> Command: Checkout from >>> http://silv.eidos.local/svn/arianna/arianna-2011/trunk, revision HEAD, >>> Fully recursive, Externals included >>> Error: Server sent unexpected return value (501 Not Implemented) in >>> response to >>> Error: OPTIONS request for >>> 'http://silv.eidos.local/svn/arianna/arianna-2011/trunk' >>> Finished! >>> >>> Anyone can help or have any suggestion? >> Yes, ask on the users@subversion.apache.org mailing list, which is the right >> one to answer support questions on. >> >> But before you do that, try replacing that http:// with svn://. > > You're either not running the Subversion server, or the firewall on your > server is blocking connections. > > -- Brane >
Help with files changed outside of svn
I'm fairly new to svn, and I have things set up and running well. I wanted to test out a scenario where a file controlled by svn gets changed outside of svn inside the working copy, and now I'm lost and can't find much help on what to do. Here's my example: I setup the hooks folder as a svn project. Checked it out onto my windows box and made a small change, then committed the changes. Now I went through my command shell and manually changed a file outside of svn. Then I went back to my windows box and editted the same file with a different change. Now the original file contains: ">>> .r3" at the bottom Also I have some more files inside my working directory too: pre-revprop-change.tmpl pre-revprop-change.tmpl.mine pre-revprop-change.tmpl.r2 pre-revprop-change.tmpl.r3 Can someone please explain to me: 1) Why does >>> get put into the bottom of my files? 2) What are the 3 copies of this file for? 3) And now how do I get these files merged back into one copy with the changes made inside svn included and the changes made outside svn excluded?
Re: Help with files changed outside of svn
On Mon, Feb 28, 2011 at 10:54, Christopher D Haakinson wrote: > I'm fairly new to svn, and I have things set up and running well. > > I wanted to test out a scenario where a file controlled by svn gets changed > outside of svn inside the working copy, and now I'm lost and can't find much > help on what to do. > > Here's my example: I setup the hooks folder as a svn project. Checked it out > onto my windows box and made a small change, then committed the changes. > Now I went through my command shell and manually changed a file outside of > svn. > Then I went back to my windows box and editted the same file with a > different change. Do you mean to say that you edited the same file in multiple working copes? There is no "outside" svn as svn isn't a program in which you edit files, and you can't edit directly in the repository. > Now the original file contains: ">>> .r3" at the bottom > > Also I have some more files inside my working directory too: > > pre-revprop-change.tmpl > pre-revprop-change.tmpl.mine > pre-revprop-change.tmpl.r2 > pre-revprop-change.tmpl.r3 > > > Can someone please explain to me: > > 1) Why does >>> get put into the bottom of my files? > 2) What are the 3 copies of this file for? You have generated a merge conflict - you've changed the same line(s) of the file in 2 different ways. > 3) And now how do I get these files merged back into one copy with the > changes made inside svn included and the changes made outside svn excluded? You must now resolve the conflicts. See http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.resolve As I said above, there is no "outside vs. inside svn" - you apparently have changes made from 2 different working copies. This is a normal situation but Subversion cannot handle this for you automatically - YOU must tell Subversion which content is correct.
Re: Help with files changed outside of svn
I mean that I have a working copy of my project under: /svn/hooks This folder gets automatically updated with svn update on every commit with a post-commit hook This folder also is "live", meaning that the files here are in use at all times, so nobody will be using this "working copy" as their development copy, it's just there to receive all the newest changes. The scenario I want to test and know how to handle is when a file in /svn/hooks gets changed outside of svn and these changes never get commited into svn. I understand what svn is and is not, but the files I will have inside svn will also be available and writable on a network, so I need to know how to handle files that get changed inside my live working folder outside of svn. Also is there a way to change what gets written to a file when this occurs? All my scripts get corrupted because of the >>> and I'd like to at least put a # in front so that it's a commented line and doesn't affect the execution... |> | From: | |> >-| |Andy Levy | >-| |> | To:| |> >-| |Christopher D Haakinson/Raleigh/IBM@IBMUS | >-| |> | Cc:| |> >-| |users@subversion.apache.org | >-| |> | Date: | |> >-| |02/28/2011 11:02 AM | >-| |> | Subject: | |> >-| |Re: Help with files changed outside of svn | >-| On Mon, Feb 28, 2011 at 10:54, Christopher D Haakinson wrote: > I'm fairly new to svn, and I have things set up and running well. > > I wanted to test out a scenario where a file controlled by svn gets changed > outside of svn inside the working copy, and now I'm lost and can't find much > help on what to do. > > Here's my example: I setup the hooks folder as a svn project. Checked it out > onto my windows box and made a small change, then committed the changes. > Now I went through my command shell and manually changed a file outside of > svn. > Then I went back to my windows box and editted the same file with a > different change. Do you mean to say that you edited the same file in multiple working copes? There is no "outside" svn as svn isn't a program in which you edit files, and you can't edit directly in the repository. > Now the original file contains: ">>> .r3" at the bottom > > Also I have some more files inside my working directory too: > > pre-revprop-change.tmpl > pre-revprop-change.tmpl.mine > pre-revprop-change.tmpl.r2 > pre-revprop-change.tmpl.r3 > > > Can someone please explain to me: > > 1) Why does >>> get put into the bottom of my files? > 2) What are the 3 copies of this file for? You have generated a merge conflict - you've changed the same line(s) of the file in 2 different ways. > 3) And now how do I get these files merged back into one copy with the > changes made inside svn included and the changes made outside svn excluded? You must now resolve the conflicts. See http://s
Re: Help with files changed outside of svn
On 2/28/2011 8:13 AM, Christopher D Haakinson wrote: I mean that I have a working copy of my project under: /svn/hooks This folder gets automatically updated with svn update on every commit with a post-commit hook This folder also is "live", meaning that the files here are in use at all times, so nobody will be using this "working copy" as their development copy, it's just there to receive all the newest changes. The scenario I want to test and know how to handle is when a file in /svn/hooks gets changed outside of svn and these changes never get commited into svn. I understand what svn is and is not, but the files I will have inside svn will also be available and writable on a network, so I need to know how to handle files that get changed inside my live working folder outside of svn. This is asking for trouble. You want your Subversion repository to be up and running at all times. Version control systems cannot prevent all merge conflicts, so your repository could very well go down whenever a conflict occurs. The repository control directories (such as the hooks directory) should be tightly controlled, not open to any and all modifications, and certainly not changing on the fly. As Andy Levy said, Subversion does not care how the files are modified. It is a lightweight system, meaning that it doesn't run unless you tell it to. And so it doesn't know that files in a working copy are modified until you tell it. Also is there a way to change what gets written to a file when this occurs? All my scripts get corrupted because of the >>> and I'd like to at least put a # in front so that it's a commented line and doesn't affect the execution... This particular conflict might not have affected execution, but you can't guarantee this will always occur. What if you have a conflict of the form: "exit 0" vs. "exit 1"? How is Subversion supposed to know which is correct? This is why conflict resolution is manual. Trust me - you really, really, want to have conflicts be obvious and cause problems; you don't want them hidden. If you really want to have your repository's hooks directory updated through Subversion (which I do not recommend), make the directory writable only by the process that is running Subversion so that only the post-commit hook script can change it. Don't *ever* allow users to modify files in that directory. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: Help with files changed outside of svn
On Feb 28, 2011, at 10:13, Christopher D Haakinson wrote: > I mean that I have a working copy of my project under: > /svn/hooks > > This folder gets automatically updated with svn update on every commit with a > post-commit hook > This folder also is "live", meaning that the files here are in use at all > times, so nobody will be using this "working copy" as their development copy, > it's just there to receive all the newest changes. > > The scenario I want to test and know how to handle is when a file in > /svn/hooks gets changed outside of svn and these changes never get commited > into svn. > > I understand what svn is and is not, but the files I will have inside svn > will also be available and writable on a network, so I need to know how to > handle files that get changed inside my live working folder outside of svn. If that's how you have Subversion set up (a directory containing the hooks, and it is a working copy of a repository, and it is automatically updated in a post-commit hook), then the post-commit hook really must be the only thing modifying it. Nobody should have the ability to make changes there manually. All changes to this directory should occur by making the change in a working copy the user has checked out, then committing the change. > Also is there a way to change what gets written to a file when this occurs? > All my scripts get corrupted because of the >>> and I'd like to at least > put a # in front so that it's a commented line and doesn't affect the > execution... It is up to the user to resolve the merge conflict (i.e. remove those lines and retain the correct merged version of the code) before committing the changes, before the server can "svn update" its private working copy and try to run the scripts there.
Re: Help with files changed outside of svn
On Mon, Feb 28, 2011 at 11:13, Christopher D Haakinson wrote: > > I mean that I have a working copy of my project under: > /svn/hooks > > This folder gets automatically updated with svn update on every commit with a > post-commit hook > This folder also is "live", meaning that the files here are in use at all > times, so nobody will be using this "working copy" as their development copy, > it's just there to receive all the newest changes. If you're getting conflicts in those files when performing an update, then someone *is* using that working copy. Otherwise, the changes would be merged without conflict into that working copy. > The scenario I want to test and know how to handle is when a file in > /svn/hooks gets changed outside of svn and these changes never get commited > into svn. > > I understand what svn is and is not, but the files I will have inside svn > will also be available and writable on a network, so I need to know how to > handle files that get changed inside my live working folder outside of svn. Again, "outside/inside svn" has no meaning (or ambiguous meaning) in this context - please try to find the correct terminology to use here to remove this ambiguity. It sounds like your workflow is supposed to be: 1) Hook developer checks out hook scripts from repository to a local WC 2) Make edits 3) Commit changes to hook script 4) Hook scripts are auto-updated in /svn/hooks via a hook. Result: Nothing should be in /svn/hooks that isn't in the repository. What appears to be happening is that someone is editing in /svn/hooks while at the same time someone else (or maybe the same person) is editing in their own WC. This can generate a conflict when those changes are committed from one WC and updated into the other. Solution: lock people out of making changes to /svn/hooks, except via that hook script that pulls the updates down. You should not get any conflicts this way. Alternate solution: Require people to only make changes in /svn/hooks, and disallow commits from any other location (which would not be easy, as the hook script does not know where on the client content is being committed from - you'd have to do some per-user permissions & only allowed a specific person/group to commit, and trust them to do the right thing). > Also is there a way to change what gets written to a file when this occurs? > All my scripts get corrupted because of the >>> and I'd like to at least > put a # in front so that it's a commented line and doesn't affect the > execution... No, part of the point of doing this is to make it *very* obvious that something needs to be fixed. Even if those lines were commented out, the content between them would likely break your script, or at least cause unpredictable/undesired behavior. > Andy Levy ---02/28/2011 11:02:11 AM---On Mon, Feb 28, 2011 at 10:54, > Christopher D Haakinson > > > From: > Andy Levy > To: > Christopher D Haakinson/Raleigh/IBM@IBMUS > Cc: > users@subversion.apache.org > Date: > 02/28/2011 11:02 AM > Subject: > Re: Help with files changed outside of svn > > > > On Mon, Feb 28, 2011 at 10:54, Christopher D Haakinson > wrote: > > I'm fairly new to svn, and I have things set up and running well. > > > > I wanted to test out a scenario where a file controlled by svn gets changed > > outside of svn inside the working copy, and now I'm lost and can't find much > > help on what to do. > > > > Here's my example: I setup the hooks folder as a svn project. Checked it out > > onto my windows box and made a small change, then committed the changes. > > Now I went through my command shell and manually changed a file outside of > > svn. > > Then I went back to my windows box and editted the same file with a > > different change. > > Do you mean to say that you edited the same file in multiple working > copes? There is no "outside" svn as svn isn't a program in which you > edit files, and you can't edit directly in the repository. > > > Now the original file contains: ">>> .r3" at the bottom > > > > Also I have some more files inside my working directory too: > > > > pre-revprop-change.tmpl > > pre-revprop-change.tmpl.mine > > pre-revprop-change.tmpl.r2 > > pre-revprop-change.tmpl.r3 > > > > > > Can someone please explain to me: > > > > 1) Why does >>> get put into the bottom of my files? > > 2) What are the 3 copies of this file for? > > You have generated a merge conflict - you've changed the same line(s) > of the file in 2 different ways. > > > 3) And now how do I get these files merged back into one copy with the > > changes made inside svn included and the changes made outside svn excluded? > > You must now resolve the conflicts. See > http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.resolve > > As I said above, there is no "outside vs. inside svn" - you apparently > have changes made from 2 different working copies. This is a normal > situation but Subversion cannot handle t
WG: Subversion Apache2.2 LDAPS authentication failed
-Ursprüngliche Nachricht- Von: 金健康 [mailto:jinjiankang1...@gmail.com] Gesendet: Montag, 28. Februar 2011 09:34 An: Heimo Stieg Betreff: Re: Subversion Apache2.2 LDAPS authentication failed telnet master.ldap.ebupt.com 636 is OK. 2011/2/25 Heimo Stieg : > Hello, > > Check if the connection is possible from your machine to the ldap server with > telnet. > > telnet master.ldap.ebupt.com 636 > > If the connection works -> problem is inside the apache configuration > If not -> check your firewalls. > > > > Von: 金健康 [jinjiankang1...@gmail.com] > Gesendet: Freitag, 25. Februar 2011 07:53 > Bis: users@subversion.apache.org > Betreff: Subversion Apache2.2 LDAPS authentication failed > > Hi, > > OS: Redhat Linux > Subversion: 1.5.0 > Apache: 2.2.17 > OpenLDAP: 2.3.27 > > httpd.conf: > ... > LDAPSharedCacheSize 20 > LDAPCacheEntries 1024 > LDAPCacheTTL 600 > LDAPOpCacheEntries 1024 > LDAPOpCacheTTL 600 > > > DAV svn > SVNParentPath /home/svnroot/repository AuthzSVNAccessFile > /home/svnroot/repository/svn_access_file > AuthType Basic > AuthBasicProvider ldap > AuthzLDAPAuthoritative off > AuthLDAPURL > "ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectClass=*)" > SS > L > AuthName "Subversion.resository" > Require valid-user > > ... > > Apache error_log: > > [Thu Feb 24 16:48:00 2011] [debug] mod_authnz_ldap.c(403): [client > 10.1.85.181] [25242] auth_ldap a > uthenticate: using URL > ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(ob > jectCl > ass=*) > [Thu Feb 24 16:48:00 2011] [info] [client 10.1.85.181] [25242] > auth_ldap authenticate: user jinjian kang authentication failed; URI > /svn [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server] > > ping master.ldap.ebupt.com is OK. > > My FTP LDAPS authentication is OK as below: > server:master.ldap.ebupt.com > port:636 Enable > SSL:checked > Base DN:ou=staff,dc=ebupt,dc=com > anonymous bind:checked > Search Filter:(objectClass=*) > User DN attribute:uid > Search scope:subtree > > Thanks. > Jin Jiankang > >
can "svnadmin dump" tolerate read-only repository access?
Recently, Red Hat Enterprise Linux 5 updated its Subversion package from 1.5.x to 1.6.11. This exposed a *forwards* compatibility problem: the Subversion 1.6 hotcopy command fails on Subversion 1.5 repositories: $ svnadmin hotcopy test-repo test-repo.HOTCOPY; echo $? svnadmin: Can't open file 'test-repo/db/fsfs.conf': No such file or directory 1 We tested if creating an empty db/fsfs.conf file will resolve this issue, and it does. And this issue seems to have been fixed in 1.6.13. But given that this very simple compatibility issue wasn't caught until two bugfix releases later, we're concerned that there may be other forwards compatibility issues that will bite us in the future. Therefore, we've decided to dump and restore all of our Subversion repositories, to bring them up to Subversion 1.6 db backends. Question: if I "svnadmin dump" a repository, is it safe to allow read-only access to the repository while the dump is in progress? Or is it the case that permitting even read access could interfere with the "svnadmin dump" operation? I ask because it will take a non-trivial amount of time to perform svnadmin dump/load operations on all of Subversion repositories. If we can at least permit read-only access while this upgrade is in progress, that will have much less of an impact on our users then it we have to block all access during the upgrade...
Re: can "svnadmin dump" tolerate read-only repository access?
On 2/28/2011 10:37 AM, James Ralston wrote: Question: if I "svnadmin dump" a repository, is it safe to allow read-only access to the repository while the dump is in progress? Or is it the case that permitting even read access could interfere with the "svnadmin dump" operation? I ask because it will take a non-trivial amount of time to perform svnadmin dump/load operations on all of Subversion repositories. If we can at least permit read-only access while this upgrade is in progress, that will have much less of an impact on our users then it we have to block all access during the upgrade... A "hot copy" by definition is one that will safely allow read-only access while the backup is in progress. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
RE: Subversion Apache2.2 LDAPS authentication failed
-Original Message- From: 金健康 [mailto:jinjiankang1...@gmail.com] Sent: Friday, February 25, 2011 12:53 AM To: users@subversion.apache.org Subject: Subversion Apache2.2 LDAPS authentication failed Hi, OS: Redhat Linux Subversion: 1.5.0 Apache: 2.2.17 OpenLDAP: 2.3.27 httpd.conf: ... LDAPSharedCacheSize 20 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 DAV svn SVNParentPath /home/svnroot/repository AuthzSVNAccessFile /home/svnroot/repository/svn_access_file AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative off AuthLDAPURL "ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectClass=*)" SS L AuthName "Subversion.resository" Require valid-user ... Apache error_log: [Thu Feb 24 16:48:00 2011] [debug] mod_authnz_ldap.c(403): [client 10.1.85.181] [25242] auth_ldap a uthenticate: using URL ldaps://master.ldap.ebupt.com:636/OU=staff,DC=ebupt,DC=com?uid?sub?(objectCl ass=*) [Thu Feb 24 16:48:00 2011] [info] [client 10.1.85.181] [25242] auth_ldap authenticate: user jinjian kang authentication failed; URI /svn [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server] ping master.ldap.ebupt.com is OK. My FTP LDAPS authentication is OK as below: server:master.ldap.ebupt.com port:636 Enable SSL:checked Base DN:ou=staff,dc=ebupt,dc=com anonymous bind:checked Search Filter:(objectClass=*) User DN attribute:uid Search scope:subtree Thanks. Jin Jiankang I don't see any "LDAPTrustedGlobalCert" entries that tell Apache how to verify the server certificate... Have you defined any in the config file? http://httpd.apache.org/docs/2.2/mod/mod_ldap.html Otherwise, you could also try adding this directive to see if it has any affect: LDAPVerifyServerCert Off Other than checking to verify the host name matches what's in the certificate, and making sure the CAs are setup, you could also check out this message: http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=395193 FWIW! -Message Disclaimer- This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email to conn...@principal.com and delete or destroy all copies of the original message and attachments thereto. Email sent to or from the Principal Financial Group or any of its member companies may be retained as required by law or regulation. Nothing in this message is intended to constitute an Electronic signature for purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic Signatures in Global and National Commerce Act ("E-Sign") unless a specific statement to the contrary is included in this message. While this communication may be used to promote or market a transaction or an idea that is discussed in the publication, it is intended to provide general information about the subject matter covered and is provided with the understanding that The Principal is not rendering legal, accounting, or tax advice. It is not a marketed opinion and may not be used to avoid penalties under the Internal Revenue Code. You should consult with appropriate counsel or other advisors on all matters pertaining to legal, tax, or accounting obligations and requirements.
Re: can "svnadmin dump" tolerate read-only repository access?
On 2011-02-28 at 10:49-08 David Chapman wrote: > A "hot copy" by definition is one that will safely allow read-only > access while the backup is in progress. But I asked about "svnadmin dump", not "svnadmin hotcopy". Are you asserting that read-only repository access (in our case, via WebDAV via mod_dav_svn) will *not* perturb a running "svnadmin dump" operation?
Subversion keeps recreating my repositories
Hi, I think I'm on the verge of going crazy. Whenever I try to delete a Subversion repository (including the subfolders or the containing folder itself), Linux keeps recreating the folder and the repository. How can I delete the repositories for good and basically start over? Thanks so much, -- Jordan Spivack Lead Web Architect - Athens Social Media cell: 706.207.4974 http://www.athenssocialmedia.com
Re: can "svnadmin dump" tolerate read-only repository access?
On 2/28/2011 11:00 AM, James Ralston wrote: On 2011-02-28 at 10:49-08 David Chapman wrote: A "hot copy" by definition is one that will safely allow read-only access while the backup is in progress. But I asked about "svnadmin dump", not "svnadmin hotcopy". Are you asserting that read-only repository access (in our case, via WebDAV via mod_dav_svn) will *not* perturb a running "svnadmin dump" operation? Sorry, missed that detail. Per the book: http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnadmin "Note that *svnadmin dump* is reading revision trees from the repository just like any other "reader" process would (e.g., *svn checkout*), so it's safe to run this command at any time." You may have to scroll down a bit to find this text. I always do a hot copy first; since no one else can access the hot copy I don't have to worry about "svnadmin dump" conflicts. Of course, my repositories are still writable while I'm running my backups. The main issue as I understand it is determining exactly which revision is the "last" and not copying any data beyond that one. For you, hot copy plus dump would take longer, which would be an issue for your developers. But if you prevent commits (including revprop changes) during the transition, you should be fine. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Better way to create project?
I just put my bin folder in subversion. I am a new user, so maybe I do not do things in the right way. So I would like to know if there is a better way to do things. I moved my bin folder to bin.old. I created a bin folder in my repository. I did a checkout of the bin folder. I moved the files from bin.old to bin. I removed bin.old. I did a svn add. I did a svn commit. This are quit a few steps. Is there a better way to do this? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
MySQL changes into svn
I am just asked if it is possible to put the changes of MySQL databases in svn. I could of-course export the table definitions and store those in svn. I was just wondering if there is a better way? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Re: Better way to create project?
On Feb 28, 2011, at 13:25, Cecil Westerhof wrote: > I just put my bin folder in subversion. I am a new user, so maybe I do > not do things in the right way. So I would like to know if there is a > better way to do things. > > I moved my bin folder to bin.old. > I created a bin folder in my repository. > I did a checkout of the bin folder. > I moved the files from bin.old to bin. > I removed bin.old. > I did a svn add. > I did a svn commit. > > This are quit a few steps. Is there a better way to do this? You can do an in-place import: http://subversion.apache.org/faq.html#in-place-import
Re: MySQL changes into svn
On Feb 28, 2011, at 13:27, Cecil Westerhof wrote: > I am just asked if it is possible to put the changes of MySQL > databases in svn. I could of-course export the table definitions and > store those in svn. I was just wondering if there is a better way? If you're looking for something automated, that's probably a pretty complicated topic. Whenever I change my MySQL database, I do then manually run a script that saves the schema to a file, then I commit that file to my Subversion repository. I try to limit myself to one database change at a time, so that I can write reasonable commit messages.
Re: can "svnadmin dump" tolerate read-only repository access?
On Feb 28, 2011, at 12:37, James Ralston wrote: > Recently, Red Hat Enterprise Linux 5 updated its Subversion package > from 1.5.x to 1.6.11. > > This exposed a *forwards* compatibility problem: the Subversion 1.6 > hotcopy command fails on Subversion 1.5 repositories: > > $ svnadmin hotcopy test-repo test-repo.HOTCOPY; echo $? > svnadmin: Can't open file 'test-repo/db/fsfs.conf': No such file or directory > 1 > > We tested if creating an empty db/fsfs.conf file will resolve this > issue, and it does. And this issue seems to have been fixed in 1.6.13. > > But given that this very simple compatibility issue wasn't caught > until two bugfix releases later, we're concerned that there may be > other forwards compatibility issues that will bite us in the future. The Subversion team's promise is that any Subversion 1.x client will be compatible with any Subversion 1.x server, and I would assume with any Subversion 1.x repository. If bugs are introduced that break that promise, I'm confident that those bugs would be fixed.
Re: Subversion keeps recreating my repositories
On Feb 28, 2011, at 12:49, Jordan Spivack wrote: > I think I'm on the verge of going crazy. Whenever I try to delete a > Subversion repository (including the subfolders or the containing folder > itself), Linux keeps recreating the folder and the repository. How can I > delete the repositories for good and basically start over? Subversion has no capability to magically respawn killed repositories, and in fact no command to delete a repository; to do so, you just use your operating system's directory deletion command to delete the repository directory.
Re: MySQL changes into svn
On Monday 28 February 2011 20:31:22 Ryan Schmidt wrote: > On Feb 28, 2011, at 13:27, Cecil Westerhof wrote: > > I am just asked if it is possible to put the changes of MySQL > > databases in svn. I could of-course export the table definitions and > > store those in svn. I was just wondering if there is a better way? > > If you're looking for something automated, that's probably a pretty > complicated topic. > > Whenever I change my MySQL database, I do then manually run a script that > saves the schema to a file, then I commit that file to my Subversion > repository. I try to limit myself to one database change at a time, so > that I can write reasonable commit messages. I am wondering the same thing, how to automate database backup. There is a tool in Linux for automatic database backup, but it seems quite buggy. I have been able to backup my databases using a bash script and a pre commit hook could be the next thing to do, but still no automation there. regards -- Bogdan Cristea http://cristeab.googlepages.com
Re: Better way to create project?
On 2/28/2011 1:29 PM, Ryan Schmidt wrote: On Feb 28, 2011, at 13:25, Cecil Westerhof wrote: I just put my bin folder in subversion. I am a new user, so maybe I do not do things in the right way. So I would like to know if there is a better way to do things. I moved my bin folder to bin.old. I created a bin folder in my repository. I did a checkout of the bin folder. I moved the files from bin.old to bin. I removed bin.old. I did a svn add. I did a svn commit. This are quit a few steps. Is there a better way to do this? You can do an in-place import: http://subversion.apache.org/faq.html#in-place-import Or even easier, just import the top level directory, delete the original, and check the whole thing back out (or rename the original until you are sure it worked). The in-place approach is for things where you don't want to delete/move the originals at all. -- Les Mikesell lesmikes...@gmail.com
Re: Subversion keeps recreating my repositories
It was some weirdness with subversion and cPanel. Thanks for your help, Jordan On Mon, Feb 28, 2011 at 2:35 PM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > > On Feb 28, 2011, at 12:49, Jordan Spivack wrote: > > > I think I'm on the verge of going crazy. Whenever I try to delete a > Subversion repository (including the subfolders or the containing folder > itself), Linux keeps recreating the folder and the repository. How can I > delete the repositories for good and basically start over? > > Subversion has no capability to magically respawn killed repositories, and > in fact no command to delete a repository; to do so, you just use your > operating system's directory deletion command to delete the repository > directory. > > > -- Jordan Spivack Lead Web Architect - Athens Social Media cell: 706.207.4974 http://www.athenssocialmedia.com
Re: MySQL changes into svn
On Mon, Feb 28, 2011 at 14:35, Bogdan Cristea wrote: > On Monday 28 February 2011 20:31:22 Ryan Schmidt wrote: >> On Feb 28, 2011, at 13:27, Cecil Westerhof wrote: >> > I am just asked if it is possible to put the changes of MySQL >> > databases in svn. I could of-course export the table definitions and >> > store those in svn. I was just wondering if there is a better way? >> >> If you're looking for something automated, that's probably a pretty >> complicated topic. >> >> Whenever I change my MySQL database, I do then manually run a script that >> saves the schema to a file, then I commit that file to my Subversion >> repository. I try to limit myself to one database change at a time, so >> that I can write reasonable commit messages. > > I am wondering the same thing, how to automate database backup. There is a > tool in Linux for automatic database backup, but it seems quite buggy. I have > been able to backup my databases using a bash script and a pre commit hook > could be the next thing to do, but still no automation there. Subversion is not a backup system.
Re: can "svnadmin dump" tolerate read-only repository access?
Ryan Schmidt wrote on Mon, Feb 28, 2011 at 13:33:51 -0600: > > On Feb 28, 2011, at 12:37, James Ralston wrote: > > > Recently, Red Hat Enterprise Linux 5 updated its Subversion package > > from 1.5.x to 1.6.11. > > > > This exposed a *forwards* compatibility problem: the Subversion 1.6 > > hotcopy command fails on Subversion 1.5 repositories: > > > > $ svnadmin hotcopy test-repo test-repo.HOTCOPY; echo $? > > svnadmin: Can't open file 'test-repo/db/fsfs.conf': No such file or > > directory > > 1 > > > > We tested if creating an empty db/fsfs.conf file will resolve this > > issue, and it does. And this issue seems to have been fixed in 1.6.13. > > > > But given that this very simple compatibility issue wasn't caught > > until two bugfix releases later, we're concerned that there may be > > other forwards compatibility issues that will bite us in the future. > > The Subversion team's promise is that any Subversion 1.x client will > be compatible with any Subversion 1.x server, and I would assume with > any Subversion 1.x repository. If bugs are introduced that break that > promise, I'm confident that those bugs would be fixed. > Any 1.x and 1.y are compatible *over the wire*. If you want to access a repository locally (svnadmin) you might not be able to access a repository that had been upgraded/created by an svnadmin of a newer minor version. > >
Re: can "svnadmin dump" tolerate read-only repository access?
'svnadmin dump' can work on live repositories, even if they're being written to as it goes. In general, ANY Subversion command can be run on live repositories. It's rsync and friends that aren't promised to work on live repositories.
Re: can "svnadmin dump" tolerate read-only repository access?
On Feb 28, 2011, at 14:29, Daniel Shahaf wrote: > Ryan Schmidt wrote on Mon, Feb 28, 2011 at 13:33:51 -0600: >> >> The Subversion team's promise is that any Subversion 1.x client will >> be compatible with any Subversion 1.x server, and I would assume with >> any Subversion 1.x repository. If bugs are introduced that break that >> promise, I'm confident that those bugs would be fixed. > > Any 1.x and 1.y are compatible *over the wire*. > > If you want to access a repository locally (svnadmin) you might not be > able to access a repository that had been upgraded/created by an > svnadmin of a newer minor version. Er, yes. I worded that wrong. Isn't it correct, though, that any 1.y server or client should be able to access locally any repository created with 1.x if 1.x <= 1.y?
Re: svn 1.7 slow with many dirs
This is on-topic for dev@. We're aware of speed issues, but we'll always appreciate more input. Daniel (good to see more people building svn.exe on Windows...) Gunnar Dalsnes wrote on Sun, Feb 27, 2011 at 21:34:41 +0100: > Hi, > > My WC have 1881dirs and 12693 files, and I am experiencing extreme > slowness in some situations: > 'svn propget svn:dummyprop -R' in WC root take 70seconds! In svn 1.6 > it take 2 seconds. > In WC's with around 200dirs, it's only take a few seconds in svn 1.7 too. > > Discovered the problem while testing TortoiseSVN, where > svn_wc_revision_status2 took 70seconds on WC root. > > Seems svn_wc__node_walk_children/walker_helper is slow. Does not > seem to scale linear. > > Strangely, 'svn stat -v > nul' in WC root only take 2 seconds, and > it is also recursive and traverse all nodes in WC, so there seem to > be several implementations of walking nodes in wc.db, where one is > fast. > > Gunnar Dalsnes
Re: MySQL changes into svn
>>> Whenever I change my MySQL database, I do then manually run a script that >>> saves the schema to a file, then I commit that file to my Subversion >>> repository. I try to limit myself to one database change at a time, so >>> that I can write reasonable commit messages. >> >> I am wondering the same thing, how to automate database backup. There is a >> tool in Linux for automatic database backup, but it seems quite buggy. I have >> been able to backup my databases using a bash script and a pre commit hook >> could be the next thing to do, but still no automation there. > > Subversion is not a backup system. > Perfectly OK the place a __schema__ in SVN. But it is not reasonable to use SVN to store the content of a database. Most every SQL database I've seen has a "dump" command that will dump content to an ASCII file. Then you save the files the same way you'd save any other files. You __do__ have to do the dumps inside a transaction so to maintain consistency. -- = Chris Albertson Redondo Beach, California
Re: can "svnadmin dump" tolerate read-only repository access?
Ryan Schmidt wrote on Mon, Feb 28, 2011 at 14:33:56 -0600: > Isn't it correct, though, that any 1.y server or client should be able > to access locally any repository created with 1.x if 1.x <= 1.y? Yes, svn 1.y can read repositories created by 1.x for x<=y, as well as repositories created by 1.z with an appropriate --pre-1.%d-compatible flag.
Re: Better way to create project?
On Feb 28, 2011, at 13:55, Les Mikesell wrote: > On 2/28/2011 1:29 PM, Ryan Schmidt wrote: >> >> On Feb 28, 2011, at 13:25, Cecil Westerhof wrote: >> >>> I just put my bin folder in subversion. I am a new user, so maybe I do >>> not do things in the right way. So I would like to know if there is a >>> better way to do things. >>> >>> I moved my bin folder to bin.old. >>> I created a bin folder in my repository. >>> I did a checkout of the bin folder. >>> I moved the files from bin.old to bin. >>> I removed bin.old. >>> I did a svn add. >>> I did a svn commit. >>> >>> This are quit a few steps. Is there a better way to do this? >> >> You can do an in-place import: >> >> http://subversion.apache.org/faq.html#in-place-import > > Or even easier, just import the top level directory, delete the original, and > check the whole thing back out (or rename the original until you are sure it > worked). The in-place approach is for things where you don't want to > delete/move the originals at all. Multiple ways the cat can be skinned, but in-place import is for anytime you want to import the contents of an unversioned directory and turn that directory into a working copy, which is what he wanted to do.
failed commit that did not fail
I got this error on a commit because the rep-cache.db file in the repository had the wrong mode: Transmitting file data ... ... ... ... ... ... svn: Commit failed (details follow): svn: attempt to write a readonly database svn: attempt to write a readonly database Clearly, it says the commit failed. So I fixed the permissions in the repository and tried the commit again: svn: Commit failed (details follow): svn: File already exists: filesystem '/svnroot/myrepo/db', transaction '5323-43v', path '/blah/blah/blah' So I seem to be stuck. I run svn update in my working copy and nothing seems to happen. svn status still shows all my added files staged and ready to be committed. the commit did not fail correctly. So, what do I do to get out of this besides dumping up to right before the current rev and reloading the repository? Also, is this a known issue or shall I file a bug? Subversion command-line client, version 1.6.15. server is running 1.6.13, both are Linux. -- Mark Keisler
failed commit that did not fail
I got this error on a commit because the rep-cache.db file in the repository had the wrong mode: Transmitting file data ... ... ... ... ... ... svn: Commit failed (details follow): svn: attempt to write a readonly database svn: attempt to write a readonly database Clearly, it says the commit failed. So I fixed the permissions in the repository and tried the commit again: svn: Commit failed (details follow): svn: File already exists: filesystem '/svnroot/myrepo/db', transaction '5323-43v', path '/blah/blah/blah' So I seem to be stuck. I run svn update in my working copy and nothing seems to happen. svn status still shows all my added files staged and ready to be committed. the commit did not fail correctly. So, what do I do to get out of this besides dumping up to right before the current rev and reloading the repository? Also, is this a known issue or shall I file a bug? Subversion command-line client, version 1.6.15. server is running 1.6.13, both are Linux. -- Mark
Re: failed commit that did not fail
There's been a bunch of work on trunk recently on recognizing this difference --- a successful commit with a failure somewhere during the so-called "post-commit FS processing". I believe most of it is nominated for 1.6.16 --- could you please try that (once it's released) before filing a bug? Also: see issue #3641. Thanks! Daniel Mark Keisler wrote on Mon, Feb 28, 2011 at 16:38:50 -0600: > I got this error on a commit because the rep-cache.db file in the > repository had the wrong mode: > > Transmitting file data > > ... > ... > ... > ... > ... > ... > svn: Commit failed (details follow): > svn: attempt to write a readonly database > svn: attempt to write a readonly database > > Clearly, it says the commit failed. So I fixed the permissions in the > repository and tried the commit again: > > svn: Commit failed (details follow): > svn: File already exists: filesystem '/svnroot/myrepo/db', transaction > '5323-43v', path '/blah/blah/blah' > > > So I seem to be stuck. I run svn update in my working copy and > nothing seems to happen. svn status still shows all my added files > staged and ready to be committed. the commit did not fail correctly. > So, what do I do to get out of this besides dumping up to right before > the current rev and reloading the repository? Also, is this a known > issue or shall I file a bug? > > Subversion command-line client, version 1.6.15. > server is running 1.6.13, both are Linux. > > -- > Mark