But these days I much prefer Mercurial because it's distributed. You can sign up to notified when the beta is available.įinally, there's one more feature that I'm not allowed to mention yet, but I suspect it will win over independent developers who are still on the fence. I'm told Versions will be available to the general public very soon, but a specific date has not been set yet.
And all of us should care about that because it means developers will ship better software on a shorter schedule. I'm excited to see this app ship because I think developers will finally start to see source control as a way to improve their process, not just another obstacle to shipping.
Any time saved in this area is time that can go into actually writing code instead. So even if you have an existing solution, you can probably still improve your improve your process - particularly for browsing specific versions, running comparisons, and so on. As a dedicated tool, Versions orients its UI and feature set entirely around this particular set of tasks, separate from all of the existing requirements of Xcode as a whole. There is also good SCM support built in Xcode 3, but that's part of a much larger application. Versions abstracts the details of all of that, and just allows you to browse the content.
They're good for basic check in and check out, but they can be incredibly tedious for anything else. But honestly, 'svn ls' isn't a great experience. I use them daily and they're pretty straightforward. Now, certainly some of you are thinking that the svn command line tools work fine, and they do. Pico developed the actual engine of the app, which uses libsvn instead of simply wrapping the command line tools.
Sofa is best known for the excellent Checkout point-of-sale app for Mac OS X, and was responsible for the visual design. Versions is a collaboration between Sofa and a brand new company called Pico. Separately classified certificate errors).If you've never tried to browse svn projects via the command line or a web browser, believe me that this is a vast improvement over the usual experience. Valid certificate) and 'other' (all other not (Expired certificate), 'not-yet-valid' (Not yet
'cn-mismatch' (Hostname mismatch), 'expired' List of 'unknown-ca' (Unknown Authority), trust-server-cert-failures ARG : with -non-interactive, accept SSL serverĬertificates with failures ARG is comma-separated force-interactive : do interactive prompting even if standard input Only if standard input is a terminal device) non-interactive : do no interactive prompting (default is to prompt no-auth-cache : do not cache authentication tokens
password-from-stdin : read password from stdin Systems, other users will be able to see this) password ARG : specify a password ARG (caution: on many operating ignore-externals : ignore externals definitions TO-URL is the (complete) new repository URL to use for PATH.
(You may specify theĬomplete old and new URLs if you wish.) Use 'svn info' to determineĢ. FROM-PREFIX and TO-PREFIX are initial substrings of the workingĬopy's current and new URLs, respectively. Or hostname change) but your working copy still reflects the sameġ. This is used when a repository's root URL changes (such as a scheme Rewrite working copy URL metadata to reflect a syntactic change only. Relocate: Relocate the working copy to point to a different repository root URL. see: D:\dev\svn_monitor>svn help relocate
The svn relocate command fixed the problem. The local working directories were still pointing at the old server. I had just migrated from an older svn version to a newer one, and a newer server. I'm way late to this party, but faced the same problem.