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 Subeclipse....I 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 success.
However, it's unlikely we'll see a commercial app for the most common DVCS tools today, because they're all under GPL, and thus can't be linked to directly from proprietary code. Essentially, it would have to be an open-source effort, and the developers that have the skills to create a truly polished Mac app are too occupied — with either (a) surviving as indie developers or (b) making money hand over fist with Mac and iPhone apps — to devote the time required for creating such an app. Well, the other option is that they are so accustomed to the command line that they see no need to create a GUI to do the same thing. :-)
Valeu, - Quinn
smime.p7s
Description: S/MIME cryptographic signature
