RE: Windows 8 Tortoise SVN --- missing green check marks
This is a svn mailing list, not a tortoise list. What is the difference? Svn is the product. Works great, has an 1980's era interface. Cumbersome to use. Has great support and a manual. Tortoise is a wrapper for svn. It is a modern interface that does not keep up with the operating systems it runs on nor does it allow all the capabilities of svn. Tortoise doesn't display the check marks on windows 7 either. Tortoise is a great concept, providing a modern interface for a powerful tool, however, it is not being kept up to date as it should. You have two choices: 1) Use svn as-is and gets all its power but be ready to do a lot of typing. 2) Use tortoise and get a modern interface that is lacking. JM From: Hossein Miri [mailto:hm...@me.com] Sent: Saturday, October 11, 2014 12:17 PM To: users@subversion.apache.org Subject: Windows 8 Tortoise SVN --- missing green check marks Hello, I am new to using SVN for sw-dev, so if I am doing something silly or posting in the wrong place, please say so kindly... I have just installed Tortoise SVN on a Windows 8 machine, to be used for Unity and Oculus development. I checked out the SVN of the company I have just joined into a local folder on my PC to work on. I understand every file/directory in a working copy should have a green check mark in its bottom left corner, indicating that it is unchanged from the version in the repository. But none of my checked out files/folders in my working copy directory has that. Is it normal in Win 8 or have I done something wrong here? Thank you,
RE: Windows 8 Tortoise SVN --- missing green check marks
Hi Dave What version of tsvn are you using. Perhaps I have an older version? -Original Message- From: Dave Huang [mailto:k...@azeotrope.org] Sent: Monday, October 13, 2014 11:14 AM To: John Maher Cc: Hossein Miri; users@subversion.apache.org Subject: Re: Windows 8 Tortoise SVN --- missing green check marks On Oct 13, 2014, at 8:09, John Maher jo...@rotair.com wrote: Tortoise doesn't display the check marks on windows 7 either. Tortoise is a great concept, providing a modern interface for a powerful tool, however, it is not being kept up to date as it should. FYI, it displays the status overlays on Windows 7, 8, and 8.1--I use TSVN on Win8.1 daily and have the check marks, etc... The TSVN documentation even shows them on Windows 7; I'm pretty sure figure 4.12 at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-wcstatus.html is from Windows 7, and Figure 4.13 is definitely Windows 7. As others have mentioned, if you're having problems with the overlays not showing, ask the TortoiseSVN mailing list. And check this FAQ item too: http://tortoisesvn.net/faq.html#ovlnotshowing -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 38 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
RE: Exception reporting
I was supposed to do a reply all to keep the thread up to date and also let others see the issue. If you're not sure if the issue is raised already you can always search. Search is your friend. Did you follow the recommendation from the link you posted? What happens if you get a new working copy? JM From: Kumar Krishnamoorthy [mailto:rkrishnamoor...@seamlesscms.com] Sent: Thursday, October 09, 2014 7:30 PM To: John Maher Subject: RE: Exception reporting Oops. Sorry, I was in the middle of something when I got this error, so just skimmed through the message and took and screenshot and sent it. This time I really took the time to read the message and found that it's the same error reported here. http://stackoverflow.com/questions/23991573/subversion-reported-a-malfunction-action-svn-wc-conflict-action-delete-on-l Only difference I see is the version number in my message in 1.8.8 Not sure if it has an issue raised already. I was trying to checkout spring-net from GitHub using Subversion url https://github.com/spring-projects/spring-net But the checkout operation completed with some error. I did a cleanup and did update and that's when I got this error. I think the real problem was in the checkout process, which might have left my local copy in a stale state. And I should not have done an update and instead just deleted the whole repo and checkout again. But didn't bother with it and went with git for now. Hope that's enough information. Let me know if you need any more details. Thanks, Kumar Krishnamoorthy Developer Seamless | Leaders in Government WCM Follow us on Twitter: @seamlesscms Phone: +613 9913 0020 E-mail: rkrishnamoor...@seamlesscms.commailto:rkrishnamoor...@seamlesscms.com www.seamlesscms.comhttp://www.seamlesscms.com [cid:image002.png@01CFE46F.1F1B9D80] From: John Maher [mailto:jo...@rotair.com] Sent: Wednesday, 8 October 2014 10:49 PM To: Kumar Krishnamoorthy Subject: RE: Exception reporting HI Kumar Thanks for reporting, however this report is useless. Graphics files are not supported in this help system so many will not even see any exception. All they will see is Just reporting it because by subversion client asked me to report it :-) which doesn't tell them anything. JM From: Kumar Krishnamoorthy [mailto:rkrishnamoor...@seamlesscms.com] Sent: Wednesday, October 08, 2014 3:02 AM To: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: Exception reporting Just reporting it because by subversion client asked me to report it :-) [cid:image003.png@01CFE46F.1F1B9D80] Cheers, Kumar Krishnamoorthy Developer Seamless | Leaders in Government WCM Follow us on Twitter: @seamlesscms Phone: +613 9913 0020 E-mail: rkrishnamoor...@seamlesscms.commailto:rkrishnamoor...@seamlesscms.com www.seamlesscms.comhttp://www.seamlesscms.com [cid:image002.png@01CFE46F.1F1B9D80]
[no subject]
Hello Using subversion 1.7.6 on windows with visual studio 2008 on windows 7 and I'm wondering why subversion won't add new files. I've had problems with subversion adding junk to the repository and I was able to stop that using global ignores. Having to remember to manually add files, and if I add a form I must remember to add 3 files, runs the risk of losing data at worst and merge conflicts at best. I did move my code from a network share to a local drive. I just copied everything. The other commands seem to work well enough. Here's a section from my config file in C:\Users\JohnM.ROTAIR\AppData\Roaming\Subversion # global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.sou # *.rej *~ #*# .#* .*.swp .DS_Store global-ignores = *.suo *.user bin obj There are no other global ignores in that file.
RE: subversion won’t add new files
Not quite sure what you mean. I issue svn commit -m message Files do not get added. -Original Message- From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] Sent: Wednesday, September 24, 2014 11:08 AM To: John Maher Cc: Subversion Users Subject: Re: subversion won’t add new files On Sep 24, 2014, at 9:49 AM, John Maher wrote: Using subversion 1.7.6 on windows with visual studio 2008 on windows 7 and I’m wondering why subversion won’t add new files. Can you show us a transcript of this happening (or rather not happening)?
RE: subversion won’t add new files
I issue svn commit -m testing I get SendingRotairUI_CertificatePrint\CertificatePrint.designer.vb SendingRotairUI_CertificatePrint\CertificatePrint.vb SendingRotairUI_CertificatePrint\My Project\Application.Designer.vb SendingRotairUI_CertificatePrint\My Project\Resources.Designer.vb SendingRotairUI_CertificatePrint\My Project\Settings.Designer.vb SendingRotairUI_CertificatePrint\RotairUI_CertificatePrint.vbproj Transmitting file data .. Committed revision 254. svn status ? RotairUI_CertificatePrint\FreeFormText.Designer.vb ? RotairUI_CertificatePrint\FreeFormText.resx ? RotairUI_CertificatePrint\FreeFormText.vb Those are files that did not get added. I add another one, Form1. Build the project. Issue another commit. svn commit -m testing SendingRotairUI_CertificatePrint\RotairUI_CertificatePrint.vbproj Transmitting file data . Committed revision 255. svn status ? RotairUI_CertificatePrint\Form1.Designer.vb ? RotairUI_CertificatePrint\Form1.vb ? RotairUI_CertificatePrint\FreeFormText.Designer.vb ? RotairUI_CertificatePrint\FreeFormText.resx ? RotairUI_CertificatePrint\FreeFormText.vb Now I have even more files that subversion missed. I did not issue any add commands. Do I have to manually add files? I thought subversion was supposed to handle this. This is a change to my working copy that did not get incorporated into the repository. At one time it was adding files I did not want added. Now its ignoring files I want to add. Very confusing tool indeed. The book says this: Send changes from your working copy to the repository. If you do not supply a log message with your commit by using either the --file (-F) or --message (-m) option, svn will launch your editor for you to compose a commit message. See the editor-cmd list entry in the section called “Config”. Which gives me no information as if it should add new files or that is my job. Can someone tell me if it's my responsibility to add new files or subversion's? Thanks JM -Original Message- From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] Sent: Wednesday, September 24, 2014 11:41 AM To: John Maher Cc: Subversion Users Subject: Re: subversion won’t add new files On Sep 24, 2014, at 10:38 AM, John Maher wrote: Ryan Schmidt wrote: On Sep 24, 2014, at 9:49 AM, John Maher wrote: Using subversion 1.7.6 on windows with visual studio 2008 on windows 7 and I’m wondering why subversion won’t add new files. Can you show us a transcript of this happening (or rather not happening)? Not quite sure what you mean. I issue svn commit -m message Files do not get added. What I mean is that since this is working correctly for everybody else, we need more information from you to see what you're doing differently. What does svn status say before you run svn commit? What svn add commands did you run before that?
RE: subversion won’t add new files
-Original Message- From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] Sent: Wednesday, September 24, 2014 11:58 AM To: John Maher Cc: Subversion Users Subject: Re: subversion won’t add new files On Sep 24, 2014, at 10:54 AM, John Maher wrote: I issue svn commit -m testing I get SendingRotairUI_CertificatePrint\CertificatePrint.designer.vb SendingRotairUI_CertificatePrint\CertificatePrint.vb SendingRotairUI_CertificatePrint\My Project\Application.Designer.vb SendingRotairUI_CertificatePrint\My Project\Resources.Designer.vb SendingRotairUI_CertificatePrint\My Project\Settings.Designer.vb SendingRotairUI_CertificatePrint\RotairUI_CertificatePrint.vbproj Transmitting file data .. Committed revision 254. svn status ? RotairUI_CertificatePrint\FreeFormText.Designer.vb ? RotairUI_CertificatePrint\FreeFormText.resx ? RotairUI_CertificatePrint\FreeFormText.vb Those are files that did not get added. I add another one, Form1. Build the project. Issue another commit. svn commit -m testing SendingRotairUI_CertificatePrint\RotairUI_CertificatePrint.vbproj Transmitting file data . Committed revision 255. svn status ? RotairUI_CertificatePrint\Form1.Designer.vb ? RotairUI_CertificatePrint\Form1.vb ? RotairUI_CertificatePrint\FreeFormText.Designer.vb ? RotairUI_CertificatePrint\FreeFormText.resx ? RotairUI_CertificatePrint\FreeFormText.vb Now I have even more files that subversion missed. I did not issue any add commands. Do I have to manually add files? I thought subversion was supposed to handle this. This is a change to my working copy that did not get incorporated into the repository. At one time it was adding files I did not want added. Now its ignoring files I want to add. Very confusing tool indeed. The book says this: Send changes from your working copy to the repository. If you do not supply a log message with your commit by using either the --file (-F) or --message (-m) option, svn will launch your editor for you to compose a commit message. See the editor-cmd list entry in the section called “Config”. Which gives me no information as if it should add new files or that is my job. Can someone tell me if it's my responsibility to add new files or subversion's? Yes, you must svn add any files you want Subversion to add to the repository. It's not meant to be confusing... I found the book exceptionally clear and helpful in explaining how Subversion works and is meant to be used. Thanks for your reply. Not sure why you wish to post opinions or think it's clear when the book says Send changes from your working copy to the repository when I make a change in my working copy and it is ignored. Don't take it personal if a user does not understand something. And just because you understand something does not make it clear. It just makes it clear to you. But none the less, thank you for explaining the weird behavior, it was very helpful. JM
RE: subversion won’t add new files
Thanks for the link jb. Reading through that section of the book I encountered file changes and tree changes. It also just mentions changes numerous times. On my initial reading it appears that when the book mentions changes without specifying the type (like the definition of the Commit command) it is talking about file changes ONLY and it is excluding tree changes. Just wondering if that assumption would be right most of the time or could it go either way and I would have to test to see which one was applicable. I tried looking at other mentions of the changes but due to my ignorance of the software I wasn't able to come to any conclusions myself. -Original Message- From: jbl...@icloud.com [mailto:jbl...@icloud.com] Sent: Wednesday, September 24, 2014 12:24 PM To: John Maher Cc: Subversion Users Subject: Re: subversion won’t add new files On Sep 24, 2014, at 9:14 AM, John Maher jo...@rotair.com wrote: Yes, you must svn add any files you want Subversion to add to the repository. It's not meant to be confusing... I found the book exceptionally clear and helpful in explaining how Subversion works and is meant to be used. Thanks for your reply. Not sure why you wish to post opinions or think it's clear when the book says Send changes from your working copy to the repository when I make a change in my working copy and it is ignored. Don't take it personal if a user does not understand something. And just because you understand something does not make it clear. It just makes it clear to you. But none the less, thank you for explaining the weird behavior, it was very helpful. JM The svn add only needs to be performed once so that SVN knows to begin tracking the file. Afterwards, any subsequent changes to the file will be commited. Adding a file to the repository is a change to the repository and must be indicated with the svn add. This change to the repository (the addititon) is then commited upon svn commit. Likewise, when you choose to remove a file from the repository, you must use svn rm. The deletion is then commited with svn commit. Simply removing a file from your working copy is not sufficient. Please review the Basic Work Cycle section of the SVN book for more information. http://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html
RE: subversion won’t add new files
Thanks for the links Ryan, but I've read through chapter 4. Can't say I understand through chapter 4, but reading it again will unlikely produce better results. Maybe in a couple of years. And I must mention that once you understand something you have a bias toward it, i.e. the understanding. To say it's clear does nothing to describe the state of it to someone without your knowledge. Plus it is not helpful to anyone who does not understand something to say works for me. That is borderline combative and creates a rift threatening further understanding. I apologize if I took your comment wrong but it's important to me to help you to improve your comments. You can ignore me and that’s fine, I don't mind. But if I see an unuseful comment from someone who may wish to make only useful comments and I don't help them then its shame on me. And I would like to help with the book. I don't believe I am at a level to do that properly yet. I have a long way to go. JM -Original Message- From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] Sent: Wednesday, September 24, 2014 12:41 PM To: John Maher Cc: Subversion Users Subject: Re: subversion won’t add new files On Sep 24, 2014, at 11:14 AM, John Maher wrote: Thanks for your reply. Not sure why you wish to post opinions or think it's clear when the book says Send changes from your working copy to the repository when I make a change in my working copy and it is ignored. Don't take it personal if a user does not understand something. And just because you understand something does not make it clear. It just makes it clear to you. But none the less, thank you for explaining the weird behavior, it was very helpful. Tone is not always easy to infer in email, but I'm not taking anything personally. I am just a Subversion user, just like you; this list is for Subversion users to help other Subversion users use and understand the software. In my case, I have about 10 years of experience using Subversion, which is why I mentioned my opinions about the tool and its documentation. I understand you're frustrated that the tool isn't working the way you expected, which is why I wanted to give you the benefit of my experience to let you know that Subversion is in fact a quality tool, but like other complex software, it is important to understand how it works, which is what the Subversion Book and other documentation (and this list) are there to help you with. The passage you quoted, Send changes from your working copy to the repository, is from Chapter 9 of the book: http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.commit.html This is a very late section of the book, supposed to give you a quick reminder of specific commands, after you've already learned how to use the tool; it's not an appendix though it might as well be. To learn how to use the tool, read the earlier chapters of the book, such as Chapter 1: Fundamental Concepts and Chapter 2: Basic Usage. http://svnbook.red-bean.com/en/1.7/svn.basic.html http://svnbook.red-bean.com/en/1.7/svn.tour.html Hopefully this will give you a good understanding of how to use Subversion effectively and you'll come to enjoy using it as much as I do. You can also send feedback about the book to its authors; their contact information is on the book's main page: http://svnbook.red-bean.com
RE: [svn exception]
Not everyone can see pictures in their e-mail so you will need to paste the text. From: 屈彬 [mailto:464128...@qq.com] Sent: Friday, September 19, 2014 10:42 AM To: users Subject: [svn exception] [cid:image001.jpg@01CFD402.32F4A270] can you help me? I am Chinese，Think you！
RE: SVN Book Site Down (UNCLASSIFIED)
I was getting that page but I can get to the book now. Try it tomorrow, maybe the DNS server that you are using needs to be updated? I don't know how they block it and why some can get it while others can not. JM -Original Message- From: Weeks, Shawn C CTR (US) [mailto:shawn.c.weeks2@mail.mil] Sent: Tuesday, September 16, 2014 3:02 PM To: Ryan Schmidt Cc: Subversion Users Subject: RE: SVN Book Site Down (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE This is what I get when I access it. I'm on a military installation if it matters but I'm not sure how it would make that happen. Thanks Shawn Weeks Brockwell Technologies Supporting LOGSA LITeS 256-955-0779 -Original Message- From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] Sent: Monday, September 15, 2014 6:02 PM To: Weeks, Shawn C CTR (US) Cc: Subversion Users Subject: Re: SVN Book Site Down (UNCLASSIFIED) On Sep 15, 2014, at 11:16 AM, Weeks, Shawn C CTR (US) wrote: Not sure who to report this to but svnbook.com is down due to some registrar issues. It's working for me. If it's still down for you, you can get to the site at: http://svnbook.red-bean.com Their contact information is there. Classification: UNCLASSIFIED Caveats: NONE
RE: Merge problem
I sent lots of details. If you can't see them then perhaps something is buggy with the help system. The conflicts were either local add, incoming add upon merge or local delete, incoming delete upon merge -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Wednesday, September 10, 2014 7:32 AM To: Andreas Tscharner Cc: John Maher; Subversion help Subject: Re: Merge problem On Wed, Sep 10, 2014 at 10:56:42AM +, Andreas Tscharner wrote: [snip] Just wondering if anyone may have an idea how my repository got so buggered up. I tried to merge a branch to the trunk and received 49 conflicts. 2 are files that do not need to be tracked so that leaves 47. Out of the 47 there are two problems, local add, incoming add upon merge local delete, incoming delete upon merge. I was doing some code cleanup so it is possible I deleted the files in two different branches. But I know for certain that I did not create the same file twice. I did a diff on the first one and it is identical in both branches, easy to fix, difficult to determine how the conflict came about. The second file is different, I deleted dome code that is not needed anymore. More work to fix. With the conflict it causes the merge to fail thus making this much more time consuming to fix. The question I have is I don't want to offend anyone here, but such bogus merge conflicts were the reason we changed to git. Apples and oranges. anyone know what I could’ve done to create these false conflicts? Not to my knowledge... Did you ask for help on this list when you got similar conflicts? Any pointers to threads I could read? I'm genuinly interested in what conflicts you were seeing and how you attempted to resolve them. But I need details, handwavy statements won't help me.
RE: Merge problem
Thanks for your reply Stefan. There are no subdirs on either my trunk or branches. The command I used was (from the working copy of (for example) https://server/svn/erp/trunk) svn merge https://server/svn/erp/branches/feature. -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Wednesday, September 10, 2014 4:24 AM To: John Maher Cc: Subversion help Subject: Re: Merge problem On Tue, Sep 09, 2014 at 06:48:31PM +, John Maher wrote: Hello Just wondering if anyone may have an idea how my repository got so buggered up. I tried to merge a branch to the trunk and received 49 conflicts. 2 are files that do not need to be tracked so that leaves 47. Out of the 47 there are two problems, local add, incoming add upon merge local delete, incoming delete upon merge. I was doing some code cleanup so it is possible I deleted the files in two different branches. But I know for certain that I did not create the same file twice. I did a diff on the first one and it is identical in both branches, easy to fix, difficult to determine how the conflict came about. The second file is different, I deleted dome code that is not needed anymore. More work to fix. With the conflict it causes the merge to fail thus making this much more time consuming to fix. The question I have is anyone know what I could've done to create these false conflicts? What are the parameters you used to run this merge? At first glance this looks like your merge source and target are at non-corresponding levels in the tree, e.g. as if you merged from ^/branches/mybranch to ^/trunk/some/subdir/of/trunk Result of the merge: --- Merging r222 through r235 into '.': C RotairAO_SupplierManufacturer\SupplierManufacturerTranslate.vb C RotairAO_SupplierManufacturer\SupplierManufacturerController.vb C IntuitiveUI_ItemCard_CUSTOM\CopyItem.vb C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.resx C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.designer.vb C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.vb C IntuitiveUI_ItemCard_CUSTOM\ItemCard.resx C IntuitiveUI_ItemCard_CUSTOM\CopyItem.resx C IntuitiveUI_ItemCard_CUSTOM\ItemCard.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\CopyItem.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\ItemCard.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.resx C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.resx C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.resx AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.resx AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.Designer.vb AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.vb C RotairUI_SupplierManufacturer\app.config C Rotair_Excel\Schema.resx C Rotair_Excel\Schema.Designer.vb C Rotair_Excel\Schema.vb C RotairAO_RFQ\RFQVendorCharge.vb ARotairAO_RFQ\RFQImaging OLD.vb C RotairAO_RFQ\RFQVendorQuote.vb C RotairAO_RFQ\RFQImagingController.vb ARotairAO_RFQ\RFQUnindexed OLD.vb C RotairAO_RFQ\RFQsEmailed.vb C RotairAO_RFQ\RFQUnindexedController.vb C RotairAO_RFQ\RFQMaster.vb C RotairAO_RFQ\RFQVendor.vb C RotairAO_RFQ\RFQItemQuantity.vb C RotairAO_RFQ\RFQItem.vb C RotairAO_RFQ\IO.vb C Rotair_System\File.vb --- Merging r222 through r235 into 'RotairUI_Email': C RotairUI_Email\NewMessage.Designer.vb C RotairUI_Email\NewMessage.vb C RotairUI_Email\NewMessage.resx --- Merging r222 through r235 into '.': C RotairUI_RFQ\UnenteredVendorDialog.resx C RotairUI_RFQ\Resources C RotairUI_RFQ\UnenteredVendorDialog.Designer.vb C RotairUI_RFQ\UnenteredVendorDialog.vb C RotairUI_RFQ\RotairUI_RFQ.vbproj.user C RotairUI_RFQ\RotairUI_RFQ.suo C RotairDataAccess\DomainWorkOrder.vb C RotairDataAccess_Wrapper\DomainShipping.vb C RotairDialog_Screening\SelectVendor.Designer.vb C RotairDialog_Screening\SelectVendor.vb C RotairDialog_Screening\SelectVendor.resx --- Recording mergeinfo for merge of r222 through r235 into '.': U . --- Recording mergeinfo for merge of r222 through r235 into 'RotairUI_Email': U RotairUI_Email Summary of conflicts: Tree conflicts: 49 Status of the files: C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.vb local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 C IntuitiveUI_ItemCard_CUSTOM\ItemCard.resx local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 C IntuitiveUI_ItemCard_CUSTOM\CopyItem.resx local add, incoming add upon merge Summary of conflicts: Tree
RE: Merge problem
Thanks Stefan, I found the problem, it was me. First off I am the only developer here, so I suspected I did something. I also try to leave meaningful comments which helped out in this case. After reading the comments produced by the log command I remember seeing some files that subversion 'forgot' to add. I do not know why it decided not to add them but now I remember adding them and feeling déjà-vu. I presumed it was just too much whiskey on the holiday weekend. Add to that the fact I have had other problems with subversion I guessed incorrectly that something was wrong. But with the log command I see a record of me adding the files with a comment and doing the same thing a week later with a different but similar comment. So I believe the messages from the merge command are accurate. And since I made the branch from a trunk missing files the branch naturally was missing the same files. Not sure why they never got added in the first place, but thanks for your help. I think I will punish the perpetrator and send them home early! -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Thursday, September 11, 2014 2:09 PM To: John Maher Cc: Subversion help Subject: Re: Merge problem On Thu, Sep 11, 2014 at 11:56:22AM +, John Maher wrote: Thanks for your reply Stefan. There are no subdirs on either my trunk or branches. The command I used was (from the working copy of (for example) https://server/svn/erp/trunk) svn merge https://server/svn/erp/branches/feature. OK, that's fine. So you're merging from the branch into the trunk, right? Perhaps the merge is merging changes which have been previously merged into the trunk but not recorded as merged in mergeinfo? E.g. if a revsision between r222 and r235 added the file RotairAO_SupplierManufacturer\SupplierManufacturerTranslate.vb on your branch, and the trunk already merged that revision from your branch -- but mergeinfo claims this was not the case -- then I would expect the conflict you are seeing. The question is then, how come the change was merged but not recorded? Did the person doing the merge forget to commit the svn:mergeinfo property changes, perhaps? Another possiblity is that the same file was added on the trunk independently, i.e. not via a merge operation, but for some other reason. Can you trace back the history of this file both on your branch and the trunk with 'svn log' to see how they came into existence? -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Wednesday, September 10, 2014 4:24 AM To: John Maher Cc: Subversion help Subject: Re: Merge problem On Tue, Sep 09, 2014 at 06:48:31PM +, John Maher wrote: Hello Just wondering if anyone may have an idea how my repository got so buggered up. I tried to merge a branch to the trunk and received 49 conflicts. 2 are files that do not need to be tracked so that leaves 47. Out of the 47 there are two problems, local add, incoming add upon merge local delete, incoming delete upon merge. I was doing some code cleanup so it is possible I deleted the files in two different branches. But I know for certain that I did not create the same file twice. I did a diff on the first one and it is identical in both branches, easy to fix, difficult to determine how the conflict came about. The second file is different, I deleted dome code that is not needed anymore. More work to fix. With the conflict it causes the merge to fail thus making this much more time consuming to fix. The question I have is anyone know what I could've done to create these false conflicts? What are the parameters you used to run this merge? At first glance this looks like your merge source and target are at non-corresponding levels in the tree, e.g. as if you merged from ^/branches/mybranch to ^/trunk/some/subdir/of/trunk Result of the merge: --- Merging r222 through r235 into '.': C RotairAO_SupplierManufacturer\SupplierManufacturerTranslate.vb C RotairAO_SupplierManufacturer\SupplierManufacturerController.vb C IntuitiveUI_ItemCard_CUSTOM\CopyItem.vb C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.resx C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.designer.vb C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.vb C IntuitiveUI_ItemCard_CUSTOM\ItemCard.resx C IntuitiveUI_ItemCard_CUSTOM\CopyItem.resx C IntuitiveUI_ItemCard_CUSTOM\ItemCard.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\CopyItem.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\ItemCard.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.resx C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.resx C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.Designer.vb C IntuitiveUI_ItemCard_CUSTOM
Merge problem
Hello Just wondering if anyone may have an idea how my repository got so buggered up. I tried to merge a branch to the trunk and received 49 conflicts. 2 are files that do not need to be tracked so that leaves 47. Out of the 47 there are two problems, local add, incoming add upon merge local delete, incoming delete upon merge. I was doing some code cleanup so it is possible I deleted the files in two different branches. But I know for certain that I did not create the same file twice. I did a diff on the first one and it is identical in both branches, easy to fix, difficult to determine how the conflict came about. The second file is different, I deleted dome code that is not needed anymore. More work to fix. With the conflict it causes the merge to fail thus making this much more time consuming to fix. The question I have is anyone know what I could've done to create these false conflicts? Result of the merge: --- Merging r222 through r235 into '.': C RotairAO_SupplierManufacturer\SupplierManufacturerTranslate.vb C RotairAO_SupplierManufacturer\SupplierManufacturerController.vb C IntuitiveUI_ItemCard_CUSTOM\CopyItem.vb C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.resx C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.designer.vb C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.vb C IntuitiveUI_ItemCard_CUSTOM\ItemCard.resx C IntuitiveUI_ItemCard_CUSTOM\CopyItem.resx C IntuitiveUI_ItemCard_CUSTOM\ItemCard.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\CopyItem.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\ItemCard.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.resx C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.resx C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.Designer.vb C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.vb C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.resx AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.resx AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.Designer.vb AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.vb C RotairUI_SupplierManufacturer\app.config C Rotair_Excel\Schema.resx C Rotair_Excel\Schema.Designer.vb C Rotair_Excel\Schema.vb C RotairAO_RFQ\RFQVendorCharge.vb ARotairAO_RFQ\RFQImaging OLD.vb C RotairAO_RFQ\RFQVendorQuote.vb C RotairAO_RFQ\RFQImagingController.vb ARotairAO_RFQ\RFQUnindexed OLD.vb C RotairAO_RFQ\RFQsEmailed.vb C RotairAO_RFQ\RFQUnindexedController.vb C RotairAO_RFQ\RFQMaster.vb C RotairAO_RFQ\RFQVendor.vb C RotairAO_RFQ\RFQItemQuantity.vb C RotairAO_RFQ\RFQItem.vb C RotairAO_RFQ\IO.vb C Rotair_System\File.vb --- Merging r222 through r235 into 'RotairUI_Email': C RotairUI_Email\NewMessage.Designer.vb C RotairUI_Email\NewMessage.vb C RotairUI_Email\NewMessage.resx --- Merging r222 through r235 into '.': C RotairUI_RFQ\UnenteredVendorDialog.resx C RotairUI_RFQ\Resources C RotairUI_RFQ\UnenteredVendorDialog.Designer.vb C RotairUI_RFQ\UnenteredVendorDialog.vb C RotairUI_RFQ\RotairUI_RFQ.vbproj.user C RotairUI_RFQ\RotairUI_RFQ.suo C RotairDataAccess\DomainWorkOrder.vb C RotairDataAccess_Wrapper\DomainShipping.vb C RotairDialog_Screening\SelectVendor.Designer.vb C RotairDialog_Screening\SelectVendor.vb C RotairDialog_Screening\SelectVendor.resx --- Recording mergeinfo for merge of r222 through r235 into '.': U . --- Recording mergeinfo for merge of r222 through r235 into 'RotairUI_Email': U RotairUI_Email Summary of conflicts: Tree conflicts: 49 Status of the files: C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.vb local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 C IntuitiveUI_ItemCard_CUSTOM\ItemCard.resx local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 C IntuitiveUI_ItemCard_CUSTOM\CopyItem.resx local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 C IntuitiveUI_ItemCard_CUSTOM\ItemCard.Designer.vb local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 C IntuitiveUI_ItemCard_CUSTOM\CopyItem.Designer.vb local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 C IntuitiveUI_ItemCard_CUSTOM\ItemCard.vb local add, incoming add upon merge Summary of conflicts: Tree conflicts: 1 ! C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.Designer.vb local delete, incoming delete upon merge Summary of conflicts: Tree conflicts: 1 ! C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.vb local delete, incoming delete upon merge Summary of conflicts: Tree conflicts: 1 ! C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.resx
global ignores
Hello I am trying to get subversion to ignore certain files and directories on a windows system. I am using a windows 7 machine with a 1.7 subversion client. My repository has about 40 projects in it and I want to ignore bin and obj directories along with *.sou and *.user files. I seemed like it was working but it is acting strangely. I just recently rebuilt my machine, but a project I added prior to the rebuild is only half correct, the folders are being ignored but not the files. The files are stored on a network drive and I issued svn proplist -R and do not see any ignores in the list. I saw somewhere that I can edit the config file in this folder C:\Documents and Settings\[username]\Application Data\Subversion, but this directory is inaccessible. I went to %Appdata% and found a config file there. So I tried to edit it, however I can find no information on how to properly edit it. I saw # global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo I tried # global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.sou And # global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo global-ignores = *.sou But everytime I issue a svn status I still see the files. I do not know if status ignores the ignore list and it is just for committing or if I am editing the right file. Nor do I know if a reboot is needed before the changes take effect, I tried that once but I can be here for hours with all the unknowns. Anyone have any idea? JM
RE: global ignores
Thanks Mark, that did it. JM From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, September 08, 2014 1:18 PM To: John Maher; users@subversion.apache.org Subject: Re: global ignores Please keep users@ involved. On Mon, Sep 8, 2014 at 1:07 PM, John Maher jo...@rotair.commailto:jo...@rotair.com wrote: Thanks Mark. Could you be a little more specific? Like look at what and where. I’ve been looking at all kinds of stuff and reading many, many posts but nothing is clear. I do not have any specific suggestion, just that if you see a ? then that means the file should be ignorable if the settings are right. For example, what is a comment in the config file. Many places it talks about comments but nowhere does it explain what a comment is. I see lines starting with # and lines starting with ###. Are all of those comments or just the ###? It is clear that the lines with ### are comments but is subversion reading the lines with # or are they comments also? Any line that starts with # is a comment. On Windows, open the Run dialog and enter %APPDATA%\Subversion and press ENTER. Then edit the file named config with a text editor. The default value for this option is: [miscellany] ### Set global-ignores to a set of whitespace-delimited globs ### which Subversion will ignore in its 'status' output, and ### while importing or adding files and directories. global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store Make sure your text editor does not change the filename or save it with a file extension added. If you are using TortoiseSVN, I recall their Settings dialog also provides access to this. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: How to display the code in my branch without merge changes?
Can you explain what you mean by current version. When you merge from the trunk you change the current version. So the current version and all versions afterward include the merged changes. Do you mean a version BEFORE the merge? You can pass a revision to the diff command to get the one you want. From: Gabriela Gibson [mailto:gabriela.gib...@gmail.com] Sent: Tuesday, October 15, 2013 7:24 AM To: users@subversion.apache.org Subject: How to display the code in my branch without merge changes? My goal is to get svn to show the current version of my code, without the merged changes added from trunk. I've tried a lot of different approaches by now (as advertised in svn help diff), but nothing seems to do the trick. thanks for any advice, Gabriela
Branch changes
Is there a way to find out all the files that changed since a branch was created? Thanks John
RE: Branch changes
Thanks Andrew. That is an even better way to get the version than the way I found. -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, October 08, 2013 11:00 AM To: John Maher Cc: Subversion help Subject: RE: Branch changes -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, October 08, 2013 10:14 AM To: Andy Levy Cc: Subversion help Subject: RE: Branch changes Thanks for your reply Andy, that was helpful. For anyone else interested, to get the revision where the branch was created you can do this: svn log --verbose --stop-on-copy URL_TO_BRANCH The last line indicates what revision the branch was created. Unless, of course, you renamed your branch, e.g. 'svn mv rel-1.2 rel-2.0', or if you renamed/moved the parent directory components, e.g. 'svn mv /branches /project1/branches' in which case you will need to run the 'svn log --stop-on-copy -r REV-1' iteratively (where 'REV-1' is the revision returned by --stop-on-copy minus 1,) until you get to the real branch point. /pedantic Also, if you want 'svn log --stop-on-copy' to return just a single revision, you can use --limit thusly: svn log -v -r1:HEAD --stop-on-copy --limit 1 ^/branches/my_branch
RE: Switching
Hello Can you provide me with a link as to how to apply this patch? When I search for applying a subversion patch all I get is stuff involving svn diff. I think the patch may be safer than using --force with switch for which all the ramifications I do not even know. -Original Message- From: Travis Brown [mailto:trav...@travisbrown.ca] Sent: Saturday, August 24, 2013 5:58 PM To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; d...@subversion.apache.org; John Maher Subject: Re: Switching On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed: On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote: That's just overcomplicating the issue. This doesn't even need to become a tree conflict. In my opinion it does need to be flagged as a conflict. Because we don't know what the contents of the incoming directory will be nor what the user may eventually want to do to resolve the problem. Making the unversioned directory versioned is just one possible options among several. See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about. John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it. Now I'll address Branko's points directly in a tedious fashion. You're assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. This goes further than this patch attempts. This patch only says I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling in this hierarchy as if I created this directory. Significantly, this patch doesn't change anything about how _files_ within this hierarchy are dealt with. If you have an unversioned _file_ within the directory with the same name as in incoming versioned object then you still get a tree conflict as you would in a similar situation without an incoming directory. [As an aside a merge conflict is superior in every case to a tree conflict. It would be useful if some other patch changed this case from a tree conflict to a merge conflict where svn didn't try to merge anything, but only gives you the Theirs, Mine, Edit (and equivalent) options. But that's a separate discussion.] It actually gets worse, because following your proposal, Subversion will happily recurse in the same way into src and test -- the final result being an unholy mess that you're going to have a fine time untangling, not to mention that you just messed up the poor user's unversioned local changes. As noted above this patch doesn't modify _anything_ local in any way which is not obviously reversible. The existing directory has no permissions or properties changed. No existing files are modified at all. The directory now contains files it didn't originally, but svn will tell you which files were originally there since they are either unversioned or in the conflict state. And of course, all of the above is not specific to switch -- but also to update, when there are no branches
RE: Switching
Thanks Travis. I thought this was a binary patch, not a source code patch. Now I realize that since subversion gets compiled into a variety of executables a binary patch can not be done. I do not wish to compile subversion. I have found that --force works and I only need it if switching to a branch that has any new libraries. Switching away from that type of branch works fine. -Original Message- From: Travis Brown [mailto:trav...@travisbrown.ca] Sent: Monday, August 26, 2013 2:58 PM To: John Maher Cc: Subversion Subject: Re: Switching On Mon, Aug 26, 2013 at 01:31:49PM +, John Maher claimed: Hello Can you provide me with a link as to how to apply this patch? When I search for applying a subversion patch all I get is stuff involving svn diff. I think the patch may be safer than using --force with switch for which all the ramifications I do not even know. It's a patch you need to apply to the Subversion source code before building it. On a Unix-like system the following steps are what I do: daredevil:~/temp $ tar -jxf subversion-1.8.1.tar.bz2 daredevil:~/temp $ cd subversion-1.8.1 daredevil:#emp/subversion-1.8.1 $ patch -p1 ../local_unversioned_dir-incoming_add_dir.patch patching file subversion/libsvn_wc/update_editor.c Hunk #1 succeeded at 2249 (offset -1 lines). daredevil:#emp/subversion-1.8.1 $ You would then go ahead and build Subversion as normal for whatever platform(s) you are on. Unfortunately I cannot provide any guidance on how to accomplish this with a packaging system such as RPM or on Windows. If you don't have existing infrastructure and procedures to install and update software installed from source then this patch may be a greater maintenance headache than it's worth. -- Travis -Original Message- From: Travis Brown [mailto:trav...@travisbrown.ca] Sent: Saturday, August 24, 2013 5:58 PM To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; d...@subversion.apache.org; John Maher Subject: Re: Switching On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed: On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote: That's just overcomplicating the issue. This doesn't even need to become a tree conflict. In my opinion it does need to be flagged as a conflict. Because we don't know what the contents of the incoming directory will be nor what the user may eventually want to do to resolve the problem. Making the unversioned directory versioned is just one possible options among several. See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml I read that and I still wrote and posted the patch because the arguments there bear no relation to what _this_ patch does. That post does a fine job describing a few challenges for what a more complete system would do. This patch just makes the ratchet not cut the user's knuckles when they reverse direction, it isn't the fully automated manufacturing plant most of this thread seem to be talking about. John, before I go onto to exhaustively say my final piece on this matter, you have my patch[0] which I believe makes your use case work. If you have the resources to run an otherwise standard SVN binary with this patch applied I would consider doing it. Now I'll address Branko's points directly in a tedious fashion. You're assuming it is correct, in all cases, to silently make a directory versioned because the incoming directory happens to have the same name. It is not. It may be marginally correct in your case, however, Subversion has no way of knowing that the unversioned directory it sees is in any way related to whatever is on the switched branch. It needs user input; it cannot magically become smart enough. This thinking is much higher level and trying to do much more than this patch. This patch doesn't attempt to deal with trying to merge the existing unversioned file hierarchy and the incoming version object hierarchy. It merely avoids unnecessary tree conflicts on directories in _one_ specific case. The general problem is hard, but this is not the general problem. For example, consider a typical Java module which has build.xml file and two directories, src and test. You add such a module called A on the branch. Someone else creates a completely different and unrelated module in their working copy, incidentally also calling it A. Then they switch to the branch. What happens? You're proposing that Subversion would say, Oh, this unversioned thing I have here is also called A, I'm going to assume its the same as the incoming directory, let's make it so. And in the next step: Oh, I have an unversioned file called build.xml, I'll just assume it's the same as the incoming and merge changes in boom, instant merge conflict. This goes further than this patch attempts. This patch only says I see you have an existing directory called A. I won't make you move/delete it, instead I'll just continue on filling
RE: Switching
I will try to explain one more time. The files in question are settings files (think config files) and intermediate compilet generated files. The settings files can be recreated at any time. If they are wrong the only thing affected is the development environment. The other files get recreated every time the code is run, plus they never get into production. So they 1) could be recreated any time at will with the versioned code files and 2) they will never be in production anyway. Don't read more than what is stated otherwise you have a chance of being wrong and wasting time. Someone was claiming the files are important which I never stated. I didn't even respond to the mail since it was erroneous and irrelevant. The real reason I responded is the force option eliminates the conflict but creates some questions. The documentation says using it will make sure unversioned obstructiong paths do not cause a failure. Could that also be written as unversioned obstructiong paths do not cause a conflict? Or is there some other kind of failure that I do not know about. The problem this fixes displays as Local unversioned, incoming add upon switch which is the result of a switch. The revert command fails to bring my working copy back to its unconflicted state. Switching back also fails. The question is can I bring back my working directory from a failed switch (I'm talking undo, not resolve) so I can use the force option or must I always use the force option to be able to switch branches? Have a good weekend JM -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 5:17 PM To: John Maher Cc: Edwin Castro; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 1:34 PM, John Maher jo...@rotair.com wrote: Again Les, you misunderstand. I have no problems with the workspace. It is exactly the same for everyone, everytime. Please read carefully before you respond. It has nothing to do with the build. It is user settings, a config file, ini file, choose your terminology. If you don't understand please ask for clarification instead of making incorrect assumptions. The contents of the file are irrelevant. The point is that it has to either be versioned so svn can delete it knowing that you can get it back, and then delete the containing directory that is really the issue, or you have to delete it yourself. Pick one. If it really is always the same, I don't see the problem with committing it. If it isn't, and you need to reproduce it, you need to work out a way to do that, or use the multiple-checkout approach to maintain dirty workspaces, realizing that you can't reproduce them reliably. Personally, I don't like things that rely on any unversioned state getting into production releases. That developer will leave or that machine will crash and all the magic is gone - and if you can't do a matching build on a clean machine from a clean checkout, you won't ever know how much magic was involved. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
Good to know, thank you. -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, August 23, 2013 12:50 PM To: Edwin Castro Cc: users@subversion.apache.org Subject: Re: Switching On Fri, Aug 23, 2013 at 09:24:52AM -0700, Edwin Castro wrote: I think the mailing list has already said the *best* way to use switch is to have a clean working copy (clean out all ignored and unversioned files which is admittedly inconvenient). This won't help right now, but cleaning out such items will be easier in Subversion 1.9: https://blog.elegosoft.com/?q=cleaning-up-svn-cleanup
RE: Switching
Thanks for your replies Andrew and Thorsten. @Andrew there is no need for a svn copy. I do not want to copy a feature in one branch to another; I wish to keep the code isolated. And yes I know subversion won't delete unversioned files, I appreciate the info on how subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. But it seems the only answer is a tedious and manual process for the simplest of enhancements. I was hoping to find what others seem to praise, but have continually come up empty handed. I'll check stackoverflow before I give up. Thanks anyway JM -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, August 20, 2013 4:02 PM To: John Maher; Subversion help Subject: RE: Switching -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, August 20, 2013 1:33 PM To: Andrew Reedick; Subversion help Subject: RE: Switching Thanks for your reply. I agree it does not make sense. But it is reproducible. The dir trees are NOT identical because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server. So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says local unversioned, incoming add upon switch. The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. When removing dirs, switch will not delete local/private/unversioned files. If there is a local file in a dir tree, then all the versioned files will be removed from your workspace, but a local tree will remain with the local files still in it. That's mostly likely why you see a '?' after the switch. Ex: 1. 'this_dir' exists in current workspace as a versioned dir tree. 2. 'this_dir' does NOT exist in branch P. 3. touch this_dir/hello_world.txt 3. svn switch ^/branches/P 4. svn status: ? this_dir The only file under this_dir will be hello_world.txt. All other versioned files/dirs will have been removed. Svn revert does not do anything useful. So I then issue svn resolve -- accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says local delete, incoming delete. Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. You shot yourself in the foot. =) The local copy of the dir prevented switch from running the add. (Switch wasn't able to pull in the versioned copy of the dir.) Then you didn't fix the dir conflict by manually running 'svn copy' yourself to pull in the dir from branch P. When you did the resolve, you told svn that the current state of the dir is correct, and since the current state of the dir was effectively deleted, you wound up telling svn to delete the file from branch P. Again, when resolving tree conflicts, you need to manually copy/add/delete/mv manipulate the tree into the correct state before resolving the tree conflict. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). You can recover the deleted versioned dirs and files via peg revisions. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect Then I switch to branch E. No conflict. But I won't get my hopes up yet, I still do not have the new library included which was the whole reason for creating the branch in the first place. Right. You deleted the dir from branch P. And you deleted the local/private files/tree as well. Thus no conflict with branch E. However, if you want to get the dir into branch E, then you should have merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/E/some_dir.) (But you'll need to restore the dir in branch P first via 'svn copy' and a peg revision.) So I copy over the directory and do a svn add then commit. Then I can switch to branch P. Argh
RE: Switching
Thanks for the reply Les. Actually I would call the problem the way I am using the tool. Since no one has provided a better solution there may not be one. Perhaps no one considered switching between branches where there could exist a directory with unversioned files in one and not the other. I don't know. Maybe no one wanted to make it work since they never needed that feature. I don't know. After reading tons of material on subversion I thought it would be good to keep development for individual features in separate branches. But the cost is easily out weighing the benefit. And one of the files I am ignoring is user settings which is required for testing. Deleting that file would just introduce more trouble causing the user to repeatedly re-enter settings to test code. The output is already directed away to a development directory. I see no way to delete the intermediate files which would get constantly re-created anyway and would not solve the problem because the user settings file would still cause the same issue. And the developers need their own settings. Before I started trying to learn the branching (which I didn't even get to yet since simply switching is causing so much grief) I would jot down on a piece of paper which projects affected which feature and do all the development in the trunk then only put in production what was needed. This worked. It just seems strange to have to keep notes on a piece of paper which modules are for which feature using source code control software. But if that's how subversion works, then that's how it works. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 11:00 AM To: John Maher Cc: Andrew Reedick; Thorsten Schöning; Subversion help Subject: Re: Switching On Thu, Aug 22, 2013 at 6:30 AM, John Maher jo...@rotair.com wrote: @Andrew there is no need for a svn copy. I do not want to copy a feature in one branch to another; I wish to keep the code isolated. And yes I know subversion won't delete unversioned files, I appreciate the info on how subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. Your problem is not so much that svn doesn't deleted the unversioned files, but that it can't delete the directory containing them. But it seems the only answer is a tedious and manual process for the simplest of enhancements. Don't your build tools have commands to remove any spurious files they've created or some equivalent of 'make clean' that you can run to remove the clutter in a non-tedious way so that svn switch is free to work correctly with the versioned content? I was hoping to find what others seem to praise, but have continually come up empty handed. I'll check stackoverflow before I give up. If the big picture is including library components and their containing directories in some versions and not others, the simple solution might be to give the components their own location in the repository (or a different one) and pull them in only as needed with svn externals. But, I think you still have to clean up the unversioned clutter so a switch can remove the directory when it is not wanted. A slightly different approach is to version the built component binaries and access them with externals, but that has its own issues in multi-platform scenarios. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
I don't think you even tried Thorsten, I can easily. There are actually several options. 1) When switching branches don't raise a conflict if all the files in the directory are in the global ignore list. And if all that exists in a directory are files to be ignored it makes logical sense to ignore the parent directory. 2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list. 3) An OK-to-delete-if-in-conflict property could be created. And I don't even know the tool well, if I knew it better I can come up with even better solutions. I'm not going to bother listing any more alternatives, there are plenty. Might as well wish I had a candy bar right now. Its OK to wish, but it won't happen. I'll bet any talented developer could come up with a solution if they tried. -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Thursday, August 22, 2013 12:21 PM To: users@subversion.apache.org Subject: Re: Switching Guten Tag John Maher, am Donnerstag, 22. August 2013 um 17:48 schrieben Sie: Actually I would call the problem the way I am using the tool. Since no one has provided a better solution there may not be one. Perhaps no one considered switching between branches where there could exist a directory with unversioned files in one and not the other. I don't know. Maybe no one wanted to make it work since they never needed that feature. I don't know. After reading tons of material on subversion I thought it would be good to keep development for individual features in separate branches. But the cost is easily out weighing the benefit. How would you like Subversion to work in your case? From my understanding it breaks down to something generated some files for some reason in one of your branches and now you want to switch form that branch to another which does not contain the base directory of the generated files. What should subversion do with your generated files it doesn't know anything about? I don't see how this problem can be solved by any tool. 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: Switching
How about just 'delete the spurious unversioned files yourself'? As I said in the previous reply, two of those files are user settings. They would have to be constantly recreated by the developer. That increases costs. One of the reasons I wanted some form of source code control was to reduce costs. Svn can't decide which of your files that it can't recreate for you should disappear. It could ignore files that it is instructed to ignore. That would help. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 1:11 PM To: John Maher Cc: Thorsten Schöning; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 11:40 AM, John Maher jo...@rotair.com wrote: I don't think you even tried Thorsten, I can easily. There are actually several options. How about just 'delete the spurious unversioned files yourself'? The problem is the versioned directory containing them that is not supposed to exist after the switch. And the only way svn can fix it for you is if you clean it up. Svn can't decide which of your files that it can't recreate for you should disappear. Getting that wrong would be much worse than presenting a conflict on the directory holding them. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
Thanks for the reply Johan. I did not get your previous mail, thanks for re-stating it. That is worth looking into. I'll see how much I have to change to allow the alternate directories. Maybe experiment keeping the trunk on the network for backup purposes and the branches local so as not to tax the backup. The costs can really increase. If an unversioned directory is in the way, Subversion has no place where to put that data. The problem isn't something in the way, the problem is something is there when nothing is expected. There is a directory in one branch but not the other. Subversion half empties it when switching to the branch without the directory. Then when switching back to the branch where the directory lives it complains that it can not add it because it is there. But that very same directory was part of the branch that is complaining that it can not add it because it is there. What I mean by ignore is that subversion properly ignored deleting the directory because it had unversioned files in it. But refused to ignore adding it. There may be a good reason for that behavior, I just find it hard to believe that I am the only one who had this problem. I'm betting that there is some unintuitive solution to this. JM -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Thursday, August 22, 2013 1:13 PM To: John Maher Cc: Thorsten Schöning; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 5:48 PM, John Maher jo...@rotair.com wrote: Actually I would call the problem the way I am using the tool. Since no one has provided a better solution there may not be one. ... Did you read my previous mail in this thread? IMO a better solution in your case is not to use switch, but use dedicated checkouts for each branch. If you have to do this often (say multiple times a day), perhaps create a small script that takes away some of the typing of 'svn co $URL/branches/X' On Thu, Aug 22, 2013 at 6:40 PM, John Maher jo...@rotair.com wrote: I don't think you even tried Thorsten, I can easily. There are actually several options. 1) When switching branches don't raise a conflict if all the files in the directory are in the global ignore list. And if all that exists in a directory are files to be ignored it makes logical sense to ignore the parent directory. What do you mean with ignore? By switching you asked Subversion to download all the data that's meant to be there. If an unversioned directory is in the way, Subversion has no place where to put that data. Do you mean SVN should just throw away your unversioned data? That would go against one of SVN's prime directives, which is to try never to destroy any unversioned data. Those unversioned files may be very important to me (even if in the global-ignores list). 2) A parameter could be passed to the switch command to ignore any directory that ends up with only files on the global ignores list. 3) An OK-to-delete-if-in-conflict property could be created. That might be possible (but this sounds *very* handwavy -- there are a lot of details in there, lots of edge cases), but that's a very dangerous flag, which makes it very much possible for people to shoot themselves in the foot. After implementing such a feature, I bet there will be more posts than yours, from people asking if they can get their data back. And I don't even know the tool well, if I knew it better I can come up with even better solutions. I'm not going to bother listing any more alternatives, there are plenty. Might as well wish I had a candy bar right now. Its OK to wish, but it won't happen. I'll bet any talented developer could come up with a solution if they tried. Perhaps, but I can't (or at least, it would take me quite a bit of my rare free time). Perhaps someone else will jump in, but if you badly want this, I think you'll have to try describing a good (detailed) behavior yourself (and be prepared to patiently answer tough questions that may arise). -- Johan
RE: Switching
Thanks for the reply Edwin. The clean up script is a good idea but won't work here. We have mostly all class libraries. One executable. This means to test we need to specify an application in the project. Some developers use the exe while some use a tool made just for testing the classes. This information is in the *.sou files which are unversioned for this reason. So we don't want to delete them (as I incorrectly stated somewhere) but ignore them. I'll try the force, that may work. I'll try it on a copy of the repository. JM -Original Message- From: Edwin Castro [mailto:0ptikgh...@gmx.us] Sent: Thursday, August 22, 2013 1:22 PM To: users@subversion.apache.org Subject: Re: Switching On 8/22/13 7:59 AM, Les Mikesell wrote: On Thu, Aug 22, 2013 at 6:30 AM, John Maher jo...@rotair.com wrote: @Andrew there is no need for a svn copy. I do not want to copy a feature in one branch to another; I wish to keep the code isolated. And yes I know subversion won't delete unversioned files, I appreciate the info on how subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. Your problem is not so much that svn doesn't deleted the unversioned files, but that it can't delete the directory containing them. But it seems the only answer is a tedious and manual process for the simplest of enhancements. Don't your build tools have commands to remove any spurious files they've created or some equivalent of 'make clean' that you can run to remove the clutter in a non-tedious way so that svn switch is free to work correctly with the versioned content? I typically run into this problem when a build output directory exists due to having built the project that doesn't exist in the other branch. Something along these lines: root/ +-- projectA/ | +-- bin/ | | +-- debug/ | | | +-- projectA.dll | | +-- release/ | | +-- projectA.dll | +-- src/ +-- projectB/ +-- bin/ | +-- debug/ | | +-- projectB.dll | +-- release/ | +-- projectB.dll +-- src/ Let's say in branch1 both projects exist but in branch2 only projectB exists. The tree above would obviously imply I am currently on branch1. I would have added the bin directory to svn:ignore on both the projectA and projectB directories as I don't want to accidentally commit the contents of the bin directory. The tree above is only an example. The branches I'm used to dealing with contain hundreds of such projects and building all of them can take up to 2 hours even on relatively fast hardware. If projectA has been built while I'm working on branch1 and I want to svn switch to branch2, then svn will attempt to delete root/projectA/ but it can't because root/projectA/bin/ still exists. The switch leaves behind root/projectA/ as unversioned (including the root/projectA/bin/ directory). Now that I'm done working with branch2 I try to svn switch back to branch1 and svn fails to add root/projectA/ because it already exists in the working copy unversioned. We have a root build script that can run the clean target on all of our projects. Alternatively, I could run clean on individual projects prior to a switch but that requires that I know which projects do not exist on the target branch. I could also use the --force argument to svn switch but it carries it's own hazards. From svn help switch: If --force is used, unversioned obstructing paths in the working copy do not automatically cause a failure if the switch attempts to add the same path. If the obstructing path is the same type (file or directory) as the corresponding path in the repository it becomes versioned but its contents are left 'as-is' in the working copy. This means that an obstructing directory's unversioned children may also obstruct and become versioned. For files, any content differences between the obstruction and the repository are treated like a local modification to the working copy. All properties from the repository are applied to the obstructing path. I'm particularly worried by This means that an obstructing directory's unversioned children may also obstruct and become versioned. You might end up committing files you don't want to commit by using svn switch --force so you'll want to be very careful. It would probably be a good idea to follow up svn switch --force with svn status to see if anything becomes versioned that shouldn't be. Even though our builds can be quite long, I typically find it much safer to simply clean all of the projects prior to performing svn switch. I typically don't use our root build script to clean the projects because it takes a long time loading up all of those different projects/solutions to run the clean target. Since I'm on Windows I use PowerShell to find all ignored and unversioned items and manually delete them: svn status
RE: Switching
I'll try to clarify, everyone has their own copy of the tool. They also have their own copy of their settings. The problem arises because the tool stores the settings files in the same folder as some code specific files. This can not be changed. So within a single directory we need to version some files and ignore others. Sure I could write a pre-processing program to do a multitude of things. It wouldn't be that hard. But then my plate has plenty of things that are not that hard. What will I gain? A happy working copy with a single command as long as what I write always works perfectly. Highly unlikely, so then I will make more problems for myself. Plus I assigned myself the task of learning subversion. Covering up a symptom does not treat the disease. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 1:30 PM To: John Maher Cc: Thorsten Schöning; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 12:15 PM, John Maher jo...@rotair.com wrote: How about just 'delete the spurious unversioned files yourself'? As I said in the previous reply, two of those files are user settings. They would have to be constantly recreated by the developer. That increases costs. One of the reasons I wanted some form of source code control was to reduce costs. So put them somewhere else or version them - and if the tool can't deal with multiple users, work out a way to script a rename the correct copy for the current user. A clever developer should be able to find an alternative to forcing subversion to keep a versioned directory in conflicting place or retyping a file to recreate it when needed... Of course if it is too much trouble to clean up the files correctly, you can just delete the whole workspace and check out again to go between the branch/trunk versions. Svn can't decide which of your files that it can't recreate for you should disappear. It could ignore files that it is instructed to ignore. That would help. How many people actually know which files subversion is ignoring? Again, a clever developer could probably come up with his own way to delete files matching some patterns if he really wants that to happen. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
This happens even if you do not do a build. There is a class library in one branch but not the other mixed with unversioned files that I can do nothing about. -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Thursday, August 22, 2013 1:48 PM To: John Maher; Johan Corveleyn Cc: Thorsten Schöning; users@subversion.apache.org Subject: RE: Switching -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Thursday, August 22, 2013 1:34 PM To: Johan Corveleyn Cc: Thorsten Schöning; users@subversion.apache.org Subject: RE: Switching The problem isn't something in the way, the problem is something is there when nothing is expected. There is a directory in one branch but not the other. Subversion half empties it when switching to the branch without the directory. Then when switching back to the branch where the directory lives it complains that it can not add it because it is there. But that very same directory was part of the branch that is complaining that it can not add it because it is there. Okay, this isn't a svn issue. This sounds more like a I did a build against trunk, switched to branch B, and then did a build of B in a dirty workspace. That's just asking for trouble in terms of build accuracy and build repeatability; it's a bad practice in general. The whole trunk, switch to B, switch back to trunk directory conflict may be an annoyance, but a 'make clean' build option or cleanup script run after the switch sounds like something that you need to implement.
RE: Switching
You are correct that there will be issues with a fresh checkout. But I can live with that. The code will not be affected, just the way the code is tested. Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it. Think config or settings file. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 1:53 PM To: John Maher Cc: Edwin Castro; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 12:43 PM, John Maher jo...@rotair.com wrote: The clean up script is a good idea but won't work here. We have mostly all class libraries. One executable. This means to test we need to specify an application in the project. Some developers use the exe while some use a tool made just for testing the classes. This information is in the *.sou files which are unversioned for this reason. So we don't want to delete them (as I incorrectly stated somewhere) but ignore them. You are sort-of asking for trouble if you have any dependency on unversioned files being in a workspace at all, much less for them to continue to exist when switching among versions with/without the containing directories. I'd advise stepping back from the immediate problem and thinking of processes that will always work with a fresh checkout so that in the future you can use build automation tools like jenkins, relying only on the contents of the repository even when the build happens on a new host. It will simply your life even for manual operations if you can count on that. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
Again Les, you misunderstand. I have no problems with the workspace. It is exactly the same for everyone, everytime. Please read carefully before you respond. It has nothing to do with the build. It is user settings, a config file, ini file, choose your terminology. If you don't understand please ask for clarification instead of making incorrect assumptions. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Thursday, August 22, 2013 2:28 PM To: John Maher Cc: Edwin Castro; users@subversion.apache.org Subject: Re: Switching On Thu, Aug 22, 2013 at 12:58 PM, John Maher jo...@rotair.com wrote: You are correct that there will be issues with a fresh checkout. But I can live with that. Not caring if you can reproduce a workspace is a bold statement to make on a version control mail list. Don't be surprised if everyone doesn't agree with that choice. The code will not be affected, just the way the code is tested. Once the developer decides on how they wish to test I do not want to A) lose those changes or B) step on the choices others have made by versioning it. If this is preliminary testing, maybe that's OK. If it is the whole story, I'd want it to be reproducible. Think config or settings file. Think build automation where you'd want to be able to reproduce these on demand, not just rely on what happens to still live in the current filesystem. It might take a one-time effort to find the files and decide how to handle them (renamed versioned copies, templates, moved local copies, etc.) but then aside from being able to switch among banches, you can reproduce a usable working copy. -- Les Mikesell lesmikes...@gmail.com
RE: Switching
Thanks for your reply. I agree it does not make sense. But it is reproducible. The dir trees are NOT identical because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server. So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says local unversioned, incoming add upon switch. The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. Svn revert does not do anything useful. So I then issue svn resolve --accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says local delete, incoming delete. Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). Then I switch to branch E. No conflict. But I won't get my hopes up yet, I still do not have the new library included which was the whole reason for creating the branch in the first place. So I copy over the directory and do a svn add then commit. Then I can switch to branch P. This is where the problem arises. Subversion deletes the files but not the directory because it contains files that do not belong in subversion. I have no control over this as the compiler puts them there. They are on the global ignore list. Now when I switch the conflict returns. Nothing in the book explains how to handle this. Searching comes up with all kinds of irrelevant stuff and unanswered questions. My question is how to properly handle this? Or is branching unusable in this situation with out the extra hassle? Thanks JM -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, August 20, 2013 10:17 AM To: John Maher; Subversion help Subject: RE: Switching From: John Maher [mailto:jo...@rotair.com] Sent: Monday, August 19, 2013 1:31 PM To: Subversion help Subject: Switching Hello, I want to thank all who have been helpful. I have gotten my test project to merge branches successfully. Now I am trying it on our production code and wish to make sure I am not making any mistakes. I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory. I have created two branches for two new features. One feature extends an existing library. The other feature adds a new library as well as extending an existing one. When I switch I create a conflict because the directory exists in one branch and not the other: That doesn't make sense. If you branched (i.e. created copies of a baseline) then the dir trees should be identical. Extending/modifying the library (adding new dirs) shouldn't create a conflict for svn switch, unless you modified the same directory tree/structure in the workspace's branch and in the branch you're switching too. This happens if you 'svn add' the same dir in both branches. Example: Bad, causes conflict: svn add ^/branches/foo/new_dir svn add ^/branches/bar/new_dir Good: Svn add ^/branches/foo/new_dir cd to bar workspace; svn copy ^/branches/foo/new_dir . It could also happen if you renamed/moved the same dir in both branches. local unversioned, incoming add upon switch This sounds like you have a normal, unversioned directory in the workspace. As part of the switch, svn wants to add a versioned dir of the same name to your workspace. You should be able to rename the local normal dir to a new name in order to let the add operation be run unimpeded. I would 'svn revert -R' the entire workspace[1], rename the normal, local dir, and re-run the switch. And figure out why you have a normal, unversioned copy of the dir in the first place. This may or may not be what is supposed to happen, that would be the first thing I would like to know. How to fix it would be the second thing that I would like to know. According to the help
Switching
Hello, I want to thank all who have been helpful. I have gotten my test project to merge branches successfully. Now I am trying it on our production code and wish to make sure I am not making any mistakes. I use one folder for my source code (all branches) mainly because of vendor requirements the code must be run from the same directory. I have created two branches for two new features. One feature extends an existing library. The other feature adds a new library as well as extending an existing one. When I switch I create a conflict because the directory exists in one branch and not the other: local unversioned, incoming add upon switch This may or may not be what is supposed to happen, that would be the first thing I would like to know. How to fix it would be the second thing that I would like to know. According to the help of the resolve command says: So I tried svn resolve -accept working LibraryDirectory but I believe that was a mistake because then the directory was marked Delete which is not what I wanted. Does anyone know what is the proper response? I did not want to lose the library from the working copy so I switched back to the other branch and then switch back. Now it says: local delete, incoming delete upon switch It seems I did something wrong. My next step would be to add the library back, but that may not be the best response. Any suggestions? Thanks JM
RE: Strange behavior
Thanks Bob. You have been very helpful. I didn't know that there was an html version of the book. I've been using the pdf version and haven't found a way to search that. The global ignores worked. Now I'm on to my third repository. I hate having to lose all the history I'm accumulated, but that's how it goes. Thanks again. JM -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, August 12, 2013 3:33 PM To: John Maher; 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. 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
Thanks David. For the past week and a half I've been wrestling with this thing. Searching, reading, trying, back to searching. Time to switch gears but I needed to get over this hurdle. I'm now on the second repository I have to dispose of (and all the history with it) so I hope the 3rd time's the charm. Thanks again JM -Original Message- From: David Chapman [mailto:dcchap...@acm.org] Sent: Monday, August 12, 2013 3:49 PM To: John Maher Cc: users@subversion.apache.org Subject: 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
An excellent alternative. I will keep this in mind.
Thanks Andrew
JM
-Original Message-
From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net]
Sent: Monday, August 12, 2013 3:52 PM
To: John Maher; users@subversion.apache.org
Subject: 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
Thanks Mark, that's an excellent shortcut. JM -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, August 12, 2013 4:05 PM To: John Maher Cc: Bob Archer; Edwin Castro; users@subversion.apache.org Subject: 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
Hi Thorsten A good response to a less than good post. People could take lessons from you. Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening. I got a good laugh from: Of course it can, just copy your 200 commands line by line one after another into a batch file. JM -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Monday, August 12, 2013 4:43 PM To: users@subversion.apache.org Subject: 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: Strange behavior
One thing I forgot to mention is that yes, I know of Tortoise. I started with that. It works good for the most commonly used stuff, but falls short as a complete solution. So I really need to know how the real tool works. That is why I am struggling with the command line. JM -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Monday, August 12, 2013 4:43 PM To: users@subversion.apache.org Subject: 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: Strange behavior
Thanks Johan, I'll have to try it. -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, August 13, 2013 11:42 AM To: John Maher Cc: Ryan Schmidt; Subversion Users Subject: Re: Strange behavior On Tue, Aug 13, 2013 at 4:12 PM, John Maher jo...@rotair.com wrote: Thanks Ryan. I learned a lot from your reply. Namely the global-ignores are really local global-ignores and I have to copy the config file over to anyone who may import. As of version 1.8 (for the svn client), there is a new feature called Repository Dictated Configuration [1], which you can use to set a global-ignores that will be applied by all standard 1.8 clients. It works by setting an svn:global-ignores property on a directory in your repository, which then applies to the entire subtree under that directory. However, I'm not sure if that feature applies to 'svn import' (because it doesn't have a working copy). I guess someone will have to try it :-). [1] http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config -- Johan
RE: Strange behavior
Thanks Andrew, I started going through your steps and discovered something. My repository is called either iERP85_v2 or iERP85_V2. Visual SVN reports the latter but the former works with the client. Don't know which nor why one product chooses one over the other. My mistake was assuming I make a mistake with the repository. The mistake I actually made was trusting visual svn server. Although svn did report the smaller v it can be difficult to notice. So I created two branches for two new features I am working on. I'll see how they go. Thanks again JM -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, August 13, 2013 10:27 AM To: John Maher; users@subversion.apache.org Subject: RE: Strange behavior -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Tuesday, August 13, 2013 9:40 AM To: Thorsten Schöning; users@subversion.apache.org Subject: RE: Strange behavior Hi Thorsten A good response to a less than good post. People could take lessons from you. Actually, its been a frustrating week. Sometimes subversion accepts the wrong slash in a path, other times it does not. Sometimes it enforces case sensitivity in a url other times it does not. Sounds like normal windows-unix interaction issues. They're not that bad if you have experience with UNIX systems. In the Windows CMD shell, if you wrap your pathnames in double quotes, you can use forward slashes instead of backslashes for directory separators, e.g. dir /s c:/program files/subversion, which helps when feeding paths between CMD commands and svn commands. Follow the book on how it instructs to import a project then it becomes impossible to merge and branch. That's odd. Very odd. It's much more likely that you're not grokking some paradigm or missed a step when creating the branch. You might want to post your branch/merge test process (especially the commands) and have the list vet it. And now for the second time I must discard my repository along with all the history I've accumulated. Yes you can say frustrating, bordering on maddening. Why? If you have a good initial import checked in, then create a new test branch, or even roll trunk back to the initial import. Example: Revision 10 of /trunk is your 200 commands to import the initial baseline. 1. Create a new test branch from rev 10: svn copy svn://server/trunk svn://server/branches/new_test_branch@10 Or if you want to roll trunk back to rev 10: 1. svn rm svn://server/trunk 2. svn copy svn://server/trunk@10 svn://server/trunk 3. create new test branch: svn copy svn://server/trunk svn://server/branches/new_test_branch The original trunk branch (with revisions 11+) is still available via peg revisions, but peg revisions are a topic for later. Or if you really want a fresh repo, then you can use 'svn export -r' to export the initial working baseline and then import those files into your new test repository. Meaning, if revision 10 represents your initial 200 commands of importing files, then export revision 10 using 'svn export -r 10 ...'. This lets you start a new repo without having to re-do the import from scratch. I would tell you about 'svnadmin dump', but given your current mental state, that's probably not a good idea. I got a good laugh from: Of course it can, just copy your 200 commands line by line one after another into a batch file. I know it was a humorous comment, but... Anyway, dealing with new software with new paradigms/assumptions can be very frustrating (e.g. going from ClearCase to 1.3 SVN, *g*) but you need to take a step back and relax. Importing and branching and merging in svn 1.8 really isn't (shouldn't be) that difficult. Plus, svn 1.8 is pretty robust and a mature product, so you shouldn't be fighting with it that much. Good luck, and keep up the perseverance. That which doesn't kill you, probably leaves you crippled and weak (or something to that effect.)
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
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 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
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
Strange behavior
Hello I'm getting some very strange behavior from subversion. One of the biggest issues is why does it not ignore files I tell it to ignore? Can someone tell me how to get it to ignore files and directories properly? Following the documentation does not work. I have the following setup: Coins Coins/Cents Coins/Nickels Coins/Dimes Coins/Quarters And on each of those directories I have the following value for the svn:ignore property (results of svn propget svn:ignore:) *.suo *.user obj bin I have created a branch called LGcents. I try to merge back into trunk and this is what I get: --- Merging r14 through r50 into '.': GDimes\Dimes.suo Skipped 'Dimes\obj' Skipped 'Coins.suo' Skipped 'bin' Skipped missing target: 'Dimes\bin' Skipped 'obj' G Dimes C Build.bat Skipped missing target: 'Quarters\bin' Skipped 'Quarters\obj' Skipped 'Quarters\Quarters.suo' G Quarters UNickels\Nickels.Designer.vb Skipped missing target: 'Nickels\bin' Skipped 'Nickels\obj' Skipped 'Nickels\Nickels.suo' G Nickels C Cents\Cents.suo Skipped missing target: 'Cents\bin' Skipped 'Cents\obj' G Cents G . --- Recording mergeinfo for merge of r14 through r50 into '.': U . Summary of conflicts: Tree conflicts: 2 Skipped paths: 13 And svn status returns this: C Build.bat local add, incoming add upon merge M Cents\Censt.Designer.vb M Cents\Censt.vb D C Cents\Cents.suo local delete, incoming delete upon merge ! C Cents\bin local delete, incoming delete upon merge M Dimes\Dimes.Designer.vb M Dimes\Dimes.suo M Dimes\Dimes.vb ! C Dimes\bin local delete, incoming delete upon merge ! C Nickels\bin local delete, incoming delete upon merge M Quarters\Quarters.Designer.vb M Quarters\Quarters.vb ! C Quarters\bin local delete, incoming delete upon merge Summary of conflicts: Tree conflicts: 6 Why does merge report 2 conflicts and status report 6? That is very confusing. Why is build.bat causing a local add and incoming add? That file has been added many revisions ago. Why is Cents.suo causing a local delete. That file was not deleted either. Nor were any of the other conflicts. Both the trunk and branch were committed and updated in that order. Then I switch the directory between the branch and trunk since it is set up with the auxillery files needed to run the project. The first merge I tried failed and after that I issued the ignore commands and also issued the resolve command a lot. Is subversion extremely fragile? Is there a way to fix it? Is there any more complete documentation? The book is incomplete. Thanks JM
RE: Advice on handing common code
I use the externals property for my common code. http://www.visualsvn.com/support/svnbook/advanced/externals/ From: C M [mailto:cmanalys...@gmail.com] Sent: Tuesday, January 08, 2013 11:43 AM To: users@subversion.apache.org Subject: Advice on handing common code All, I am setting up a new repository and have a question on how to handle common code. Common refers to code which is shared across the multiple systems that we deploy. In addition to the common code, we also have system-specfic software (custom code). Given the typical SVN layout, what's a recommended way to manage this, especially when creating release tags? In this model, we include the /trunk/common_version1/application_1 ../../application_2 ./../application_3 /trunk/system1/application_1 ../../application_2 ../../application_3 /tags/system1/Rel_1 [where this may include the system1 apps plus common_version1/application_1 and application 3] ../system2/application_1 ../system2/application_2 ../system2/application_3 /tags/system2/Rel_1 [where this may include system2 apps plus common_version1/application_1, application_2 and application3]
RE: Branching best practice advice for an inherently complex environment
I feel your pain. The only thing I can think of would be to demonstrate a merge with no conflicts. Then show them what you have to do with the 90% conflicts. You can then explain how much development work can get done if you do not have to resolve the conflicts. How often do you merge? One mistake I made was not merging often enough. A daily merge would not be a bad idea. John -Original Message- From: Phil Pinkerton [mailto:pcpinker...@gmail.com] Sent: Tuesday, September 25, 2012 7:40 AM To: users@subversion.apache.org Subject: Branching best practice advice for an inherently complex environment Looking for convincing guidelines to change some rather poor practices Scenario : Project has multiple branches with frequent changes by several different developers, merging back to trunk is infrequent and when done merge results in 90% conflicts. simple example: Project A1 (trunk) copied to branches B1, B1 gets a few changes and is copied to B2, B2 gets some changes and B2 is merged to trunk, trunk gets copied to B3, B1 is merged to B3 and copied to B4 B2 gets more changes, B2 is merged to B4, B4 gets more changes, B1 gets more changes. messy I know ; the big mess is B1 needs to be tagged and built and released but of course the merge to trunk will be full of conflicts, meanwhile B3 has more changes as does B4 and B4 needs to merge to B2 so B2 can be tagged built and released. More branches are expected, changes and lack of frequent sequential merges is out of control, releases are scheduled monthly. My thoughts are this will get worse before it gets better, any experienced users who have complex environments have an idea on how to turn this around to use best practices ? What is a good example for controlling massive changes in multiple branches, merges to trunk and maximizing tags? Have RTFM'd but need to convince the powers that be a change is needed that will also handle frequent changes in a very dynamic development environment. I am still trying to fully understand this environment and attempt to turn it around as quickly as possible. Any examples and or suggestions to produce a convincing argument would be useful. Thanks
RE: Merging headache
Don't know if this will help you or not, but I ran into some problems (still am) learning subversion. I can tell you what I learned. Someone told me that conflicts are normal, and when I looked deeper, they are 100% correct. The merge doesn't work perfect all the time. It depends on your changes. For example, I deleted a function and created a new one in its place. During a merge this caused a conflict. There was different code in the same place in the source and the target. Which to keep? This SHOULD cause a conflict so a human can look and choose the right one. That is why they say merge often, less changes means less chance for a conflict. But conflicts will occur. One way to fix things is to make a new repository. You lose all your history so it would depend on how long you've been using subversion and how important your history is vs how bad your current repository is. A new repository will start you with a clean slate and you keep the old one for the history. You then need to be more careful. Another way to fix things is to manually fix all the conflicts. Subversion does a lot of things and some of them are not so straight forward. But it is also very powerful. Very easy to shoot yourself in the foot. John -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Wednesday, September 19, 2012 4:34 AM To: David Aldrich Cc: users@subversion.apache.org Subject: Re: Merging headache On Wed, Sep 19, 2012 at 08:19:59AM +, David Aldrich wrote: As this is rather a mess, can you suggest a way to get back to some degree of order? I'm afraid I cannot make any reasonable suggestion at this point, sorry. I'd need more information about what really happened.
RE: Problem with merging
Thank you Stefan. Very helpful. John -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Friday, September 14, 2012 10:24 AM To: John Maher Cc: users@subversion.apache.org Subject: Re: Problem with merging On Thu, Sep 13, 2012 at 09:23:54AM -0400, John Maher wrote: How hard is it to change the book? Check out the book sources, make changes, and either send a patch (i.e. the output of svn diff showing your changes) to the svnbook development list, or file an issue in the book's issue tracker and attach the patch to the issue. You can create a patch file like this from the top of your book sources working copy: svn diff my-changes.patch See Feedback / Contributing on http://svnbook.red-bean.com/ for more information. If you want to compile your edited book sources before submitting your changes, which is a good idea in case you're not just making simple tweaks to the text but also add or change XML tags, see http://svnbook.googlecode.com/svn/trunk/en/README
RE: Problem with merging
Thanks Stefan. I did read most of the links. I didn't know about the FAQ, thanks. Your statement was key: Note that the tree being talked about there is not an individual branch, but all nodes in the repository, including the /trunk directory and the /branches/feature directory. Basically in the book in that section tree means repository. But you cleared it up and the FAQ helped because the fact calls it the repository tree. How hard is it to change the book? I know what it means now, but the next person may get confused. I would bet that someone will eventually get confused. If it said repository tree like the FAQ I would bet it helps. John
RE: Problem with merging
Thanks Thorsten. While its true that I didn't technically lose code, it was probably in there somewhere. The loss was discovered weeks later and we have a lot of code. It would take days going over everything then we would have to *hope* we got everything. Some things would let us know if we missed them, others things may not. We could go days or weeks before we noticed we were losing data. Since we were a few weeks away from the next release I decided to put off updating production. Basically it would cost too much to possibly not get all the code sprinkled with a slim chance of data loss. So from a business perspective, the code was lost. In reality we should've had code control a long time ago. I only got here a few years ago. And when I first got here I met extreme resistance about incorporating something like subversion. I finally got the green light, quite possibly because they didn't have to spend any money. Now I must learn to use it. :) Revisions are global is what I needed to know, thanks. John -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Wednesday, September 12, 2012 2:39 PM To: users@subversion.apache.org Subject: Re: Problem with merging Guten Tag John Maher, am Mittwoch, 12. September 2012 um 19:39 schrieben Sie: I started using subversion a while back and doing a merge I lost a bunch of source code which prohibited me from updating production for weeks. Unless you didn't commit, you can't loose source code, that's what version control is all about. Even if you didn't commit Subversion would always try everything to preserve your current modifications, which may result in the conflicts you describe later. The easiest way to never ever loose anything it always commit before doing any changes to your working copy like merges and whatever goes wrong after a commit can be restored. I now have a stable code base and wish to use subversion so I tried to follow chapter 4, branching and merging. It failed. If you mean your later mentioned conflicts with failed, this isn't exactly true, as a conflict is a normal operation and the merge may succeed. Conflicts only mean that there are changes which Subversion can't merge automatically safely and the user needs to do something to merge the changes. This is not the same as an error during the merge or else. 1) I was on revision 4. I then branced it, made a change and it jumped to revision 7. Why? Does the revision apply to all folders under a repository? Yes, revisions are global, that's one of the fundamental concepts of Subversion and is normally considered as a major benefit over previous centralized version control like CVS. 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.030-2 1001-310 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: Problem with merging
Can you tell me what that means? I had a question on merging so I sent it to the mailing list. Are you saying I'm not supposed to do that? If not then can you explain the procedure? John -Original Message- From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk] Sent: Thursday, September 13, 2012 4:56 AM To: John Maher Cc: users@subversion.apache.org Subject: Re: Problem with merging On 12/09/12 18:39, John Maher wrote: Hello [CUT] Can you please stop reusing an already existing thread and instead start a new one for a new question? Thanks John Thanks Giulio
RE: Problem with merging
Yes that is what I did. Now that I know that causes problems with the subversion mailing list I won't do it again. John -Original Message- From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk] Sent: Thursday, September 13, 2012 10:25 AM To: John Maher Cc: users@subversion.apache.org Subject: Re: Problem with merging On 13/09/12 15:15, John Maher wrote: Can you tell me what that means? I had a question on merging so I sent it to the mailing list. Are you saying I'm not supposed to do that? If not then can you explain the procedure? You are hijacking someone else's email. Presumably you have clicked on Reply or ReplyAll to a previous email and changed the subject and text. Unfortunately this means that your email is going in the same thread as the one you replied to, which is not related to your problem. When asking a new question simply send a new email, don't reply to one. I hope I was clearer now. Giulio
Problem with merging
Hello I started using subversion a while back and doing a merge I lost a bunch of source code which prohibited me from updating production for weeks. I now have a stable code base and wish to use subversion so I tried to follow chapter 4, branching and merging. It failed. I was hoping someone could tell me what I am doing wrong. I went through the process twice and got the same result, so at least I make the same mistake consistently. There are a couple of weird unexplained behaviors I am noting along with a log of what I did. 1) I was on revision 4. I then branced it, made a change and it jumped to revision 7. Why? Does the revision apply to all folders under a repository? 2) I made a change to the branch, commited it to revision 6. Then made a change to the trunk to revision 7 (from 4). Then I tried to merge the change from the trunk to the branch and it required an update. Why? 3) Now it says text conflict. What does that mean? Is there another section in the book that may explain merging? Another read? I would like to get subversion working without any more code loss. Here's what I did: 1. Create repository on the server called test with trunk and branches directories. 2. Issue the command G:\Code\stsvn checkout https://server.com/svn/test/trunk . 3. Added the project using tortoise (14 files/directories). 4. Made a change to the project. 5. Issue the command G:\Code\stsvn commit -m Two Adding WindowsApplication1 Adding WindowsApplication1\Form1.Designer.vb Adding WindowsApplication1\Form1.resx Adding WindowsApplication1\Form1.vb Adding WindowsApplication1\My Project Adding WindowsApplication1\My Project\Application.Designer.vb Adding WindowsApplication1\My Project\Application.myapp Adding WindowsApplication1\My Project\AssemblyInfo.vb Adding WindowsApplication1\My Project\Resources.Designer.vb Adding WindowsApplication1\My Project\Resources.resx Adding WindowsApplication1\My Project\Settings.Designer.vb Adding WindowsApplication1\My Project\Settings.settings Adding WindowsApplication1\WindowsApplication1.sln Adding WindowsApplication1\WindowsApplication1.vbproj Transmitting file data Committed revision 2. 6. Made a change to the project. 7. Issue the command G:\Code\stsvn commit -m Three SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 3. 8. Made a change to the project to simulate a feature. 9. Issue the command G:\Code\stsvn commit -m Four SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 4. 10. Issue the command G:\Code\stsvn copy https://server.com/svn/test/trunk https://server.com/svn/test/branches/feature -m Feature Committed revision 5. 11. Changed the current directory from st (subversion test) to stb (subversion test branch. 12. Issue the command G:\Code\stbsvn checkout https://server.com/svn/test/branches/feature . AWindowsApplication1 AWindowsApplication1\WindowsApplication1.vbproj AWindowsApplication1\Form1.resx AWindowsApplication1\Form1.Designer.vb AWindowsApplication1\Form1.vb AWindowsApplication1\WindowsApplication1.sln AWindowsApplication1\My Project AWindowsApplication1\My Project\Resources.Designer.vb AWindowsApplication1\My Project\Settings.settings AWindowsApplication1\My Project\AssemblyInfo.vb AWindowsApplication1\My Project\Settings.Designer.vb AWindowsApplication1\My Project\Application.Designer.vb AWindowsApplication1\My Project\Application.myapp AWindowsApplication1\My Project\Resources.resx Checked out revision 5. 13. Made a change to the feature branch. 14. Issue the command G:\Code\stbsvn commit -m Six-feature SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 6. 15. Changed the current directory from stb to st. 16. Made a change to the project to simulate a bug fix. 17. Issue the command G:\Code\stsvn commit -m Five-bug fix SendingWindowsApplication1\Form1.Designer.vb Transmitting file data . Committed revision 7. *** Why 7? 18. Changed the current directory from st to stb to try to merge the bug fix to the feature branch. 19. Issue the command G:\Code\stbsvn merge https://server.com/svn/test/trunk --dry-run svn: E195020: Cannot merge into mixed-revision working copy [5:6]; try updating first *** Why update? No one else is doing anything!! 20. Issue the command G:\Code\stbsvn update Updating '.': At revision 7. *** Why go to 7? 21. Issue the command G:\Code\stbsvn diff -r6:7 (Nothing returned using -r5:7 displays the changes I made) 22. Issue the command G:\Code\stbsvn merge https://server.com/svn/test/trunk --dry-run --- Merging r5 through r7 into '.': CWindowsApplication1\Form1.Designer.vb Summary of conflicts:
RE: general questions
Tortoise is pretty cool, the best out of what I tried, and I haven't tried much. But there are some things it can not do. John From: David Chapman [mailto:dcchap...@acm.org] Sent: Monday, September 10, 2012 4:17 PM To: John Maher Cc: Mark Phippard; users@subversion.apache.org Subject: Re: general questions On 9/10/2012 12:31 PM, John Maher wrote: Thanks Dave, that was helpful. I saw the svn prefix in the book but didn't know what it meant. Your explanation was good. The scripts are a good idea, but I was thinking about a gui for the client side, kinda like Subversion Edge; basically a wrapper for the command line. Even though my first computer didn't have a mouse (or hard drive) the gui is the way to go, typing commands is just not the future. I may start something to make my job easier. I think HTML would benefit the most people. But I need to learn a lot more first. Hmm, my first personal computer had a hexadecimal keypad and 256 bytes (not even kilobytes!) of memory. :-) Scripts (aka typing) allow repeatability. A GUI that allows you to specify a set of options for every repository can be helpful, but down inside it will be doing the same thing as a script - and a script is easier to customize or debug when the existing tools don't do what you need. Also, scripts don't disappear if the GUI goes down. For this reason many sysadmins prefer scripts over GUI-based tools, and I don't see this ever changing. As a result, I can't help you find a GUI that will help you administer your repositories. TortoiseSVN is a client-side GUI for Windows-based machines but I haven't used it. I don't know how close it comes to meeting your needs. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: general questions
Interesting discussion. It appears you have not had the chance to work with a good wrapper, or maybe you shun guis or something because there appears to be a strong bias to your statements. I have been a programmer AND user on both sides, gui and command line, so I am not making things up. I'm not saying GUIs don't work. Just that they are generally a subset of what can be done with commands. This is simply not true. Expose every function and every parameter and there is nothing the gui can not do. Add some automation, and the gui can actually do more. You are making some assumptions about scale and locality here. I have most of the world at my fingertips in the form of URLs. Of course I am. I must make some assumptions or there is nothing to talk about. Don't forget a gui can have a box where a URL is entered so it can do everything you can by just typing in stuff plus anything else that gets added. OK, but if I regularly work with 44 repositories, I'm likely to have their URLs in a file where a script can extract them a lot faster than you can navigate the world in a picklist. Now you're making assumptions, that's OK though. Makes for a good discussion. And you are right. Nothing works best 100% of the time. Now think of the reverse of that. What if you wish to do something to 44 repositories once? Whats better typing them all in or clicking on them. You can type, I'll click. Let's assume the list of choices won't fit on a screen... See above reply. But it can only be a good design after you already now what I'm going to do. Until then you can only offer the bazillion choices. Again, not true. With experience comes wisdom. Although you can never predict a user 100% of the time, you can learn to be spot on 50% (or better) of the time. And you seem to be forgetting a gui can do anything text can do by offering a textbox. There's a bazillion right there. You also have a bazillion at the command line. I think what you are picturing is nothing like what I am planning. lol. At least I would never use the same words to describe it as you do. John -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Monday, September 10, 2012 4:29 PM To: John Maher Cc: David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions On Mon, Sep 10, 2012 at 3:15 PM, John Maher jo...@rotair.com wrote: I don't 100% agree. I've designed lots of guis. And there were times users discovered a feature I never intended. And I'm not talking about a bug called a feature. While true that the programmer has a lot to think about (fortunately I am one), the gui can be designed in such a way to empower the user. I'm not saying GUIs don't work. Just that they are generally a subset of what can be done with commands. Simply presenting the choices in a list will speed use by avoiding typing in long paths and the occasional type. You are making some assumptions about scale and locality here. I have most of the world at my fingertips in the form of URLs. Having a multi-selectable list allows any command ease of application to many targets with a loop you spoke of. I never have to think of every possibility the user can enter, just every possibility of a command I will execute. They are not the same. OK, but if I regularly work with 44 repositories, I'm likely to have their URLs in a file where a script can extract them a lot faster than you can navigate the world in a picklist. You are right where a script is more suitable for a sequence on many things. My gui will never be able to compete with that. On a single operation on many things, if the gui can do it, it will win every time. I can out-click a very fast typer, probably not the fastest. Let's assume the list of choices won't fit on a screen... And if it requires a bazillion mouse clicks, it is a poor design. But it can only be a good design after you already now what I'm going to do. Until then you can only offer the bazillion choices. -- Les Mikesell lesmikes...@gmail.com
RE: svnadmin
Thank you Ryan. I couldn't find where I read that before and you and others explained it well. John -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Monday, September 10, 2012 5:38 PM To: John Maher Cc: Subversion Users Subject: Re: svnadmin Returning the thread to the list: On Sep 10, 2012, at 11:18, John Maher wrote: Thanks Ryan. I was wrong about the hooks directory not being there, it was there just not displayed by VisualSVN. So if I create a repository on a network drive multiple users can use it if with no problems, right? If so then does that mean VisualSVN Server is optional? Just trying to understand subversion. Its not easy. I'm on chapter 3 and the book is making more questions than it answers. Hopefully soon I'll be at the point where more questions get answered by the book than are created. You should not create repositories on network drives; you could encounter [permissions|performance|corruption|dataloss] problems. Repositories should be on a disk local to the machine that's running svnserve or httpd with mod_dav_svn to serve it to users, and should be secured so that only the user that svnserve or httpd runs as can read from and write to them.
RE: general questions
On our server we have 21 repositories. One of those repositories contains 44 projects (dlls). Each project needs the svn:ignore property set. You're right, it is not common. But several times I had to leave tortoise to go to the command line. It's just one more pain. I feel there is a better way, I am just not sure what that way is, yet. John -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Monday, September 10, 2012 5:59 PM To: John Maher; Thorsten Schöning; users@subversion.apache.org Subject: RE: general questions If you think it would require 44 click paths then that is indeed a poor design. Do you really have 44 repositories? Or 44 projects in a single repository? 1 click to select the repository, 1 click to select all. I just turned 44 click paths into 2 clicks. Sounds like your vision is nothing like mine. What other guis are out there besides tortoise? If there's something I like, I'll use it. Otherwise I'll make one if only to illustrate what seems difficult for me to explain and others to grasp. Tortoise is the best GUI for Windows I think. There are others. But, what you are doing is not a COMMON use case. The common use case it to add your ignores when you set up a new project in your repository. Doing 44 after the fact is not a standard use case. Here is a list to some of the others: http://svn-ref.assembla.com/windows-svn-client-reviews.html BOb John
RE: general questions
Thanks Mark!!! That might be exactly what I was looking for. Now I have an unusual question I don't know if anyone knows the answer. I may just try it anyway. What happens if I have more ignores than I need. Will it hurt performance much? For example, my setup looks like this: Reporitory/Project1 Reporitory/Project1/bin Reporitory/Project1/Graphics Reporitory/Project1/My Project Reporitory/Project1/obj Reporitory/Project1/sql Reporitory/Project2 ... Reporitory/Project44 What if I set this property recursively svn:ignore *.sou *proj.user bin obj? I know it will get applied to many directories unnecessarily. For example, only the top level directory (Project1) will contain any *.sou files. The ignore will get applied everywhere, even where it is not needed. Can this cause any major issues? I like the idea of entering the property once. Although I can go down the line and paste the property where it is supposed to go. Is it worth the extra effort? That is what I was looking for Mark, thanks. John From: Mark Phippard [mailto:markp...@gmail.com] Sent: Tuesday, September 11, 2012 8:41 AM To: John Maher Cc: Bob Archer; Thorsten Schöning; users@subversion.apache.org Subject: Re: general questions On Tue, Sep 11, 2012 at 8:32 AM, John Maher jo...@rotair.com wrote: On our server we have 21 repositories. One of those repositories contains 44 projects (dlls). Each project needs the svn:ignore property set. You're right, it is not common. But several times I had to leave tortoise to go to the command line. It's just one more pain. I feel there is a better way, I am just not sure what that way is, yet. You can set properties using TortoiseSVN: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-props You can also set properties on folders recursively. The problem with doing this for svn:ignore is that it is a multi-line property and it would be fairly uncommon to want an identical property value for every folder. If that is what you want, setting it would be very easy to do. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: general questions
Thanks Bob. Exactly what I was looking for. John -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Tuesday, September 11, 2012 9:48 AM To: John Maher; Thorsten Schöning; users@subversion.apache.org Subject: RE: general questions If you think it would require 44 click paths then that is indeed a poor design. Do you really have 44 repositories? Or 44 projects in a single repository? 1 click to select the repository, 1 click to select all. I just turned 44 click paths into 2 clicks. Sounds like your vision is nothing like mine. What other guis are out there besides tortoise? If there's something I like, I'll use it. Otherwise I'll make one if only to illustrate what seems difficult for me to explain and others to grasp. Tortoise is the best GUI for Windows I think. There are others. But, what you are doing is not a COMMON use case. The common use case it to add your ignores when you set up a new project in your repository. Doing 44 after the fact is not a standard use case. Here is a list to some of the others: http://svn-ref.assembla.com/windows-svn-client-reviews.html BOb John On our server we have 21 repositories. One of those repositories contains 44 projects (dlls). Each project needs the svn:ignore property set. You're right, it is not common. But several times I had to leave tortoise to go to the command line. It's just one more pain. I feel there is a better way, I am just not sure what that way is, yet. John Tortoise lets you apply properties recursively. If you want to apply the property to every file and folder in the hierarchy below the current folder, check the Recursive checkbox. Check the tortoise help: 4.17.1.2. Adding and Editing Properties BOb
RE: general questions
Sorry Les, you just don't get it. Just because you've never seen something doesn't mean it can't or shouldn't be done. Its sad that you haven't seen any good tools. You make the same mistake over and over assuming that a wrapper designer anticipates what the user wants to do. While that may be true in an application that is definitely not necessary in a wrapper, and not desired. If a programmer based thier logic on that assumption, they would always be wrong. A good wrapper wraps the functionality of the command line to a guid, initially there is no anticipation or user actions. A good wrapper would only anticipate AFTER all functionality has been accounted for, this anticipation would be for features that do not exist in the command line AFTER all functions and parameters are already passed from the gui to the command line. So there is NOTHING the gui can't do that the command line can except take more time to do something. You're confusing the steps to design an application with the steps to design a wrapper. Two different animals and if you mix the two its like trying to pull a trailer with a corvette. It may work, it may cause problems. It definitely is not optimal. John -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Tuesday, September 11, 2012 11:45 AM To: John Maher Cc: David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions On Tue, Sep 11, 2012 at 7:22 AM, John Maher jo...@rotair.com wrote: Interesting discussion. It appears you have not had the chance to work with a good wrapper, or maybe you shun guis or something because there appears to be a strong bias to your statements. First, let me remind you that you started the discussion, complaining about not being able to find the way to do what you wanted in a GUI. I have been a programmer AND user on both sides, gui and command line, so I am not making things up. I'm more of a system administrator, so used to doing things that aren't designed into GUIs as everyday operations for most users. I'm not saying GUIs don't work. Just that they are generally a subset of what can be done with commands. This is simply not true. Expose every function and every parameter and there is nothing the gui can not do. Add some automation, and the gui can actually do more. But that's within a single application. Well designed command line tools and scripting languages include all of each others' functionality fairly seamlessly. While a GUI 'could' let me run a program of my choice to supply any option or input, none that I've seen actually do. So they are limited to what the designer anticipated where the command line tools gain functionality as new tools are developed or you add your own helper/wrapper scripts. You are making some assumptions about scale and locality here. I have most of the world at my fingertips in the form of URLs. Of course I am. I must make some assumptions or there is nothing to talk about. Don't forget a gui can have a box where a URL is entered so it can do everything you can by just typing in stuff plus anything else that gets added. But, I said I would have a list of URLs in a file. Your GUI 'could' let me provide the file as input. But that would be a rare choice for a GUI designer and a common scenario for me. So if forced to use a gui for a repeated operation, I'd probably end up displaying the file in one window and cutting/pasting a line at a time as I repeat the many mouse-clicks it might take for the rest of the work. OK, but if I regularly work with 44 repositories, I'm likely to have their URLs in a file where a script can extract them a lot faster than you can navigate the world in a picklist. Now you're making assumptions, that's OK though. Makes for a good discussion. And you are right. Nothing works best 100% of the time. Now think of the reverse of that. What if you wish to do something to 44 repositories once? Whats better typing them all in or clicking on them. You can type, I'll click. My assumptions are from past history. Picking 44 names out of 100 might be a win. Picking 44 out of 50,000, I'd rather just type them in, but if I am creating a new, arbitrary set of names for related things I'd use a name convention where wildcards or number sequences make the set script-friendly for operations on the group. If someone else has given me the names, we are back to already having the list in a file and the script just has to iterate over it. But it can only be a good design after you already now what I'm going to do. Until then you can only offer the bazillion choices. Again, not true. With experience comes wisdom. How does that differ from what I said? If the GUI designer knows what I'm going to do and wants to spend the time making it easier, then yes, the GUI approach can be nicer. But if I want to do something new and different (and what's the point if I don't
RE: general questions
You're confusing a single application with the whole command line and *everything* it can invoke. In your picture that whole set of all commands available now or in the future is the 'the application' for which you'd need to design a GUI, would you want to have its flexibility available in a GUI. I don't understand this statement at all. I'm talking about a simple wrapper. And it would be very easy in incorporate *everything*. Even command that have not been added yet. Interaction with *other* applications (the trailer) isn't designed in, and can't be automated. Again, if necessary it can be, very easy. However that is not the point of the wrapper. If I want to build a car you can say but it can't fly. And it can't float. You're right. It isn't supposed to. You can always pick fault about something if you go beyond its scope. GUI applications are designed to interact with a user, and not with other applications Again that is not true. Well the first part is. The second part ((not with other applications) may or may not be true. Depends on the app. I'm starting to learn who isn't a programmer because they have common misconceptions about how programs are designed. I wonder if its from watching TV? Or maybe designing a system is so rigid that its difficult to comprehend the freedom allowed in designing a program. They are not as limited as you believe them to be. John -Original Message- From: Andreas Krey [mailto:a.k...@gmx.de] Sent: Tuesday, September 11, 2012 12:57 PM To: John Maher Cc: Les Mikesell; David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions On Tue, 11 Sep 2012 12:02:51 +, John Maher wrote: ... line can except take more time to do something. You're confusing the steps to design an application with the steps to design a wrapper. You're confusing a single application with the whole command line and *everything* it can invoke. In your picture that whole set of all commands available now or in the future is the 'the application' for which you'd need to design a GUI, would you want to have its flexibility available in a GUI. different animals and if you mix the two its like trying to pull a trailer with a corvette. It may work, it may cause problems. It definitely is not optimal. That's because a corvette isn't designed for a trailer hook. That is exactly the situation with all kinds of GUis: Interaction with *other* applications (the trailer) isn't designed in, and can't be automated. GUI applications are designed to interact with a user, and not with other applications, and that is their general deficiency for some kinds of work. Try to get you browser and photoshop to play together and download, scale, and publish a webcam pic every hour, and you see the non-power of the GUI. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
RE: general questions
lol. These rants are priceless!! I talk about a simple wrapper and we get text stream processing!! Tack on irrelevant things to make your point sound good!! If you gotta reach that far then that is a clue your argument lacks merit. I give up trying to explain it. Sorry I'm not reading anything on unix if I can help it. Text based operating systems will be obsolete. I know all you text gurus will argue to your death. But JCL was junk while it was still in use. It was used only because that had to, not because it was any good. Command line interfaces, text based oses and the mouse are all going bye-bye. Its just a matter of time. May be in my lifetime, may not be, I don't care. I am focusing my attention on the future, not the past otherwise I could get a high paying job doing cobol since those guys are in demand. But I don't want to work with a dead language even if it won't die in my lifetime. I'm looking ahead. For example: If a GUI offers any of those options you pretty much lose any point/click advantage it might have since the choices approach infinity. Wrong. A gui has textboxes. You only need to click some things, not evey single parmeter for every single command. No wonder you don't like guis. Things based on text stream processing don't have 'scopes' or associated limits. Wrong. If a program doesn't have a scope its unlikely to come out well. And a program can easily accept a text stream and return one. How do you think your commands work? They are programs. -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Tuesday, September 11, 2012 1:52 PM To: John Maher Cc: Andreas Krey; David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions On Tue, Sep 11, 2012 at 12:11 PM, John Maher jo...@rotair.com wrote: You're confusing a single application with the whole command line and *everything* it can invoke. In your picture that whole set of all commands available now or in the future is the 'the application' for which you'd need to design a GUI, would you want to have its flexibility available in a GUI. I don't understand this statement at all. I'm talking about a simple wrapper. And it would be very easy in incorporate *everything*. Even command that have not been added yet. On the command line, every piece of text, including the base command to run can be the expansion of shell variables, file wildcards, or the output of any other program. If a GUI offers any of those options you pretty much lose any point/click advantage it might have since the choices approach infinity. The input can be the output of any other program. If the tool doesn't do the complete job, the output can go to any other tool. Interaction with *other* applications (the trailer) isn't designed in, and can't be automated. Again, if necessary it can be, very easy. However that is not the point of the wrapper. If I want to build a car you can say but it can't fly. And it can't float. You're right. It isn't supposed to. You can always pick fault about something if you go beyond its scope. That's the point here. Things based on text stream processing don't have 'scopes' or associated limits. Likewise for command lines based on text expansions. GUI applications are designed to interact with a user, and not with other applications Again that is not true. Well the first part is. The second part ((not with other applications) may or may not be true. Depends on the app. I'm starting to learn who isn't a programmer because they have common misconceptions about how programs are designed. I wonder if its from watching TV? Starting here worked out pretty well for me: http://books.google.com/books/about/The_UNIX_programming_environment.htm l?id=poFQMAAJ The concepts still save me time every day. -- Les Mikesell lesmikes...@gmail.com
RE: general questions
A script is a wrapper around all of your programs and becomes a superset of all of them. lololol that has got to be the most unusual definition I have ever heard of a script. According to your definition, a macro in a word processer is a superset of the entire word processer. I disagree. Using text is not a requirement of a wrapper!! This is getting funnier and funnier. Maybe you are used to some more restricted form of scripting. Nope. I am not a scripter. I am a programmer. We use terms consistently otherwise confusion would result. We have to communicate with each other and work together so when we use terms like wrapper it generally means the same thing. We can have a wrapper to encapsulate code, redefine the api, but I never, ever heard of a list of command (script) called a wrapper. What else ya gat? John -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Tuesday, September 11, 2012 3:12 PM To: John Maher Cc: Andreas Krey; David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions On Tue, Sep 11, 2012 at 1:57 PM, John Maher jo...@rotair.com wrote: A script is just a subset of a full fledged program. In other words, a program can do all a script can do and more. That's the part you don't seem to be getting. A script is a wrapper around all of your programs and becomes a superset of all of them. At least the ones that are capable of using and generating text. It is not just limited to what any single program can do - or what is on any single machine for that matter assuming you have a tool like ssh available.At least that's the unix-inspired way of thinking. Maybe you are used to some more restricted form of scripting. -- Les Mikesell lesmikes...@gmail.com
RE: svnadmin
Thanks Chris, I appreciate the link, I'm still on chapter 2. Strange it describes creating a repository AFTER it explains properties and commands like diff. I read that link you posted but now I am confused about hooks. I see the hook directory get created when I create a repository locally. But there isn't any such directory in the repository created on a server (VisualSVN). I searched through the book using the keyword hooks and couldn't find any clue. 1) Can hooks be used on a non-local repository? 2) I read somewhere that a directory repository structure is not recommended for multi-user environments. Is this true? 3) If #2 is true then is it also true that svnadmin create is for single users ONLY? -Original Message- From: Chris Shelton [mailto:cshel...@shelton-family.net] Sent: Friday, September 07, 2012 3:59 PM To: John Maher Cc: users@subversion.apache.org Subject: Re: svnadmin John On Fri, Sep 7, 2012 at 3:47 PM, John Maher jo...@rotair.com wrote: Is svnadmin create limited to creating a local repository? Yes. If not then how do you use it for a URL? You don't. If so then is there a command for creating a repository via an URL? Or is this impossible? It is impossible to create a repository remotely. Read the book on repository creation: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html svnadmin is a server side utility to create a repository within the local filesystem. chris
RE: svnadmin
Thanks Bob. I installed subversion edge but I don't know if it can help me or I just can't figure it out. I can't get it to find our repositories. It won't let me change the IP address which makes me think that it doesn't work with non-local repositories. I searched the forums (developer and admin) with the text existing repositories and found one post that didn't match my question but it didn't matter anyway because the post wasn't answered itself. I was thinking about writing an html or java wrapper because command line arguments are a thing of the past, forget about looking to the future. Then I thought that edge does this. If it doesn't then is there any thing else out there that may do this? For example I have to set the svn:ignore property on 44 modules, and that is only one project. We have other projects. Typing or editing the same command 44 times is a bit archaic. It would be nice to type it once and click on the modules that it applies to. I may write this myself because it would be quicker to write a small program than type or edit the same thing over and over again and hope I don't miss one. John -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Friday, September 07, 2012 4:03 PM To: Chris Shelton; John Maher Cc: users@subversion.apache.org Subject: RE: svnadmin John On Fri, Sep 7, 2012 at 3:47 PM, John Maher jo...@rotair.com wrote: Is svnadmin create limited to creating a local repository? Yes. If not then how do you use it for a URL? You don't. If so then is there a command for creating a repository via an URL? Or is this impossible? It is impossible to create a repository remotely. Well, strictly not true. If you have access to remote share you can create the repository on another machine. Read the book on repository creation: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html svnadmin is a server side utility to create a repository within the local filesystem. John, if you use Subversion Edge it will allow you to create repos using the Web Admin UI as well. BOb
RE: general questions
Thanks again, I'm learning. I appreciate the time put in to help me and I really don't want to cost you more time, so I have a couple of yes/no questions. So the only time to use svnadmin create without having a dedicated server would be a single user (like me at home)? As for as the dll extensions, those are not a concern. I am talking about ide setting files. And if we have a project made up of 44 repositories I need to enter the command 44 times, no eaiser way, right? Thanks again. John From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, September 10, 2012 12:35 PM To: John Maher; users@subversion.apache.org Subject: Re: general questions Please keep replies on the mailing list. On Mon, Sep 10, 2012 at 12:02 PM, John Maher jo...@rotair.com wrote: Thanks again Mark, you have been helpful. Let me clear some things up. Let me clear up by what I mean as local repository. We have a svn server which has repositories on it. It serves us files to our local directories when we ask for them using VisualSVN Server. I also created some repositories locally with svnadmin create. The repositories are on the same machine, on the same drive as the working copy and I can get a working copy without any network access and do not need VisualSVN Server, Subversion Edge or any other server to create or access it. Sure you can say the server is MyMachineName and the client is MyMachineName. However the repositories ARE different because svnadmin works with one type and fails with another. Perhaps you never used the second type. If you have what would you call it to differentiate between them? They are just repositories. You can say you are accessing one via file:// protocol and one via http:// protocol if you like. svnadmin only operates directly on the file system via the OS. It does not talk to anything except the bytes on disk. So it needs access to those bytes. The normal thing to do is to run svnadmin on the server where you want your repositories to live. You login to the server directly using something like an SSH terminal or a Remote Desktop. When you run a GUI on your server like VisualSVN or SVN Edge, those tools are simply providing a way to run the svnadmin command via some other remote access interface such as your web browser. I am still wondering about the issue I read somewhere it said you should use a what-ever-you-want-to-call-it repository via a URL and a server product (like VisualSVN Server) instead of a what-ever-you-want-to-call-it repository on a network drive without using a server product (using svnadmin create) in a multi-user environment. You can create repositories on a network share and access them via file:// protocol but you shouldn't. All users need full read/write access to the repository files if you do this, which means they can accidentally delete or corrupt those files. Of course they can also do so for malicious/intentional reasons. Accessing the repository this way will also typically be significantly slower than accessing them via a server. And we have numerous files we need to ignore. We are using visual studio. We have a project which consists of 44 dlls. Each dll is in its own directory and is a project in and of itself. Each directory contains files and directories which need to be ignored when a new user creates a working copy so the user's settings don't get stepped on. So that means entering the svn:ignore command 44 times at least for this one project alone. I was hoping for a better way. You can setup clients to ignore the DLL extensions always, but that has to be done on each client. Setting svn:ignore is the better way and it only has to be done by one user and then committed to the repository for all others. We do have TortiseSVN. The documentation is quite poor with this product. Well, I disagree. At least compared to every other SVN client, they have the best and most complete documentation. I cannot speak to the commercial clients, maybe some of them are better but I doubt it. That is the reason I am reading the book, which is NOT an easy read by the way, unless of course you already know the subject. I think it is an easy read. That is how I learned Subversion. I was coming from an AS/400 background where version control is quite different. I had used PVCS and SourceSafe quite a bit, and CVS a little bit. From reading the book when Subversion 1.0 came out, I felt like I understood the tool almost immediately. Obviously there was still a lot more I learned over the years by experience and this mailing list, but the book laid the ground work. Understanding things like repositories, working copies, revisions and mixed revision working copies are all essential concepts and I think the book explains them well. The book jumps around worse than a bullfrog on a blacktop
RE: general questions
Thank you very much. Now I can get back to reading. John From: Mark Phippard [mailto:markp...@gmail.com] Sent: Monday, September 10, 2012 3:06 PM To: John Maher Cc: users@subversion.apache.org Subject: Re: general questions On Mon, Sep 10, 2012 at 1:43 PM, John Maher jo...@rotair.com wrote: Thanks again, I'm learning. I appreciate the time put in to help me and I really don't want to cost you more time, so I have a couple of yes/no questions. So the only time to use svnadmin create without having a dedicated server would be a single user (like me at home)? Yes. You only use svnadmin to create repositories and a few other actions that operate directly on the disk. That means you are either managing a server or in the case of a single user, creating a personal repository on the same machine you do development. As for as the dll extensions, those are not a concern. I am talking about ide setting files. As is noted in the book: http://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.htm l There is a global ignores that can be configured per client. This lets you just ignore all files with a specific extension. I do not know what the IDE configuration files are the you want to ignore but if they have a unique extension, this is one option. The other option is the svn:ignore property. This has to be set on the parent folder that might contain the files you want to ignore. You can also ignore an entire folder, so if all your build output goes to a folder named build you can just ignore that entire folder. And if we have a project made up of 44 repositories I need to enter the command 44 times, no eaiser way, right? The global ignores are a per client setting and would apply to all repositories. You just have to make sure all your users set it up. The svn:ignore property is set on folders within the repository. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: general questions
Thanks Dave, that was helpful. I saw the svn prefix in the book but didn't know what it meant. Your explanation was good. The scripts are a good idea, but I was thinking about a gui for the client side, kinda like Subversion Edge; basically a wrapper for the command line. Even though my first computer didn't have a mouse (or hard drive) the gui is the way to go, typing commands is just not the future. I may start something to make my job easier. I think HTML would benefit the most people. But I need to learn a lot more first. John From: David Chapman [mailto:dcchap...@acm.org] Sent: Monday, September 10, 2012 3:12 PM To: John Maher Cc: Mark Phippard; users@subversion.apache.org Subject: Re: general questions On 9/10/2012 10:43 AM, John Maher wrote: Thanks again, I'm learning. I appreciate the time put in to help me and I really don't want to cost you more time, so I have a couple of yes/no questions. So the only time to use svnadmin create without having a dedicated server would be a single user (like me at home)? At some level, svnadmin create will be called once per repository. Whether that is done through a GUI-based interface or from the command line is immaterial. This is the first step in setting up a repository, and it has to be on the machine that will serve the repository. It may be helpful to think of Subversion as a program package that runs on a server. If you are a single user working on a non-networked machine, then your local machine can be a Subversion server by reading the repository directly, using the file:// file:///\\ protocol. This protocol has major problems with multiple (and sometimes even remote) access, so it is safely run only on the machine where the files reside and only by one user at a time. If you need to access a repository on another machine, particularly if multiple users will be accessing the repository, you need some kind of server process running on that machine to manage internal operations safely and arbitrate between simultaneous requests. Subversion includes the svnserve program to serve files using the svn:// protocol and has code that allows Apache HTTPD to serve files using the http://; http:// or https://; https:// protocol. Personally, my repositories are all served using Apache HTTPD. I have multiple machines, and although it is unlikely that I would ever commit code from two different machines at the same time, the ease of use for the file:// file:///\\ protocol just wasn't worth the risk. I host some Web sites too, and it was easier for me to adapt my HTTPD setup knowledge than to learn how to configure svnserve. Your mileage may vary. As for as the dll extensions, those are not a concern. I am talking about ide setting files. And if we have a project made up of 44 repositories I need to enter the command 44 times, no eaiser way, right? Subversion does not provide repository administration or sandbox configuration tools; it provides a repository hosting mechanism. What you are asking for is not part of Subversion, so yes you need to enter the command 44 times. Scripting languages are your friends here. Write one script to invoke the configuration commands for a single repository, then another to invoke the first script for every repository in a list. This has multiple benefits: 1) You can call the first script each time you add a new repository, rather than type in the commands all over again. 2) Automation of this kind allows you to configure all of your repositories identically. 3) The scripts document the configuration you used (rather than scraps of paper somewhere, or the memory of an employee who may leave). -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
RE: general questions
I don't 100% agree. I've designed lots of guis. And there were times users discovered a feature I never intended. And I'm not talking about a bug called a feature. While true that the programmer has a lot to think about (fortunately I am one), the gui can be designed in such a way to empower the user. Simply presenting the choices in a list will speed use by avoiding typing in long paths and the occasional type. Having a multi-selectable list allows any command ease of application to many targets with a loop you spoke of. I never have to think of every possibility the user can enter, just every possibility of a command I will execute. They are not the same. You are right where a script is more suitable for a sequence on many things. My gui will never be able to compete with that. On a single operation on many things, if the gui can do it, it will win every time. I can out-click a very fast typer, probably not the fastest. And if it requires a bazillion mouse clicks, it is a poor design. John -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Monday, September 10, 2012 4:05 PM To: John Maher Cc: David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions On Mon, Sep 10, 2012 at 2:31 PM, John Maher jo...@rotair.com wrote: The scripts are a good idea, but I was thinking about a gui for the client side, kinda like Subversion Edge; basically a wrapper for the command line. Even though my first computer didn't have a mouse (or hard drive) the gui is the way to go, typing commands is just not the future. GUI's require the programmer to anticipate every possible thing you might want to do and provide an elaborate user interface for it. Command driven things can generally be combined in useful ways that weren't initially anticipated. If you need to do some sequence of operations on your 44 repositories, it will likely be much easier to put the commands inside a for loop in a script than to do the bazillion mouse clicks it will take to get to the right places in a GUI and type them in.Unless, of course, the GUI designer anticipated exactly that usage and gave you a way to describe it (and then does the same loop internally...). -- Les Mikesell lesmikes...@gmail.com
RE: general questions
If you think it would require 44 click paths then that is indeed a poor design. 1 click to select the repository, 1 click to select all. I just turned 44 click paths into 2 clicks. Sounds like your vision is nothing like mine. What other guis are out there besides tortoise? If there's something I like, I'll use it. Otherwise I'll make one if only to illustrate what seems difficult for me to explain and others to grasp. John -Original Message- From: Thorsten Schöning [mailto:tschoen...@am-soft.de] Sent: Monday, September 10, 2012 4:14 PM To: users@subversion.apache.org Subject: Re: general questions Guten Tag John Maher, am Montag, 10. September 2012 um 21:31 schrieben Sie: The scripts are a good idea, but I was thinking about a gui for the client side, kinda like Subversion Edge; basically a wrapper for the command line. Even though my first computer didn't have a mouse (or hard drive) the gui is the way to go, typing commands is just not the future. I may start something to make my job easier. I think HTML would benefit the most people. But I need to learn a lot more first. Don't do that, there are a lot of GUIs for Subversion out there. Especially if you need to repeat the same task many times, the command line and scripts are the way to got, because that's what they are made for. Nobody wants to click the same click paths 44 times through a GUI, that's why some programs are capable of macros. You should really think twice if your want to waste your time with building some client side HTML application with very limited benefit and capabilities. Have a look at TortoiseSVN and its integration into the Windows Explorer, a lot of mass editing tasks of whatever are really easy to achieve, as with normale file operations. 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.030-2 1001-310 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
svnadmin
Is svnadmin create limited to creating a local repository? If not then how do you use it for a URL? If so then is there a command for creating a repository via an URL? Or is this impossible? Thanks JPM
RE: Question about Basic Authentication
Hello I am trying to create a repository without a lot of junk that exists with the source. Namely 2 files and two folders. The import command doesn't seem to allow exclusion, at least not in the book. These exclusions also need to be applied to all users so a directory property is required. But the directory property is not allowed if a working copy does not exist. This project contains 44 modules in separate directories. So the best way I can figure out how to do this is edit the config file, import the project, set the svn:ignore property on each of the 44 directories and I'm done. In which case every time I add a module I must remember to repeat setting the svn:ignore. Note: the documentation says the config file accepts whitespace delimited ignores while the svn:ignore accepts new-line separated ignores. I hope that is an error since I do not know if I can type a new line at my command prompt. Very tedious, unless, of course, there is a better way. JM
RE: Need Help : Purging very old (/unwanted) revisions
Hello, You can create a new repository then get the second to last revision and use that to create a new project in that new repository. Then create a working copy and replace it with the current revision. Then do a commit and you're done. JPM From: vinay modi [mailto:modivi...@gmail.com] Sent: Tuesday, September 04, 2012 4:04 PM To: users@subversion.apache.org Subject: Need Help : Purging very old (/unwanted) revisions Hi My organization's svn repository size has grown too large and most of the old revisions of documents are never being used. Consider I have 4 documents in my repository, of which I have 10 revisions: 4 for document A 3 for document B 2 for document C 1 for document D. Now, I want to keep only the last 2 revisions of all documents i.e 2 for A, 2 for B, 2 for C and 1 for D.. Is there any way I can achieve this in my subversion repository? Thanks in Advance Regards Vinay
RE: svn merge help
I can be wrong because I'm struggling with this myself, but shouldn't rev 9995 already include all the prior changes? JPM From: Douglass Davis [mailto:dda...@northcarolina.edu] Sent: Tuesday, August 28, 2012 3:55 PM To: users@subversion.apache.org Subject: svn merge help Hi, Client is svn, version 1.6.11 (r934486) I read the manual, but I'm not sure what I'm doing wrong. I copied https://mydomain/services/trunk (services) to https://mydomain/online/trunk (online) at revision 9884. There were several bugfixes made on services that I wanted to put in online. Some I just edited the code manually in my working copy of online. Right now, what I would like to do is just take the changes from revisions 9938 up to and including 9995 (about 20 revisions) from services (https://mydomain/services/trunk), and apply those to online (https://mydomain/online/trunk). So, I go to my working copy of online. I have tried this: svn merge -r 9937:9996 https://mydomain/services/trunk . And that just gives me the changes from revision 9995 of services. I revert, then tried svn merge https://svn.northcarolina.edu/os/cms/apps/services/trunk@9937 https://svn.northcarolina.edu/os/cms/apps/services/trunk@9995 . And still it only gave me the changes from 9995. How do I get all changes from 9937-9995 (inclusive) and apply them to my working copy of online? Thanks, Doug
How to import
Hello I'm trying to figure out how to use the import command in a windows environment. I'm reading the book but the documentation is unclear as is the help. Perhaps someone can clarify it for me. For example the help says: Import [PATH] URL I need to import from one path to another. A path can also be referred to as an URL. However when both terms are used in an example then that implies a difference. What's the difference? Or is there none? I see no explanation anywhere. Too bad neither the help nor the book explain what the command expects. I wish to add some files to their own folder called iERP_v2 under the Repositories (shared) folder but can't find any information on that at all. How do I create a folder? From the server? Is there a command? Will import do it? The svn server lives on host Vm006 which I also mapped to drive s. A repository exists (called Repositories) with folders in it that I created with VisualSVN. Unfortunately VisualSVN is inadequate for our needs so I need to learn the archaic commands. The code I wish to import lives on a mapped network drive; g. I tried issuing the command from the directory where the files reside: \\Vm006\RepositoriesFails Invalid URL '//vm006/Repositories' //Vm006/RepositoriesFails Invalid URL '//vm006/Repositories' \\Vm006\$e\Repositories Fails Error resolving case of '\\Vm006\$e\Repositories' //Vm006/$e/Repositories Fails Error resolving case of '\\Vm006\$e\Repositories' s:\Repositories Fails Invalid URL 'S:/Repositories' s:/Repositories Fails Invalid URL 'S:/Repositories' s:\Repositories\iERP_v2 Fails Invalid URL 'S:/Repositories/iERP_v2' s:/Repositories/iERP_v2 Fails Invalid URL 'S:/Repositories/iERP_v2' Then I tried changing directories to the SVN server but received the same results. svn import g:\code\intuitive projects\projects Vm006\Repositories Fails svn: E205000: Invalid URL 'Vm006/Repositories' etc. It seems to ignore what kind of slash is used but all the logical options failed so I tried the illogical ones also. They all failed. John Maher
RE: How to import
@Thorsten: Thanks for taking the time to respond, I do appreciate it, I should provide more background. I did use tortoise. Then I lost a bunch of source code trying to do a merge probably because I didn't know what I was doing. I started with version 1. Branched for version 2. Enhanced version 1 then merged to version 2 and somehow killed the enhanced version 1. All I could get was old version 1 or new version 2 in effect prohibiting any more enhancements to version 1 (I didn't want to dig through version 2 to find the changes and put them back in version 1 with the release of version 2 so close). I have now completed version 2 and would like to get it under source code control without any code loss. That is why I wished to learn the command line version, it seems knowing how the CLI works will tell me how svn works better than a third party product. Am I right or wrong? Besides the book that I am reading only mentions command line options so it is incompatible with anything else. To top it off, I can get clarifications for the CLI here but the support for the other products stinks. Thanks for the link http://en.wikipedia.org/wiki/Uniform_resource_locator, however it indicates the problem I was trying to resolve earlier. Wikipedia claims a URL points to a resource on the internet. We don't store our repository on the internet. We store it on our intranet. So either we can't use the command line to import files, which seems unlikely. Or svn uses the term URL differently than Wikipedia, very likely. I have seen numerous instances where different sources use terms differently. What does the svn book (http://svnbook.red-bean.com/en/1.7/svn-book.pdf) mean when it uses the term? Actually I don't need to create a directory, I need to create a repository. Looking at the server now it looks like we have a separate repository for each project with folders such as branches, tags and files stored in the root so we can't use a repository for more than 1 project. Is this incorrect? So it looks like I need to create a repository before the import. I issued svnadmin create to make a new repository, and it succeeded but only when issued when the current directory was the repository directory. Actually it appears to succede anywhere, but I doubt the folders it creates are useable if they are not on the server. Import still fails though. See below. @Andy: Thanks for replying, but we do have a proper server set up using VisualSVN Server. But the problem remains. Also I would like to point out that it is not helpful to use a word in its own definition: A URL is always a properly-formed URL. That doesn't tell me much. Care to claify? Realizing I needed a new repository, I issued: svnadmin create iERP85_v2 WORKED!! svn import g:/code/intuitive projects/projects file://Vm006/Repositories/iERP85_v2 svn import g:/code/intuitive projects/projects svn://Vm006/Repositories/iERP85_v2 svn import g:/code/intuitive projects/projects http://Vm006/Repositories/iERP85_v2 All fail with Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options It appears that the import command has an undocumented required parameter, or something else is wrong, because when I provide the parameter I get different errors. import g:/code/intuitive projects/projects file://Vm006/Repositories/i erp_v2 -m JPM svn: E180001: Unable to connect to a repository at URL 'file://vm006/Repositories/ierp_v2' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository 'file://vm006/Repositories/ierp_v2' import g:/code/intuitive projects/projects svn://Vm006/Repositories/iE RP85_v2 -m JPM svn: E730060: Unable to connect to a repository at URL 'svn://vm006/Repositories/iERP85_v2' svn: E730060: Can't connect to host 'vm006': A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. import g:/code/intuitive projects/projects http://Vm006/Repositories/i ERP85_v2 -m JPM svn: E175002: Unable to connect to a repository at URL 'http://vm006/Repositories/iERP85_v2' svn: E175002: OPTIONS of 'http://vm006/Repositories/iERP85_v2': could not connect to server (http://vm006) Thanks again for your time. John Maher
RE: Branching/Merging Strategy
Yes it was helpful. Thanks. -Original Message- From: Varnau, Steve (Seaquest RD) [mailto:steve.var...@hp.com] Sent: Monday, February 20, 2012 12:40 PM To: John Maher Cc: users@subversion.apache.org Subject: RE: Branching/Merging Strategy -Original Message- From: John Maher [mailto:jo...@rotair.com] Sent: Monday, February 20, 2012 5:37 AM To: Varnau, Steve (Seaquest RD) Subject: RE: Branching/Merging Strategy Hello I'm new to subversion and have two questions. 1) How do I properly make a post? I get these e-mails but no where do I see any information on how to put a post up. Just mail to users@subversion.apache.org. I've copied the list on this response. 2) I had a problem with a merge where code from one function had gotten placed in another along with all kinds of other problems to the point where I do not feel comfortable with the merge. It took a week going through backups to fix the code. I would like to learn how to use it without problems but something in the statement confused me. The statement A common pattern is that the trunk is for new feature development doesn't make much difference between using the trunk for production and branches for future releases if the trunk and branch are just labels that have no meaning. Or is there some hidden meaning that I do not know about? The naming does not really matter. In my project, what we treat as our trunk is not really named trunk. But that is the common terminology used in the list. The pattern of usage is the key thing, not the names. So one place where all the changes get integrated back together into a common source tree is the logical trunk, whether we call it trunk, branch/main, or bob. The original poster is using a pattern where the trunk is what is in production. So when a feature is ready to go into production, they merge it in. I am suggesting that a more common method is the reverse -- when something is ready for production, branch it off. For instance, the subversion software itself has to support old releases that are in the field, not just one production version. So, features are developed on the trunk and when getting ready to release, they create a release branch. Fixes can be made on those branches, released, and also merged back to trunk for future releases. But the trunk is never synched (merged) back to those release branches. So in this model, there is a main line of development (trunk), and two kinds of side branches. Release branches and development branches. As I described above, release branches are not synched up to the trunk, but development branches are synched before they are reintegrated. Nothing magic in the naming, and subversion does not keep track of which branches are what types. It is just in the merging patterns used. You are left to keep track of that by naming schemes, etc. Thanks Mar Hope that helps. -Steve -Original Message- From: Varnau, Steve (Seaquest RD) [mailto:steve.var...@hp.com] Sent: Sunday, February 19, 2012 1:34 PM To: leojhartiv; users@subversion.apache.org Subject: RE: Branching/Merging Strategy From: leojhartiv [mailto:leo.h...@gmail.com] Sent: Saturday, February 18, 2012 8:36 AM To: users@subversion.apache.org Subject: Branching/Merging Strategy I wanted to describe our branching and merging strategy and hopefully get some feedback. We are using Subversion Server 1.6. Currently we manage trunk plus up to 3 other branches: * trunk: always represents what's in production * 1.0.0, 2.0.0, etc: represent long-term (normally quarterly) development branches * 1.1.0, 1.2.0, etc: represent monthly maintenance branches * 1.0.1, 1.0.2, etc: represent deploy immediately hot fix branches Our process of creating a branch is to svn copy from trunk into the new branch. So in the case of a new development branch: svn copy http://myrepos/trunk; http://myrepos/branches/2.0.0; Or in the case of a new maintenance branch: svn copy http://myrepos/trunk; http://myrepos/branches/1.1.0; When either branch has been deployed to production, we use a svn merge reintegrate to merge it back into trunk. So in the case of the maintenance branch: svn --accept p merge --reintegrate http://myrepos/branches/1.1.0; http://myrepos/trunk; We then merge trunk into any future releases still pending and resolve any conflicts: svn merge http://myrepos/trunk; http://myrepos/branches/2.0.0; This has worked well in most instances. The reintegrate option almost never has any conflicts. However, when we got close to deploying 2.0.0 we ran into trouble. 1 or 2 weeks before we were ready to launch 2.0.0, some of the team needed to start work on 2.1.0 and 3.0.0 while others were finishing up on 2.0.0. The normal process would be to create 2 branches off trunk: svn copy http://myrepos/trunk; http://myrepos/branches/2.1.0; svn copy http://myrepos/trunk; http://myrepos/branches/3.0.0
