Re: capitalization in filenames -- bad bug
On Apr 12, 8:52 pm, kerri miller ke...@vholdr.com wrote: Working in the web world, I'm constantly annoyed by the Mac not understanding that capitalized versions of letters are NOT the same as their lower-case counterparts :S My guess is that this is an OS issue this might be gruesome to code defensively for. -k- This is not an OS issue – it's a feature. Logically, most lay-people will assume DaVe = dave = Dave and the Mac has always been intended as the computer for the rest of us. It's intended behaviour. The HFS+ filesystem used by default on Macs is case insensitive. Simple fact. So, therefore I can't understand how this is not a bug with handling case insensitivity and how things have become deleted. Does the repository reside on a case sensitive remote server? -jp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: svn 1.6 support?
Unfortunately I am not getting the benefit of my paid registration while I wait for Versions to catch up with Subversion. On Apr 3, 2009, at 3:15 PM, Lorin Rivers wrote: I'm eagerly awaiting news on support for 1.6. Any word? I'd love to be able to provide Versions with my current svn libs and so forth so I don't have to wait for Sofa to update the app. -- Lorin Rivers Mosasaur: Killer Technical Marketing http://www.mosasaur.com mailto:lriv...@mosasaur.com 512/203.3198 (m) -- Lorin Rivers Mosasaur: Killer Technical Marketing http://www.mosasaur.com mailto:lriv...@mosasaur.com 512/203.3198 (m) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: svn 1.6 support?
Me too... i say for my friends to don't buy Versions again. The Eclipse Integrated SVN Control Plugin is more better. I think, why i bought and spend my money with Versions. They no add any value for me. I'm repassing this mail for other mail lists and forums. Thankx -- The Future Begins Today Em 14/04/2009, às 15:40, Lorin Rivers escreveu: Unfortunately I am not getting the benefit of my paid registration while I wait for Versions to catch up with Subversion. On Apr 3, 2009, at 3:15 PM, Lorin Rivers wrote: I'm eagerly awaiting news on support for 1.6. Any word? I'd love to be able to provide Versions with my current svn libs and so forth so I don't have to wait for Sofa to update the app. -- Lorin Rivers Mosasaur: Killer Technical Marketing http://www.mosasaur.com mailto:lriv...@mosasaur.com 512/203.3198 (m) -- Lorin Rivers Mosasaur: Killer Technical Marketing http://www.mosasaur.com mailto:lriv...@mosasaur.com 512/203.3198 (m) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
Re: svn 1.6 support?
On Apr 14, 2009, at 12:09 PM, CodeWarrior wrote: Me too... i say for my friends to don't buy Versions again. The Eclipse Integrated SVN Control Plugin is more better. I think, why i bought and spend my money with Versions. They no add any value for me. I'm repassing this mail for other mail lists and forums. Thankx -- The Future Begins Today Em 14/04/2009, às 15:40, Lorin Rivers escreveu: Unfortunately I am not getting the benefit of my paid registration while I wait for Versions to catch up with Subversion. Sorry to be so contrary, but this claim is utter nonsense. If you registered, you can certainly use the app, and nothing is keeping you from getting the benefit of [your] paid registration. What you mean to say is that you want to use SVN 1.6 across the board, and Versions doesn't yet work with 1.6 working copies, so it doesn't work seamlessly with your desired workflow. I can certainly understand the desire to use SVN, but the fact that you'd have to install an additional package on OS X to do so means this problem of your own making. I can't speak for everyone, but for me Versions is simpler than the SVN support in Xcode, and is FAR more usable than either Subversive or Subclipse. (Eclipse in and of itself is a UI and usability abomination, despite the power and convenience it brings, but that's a discussion for another day.) Just try editing SVN properties or browsing history in real-time with Eclipse or Xcode. Especially in Eclipse, doing examining virtually any detailed information (diffs, history, properties, etc.) requires right-clicking and navigating menus. It's no skin off my nose if you want to crawl back to (what I consider) an inferior tool. Despite trumpeting your disdain for Versions, you won't fool anyone who can tell the difference between good UI and bad UI, either. If your only reason for being upset at Versions and telling friends not to buy it is because of 1.6 compatibility, you're doing them and yourselves a disservice. Support for 1.6 is on the way (regardless of whether or not the devs provide a firm date) and the app works just as well under SVN 1.4.x. Claiming that you're not getting your money's worth is absurd — hopefully you paid for Versions based on the feature set it currently has, not based on wishes and promises. Buying software based on what you hope it does, then whining when it doesn't do every bit of what you expect isn't the smartest way to go. It also tends to annoy people who are perfectly happy with the software when the whining is broadcast in public forums. I want to see 1.6 support as much as the next person, and I'd especially love to be able to have Versions link against external SVN libraries seamlessly. However, please realize that bitter complaining doesn't solve the problem — it won't make 1.6 support come any sooner, and it just adds to pile of emails the devs already have to sort through. They're working hard, and they're people with lives too — they're not anyone's slave just because that person happened to purchase a software license, and they don't owe you anything beyond what you received to begin with. They'd be within their rights to charge for updates, or halt development completely — none of us are stockholders or part owners, so let's not act like we have the right to demand a darn thing. /soapbox - Quinn smime.p7s Description: S/MIME cryptographic signature
Re: svn 1.6 support?
Its a good answer for a evil e-mail. Sometimes, things like it cause changes and impact peoples to do the certain things in the right moment. Its one example of things that i say - We have had problems with our svn files administrated by Version. In a certain moment one critical project file was locked and using the Version to unlock do not function. Our Server Admin needed to do it manually even the Version had the Force Unlock (that no have function... not in this very important moment). This crazy lock problem cause much and much problems for my team. And the bad and the ugly was my developer do the unlock using the SubeclipseI will not broadcast just and only because your very smart answer and i do not expect anything more from Version, it will be the unique way to believe again in the Version (next versions..) Excluding this (one) problem (of others), Versions is a good software. If i can suggest one thing: Add support (in a planned future) to other version control systems. It will add more value to your software and will make mac developer owners happy (The Versions have the best UI that i used. It need to be said! Thankx for you answer :) Sorry my English! -- The Future Begins Today Em 14/04/2009, às 17:11, Quinn Taylor escreveu: On Apr 14, 2009, at 12:09 PM, CodeWarrior wrote: Me too... i say for my friends to don't buy Versions again. The Eclipse Integrated SVN Control Plugin is more better. I think, why i bought and spend my money with Versions. They no add any value for me. I'm repassing this mail for other mail lists and forums. Thankx -- The Future Begins Today Em 14/04/2009, às 15:40, Lorin Rivers escreveu: Unfortunately I am not getting the benefit of my paid registration while I wait for Versions to catch up with Subversion. Sorry to be so contrary, but this claim is utter nonsense. If you registered, you can certainly use the app, and nothing is keeping you from getting the benefit of [your] paid registration. What you mean to say is that you want to use SVN 1.6 across the board, and Versions doesn't yet work with 1.6 working copies, so it doesn't work seamlessly with your desired workflow. I can certainly understand the desire to use SVN, but the fact that you'd have to install an additional package on OS X to do so means this problem of your own making. I can't speak for everyone, but for me Versions is simpler than the SVN support in Xcode, and is FAR more usable than either Subversive or Subclipse. (Eclipse in and of itself is a UI and usability abomination, despite the power and convenience it brings, but that's a discussion for another day.) Just try editing SVN properties or browsing history in real-time with Eclipse or Xcode. Especially in Eclipse, doing examining virtually any detailed information (diffs, history, properties, etc.) requires right-clicking and navigating menus. It's no skin off my nose if you want to crawl back to (what I consider) an inferior tool. Despite trumpeting your disdain for Versions, you won't fool anyone who can tell the difference between good UI and bad UI, either. If your only reason for being upset at Versions and telling friends not to buy it is because of 1.6 compatibility, you're doing them and yourselves a disservice. Support for 1.6 is on the way (regardless of whether or not the devs provide a firm date) and the app works just as well under SVN 1.4.x. Claiming that you're not getting your money's worth is absurd — hopefully you paid for Versions based on the feature set it currently has, not based on wishes and promises. Buying software based on what you hope it does, then whining when it doesn't do every bit of what you expect isn't the smartest way to go. It also tends to annoy people who are perfectly happy with the software when the whining is broadcast in public forums. I want to see 1.6 support as much as the next person, and I'd especially love to be able to have Versions link against external SVN libraries seamlessly. However, please realize that bitter complaining doesn't solve the problem — it won't make 1.6 support come any sooner, and it just adds to pile of emails the devs already have to sort through. They're working hard, and they're people with lives too — they're not anyone's slave just because that person happened to purchase a software license, and they don't owe you anything beyond what you received to begin with. They'd be within their rights to charge for updates, or halt development completely — none of us are stockholders or part owners, so let's not act like we have the right to demand a darn thing. /soapbox - Quinn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To
Re: svn 1.6 support?
Hi, Thankx for the answer. About Server Admin run svn unlock --force TARGET Its because here, is this man (Servers' Administrator) that do it, not our developers. Valeu Too! :) -- The Future Begins Today Em 14/04/2009, às 19:44, Quinn Taylor escreveu: On Apr 14, 2009, at 2:24 PM, CodeWarrior wrote: Its a good answer for a evil e-mail. Sometimes, things like it cause changes and impact peoples to do the certain things in the right moment. Its one example of things that i say - We have had problems with our svn files administrated by Version. In a certain moment one critical project file was locked and using the Version to unlock do not function. Our Server Admin needed to do it manually even the Version had the Force Unlock (that no have function... not in this very important moment). This crazy lock problem cause much and much problems for my team. And the bad and the ugly was my developer do the unlock using the SubeclipseI will not broadcast just and only because your very smart answer and i do not expect anything more from Version, it will be the unique way to believe again in the Version (next versions..) Excluding this (one) problem (of others), Versions is a good software. If i can suggest one thing: Add support (in a planned future) to other version control systems. It will add more value to your software and will make mac developer owners happy (The Versions have the best UI that i used. It need to be said! Thankx for you answer :) Sorry my English! -- The Future Begins Today I'm glad my email wasn't taken to personally (or at least nobody has said as much yet!) For some reason, our expectations are usually completely different when buying software versus any physical purchase — we expect it to last forever and get better over time, something we would never expect from a new car, or even a new computer. :-) Sorry to hear you had a productivity-hampering problem with a locked file in the repository. Although functionality may not (yet) be exposed in Versions, you can do everything from the Terminal, assuming you know the right command. I don't think a locked file would require a system admin per se — running svn unlock --force TARGET should do it. As far as adding support for other VCS to Versions, I honestly still don't see the point, and think such support belongs in an entirely different application. Here are a few reasons why: (1) Other systems have entirely different APIs (or sometimes none at all) for interacting with them, so dealing with N different systems would lead to code bloat, which means slower launch and performance, more complexity, and more bugs. (2) Some VCS have a completely different paradigm, including distributed systems like git, Mercurial, and Bazaar. Trying to fit such a different paradigm into the same UI used for centralized VCS would be an exercise in futility and frustration, for users and devs alike. (3) Assuming we stick with similar systems, it makes no sense to implement a brand new CVS client. We're using SVN primarily because CVS sucks, for goodness' sake! Perforce and everything else are essentially niche systems, either due to the price or just market share. (4) The developers' time would have to be split between all the supported systems, which means fewer and less frequent updates for a specific system. Imagine how the Versions users that are already impatient with the speed of updates would feel if updates for things other VCS were added while SVN remained stale. With the same number of developers, product quality could only go down by spreading them thinner. As we say in English, Jack of all trades, master of none. (5) From a business perspective, it doesn't make sense to give away double/triple the functionality as a free update if it requires double/triple (or probably much more) the work without additional compensation. As purchasers, we'd all love free new features. As developers, it would be smarter to release an entirely new app for another VCS. No doubt if the Sofa folks were to do this there would be a great many customers that would be angry without a valid reason. It would make as much sense as being angry you don't get a free 2010 model car that comes out a year after you bought a 2009. Personally, I'd love to see someone create a killer GUI for one or move DVCS systems (git, Mercurial, etc.) since a ton of people are using those tools, including in collaborative OSS development. For most people I know, the main thing holding them back from trying a DVCS is the complexity and steep learning curve of transitioning to a completely different mindset. If there were a tool that could do for DVCS what Versions does for SVN — that is, making it approachable and usable for the masses — I think it could be a runaway
Re: Connecting to local repository from Windows virtual machine
Thanks for the help, Quinn! This got me a lot further. FYI, I had to change the www to _www in the chown Terminal command--apparently, that's the apache username. To get things working completely, I also had to add the following line to /etc/apache2/httpd.conf: LoadModule dav_svn_module /opt/subversion/lib/svn-apache/ mod_dav_svn.so Jeff On Apr 8, 12:37 pm, Quinn Taylor quinntay...@mac.com wrote: IIRC, Windows VM partitions can't read/write on Mac partitions, so file-based access is probably not the best solution. Your two other main options are to host the repository on the network via (1) the svnserve daemon of (2) Apache2 web sharing. I've done both, and neither is terribly difficult, but they involve more work than just using file:// URLs. I'll describe how to set it up with Apache, since the directions are shorter, and I've done it more recently. :-) First, turn on web sharing in the Sharing pane of System Preferences. Create a file at /private/etc/apache2/other/ and call it subversion.conf. (You'll need admin access.) Paste in the following contents: Location /svn DAV svn SVNPath /path/to/local/repository /Location In the Terminal, run the following commands: sudo chown -R www /path/to/local/repository sudo apachectl graceful Apache should then be able to host the repository. (Obviously, you should replace /path/to/local/repository with the actual absolute path to the repository, such as /Users/jeff/Subversion/MyRepository or whatever it is.) You can access it athttp://localhost/svn— if you prefer another path, change it in the Location tag in the Apache config file. Hope that helps, - Quinn On Apr 7, 2009, at 9:10 PM, Jeff H wrote: Is it possible to connect to a local repository created in Versions (on my Mac drive) from a Windows virtual machine (VMWare Fusion)? If so, how? I do my development from Visual Studio and would like to just connect using AnkhSVN/Tortoise. My goal is to have the master code repository on the actual Mac drive and just have local copies on the virtual drive (some project types in Visual Studio require local source code copies for debugging). smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Versions group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~--~~~~--~~--~--~---
