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 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/versions?hl=en -~----------~----~----~----~------~----~------~--~---
