Re: Suggestion to change the name Subversion
On Aug 11, 2013, at 20:24, Bill George wrote: I know it is standard practice in programming to use common words in the English language for specific software terminology or naming. However, this has often caused confusions. If you go through the story of Goldman Sachs programmer Serge Aleynikov who was accused convicted of stealing open source software code, the link below, you will see that one of the factors that affected the case was that to the FBI investigator who was a software layman, the word subversion repository had a negative connotation to it. He assumed it was the verb form of the word 'Subvert'. In the story below, Agent McSwain of the FBI, who took the investigation of Aleynikov, had no idea about version control of code, let alone SVN. Later Aleynikov was found innocent and released from incarceration. Hence this is my strong suggestion : next release, please consider altering the name subversion to something else. At least Sub-version. This is to prevent confusion to non-technical people who could mistake the meaning of the name and associate it to negative activity like hacking or stealing. Just a thought and suggestion that could have far reaching implications. Please consider this. Thank you, BG Link to the story: http://www.vanityfair.com/business/2013/09/michael-lewis-goldman-sachs-programmer Quote from the story: The Web site Serge had used (which has the word “subversion” in its name) as well as the location of its server (Germany) McSwain clearly found highly suspicious. All I can say is it's very silly and sad that law enforcement still doesn't understand computers. And that the Subversion project has been using that name since 2000, and it's a trivial task for anyone to find out what it is and that it is not nefarious. I don't think the Subversion project should be asked to give up the good reputation it's built on its name, just because someone somewhere doesn't understand what it is and can't be bothered to take two seconds to find out. Should the GIMP change its name because (when not referring to the software) that can be a derogatory term? Should git change its name because (when not referring to the software) that term can be used as an insult? No. Each project was undoubtedly aware of the usual meaning of the word they chose as their name and decided to repurpose it.
Re: Suggestion to change the name Subversion
Guten Tag Bill George, am Montag, 12. August 2013 um 03:24 schrieben Sie: Hence this is my strong suggestion : next release, please consider altering the name subversion to something else. You don't really expect a project name to change this fast, don't you?! ;-) At least Sub-version. This doesn't sound any different than Subversion, what should be the benefit in discussions etc.? One could only read the difference and besides that, people who already (want?) to misinterpret Subversion would easily think of simple spelling errors and stay with their opinion. This is to prevent confusion to non-technical people who could mistake the meaning of the name and associate it to negative activity like hacking or stealing. But there will always be an idiot out there which takes things wrong, maybe even on purpose. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
AW: Balancing and proxing
Hi, Roman, Von: Roman Naumenko [mailto:ro...@naumenko.ca] Ryan Schmidt said the following, on 09-08-13 9:15 PM: [] But more important, I'd like to have a few nodes handling writes. Ah yes. Well then that's different. You must have one heck of a large svn installation for that to be a bottleneck. One day it might grow there, but even with the moderate load it is still a huge convenience when pair or more frontends available to handle the load, can take one down for maintenance any time. VMs can be used instead of physical box too and sized more adequately. Of course, it would be ideal if subversion nodes could just share a storage, so any sort of requests from a load balancer can processed by any node without need to replicate changes over network. If you use a shared storage which provides working locking semantics, exactly this is possible. SVN already supports several processes accessing the same repository (like the mod_dav_SVN processes in an apache multiprocess configuration, svnserve (directly and via svn+ssh), and local file:// access), even different versions if they all support the given repository version. So if your file system guarantees working semantics for locking, using a shared data storage should work. [...] I have not set it up myself, but I participated in discussions about it on this list some years ago: http://svn.haxx.se/users/archive-2006-10/0195.shtml http://svn.haxx.se/users/archive-2007-05/0214.shtml You may want to read those threads completely and carefully to get all the nuances. And of course information may have changed since then. Tom Mornini tmornini_at_engineyard.com confirmed that GFS works in that thread and the other too, http://svn.haxx.se/users/archive-2007-01/1307.shtml But again, there is no official confirmation or reference architecture. It seems like the number of repositories or the load on a server is never large enough to make administrators (or subversion developers to some extent) designing or implementing load-balancing cluster. Or maybe it is close to huge, but in most cases svnsycn + write-though solve the problem. On the other side, there are commercial solutions available, so demand must be there :) Subversion is a free software project, and everyone has its own itch to scratch. :-) The demand is there, and there are solutions (whether using shared storage, or the built-in transparent proxy mode of mod_dav_svn, or WanDiscos proprietary solution). For example, apache.org hosts hundreds of projects (including SVN itself) and more than 1.5 million revisions using the built-in transparent write-through proxy mode. While Subversion as a free software project may not seem to officially confirm some of those solutions, the SVN community also is just a group of volunteers who share some common stakes in the SVN development, and not a commercial IT support offering. On the other hand, installations of the scale you envision should always be backed by professional SVN support. If you don't have the knowledge in-house, I suggest you sign a support contract with one of the companies providing commercial SVN support, preferably one of those who hired some of the committers, as those companies will then provide support and official confirmation for whatever setup they conceptualize for your problem. Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Built 1.8.1 from source: libz.so.1: no version information available
Randy nya_ma...@yahoo.com writes: Thank you for the reply. I think you are correct about it being a zlib version problem. But the error with /lib64/libz.so.1 happens whether I build svn with the dependencies or without. The reason I am attempting to build it with the static libraries (which are fetched You are using shared libraries. --enable-static merely enables static libraries to be produced, it does not cause the build to use them. with the included get-deps.sh script) is to prevent it from trying to use /lib64/libz.so.1 which appears to have zlib version problem. However ldd shows my svn using /lib64/libz.so.1 no matter what I do. The only problem you have shown is using different zlibs at build time and after install. Either use the system zlib during the build or arrange for your zlib to be used after install. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
svn checkout - quick question
Hi All 1- Can one simply checkout a few folders in a directory as opposed to check out everything under a directory ? We have a folder what we don't want to check out but want to co all other directories. 2- Once we checkout these directories (except one), we need to svn merge from another branch into this checkout that we just did. But the other branch has other directories that we don't want. Can we still svn merge and then svn revert -R /path/to/directory/we/dont/want ? And then ci after the merge (bearing in mind that it has that 1 missing directory) Sincerely
AW: svn checkout - quick question
Hi, Z W, Von: Z W [mailto:mpc8...@gmail.com] 1- Can one simply checkout a few folders in a directory as opposed to check out everything under a directory? We have a folder what we don't want to check out but want to co all other directories. Yes, that is possible, see http://svnbook.red-bean.com/en/1.8/svn.advanced.sparsedirs.html for more information. 2- Once we checkout these directories (except one), we need to svn merge from another branch into this checkout that we just did. But the other branch has other directories that we don't want. Can we still svn merge and then svn revert -R /path/to/directory/we/dont/want ? And then ci after the merge (bearing in mind that it has that 1 missing directory) You should be able to only merge the pathes you want to merge. See the chapter about merging in the book: http://svnbook.red-bean.com/en/1.8/svn.branchmerge.html Sincerely Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: codesys.com | CODESYS store: store.codesys.com CODESYS forum: forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Suggestion to change the name Subversion
Am 12.08.2013 03:24, schrieb Bill George: This is to prevent confusion to non-technical people who could mistake the meaning of the name and associate it to negative activity like hacking or stealing. Just a thought and suggestion that could have far reaching implications. There is nothing negative when it comes to subverting injustice. There isn't anything inherently negative to hacking either. And stealing can as well be committed by shirt'n'tie people and without breaking any law. I'm not at all convinced by your arguments. Please consider this. Please consider standing up against injustice and stupidity instead. Uli (voicing his own opinion in spite of any auto-appended disclaimer here) ** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Hans Robert Dapprich, 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: svn 1.8 causing locks to be broken on update
On Mon, Aug 12, 2013 at 5:38 AM, Felipe Alvarez felipe.alva...@gmail.com wrote: On Mon, Aug 5, 2013 at 9:50 AM, Felipe Alvarez felipe.alva...@gmail.com wrote: Maybe I'm missing something but what exactly is broken in your output? It ends with svn up, but shouldn't be there at least one additional svn st to show something about the lock? Felipe@FELIPES ~/SVN $ svn up Updating '.': BTrunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW BTrunk\SystemAdmin\rsync_transfer.cron.FreshBNE BTrunk\Lettus\lbin\backup.cron svn up doesn't show info about your locked file because it didn't change or conflict with revisions from the repo. My apologies. I have tried it again, this time with final 'svn st' ---begin output--- Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin $ svn st #- # lock broken from previous update (last week) #- Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin $ svn lock backup.cron svn: warning: W160035: Path '/Trunk/Lettus/lbin/backup.cron' is already locked by user 'felipe' in filesystem '/u3/SVN_Repository/db' Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin $ svn lock --force backup.cron 'backup.cron' locked by user 'felipe'. Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin $ svn st K backup.cron Felipe@FELIPES ~/SVN/Trunk/Lettus/lbin $ cd .. Felipe@FELIPES ~/SVN/Trunk/Lettus $ svn up; svn st Updating '.': At revision 59397. K lbin\backup.cron Felipe@FELIPES ~/SVN/Trunk/Lettus $ cd .. Felipe@FELIPES ~/SVN/Trunk $ svn up; svn st Updating '.': At revision 59397. K Lettus\lbin\backup.cron ? SystemAdmin\rsync.sh M SystemAdmin\rsync_transfer.cron.FreshASPNEW M SystemAdmin\rsync_transfer.cron.FreshBNE Felipe@FELIPES ~/SVN/Trunk $ cd .. Felipe@FELIPES ~/SVN $ svn st MM Branches\Lettus\UAT\prod\autotest\code_check.sh K Trunk\Lettus\lbin\backup.cron ? Trunk\SystemAdmin\rsync.sh M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE ? wclbin Felipe@FELIPES ~/SVN $ svn up Updating '.': BTrunk\Lettus\lbin\backup.cron At revision 59397. Felipe@FELIPES ~/SVN $ svn st MM Branches\Lettus\UAT\prod\autotest\code_check.sh ? Trunk\SystemAdmin\rsync.sh M Trunk\SystemAdmin\rsync_transfer.cron.FreshASPNEW M Trunk\SystemAdmin\rsync_transfer.cron.FreshBNE ? wclbin Felipe@FELIPES ~/SVN $ ---end output--- -- Felipe Has anybody been able to reproduce or confirm this problem? I've tried, but I can't reproduce this problem with a clean repository (see transcript below). There must be something special with your repository or working copy. Maybe your working copy is constructed in a special way, for instance a sparse working copy, or with switched subtrees or something like that? Or perhaps your ~/SVN/Trunk is, through the use of symlinks, part of two different working copies? I think you'll have to narrow this down to something reproducible, or give additional details about your repository and working copy, before anyone will be able to help. I suggest you first examine your current working copy to see if there is anything special about it (with 'svn info' etc). And then try to reproduce it in a completely new working copy (make a new checkout of the same part of the repository, and trying the same steps). If you can reproduce it that way, that's already a good step forward. Next thing is to reproduce it from scratch with a completely new repository (like I tried in the transcript below). Here's what I tried (with svn built from trunk@1513012): [[[ C:\Temp\testsvnadmin create repos C:\Temp\testsvn co file:///c:/temp/test/repos wc Checked out revision 0. C:\Temp\testcd wc C:\Temp\test\wcsvn mkdir --parents -mcreating dirs file:///c:/temp/test/repos/Trunk/Lettus/lbin Committed revision 1. C:\Temp\test\wcsvn up Updating '.': ATrunk ATrunk\Lettus ATrunk\Lettus\lbin Updated to revision 1. C:\Temp\test\wccd Trunk\Lettus\lbin C:\Temp\test\wc\Trunk\Lettus\lbinecho line1 test.txt C:\Temp\test\wc\Trunk\Lettus\lbinsvn add test.txt A test.txt C:\Temp\test\wc\Trunk\Lettus\lbinsvn ci -madding test file Adding test.txt Transmitting file data . Committed revision 2. C:\Temp\test\wc\Trunk\Lettus\lbinsvn lock --username jcorvel test.txt 'test.txt' locked by user 'jcorvel'. C:\Temp\test\wc\Trunk\Lettus\lbinsvn st K test.txt C:\Temp\test\wc\Trunk\Lettus\lbincd .. C:\Temp\test\wc\Trunk\Lettussvn st K lbin\test.txt C:\Temp\test\wc\Trunk\Lettuscd .. C:\Temp\test\wc\Trunksvn up Updating '.': At revision 2. C:\Temp\test\wc\Trunksvn st K Lettus\lbin\test.txt C:\Temp\test\wc\Trunkcd .. C:\Temp\test\wcsvn st K Trunk\Lettus\lbin\test.txt C:\Temp\test\wcsvn up Updating '.': At revision 2. C:\Temp\test\wcsvn st K Trunk\Lettus\lbin\test.txt ]]] -- Johan
Re: SVN 1.8.1 Errors - Show Log and Commit New Files
Geoff Field geoff_fi...@aapl.com.au writes: Here's a log of a trial I have just done with a relatively fresh repository: C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test.txt Checked out revision 897. C:\cd SVN_Test C:\SVN_Testdir Volume in drive C is OSDisk Volume Serial Number is E49F-06D7 Directory of C:\SVN_Test 12/08/2013 09:54 AMDIR . 12/08/2013 09:54 AMDIR .. 12/08/2013 09:54 AM20 test.txt 1 File(s) 20 bytes 2 Dir(s) 160,268,779,520 bytes free C:\SVN_Testcopy test.txt test2.txt 1 file(s) copied. C:\SVN_Testsvn add test2.txt A test2.txt C:\SVN_Testsvn ci test2.txt --message test 1.8.1 checkin Adding test2.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date svn: E175005: File 'test2.txt' already exists I can't reproduce that. Can you look in the apache log files to see the failed request? Can you reproduce the problem over http? Can you provide a network trace? -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
Re: How to change paths on an external file without a full update --depth infinity?
On Sun, Aug 11, 2013 at 8:54 PM, Ben Reser bre...@apache.org wrote: On Sun, Aug 11, 2013 at 3:24 AM, Johan Corveleyn jcor...@gmail.com wrote: I'm cc'ing Ben Reser (who has the above issue assigned to him) and Ivan Zhakov (who recenty wrote a patch for this). Perhaps they can shed some light on the current state of RA session caching. As far as I remember from discussions during the Berlin Hackathon, this was deemed too risky for 1.8, but perhaps within scope for 1.9. It's on my todo to review Ivan's patch. It seems like the best short term solution and is basically what I had already intended to do. My 'reuse-ra-session' branch is not complete yet. I'm going to finish it after fixing most critical svn 1.8 issues. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Suggestion to change the name Subversion
On 12/08/2013 6:01 PM, Ulrich Eckhardt wrote: Am 12.08.2013 03:24, schrieb Bill George: This is to prevent confusion to non-technical people who could mistake the meaning of the name and associate it to negative activity like hacking or stealing. Just a thought and suggestion that could have far reaching implications. There is nothing negative when it comes to subverting injustice. There isn't anything inherently negative to hacking either. And stealing can as well be committed by shirt'n'tie people and without breaking any law. I'm not at all convinced by your arguments. Please consider this. Please consider standing up against injustice and stupidity instead. We're not going to change the root user either.
Re: Suggestion to change the name Subversion
On Mon, Aug 12, 2013 at 2:37 AM, Ryan Schmidt subversion-20...@ryandesign.com wrote: Should the GIMP change its name because (when not referring to the software) that can be a derogatory term? Should git change its name because (when not referring to the software) that term can be used as an insult? No. Each project was undoubtedly aware of the usual meaning of the word they chose as their name and decided to repurpose it. IIRC, people *have* suggested that GIMP get a rename. Someone's probably suggested it for git as well. And isn't there a (possibly apocryphal) story about the blame (either in CVS or SVN) being aliased to annotate and praise because a manager somewhere didn't like the negative connotation of blame? That said, I agree with everyone here, changing the name on a 13-year-old project is not necessary. I'm sure the name and its spelling was considered thoroughly before it was selected.
AW: hotcopy --incremental auto-upgrade Re: Backup strategy sanity check
Hi, Von: Les Mikesell [mailto:lesmikes...@gmail.com] On Sat, Aug 10, 2013 at 5:25 PM, Daniel Shahaf danie...@elego.de wrote: It would have been nice if --incremental would automatically upgrade the target repository (and fallback to a full backup) if the versions mismatch. Hmm. Interesting idea, but replacing failure modes with automagical behaviour is generally looked at with skepticism (is this error _really_ always safe to not tell the admin about?). For the sake of argument, why shouldn't admins who want this behaviour opt-in to it by having their scripts do svnadmin upgrade $dest svnadmin hotcopy --incremental $src $dest ? (Note that 'upgrade' is idempotent, and will exit without error for already-most-recent-format repositories.) Which case is worse for an unattended script? Leaving you with no backups or one that needs a newer program to be able to use? And which case might an early user of subversion have been trained to expect? I'd oppose auto-upgrading the destination repository to whatever toolchain version one happens to use - what happens when the source repository was not yet upgraded? Or it was upgraded from 1.5 format to 1.6 format, while the hotcopy is executing using 1.8? However, I'd be fine with svnadmin hotcopy automatically falling back to a full copy (or do whatever else is necessary to create a backup) when the destination has a different version than the source repository, maybe guarded by an extra --allow-upgrades command line parameter. Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: hotcopy --incremental auto-upgrade Re: Backup strategy sanity check
On Mon, Aug 12, 2013 at 08:36:42AM -0500, Les Mikesell wrote: On Sat, Aug 10, 2013 at 5:25 PM, Daniel Shahaf danie...@elego.de wrote: It would have been nice if --incremental would automatically upgrade the target repository (and fallback to a full backup) if the versions mismatch. Hmm. Interesting idea, but replacing failure modes with automagical behaviour is generally looked at with skepticism (is this error _really_ always safe to not tell the admin about?). For the sake of argument, why shouldn't admins who want this behaviour opt-in to it by having their scripts do svnadmin upgrade $dest svnadmin hotcopy --incremental $src $dest ? (Note that 'upgrade' is idempotent, and will exit without error for already-most-recent-format repositories.) The current implementation is conservative on purpose. If there is huge demand I'll consider the idea of making incremental hotcopy deal with upgraded repositories in some automated way. Perhaps there is a good way of doing this. Perhaps not. For now, users who copy data between repositories of different formats should consider using 'svnadmin dump --incremental /svnadmin load' instead of hotcopy. Which case is worse for an unattended script? Leaving you with no backups or one that needs a newer program to be able to use? And which case might an early user of subversion have been trained to expect? Early users of Subversion don't have scripts that use incremental hotcopy anyway. And if people don't notice that their backup scripts are failing for some reason (I know this happens, I've seen it happen many times), then they've got bigger problems which we cannot solve for them.
RE: Strange behavior
Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say look, it is right!! it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way. Now the two suggestions I have are auto properties and in place import. The links provided do not relate to my situation. The provided link indicates properties that get set DURING the import. I need to ignore files BEFORE the import. Like I originally stated, I need to import SOME files. Importing compiler generated files OR user settings causes problem and makes merging impossible thereby defeating some of the benefits of using subversion. If this method will solve this problem can you provide me with a link indicating how to do this? I can not find anything in the book nor the provided link. If you could give me some keywords to search for that would help also. I tried searching and all I find is questions relating to different actions. I looked at the import command in the book and with the svn help command and could not see how to use the svn:ignore. The import-in-place command works on a single file. That would indicate I would need to issue the command hundreds of times. Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. JM -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Friday, August 09, 2013 4:17 PM To: John Maher Cc: Subversion Users Subject: Re: Strange behavior Remember to Reply All so that your message goes to the mailing list too, not just to me. On Aug 9, 2013, at 14:59, John Maher wrote: Thanks for your reply. I appreciate informing me that subversion is robust. I was concerned it was getting corrupted by the strange behavior. Plus you've also helped by telling me that the ignore property does not mean ignore, it means sometimes ignore. On page 68 of the book it explains that the ignore property is used to eliminate files from svn status. But your explanation matches my observations, thank you. The book is wrong again. I tried to delete the files from the repository with svn delete, but that failed because they were not part of the current revision. So it seems that I have to delete the repository and create it again (for the 3rd time). Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists?. I followed the instructions in the book, created a repository and it came out all wrong, again. Can someone tell me how to get code files into the repository and stop the compiler generated files and directories? Thanks JM Page 68 of the PDF version of the book is within the section Ignoring Unversioned Items, but the items you're talking about are versioned, not unversioned. svn import will obey your svn autoprops: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.html#svn.advanced.props.auto But I often prefer to avoid the svn import command and do an in-place import instead: http://subversion.apache.org/faq.html#in-place-import This affords you the opportunity to be more selective about what you import and to add properties before committing.
Re: Strange behavior
On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
-Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Monday, August 12, 2013 10:18 AM To: Ryan Schmidt Cc: Subversion Users Subject: RE: Strange behavior Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. You're overthinking this. You can use OS level commands to trim down the files to import. Copy the files to a temp directory, delete the files you don't want imported, and then run 'svn import' on the tmp dir. Even if you have mistakes in the import, you can use 'svn rm' and 'svn add' to clean things up. It would be nice if you could pass 'svn import' a list of filenames/regexes to include or exclude, but modern shells already have the tools to filter and delete files, so there's little need to add those wheels to 'svn import'. Especially since the import is normally a one-time event. Are you using 'svn import' multiple times? (Such as to create additional branches of the code?) If so, that would be bad, as in wrong paradigm/workflow. As for branching, here's the short version for the 1.8 svn client: 0) Use 'svn import' to create the initial baseline, say /trunk. then 1) Create the branch: 'svn copy svn:/server/trunk svn:/server/branches/foo.2.0.0' 2) Create branch workspace: cd /myworkspaces svn co svn:/server/branches/foo.2.0.0' cd foo.2.0.0 3) Work on foo.2.0.0 3.1) 'svn add' to add new files (svn:ignore will help here.) 3.2) 'svn ci' to commit the files 3.2) Periodically merge trunk changes up to foo.2.0.0: svn merge ^/trunk Note: makes sure your foo.2.0.0 changes are checked in before merging up from trunk, 'svn status' When foo.2.0.0 is done, first merge trunk up to foo.2.0.0 to make sure that foo.2.0.0 has the current trunk changes 4) 'svn merge ^/trunk' 4.1) Resolve any conflicts. Now merge foo.2.0.0 down to trunk. 5) Create a clean merge workspace cd /myworkspaces 'svn co svn:/server/trunk' cd trunk Note: if you are reusing a workspace, then 'svn status' and 'svn update' to make sure it's clean and ready for a merge. 6) 'svn merge ^/branches/foo.2.0.0' 6.1) Resolve any conflicts. 7) 'svn ci'
Re: Built 1.8.1 from source: libz.so.1: no version information available
You are using shared libraries. --enable-static merely enables static libraries to be produced, it does not cause the build to use them. I see. Then my problem is not knowing how to tell the build to use the zlib I built. When I build svn and point to the location of my zlib prefix (see command in original post), svn still looks for /lib64/libz.so.1. Also I noticed that libz.so.1 doesn't exist in my zlib prefix location (/tmp-build/zlib) The location is tmp because I am not trying to replace zlib on this system, I'm trying to package zlib with my build of subversion. This way subversion is deploy-able to different machines and less reliant on local libraries. The only problem you have shown is using different zlibs at build time and after install. Either use the system zlib during the build or arrange for your zlib to be used after install. Right. My attempts to make them both use the same version have been unsuccessful. If I don't build zlib manually, subversion still seems to use a newer version of zlib than the one I have locally (and results in the same error). If I do build zlib manually, I can't seem to tell subversion to use the one I built. svn still looks for /lib64/libz.so.1 In any case, thanks for sharing your thoughts, Philip. I really apprecaite the help. Randy - Original Message - From: Philip Martin philip.mar...@wandisco.com To: Randy nya_ma...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Monday, August 12, 2013 12:16 AM Subject: Re: Built 1.8.1 from source: libz.so.1: no version information available Randy nya_ma...@yahoo.com writes: Thank you for the reply. I think you are correct about it being a zlib version problem. But the error with /lib64/libz.so.1 happens whether I build svn with the dependencies or without. The reason I am attempting to build it with the static libraries (which are fetched You are using shared libraries. --enable-static merely enables static libraries to be produced, it does not cause the build to use them. with the included get-deps.sh script) is to prevent it from trying to use /lib64/libz.so.1 which appears to have zlib version problem. However ldd shows my svn using /lib64/libz.so.1 no matter what I do. The only problem you have shown is using different zlibs at build time and after install. Either use the system zlib during the build or arrange for your zlib to be used after install. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
Re: Built 1.8.1 from source: libz.so.1: no version information available
Why do you have both? I'm not sure. Maybe I'll remove the i386 version and try again. One of the advantages of my RPM building tools is that they work well building with mock, which gets you a pristine build environment every time. My goal is to create two independently deploy-able subversion client packages that don't rely on local libraries (where possible). One package for CentOS 5 and one for CentOS 6. The error I mentioned is occurring after building svn on either of my CentOS 5 and CentOS 6 build systems. It sounds like your tools would work well for my CentOS 6 package. Maybe I'm missing something, but I don't see specific instructions on using your tools. Is there a INSTALL readme somewhere? Thanks again, Nico. Randy - Original Message - From: Nico Kadel-Garcia nka...@gmail.com To: Randy nya_ma...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Sunday, August 11, 2013 7:45 PM Subject: Re: Built 1.8.1 from source: libz.so.1: no version information available On Sun, Aug 11, 2013 at 1:34 PM, Randy nya_ma...@yahoo.com wrote: Hi Nico, Thank you for the reply! I confirmed that I do have zlib-devel installed... Package zlib-devel-1.2.3-7.el5.x86_64 already installed and latest version Package zlib-devel-1.2.3-7.el5.i386 already installed and latest version I will try out your RPM building tools soon and report back. Why do you have both? One of the advantages of my RPM building tools is that they work well building with mock, which gets you a pristine build environment every time.
RE: Strange behavior
Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks for the quick merge lesson. I would need to use the same directory for the branch as the trunk since there is a rather large infrastructure required to run the project (It is an ERP application). So I would plan on using switch. As long there are no hidden gotchas I should be OK. -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Monday, August 12, 2013 1:39 PM To: John Maher Cc: Subversion Users Subject: RE: Strange behavior -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Monday, August 12, 2013 10:18 AM To: Ryan Schmidt Cc: Subversion Users Subject: RE: Strange behavior Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. You're overthinking this. You can use OS level commands to trim down the files to import. Copy the files to a temp directory, delete the files you don't want imported, and then run 'svn import' on the tmp dir. Even if you have mistakes in the import, you can use 'svn rm' and 'svn add' to clean things up. It would be nice if you could pass 'svn import' a list of filenames/regexes to include or exclude, but modern shells already have the tools to filter and delete files, so there's little need to add those wheels to 'svn import'. Especially since the import is normally a one-time event. Are you using 'svn import' multiple times? (Such as to create additional branches of the code?) If so, that would be bad, as in wrong paradigm/workflow. As for branching, here's the short version for the 1.8 svn client: 0) Use 'svn import' to create the initial baseline, say /trunk. then 1) Create the branch: 'svn copy svn:/server/trunk svn:/server/branches/foo.2.0.0' 2) Create branch workspace: cd /myworkspaces svn co svn:/server/branches/foo.2.0.0' cd foo.2.0.0 3) Work on foo.2.0.0 3.1) 'svn add' to add new files (svn:ignore will help here.) 3.2) 'svn ci' to commit the files 3.2) Periodically merge trunk changes up to foo.2.0.0: svn merge ^/trunk Note: makes sure your foo.2.0.0 changes are checked in before merging up from trunk, 'svn status' When foo.2.0.0 is done, first merge trunk up to foo.2.0.0 to make sure that foo.2.0.0 has the current trunk changes 4) 'svn merge ^/trunk' 4.1) Resolve any conflicts. Now merge foo.2.0.0 down to trunk. 5) Create a clean merge workspace cd /myworkspaces 'svn co svn:/server/trunk' cd trunk Note: if you are reusing a workspace, then 'svn status' and 'svn update' to make sure it's clean and ready for a merge. 6) 'svn merge ^/branches/foo.2.0.0' 6.1) Resolve any conflicts. 7) 'svn ci'
RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:02 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. Search for global-ignores in the single page version of the redbook: http://svnbook.red-bean.com/en/1.7/svn-book.html Here's infor about runtime configuration: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea BOb JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:02 PM To: John Maher; Edwin Castro; users@subversion.apache.org Subject: RE: Strange behavior Thanks Edwin, That's exactly what I am trying to do. I was looking for a way for the tool to accomplish this. I'd be just as glad if someone tells me it is impossible, which I suspect it may be. Otherwise there are over 200 manual operations required just to create a repository. The way some people praise subversion I would think this can be automated. But then again perhaps those are the people who use subversion for the simplest of builds. I'm not sure what you are asking for? An automated way to ignore files you don't want check in? Or are you talking about import? I believe import respects global ignores if you have them set up in your config file. BOb JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Monday, August 12, 2013 11:55 AM To: users@subversion.apache.org Subject: Re: Strange behavior On 8/12/13 6:17 AM, John Maher wrote: Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. In cases like this I perform a clean operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
Re: Strange behavior
On 8/12/13 10:57 AM, John Maher wrote: But then again perhaps those are the people who use subversion for the simplest of builds. At my previous employer I was partly responsible for a codebase in subversion whose trunk was 2+ GB large. The codebase included over 1400 C#, C++, SQL, and WiX projects. I think many of us have very complicated builds. We simply choose to use the correct tool for the job. Working on Windows I wrote many PowerShell scripts to help me manage bulk operations. I have no evidence but I suspect most of us have lots of experience working with very large codebases in subversion. Suggesting that we have the simplest of builds comes across as elitist which is odd coming from an obvious beginner. There is clear evidence that there's a cognitive mismatch between your current understanding and how subversion is intended to be used. We're here to help you but that help will come these discussions occur with respect. Sometimes it is better to present the experts with the problem you are trying to solve including how you've attempted to solve it, accepting the possibility that your current approach may not be the best approach. Seems like I keep hearing you're doing it wrong from the list and you keep responding with I don't care, how do accomplish this anyway. I don't think that's a good attitude to take. -- Edwin
Re: Strange behavior
On 8/12/2013 12:27 PM, John Maher wrote: Thanks Bob, that may be exactly what I am looking for. Something that would affect all the files without having to issue over 200 commands or build a dummy directory just for importing. Although that second suggestion provided by Andrew is definitely better than the first. I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. I can't even find the name of it. If someone can provide that I could at least search for it and hope it has some clue inside as how to alter it. First link from Google (search was windows xp subversion configuration file location, http://stackoverflow.com/questions/6310539/where-is-the-subversion-global-config-file-for-the-slik-svn-client-for-windows) sez: C:\Documents and Settings\%USERNAME%\Application Data\Subversion\config I no longer run on Windows XP, so I don't remember if this is the proper place for the file, but I have no reason to doubt it. For Windows 7 it's in: C:\Users\%USERNAME%\AppData\Roaming\Subversion\config Which I can confirm. In the config file, I have my global-ignores for Windows set to: global-ignores = *.obj *.lib *.map *.exe *.bak *.pdb *.ilk *.idb There might need to be a few more; it's been several years since I have imported existing code into my Subversion repositories. But you get the idea. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: Strange behavior
-Original Message-
From: John Maher [mailto:jo...@rotair.com]
Sent: Monday, August 12, 2013 3:27 PM
To: Bob Archer; Edwin Castro; users@subversion.apache.org
Subject: RE: Strange behavior
Thanks Bob, that may be exactly what I am looking for. Something that
would affect all the files without having to issue over 200 commands or
build a dummy directory just for importing. Although that second
suggestion provided by Andrew is definitely better than the first.
I couldn't find where it discusses the global config in the book, if it
does at all. And even if it does I doubt it would help because it
won't tell me where to find the file. Unless there is a command to
edit it. I tried a search and someone says there is a site-wide config
(what I need) and a user config but not where they are. I am using
Windows XP and an having a difficult time finding this file.
I can't even find the name of it. If someone can provide that I could
at least search for it and hope it has some clue inside as how to alter
it.
Plan B might be to use svn_load_dirs.pl:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a glob_ignores option, or will try to read your global-ignores from
your local svn config file.
From the script:
===
# If no glob_ignores specified, try to deduce from config file,
# or use the default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f $ENV{HOME}/.subversion/config )
{
open my $conf, $ENV{HOME}/.subversion/config;
while ($conf)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
Re: Strange behavior
On Mon, Aug 12, 2013 at 4:17 PM, John Maher jo...@rotair.com wrote: ... And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say look, it is right!! it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way. But since no one here is interested to maintaining good documentation ...? Oh come on. Of course we want good documentation, and feedback to help improve it is more than welcome. But give the people on this list some credit too, please. Have you read the very first response you got, from Ryan Schmidt, pointing you to the website of the book, where your feedback would be most welcome? Also, please keep in mind that the most useful feedback comes in the form of concrete suggestions, or pointing out specific shortcomings. If you say I didn't find anything about X, and someone replies it's on page Y, then the feedback loop is closed. If you want your not finding about X to be any further useful book feedback, you'll have to argue why your non-finding is a book problem (rather than an oops, I looked at the wrong section problem), and that it should be explained or pointed to on page Z, or wherever you expected to find info about it. -- Johan
Re: Strange behavior
On Mon, Aug 12, 2013 at 3:27 PM, John Maher jo...@rotair.com wrote: I couldn't find where it discusses the global config in the book, if it does at all. And even if it does I doubt it would help because it won't tell me where to find the file. Unless there is a command to edit it. I tried a search and someone says there is a site-wide config (what I need) and a user config but not where they are. I am using Windows XP and an having a difficult time finding this file. The configuration area is in the book in here: http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html The footnote links to the easiest way to find the file: %APPDATA%\Subversion Just enter that into the Windows Run dialog or the address bar of the file explorer and it will take you to the right folder where the configuration files are found. This is true for XP as well as Win 7. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Strange behavior
I apologize. It was wrong to say no one here is interested . . . Some people are uninterested. Some are interested. Some are extremely helpful. Some can be very egotistical. Just like the real world, you get a mix of good and less than good. I should've never responded like that to a group because of an apple that I did not agree with. Being frustrated with this product (no excuse) add to that critisim when I try to help (maybe small excuse there) equals my reason, though it is not a good one. There's inconsistencies with the svn help command also. Maybe in the future I'll help with the documentation. But when you get a free product, and want to give back then take flak when you think you are helping it kinda kills the urge to help. But I never should've used an absolute like that. Thank you for pointing it out Johan and pointing it out in a polite way instead of condescending. -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Monday, August 12, 2013 3:54 PM To: John Maher Cc: Ryan Schmidt; Subversion Users Subject: Re: Strange behavior On Mon, Aug 12, 2013 at 4:17 PM, John Maher jo...@rotair.com wrote: ... And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. But since no one here is interested to maintaining good documentation and are more interested in hunting out any obscured word they can find just to say look, it is right!! it seems best if I never, ever point out any flaws in the documentation. I will just selfishly concern myself with my own problems, it seems all will get along better that way. But since no one here is interested to maintaining good documentation ...? Oh come on. Of course we want good documentation, and feedback to help improve it is more than welcome. But give the people on this list some credit too, please. Have you read the very first response you got, from Ryan Schmidt, pointing you to the website of the book, where your feedback would be most welcome? Also, please keep in mind that the most useful feedback comes in the form of concrete suggestions, or pointing out specific shortcomings. If you say I didn't find anything about X, and someone replies it's on page Y, then the feedback loop is closed. If you want your not finding about X to be any further useful book feedback, you'll have to argue why your non-finding is a book problem (rather than an oops, I looked at the wrong section problem), and that it should be explained or pointed to on page Z, or wherever you expected to find info about it. -- Johan
Re: Strange behavior
On Aug 12, 2013, at 14:52, Andrew Reedick wrote:
Plan B might be to use svn_load_dirs.pl:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
It has a glob_ignores option, or will try to read your global-ignores from
your local svn config file.
From the script:
===
# If no glob_ignores specified, try to deduce from config file,
# or use the default below.
my $ignores_str =
'*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store';
if ( defined $opt_glob_ignores)
{
$ignores_str = $opt_glob_ignores;
}
elsif ( -f $ENV{HOME}/.subversion/config )
{
open my $conf, $ENV{HOME}/.subversion/config;
while ($conf)
{
if ( /^global-ignores\s*=\s*(.*?)\s*$/ )
{
$ignores_str = $1;
last;
}
}
}
svn_load_dirs is for loading multiple versions of an old project into a version
control system for the first time. The user hasn't said anything about wanting
to do that so I don't think there's any need to jump to svn_load_dirs. It seems
like its glob_ignores just does what the built-in global-ignores already does.
Re: Strange behavior
Guten Tag John Maher, am Montag, 12. August 2013 um 20:57 schrieben Sie: Otherwise there are over 200 manual operations required just to create a repository. As you mentioned you are still working on Windows XP, you are aware of TortoiseSVN, aren't you? There shouldn't be the need to run any command yourself as Tortoise is able to create repos and act as a subversion client. The way some people praise subversion I would think this can be automated. Of course it can, just copy your 200 commands line by line one after another into a batch file. ;-) But then again perhaps those are the people who use subversion for the simplest of builds. Frustrating day, wasn't it? :-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Suggestion to change the name Subversion
On Mon, Aug 12, 2013 at 09:41:03AM -0400, Andy Levy wrote: ... probably suggested it for git as well. And isn't there a (possibly apocryphal) story about the blame (either in CVS or SVN) being aliased to annotate and praise because a manager somewhere didn't like the negative connotation of blame? Nope. No managers involved. We just thought it would be funny, and in a touchy-feely way to make Subversion more positive. You praise people's changes, rather than blame them :-) [ and note: CVS has annotate; blame came from Mozilla's web-based repository viewer (MXR?) ] That said, I agree with everyone here, changing the name on a 13-year-old project is not necessary. I'm sure the name and its spelling was considered thoroughly before it was selected. Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Cheers, -g
Re: Suggestion to change the name Subversion
On 08/12/2013 03:51 PM, Greg Stein wrote: Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Great story, thanks! -- Glenn Holmer Weyco Group, Inc. phone: 414-908-1809 fax: 414-908-1601
Re: Suggestion to change the name Subversion
On Mon, Aug 12, 2013 at 4:57 PM, Glenn Holmer ghol...@weycogroup.com wrote: On 08/12/2013 03:51 PM, Greg Stein wrote: Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Great story, thanks! Agreed. On the name change topic, I had a professor who would greet people with heaveno because he believed the traditional greeting had satanic connotations. His attempts to make us use that did not go very far... -- Glenn Holmer Weyco Group, Inc. phone: 414-908-1809 fax: 414-908-1601
Re: Strange behavior
On Aug 12, 2013, at 09:17, John Maher wrote: Thanks for your help, but I still do not know how to get this to work. Perhaps I should give a little background. The project that I mentioned in my original post was a test project created just to learn how to get subversion to work. The production code that I wish to put in one repository resides in 62 directories that have over 2000 files in them of which only some of them can be included otherwise merging becomes impossible. The whole point of this exercise is to get merging to work since it causes unnecessary difficultly to try to separate new features with bug fixes in a single branch. But this is all I could get to work. Unfortunately no matter how much I read (I read the first half of the book twice) and how much I checkout and commit the tool fails to work for me. I'll let others address your merging questions, since I read the book before Subversion 1.5 was released, when merge tracking was introduced, which has simplified merging considerably. And the only reason I have been complaining about the documentation is hoping to point out areas where it is very unclear and misleading. Anyone who knows how to use the tool will never catch on to the poorly written areas of the documentation, they are biased. You NEED someone who doesn't know how to use the tool to indicate areas that need to be addressed. I totally agree, and please continue doing this. I did originally learn Subversion by reading the book, so that was the basis for my praise of it, but I have learned many more things by reading years of messages on this list so sometimes it's hard for me to recall where a particular bit of knowledge came from. Now the two suggestions I have are auto properties and in place import. The links provided do not relate to my situation. I think when I said auto-props, I meant global-ignores. Sorry about that. They're related in that they're both considered when importing. I think I see why I said that: you wrote: Does import work with the ignore property? It mentions it in the help, but I do not know if the help is wrong. If properties need to be applied to a working directory how do I use them with the import command BEFORE a working copy exists? I was confusing the svn:ignore property with the global-ignores config file setting. The svn:ignore property is applied to a directory so that files inside it might be ignored (and which affects all users who might check out a working copy of this directory), and yes, that has to happen in a working copy. The global-ignores setting in your Subversion config file has a similar function but affects all working copies and import actions you perform, regardless what server is involved, and affects only you. The provided link indicates properties that get set DURING the import. I need to ignore files BEFORE the import. Like I originally stated, I need to import SOME files. Importing compiler generated files OR user settings causes problem and makes merging impossible thereby defeating some of the benefits of using subversion. If this method will solve this problem can you provide me with a link indicating how to do this? I can not find anything in the book nor the provided link. If you could give me some keywords to search for that would help also. I tried searching and all I find is questions relating to different actions. I looked at the import command in the book and with the svn help command and could not see how to use the svn:ignore. The import-in-place command works on a single file. That would indicate I would need to issue the command hundreds of times. Are you sure this is the only way? It would seem odd that this toll does not provide a way to import an enterprise level application without ignoring the compiler generated files. The in-place import does not operate on a single file; it is a procedure for importing any number of items within a directory. The example in the FAQ showed how to do an in-place import of four files in /etc. I'll try to explain in more detail. Let's say you have a directory of original files, and a repository you want to import them into. You want to import some files but not others. Maybe you want to set properties on some files, such as MIME types or line ending styles. == Normal Import == With a normal import, you run a single command svn import and the contents of the directory are imported into the repository. While doing so, Subversion considers your global-ignores (to decide which files not to import) and your auto-props (to decide what properties to apply to files that are imported), but there is no opportunity to inspect the results of that consideration before the files are committed to the repository. Once a normal import is completed, your original directory is untouched. To get a working copy that you can perform additional Subversion
Re: Suggestion to change the name Subversion
Wait a minute, he also erased his bash history. Was he suspected of covering up assaults as well?? I don't think the suspicion arose because the repository was named subversion. I think it was because source code was being transferred to an outside location. It could have been called Utter conformist corporate monkey repository and it would have still raised suspicion. Yes, people are ignorant about things (I'm sure we don't have to look too hard to find things about this we too are ignorant). But I don't think the name of Subversion would have prevented this from happening. There were some suspicious things going on (I'm ignorant of the details, but from the article it does sound, at the start, suspicious). But I think Goldman-Sachs should have had a better understanding of what was happening before they called in the Feds On Tue, Aug 13, 2013 at 7:25 AM, Mauricio Tavares raubvo...@gmail.comwrote: On Mon, Aug 12, 2013 at 4:57 PM, Glenn Holmer ghol...@weycogroup.com wrote: On 08/12/2013 03:51 PM, Greg Stein wrote: Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Great story, thanks! Agreed. On the name change topic, I had a professor who would greet people with heaveno because he believed the traditional greeting had satanic connotations. His attempts to make us use that did not go very far... -- Glenn Holmer Weyco Group, Inc. phone: 414-908-1809 fax: 414-908-1601
Re: svn: E175009: XML parsing failed: (400 Bad Request) after upgrade to 1.8
It seems to have been resolved in SVN 1.8.1. -Craig On Wed, Jun 26, 2013 at 2:41 PM, Johan Corveleyn jcor...@gmail.com wrote: On Wed, Jun 26, 2013 at 10:44 PM, Craig Wenger craig.wen...@gmail.com wrote: Since upgrading to Subversion 1.8.0 (r1490375) a few days ago, I have been unable to checkout (or update, after upgrading my working copy) a particular repository (http://www.sharedproteomics.com/OMSSA/svn). I get the error: svn: E175009: XML parsing failed: (400 Bad Request) This is somehow related to my network configuration, as I get this problem from work but not from home. At least one other person seems to be experiencing this problem ( http://comments.gmane.org/gmane.comp.version-control.subversion.user/113693 ). Should I file a new issue? Can you figure out what the difference in network configuration is? A proxy perhaps? Can you find out which proxy? It would probably be interesting if you could get a wiretrace of what's going on. I think you should file an issue (referring to this thread), and try to provide as much information as possible. Thanks, -- Johan
Re: Built 1.8.1 from source: libz.so.1: no version information available
Randy nya_ma...@yahoo.com writes: I see. Then my problem is not knowing how to tell the build to use the zlib I built. If zlib is a shared library there are various ways: you set RPATH in the ELF libraries that use zlib, probably using -rpath while linking; or you set the LD_LIBRARY_PATH environment variable; or you modify the system ld.so.conf and run ldconfig. However you don't appear to have a shared library. When I build svn and point to the location of my zlib prefix (see command in original post), svn still looks for /lib64/libz.so.1. Also I noticed that libz.so.1 doesn't exist in my zlib prefix location (/tmp-build/zlib) You appear to be using a static zlib. What about serf? It also uses zlib. Are you linking serf against the system zlib or your own zlib? Something is linking against a shared zlib. Trying to use two different zlib is probably a bad idea. It may work, or it may give you errors that are hard to track down. The location is tmp because I am not trying to replace zlib on this system, I'm trying to package zlib with my build of subversion. If zlib is static you don't package it, it gets included when you link to the static library. This way subversion is deploy-able to different machines and less reliant on local libraries. As you have discovered, it can be hard to do that. You have to ensure that you link everything to the right libraries and that involves understanding shared library dependencies. You may find it easier to build binaries for each OS using the system libraries as far as possible. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
This application has halted due to an unexpected error.
Hi All: Crash report attached. -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory svn-crash-log20130812144701.log Description: Binary data
Re: Suggestion to change the name Subversion
No one else remember the old Satan monitoring toolkit, that had an option to change the displayed name and icon to Santa? The name Subversion has enough positive reputation that changing it, just to avoid NSA style monitoring, seems very destabilizing to a popular project. Let's not change it. Nico Kadel-Garcia Email: nka...@gmail.com Sent from iPhone On Aug 12, 2013, at 17:25, Mauricio Tavares raubvo...@gmail.com wrote: On Mon, Aug 12, 2013 at 4:57 PM, Glenn Holmer ghol...@weycogroup.com wrote: On 08/12/2013 03:51 PM, Greg Stein wrote: Apache Subversion actually started as Inversion around December 1999, or January 2000. It wasn't until April 2000, that we accepted Subversion as a rename. It had version in the name, and we *were* trying to subvert the CVS installations/community, so the name fit extremely well :-) It became Apache Subversion in February 2010. Great story, thanks! Agreed. On the name change topic, I had a professor who would greet people with heaveno because he believed the traditional greeting had satanic connotations. His attempts to make us use that did not go very far... -- Glenn Holmer Weyco Group, Inc. phone: 414-908-1809 fax: 414-908-1601
Re: Built 1.8.1 from source: libz.so.1: no version information available
Randy, are you using the --disable-shared option? --enable-static is not enough. And you should not need *any* get-deps.sh tarballs if you try my SRPM tools. There is a README.md file that goes with the git repository, and should be helpful. Nico Kadel-Garcia Email: nka...@gmail.com Sent from iPhone On Aug 12, 2013, at 14:44, Randy nya_ma...@yahoo.com wrote: If I don't run get-deps.sh and build apr apr-util, then my subversion build attempt complains about the missing apr packages. If I run get-deps.sh and then manually delete the fetched zlib directory before building subversion, I still end up with the same error /lib64/libz.so.1: no version information available when running svn commands. I'm getting the same result after building svn on two different systems. One is CentOS 5 and the other is CentOS 6. Cheers, Randy - Original Message - From: Nico Kadel-Garcia nka...@gmail.com To: Randy nya_ma...@yahoo.com Cc: users@subversion.apache.org users@subversion.apache.org Sent: Sunday, August 11, 2013 7:49 PM Subject: Re: Built 1.8.1 from source: libz.so.1: no version information available On Sun, Aug 11, 2013 at 1:34 PM, Randy nya_ma...@yahoo.com wrote: Hi Nico, Thank you for the reply! I confirmed that I do have zlib-devel installed... Package zlib-devel-1.2.3-7.el5.x86_64 already installed and latest version Package zlib-devel-1.2.3-7.el5.i386 already installed and latest version I will try out your RPM building tools soon and report back. Did you run the get-deps.sh tool and wind up with a local versoin of zlib? *Don't*. Use get-deps.sh only to get tools that are not recent enough on your local operating system, such as sqlite-automation on RHEL 6 or possibly serf on RHEL 6.
Re: Balancing and proxing
Nico Kadel-Garcia Email: nka...@gmail.com Sent from iPhone On Aug 9, 2013, at 20:12, Roman Naumenko ro...@naumenko.ca You mean this one (svn clustering)? http://www.wandisco.com/get?f=documentation/datasheets/DataSheet-Clustering.pdf It doesn't look like it's a simple loadbalancing architecture with a shared storage for repositories. Right. Shared storage is very vulnerable to corrupting that single shared back end. This seems to be a well thought out multi master setup, and should be far more resilient for most environments. There is some replication and synchronization involved, automatic failover, etc. Is anybody using it, what its like? --Roman I'm working from the public specs. I'm not a Subversion master in my current workplace, so lack the 3 hosts needed to really test it put.
RE: SVN 1.8.1 Errors - Show Log and Commit New Files
-Original Message- From: Philip Martin Sent: Monday, 12 August 2013 18:57 PM Geoff Field writes: Here's a log of a trial I have just done with a relatively fresh repository: C:\svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test ASVN_Test\test.txt Checked out revision 897. C:\cd SVN_Test C:\SVN_Testdir Volume in drive C is OSDisk Volume Serial Number is E49F-06D7 Directory of C:\SVN_Test 12/08/2013 09:54 AMDIR . 12/08/2013 09:54 AMDIR .. 12/08/2013 09:54 AM20 test.txt 1 File(s) 20 bytes 2 Dir(s) 160,268,779,520 bytes free C:\SVN_Testcopy test.txt test2.txt 1 file(s) copied. C:\SVN_Testsvn add test2.txt A test2.txt C:\SVN_Testsvn ci test2.txt --message test 1.8.1 checkin Adding test2.txt svn: E155011: Commit failed (details follow): svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date svn: E175005: File 'test2.txt' already exists I can't reproduce that. Can you look in the apache log files to see the failed request? Can you reproduce the problem over http? Can you provide a network trace? I have emailed Philip and Lieven directly with the network trace file as it's a bit big (600-odd K) for a mailing list. Attached for general amusement and delectation is the relevant portion of our Apache access log for a repeat test I did this morning (Australian Eastern Standard Time). The testing did not touch our Apache error log. Regards, Geoff -- Sorry about the automatic legal disclaimer: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files. ApacheAccess.log Description: ApacheAccess.log
