Re: Versions 1.0.4 Beta (Subversion 1.6 support)
To PT-BR, i'm here too! Obrigado. -- The Future Begins Today Em 27/04/2009, às 19:41, Quinn Taylor escreveu: The devs seem to have done a pretty decent job of breaking the app into a number of .nib files, and there is a resource for localized strings, but my first impression is that a bit more behind-the- scenes work remains to be done before localization can take place in earnest. Not only does everything in the app have to use localized strings, but it generally makes synchronizing changes much easier when the UI has settled down sufficiently. From the way the devs are describing their pending changes, my guess is that localization will come, but it will be much better if it comes after the major changes as yet in store. :-) - Quinn PS — João, I'd offer my services at Portuguese translation when the time comes, but you're much more adept than I. Perhaps if you do a pt-br localization I can help get the minor details right? Not that Portugal Portuguese is wrong, just different like English in the UK and USA. :-) On Apr 27, 2009, at 3:09 PM, WalleniuM wrote: hi :) is it possible to translate versionapp? i could translate it to german... On 27 Apr., 22:36, Koen Bok k...@madebysofa.com wrote: Hey Ted, Exactly. Although these 1.6 issues are eating more time then we would like :-/ - Koen On Apr 27, 10:30 pm, TheDO webmas...@thedigitalorchard.ca wrote: Exciting development, but should I assume this is only a stop-gap measure to keep the v1.6 people at bay? It's been a long time for what seems to be a minor upgrade for those of us not yet using 1.6. I'm happy with Versions in its current state, but would like to see some improvements to the interface, which you've stated you're working on (ie. the Commit sheet). Using Subversion 1.5.6, I did a commit of some changed files, and got an error that I've never seen before. [Apr 27, 13:22:58] Commit failed (details follow): No such transaction When I returned to Versions v1.0.3 and tried the same commit, I couldn't do the commit, but rather had to do an Update, at which point it merged the changes into my local files. Weird. ~Ted On Apr 27, 1:08 pm, Koen Bok k...@madebysofa.com wrote: Versions 1.0.4 Beta Hey everyone, A lot of people have been eager to get their hands on Versions with the Subversion libraries 1.6. We've been building and testing this over the last month, but we discovered some issues that kept us back from releasing it to the public. The biggest one is the leaking of processes when using Subversion over SSH (1). So we decided to do a public beta in the group, both to let the people who know what they are doing get their hands on it, and to determine whether it's ready for the big public. If you run into any problems, particularly when you use this build with the Subversion 1.6 libraries, please post about it here and we can figure out any remaining issues together. Thanks! Koen Bok - madebysofa.com Get it here:http://cdn.versionsapp.com/Versions_1.0.4b_63.zip (1)http://lists.apple.com/archives/Xcode-users/2009/Mar/msg00443.html Note: Enabling Subversion 1.6 will upgrade your working copies. To downgrade again you will have to make a new checkout. Release Notes: Versions 1.0.4b (Build 62) - April 27 2009 - Added Subversion 1.6 support (version 1.6.1) - Upgraded Subversion 1.5 libraries to version 1.5.6 - Added support for authentication using SASL - Fixed diffing with BBEdit - Sorting files by name in the Browse view now works like it does in the Finder - Bookmarks are now also sorted correctly when accented characters are present in their names - Fixed a crash that occurred when the subversion config file contains errors that prevent it from being parsed correctly - Added an option to start Versions in “Verbose mode” to log all errors to the Console - An alert is now shown when there are problems retrieving or saving passwords from the Keychain. When it's not convenient to show an alert, the error is logged to the Console instead - Fixed an issue that was causing crash report windows to show up when Versions had not crashed - Added a “Quit Now” button to the “Waiting for transactions to finish...” window - Fixed bugs in registration that occured in very specific scenarios - Updated the Help documentation with an FAQ page - Made the column for revision numbers wider - Various other small improvements --~--~-~--~~~---~--~~ 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: Rename of Versioned Files
Quinn, forget :) Thankx for your answer. -- The Future Begins Today Em 21/04/2009, às 12:18, Quinn Taylor escreveu: On Apr 20, 2009, at 4:55 PM, CodeWarrior wrote: What we are doing now: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - You discover that normal.java need to be normal1.java 4 - Open the Versions, go to the svn and rename (manually). 5 - Go to the trunk that was checked out and update 6 - normal.java is now normal1.java 7 - Inside the eclipse refresh the project, now, normal.java is normal1.java 8 - open normal1.java and correct the type name 9 - everything is not alright Now, i just need to know if Versions do the same of Subeclipse, i need a smart svn tool that reduce clicks and accelerate the job of my team. This is where you've lost me. In step 4, I assume you're right- clicking on the file in Versions and selecting Rename, then typing the new name. Yes, Versions does this correctly. If you're renaming the file in the working copy (which is recommended, so the developer can resolve any build errors before committing) and you run svn status (in Terminal) at this point, you'll see the following: The problem in Versions is not a software problem like a Bug, but that i need to do much think more than just use the Subeclipse, that i just rename inside the Eclipse and the SubEclipse plug-in do the remove normal.java and add the new file (normal1.java). Do u understand now? More work. I just want rename a file inside a eclipse and when open the Versions they automactic remove normal.java and add normal1.java How can Version do it, i don't know. What i'm say? That this is a very good feature that speed up our work, just it, not a Bug report or a Version software problem. You've still lost me. From what you've described in the thread, if people have Subclipse or Subversive installed, renaming inside Eclipse should work. With Eclipse by itself (no SVN plugins) it probably won't. This is totally normal behavior, not a bug in Subversion, Versions, or Eclipse. When you manipulate Subversion working copies, somehow you have to tell Subversion that you're making changes, it can't (and shouldn't) just guess what changes were made. It can be very tricky to tell if a file was moved to a different directory, renamed, or just deleted and a very similar file was added. With no offense intended, if your developers do the right thing, everything will just work. If they want to rename resources that are in Subversion from within Eclipse, they must install a Subversion plugin. (Why Eclipse comes with a CVS plugin by default, but not one for SVN yet is beyond me. It would make life easier for a lot of people.) In my experience, when you have the proper plugin installed and rename in Eclipse, there aren't any problems. I'm not sure exactly what symptom you're seeing in step 9 (everything is not alright) back in Eclipse, but it sounds like renaming in Eclipse avoids the problem. If your developers are using Versions (which they had to download, install, and configure), what's keeping them from taking 5 minutes to install Subclipse/Subversive? If that solves the problems you're having, it seems like a no-brainer. I think this is the feature you're looking for to speed up your work.:-) - 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 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: Rename of Versioned Files
What we are doing now: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - You discover that normal.java need to be normal1.java 4 - Open the Versions, go to the svn and rename (manually). 5 - Go to the trunk that was checked out and update 6 - normal.java is now normal1.java 7 - Inside the eclipse refresh the project, now, normal.java is normal1.java 8 - open normal1.java and correct the type name 9 - everything is not alright Now, i just need to know if Versions do the same of Subeclipse, i need a smart svn tool that reduce clicks and accelerate the job of my team. This is where you've lost me. In step 4, I assume you're right- clicking on the file and selecting Rename, then typing the new name. Yes, Versions does this correctly. If you're renaming the file in the working copy (which is recommended, so the developer can resolve any build errors before committing) and you run svn status (in Terminal) at this point, you'll see the following: - About it: The problem in Versions is not a software problem like a Bug, but that i need to do much think more than just use the Subeclipse, that i just rename inside the Eclipse and the SubEclipse plug-in do the remove normal.java and add the new file (normal1.java). Do u understand now? More work. I just want rename a file inside a eclipse and when open the Versions they automactic remove normal.java and add normal1.java How can Version do it, i don't know. What i'm say? That this is a very good feature that speed up our work, just it, not a Bug report or a Version software problem. Obrigado. -- The Future Begins Today Em 18/04/2009, às 11:49, Quinn Taylor escreveu: On Apr 18, 2009, at 12:06 AM, CodeWarrior wrote: Thankx Quinn. I will check with the admin of company. Just for check, i will post what happens: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (without subeclipse - just eclipse), rename it to normal1.java 4 - Open the Versions, you will see that the Version says that the normal.java is missing This is as expected, because Eclipse has only renamed the file in the file system, but knows nothing about Subversion, so any svn tool will show normal.java as missing and normal1.java as a new, unversioned file. (The same thing would happen if you just renamed the file in Finder.) What i want (to know if Versions do): 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (without subeclipse - just eclipse), rename it to normal1.java 4 - Open the Versions, they will detect that normal.java is now normal1.java 5 - Versions actualize the svn and everything is alright. Please don't expect this to happen without using Subclipse or Subversive. It's easy to think that Subversion should just know what you want to do, but it doesn't. You have to specifically tell it somehow. What happens with Subeclipse: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Subeclipse and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (with subeclipse, rename it to normal1.java 4 - Its automatic renamed in svn. normal.java is deleted, normal1.java is the new normal.java versioned 5 - everything is alright. This is as expected. If Subclipse/Subversive knows the file is in an SVN working copy, it can rename the file properly. (By everything is alright, I assume you mean that Versions and any other SVN tool sees and recognizes the file rename as valid.) What we are doing now: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - You discover that normal.java need to be normal1.java 4 - Open the Versions, go to the svn and rename (manually). 5 - Go to the trunk that was checked out and update 6 - normal.java is now normal1.java 7 - Inside the eclipse refresh the project, now, normal.java is normal1.java 8 - open normal1.java and correct the type name 9 - everything is not alright Now, i just need to know if Versions do the same of Subeclipse, i need a smart svn tool that reduce clicks and accelerate the job of my team. This is where you've lost me. In step 4, I assume you're right- clicking on the file and selecting Rename, then typing the new name. Yes, Versions does this correctly. If you're renaming the file in the working copy (which is recommended, so the developer can resolve any build errors before committing) and you run svn status (in Terminal) at this point, you'll see the following: $ svn status D normal.java A + normal1
Re: Rename of Versioned Files
Thankx Quinn. I will check with the admin of company. Just for check, i will post what happens: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (without subeclipse - just eclipse), rename it to normal1.java 4 - Open the Versions, you will see that the Version says that the normal.java is missing What i want (to know if Versions do): 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (without subeclipse - just eclipse), rename it to normal1.java 4 - Open the Versions, they will detect that normal.java is now normal1.java 5 - Versions actualize the svn and everything is alright. What happens with Subeclipse: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Subeclipse and create a new Java project to work on it (Close the Versions) 3 - Inside the eclipse (with subeclipse, rename it to normal1.java 4 - Its automatic renamed in svn. normal.java is deleted, normal1.java is the new normal.java versioned 5 - everything is alright. What we are doing now: 1 - Suppose that exist normal.java in a svn 2 - you check out it using Versions and create a new Java project to work on it (Close the Versions) 3 - You discover that normal.java need to be normal1.java 4 - Open the Versions, go to the svn and rename (manually). 5 - Go to the trunk that was checked out and update 6 - normal.java is now normal1.java 7 - Inside the eclipse refresh the project, now, normal.java is normal1.java 8 - open normal1.java and correct the type name 9 - everything is not alright Now, i just need to know if Versions do the same of Subeclipse, i need a smart svn tool that reduce clicks and accelerate the job of my team. Obrigado! -- The Future Begins Today Em 18/04/2009, às 03:16, Quinn Taylor escreveu: We're talking about the same thing. When Versions displays the state of your working copy — including what has been modified, added, deleted, renamed, etc. — it's just a graphical view of information that you can view using the `svn status` command. When Eclipse or Versions renames a file, it actually performs the equivalent of `svn move old/path/name new/path/name` on the working copy. This is what makes it possible to use different SVN tools on the same working copy. The problem comes in when one tool doesn't do exactly what it's supposed to. I'm not saying that Versions is always right (after all, it is a newish product, and quite a few bugs have already been squashed) but my experience is that when I rename using Terminal or Versions, the 2 tools have always been in sync. Same with Xcode, as far as I can tell. That's why I suppose I'm suspicious of Subclipse in this case. If you made the change inside Eclipse, and Versions doesn't display what you'd expect, always turn to Terminal to see if the most basic SVN tools agree with Eclipse or not. That will help you know if the rename is being done correctly. Espero que isso ajuda, - Quinn On Apr 17, 2009, at 9:25 PM, CodeWarrior wrote: Quinn Thankx for your answer but i'm not the programmer and not the admin, what i need is not know the status, but rename inside eclipse and Version automatic detect it and rename the file in the SVN and NOT appear missing. It's possible? Obrigado. Em 17/04/2009, às 17:13, Quinn Taylor escreveu: The first thing I'd do is fire up Terminal in that directory and type 'svn status'. Make sure that the rename (modeled as a delete and add-with-history, shown with a plus sign in column 3) is shown. Unless Subclipse has actually flagged the change in the working copy, you can't expect Versions to pick up on it. If so, the next thing I'd do is refresh the working copy view in Versions to see if the change is reflected. On Leopard, Versions listens to FSEvents for working copies, so it automatically gets notified when files change and knows to update accordingly. I'd be curious to know what the actual state of the working copy is when you're seeing this symptom in Versions - Quinn On Apr 17, 2009, at 10:36 AM, CodeWarrior wrote: I work with Eclipse and in this week we pass a big problem again. My developers rename the archive.java inside the Eclipse to ArchiveDao.java (for exemplo). When they open the Versions, Version say that file is missing and begin our problem. In a subeclipse, when we rename a file, its automatic rename in svn too. I think that the Versions have this basic (for me) feature. Its have or have not and how can we pass it? Its function like: Version file Monitor Versioned File If change (rename) make rename in svn commit Thankx! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups
Re: Rename of Versioned Files
Quinn Thankx for your answer but i'm not the programmer and not the admin, what i need is not know the status, but rename inside eclipse and Version automatic detect it and rename the file in the SVN and NOT appear missing. It's possible? Obrigado. -- The Future Begins Today Em 17/04/2009, às 17:13, Quinn Taylor escreveu: The first thing I'd do is fire up Terminal in that directory and type 'svn status'. Make sure that the rename (modeled as a delete and add-with-history, shown with a plus sign in column 3) is shown. Unless Subclipse has actually flagged the change in the working copy, you can't expect Versions to pick up on it. If so, the next thing I'd do is refresh the working copy view in Versions to see if the change is reflected. On Leopard, Versions listens to FSEvents for working copies, so it automatically gets notified when files change and knows to update accordingly. I'd be curious to know what the actual state of the working copy is when you're seeing this symptom in Versions - Quinn On Apr 17, 2009, at 10:36 AM, CodeWarrior wrote: I work with Eclipse and in this week we pass a big problem again. My developers rename the archive.java inside the Eclipse to ArchiveDao.java (for exemplo). When they open the Versions, Version say that file is missing and begin our problem. In a subeclipse, when we rename a file, its automatic rename in svn too. I think that the Versions have this basic (for me) feature. Its have or have not and how can we pass it? Its function like: Version file Monitor Versioned File If change (rename) make rename in svn commit Thankx! -- The Future Begins Today --~--~-~--~~~---~--~~ 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?
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
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
