Code. Best SVN gui client for OS X?

1 to 20 of 33

  1. Previous.
  2. 1
  3. 2
  4. Next.
  1.  
    Just (finally) hooking up with SVN (via Beanstalk for now).
    I'm wondering which client to grab and make my (initial) client for interaction with SVN.

    I installed Versions a while back, but never actually got round to using it (beyond launching it once).
    Trial period has expired, so no more testing for me.
    Don't mind buying it if it's the clear front-runner.

    I want to be babied, so as to minimise the learning curve.
    If choosing the right client can do that, then…


    TIA
  2.  

    I'm a big fan of Versions, though there are a couple of cornerstone fans in the office. Timeline view in Versions is slick, and it's pretty simple: I'm sure some other clients have loads more features, but I'm all for simplicity and ease of use, and Versions has that in spades.

  3.  
    I have played with them all (at least the ones with decent GUIs). I find Cornerstone to be head and shoulders above the rest, with Versions lagging slightly behind. A recent UI update has made Cornerstone even better.

    I use it with Beanstalk which I am really happy with as a service. I would highly recommend it.
  4.  
    Thanks, chaps.

    Coda is my dev app of choice and reportedly Versions plays real nicely as part of a Coda + Versions + Beanstalk setup.
    Can Cornerstone integrate well into that config (in place of Versions, naturally)?
  5.  
    Doesn't coda have inbuilt svn?

    I won a years free Beanstalk account about 6 months ago, but have only just started using it properly when I started working freelance on Nov 1st. I emailed them and they reset the start date to then which was really kind. They didn't have to. It was a lovely gesture.
  6.  
    "Doesn't coda have inbuilt svn?"

    It does.
    Some seem to say that Coda's own ability to integrate with Beanstalk works perfectly well, but others seem to 'drool' over the Coda + Versions + Beanstalk combo.

    I don't know enough to make even a rash decision.

    I want anything that's going to help flatten out whatever learning curve.

    Beanstalk recommends Versions and Coda doesn't seem to have a way for me to hook into the Beanstalk repository based on the info Beanstalk seems to have given me. (Coda's help/support files on this matter are quite light on the ground and mention command line, which has me running in any other direction.)
  7.  
    From Coda help (search: svn)

    Changing source control options

    To change source control options:

    Choose Coda > Preferences...
    Click Files


    Subversion Tool Path

    This field lets you customize the path to the Subversion command line client that is used for Subversion actions. By default, Coda will use the Apple-supplied svn binary located in /usr/bin.

    Source control changes

    When you add, move, copy, or delete a file within a source-controlled folder, you typically also need to notify the source control system that this change has occurred. This preference determines whether Coda performs this source control notification automatically, asks you first, or just ignores such changes.


    whoooosh!!
  8.  
    Another one for Versions here. Made the switch from PC and Tortoise in May and had a look at a few. Versions was the nicest by far. Interface is very pretty and very easy to use. Although there is one big drawback with Versions. It does not do merges. I use Smart SVN for that. Even with that drawback I really like Versions.

    Have not tried cornerstone though. Will have to have a look at that.
  9.  
    Has anyone mentioned Versions?
  10.  
    During the day of the Build Conference last week, there were tweets about Versions being 50% off for just that day - I bought it, coz it was 20 quid or something. I hadn't settled on which was best from everything I had read, so I'm glad this thread seems to be confirming my choice was OK (although it seems like they are both pretty good).

    I have yet to get my head around SVN, despite trying really hard a few times and using my best concentratey face and everything, so I may end up never using it.
  11.  
    I'm a Cornerstone man myself, using Springloops.com as the repository. Works pretty well. Once I got my head round how to use it. Which I'm still struggling with!
  12.  
    Coughed out for Versions to see if it fits.
  13.  
    @phil - damn! I was hoping you were going to teach me! :P
  14.  
    Not have much of a chance to try out Versions/SVN today, but have a question…

    If I set up a Coda + Versions + Beanstalk combi on both the work machine and the laptop, do I need to be aware of any gotchas regarding local 'checkout' files?
    Obviously, I'll need to know that I'm working on the latest versions available (and have access to historical versions).
    Is it a matter of checking files back in at the end of a session (or whatever one does to relinquish editorial control or save back to the repository*)?


    (* still probably getting the mental model of SVN wrong)
  15.  

    Hey Bill,

    First thing is to probably rethink your use of the word 'checking in/out'. It tripped up my mental map for ages when I first started using SVN.

    This is how you'd typically work with some repo code in Versions.

    1. Add a repository bookmark -- this just connects to the SVN server, and will let you browse the repository, see the timeline, and even perform operations such as moving and duplicating files/folders in the repo.
    2. Now Checkout a Working Copy of some code. Select a folder/file in the repository (it'll usually be the TRUNK, or a specific BRANCH or TAG), right-click it, and select 'Checkout...'
    3. Seelct a location for the checkout -- this can be any folder on your machine, and you can even change the name of the folder that gets checked out (by default it'll be whatever the folder is called in SVN). If I'm checking out the TRUNK of the repository 'BigProject', I normally call my checked out folder something like 'BigProject_TRUNK'
    4. The newly checked out Working Copy will now appear underneath the repository bookmark. Clicking on it will show you the file/folder structure that's been checked out.

    Some hints:

    • If you edit a file, it will be flagged as modified in the working copy view
    • If you add a new file/folder, it will appear with a question mark in the gutter of the copy view -- highlight the file and click the 'add' button at the top-right of the application to add this to the repo.
    • If you delete a file/folder, you also need to delete it (in fact, you should delete it in the first place) using the delete button in Versions.
    • Note that the fact that it's flagged a changed file/added file/deleted file (you can view only changed files using the little toggle above the file-tree -- I live with that flicked to 'changed') means that it's changed in your Working copy only. In order to send that change to the SVN server, you need to Commit the change. Do that by selecting the file(s) and hitting 'Commit'.
    • Update will update your working copy to the latest version from SVN. It won't overwrite your changes, but update the bits of the file around it (if possible) or flag a conflict. If you select a specific file/files/folder, Update will only update that file/files/folder.
    • Revert will revert a changed file to a given revision (you select which one)
    • The HEAD revision is simply a shortcut way of saying the lastest revision.
  16.  
    Outstanding, Jord. Truly appreciated.

    There are still one or two things that I'm not clear about, but I'll figure them as I go.
    I've started a test repository to orient myself on before I let myself loose on real dev files.

    Once I get a better grip, I think I may try to submit a blog post somewhere (for Google to pick up), as there seems to be no beginner's/designer's/idiot's guide to SVN using the Coda + Versions + Beanstalk combination - just the kind of article that I would have appreciated.

    (I'd actually like to reduce my direct involvement with dev, but of course, it's always good to have access and overview to be able to contribute when the want/need arises.)
  17.  

    Just couple more things.

    Don't commit at the end of a session, commit as you go. If you've completed a feature that's a good time to do it, then you can give your commits sensible comments - "Feature x completed", "Tidied up the output on Y", "Z bug fixed" etc.

    Your working copies are totally independent of each other and the server has no idea what changes you are making. eg: If you make a change on box 1's working copy, box 2's working copy will be unaware of that change until you commit that change back to the repository.

    I take it you've found the Red Book? It really is worth reading through the earlier chapters when you're starting out.

  18.  

    I originally got the idea from a blog post somewhere (don't ask me where) but I tend to prefix my commit messages with one of a few phrases (it makes reference easier):

    • Admin: blah blah blah (for creation of tags, initial commits, deleting folders, etc)
    • New: blah blah blah (for when you're commiting new functionality)
    • Change: blah blah blah (for when you're commiting a change to some prexisting functionality)
    • Tweak: blah blah blah (for when you're commiting a small design/css/functional adjustment)
    • Oops: blah blah blah (for when you're correcting a dumb mistake, like commiting with some debug code left in or something)
  19.  
    Thats a good idea. I'm going to start doing that too.
  20.  
    yeah i like that. will have to start doing that too. Only started commenting my changes a few month ago (not such a big issue as I work by myself). Still have loads that just say "minor fix". does make it a pain when trying to find something.

1 to 20 of 33

  1. Previous.
  2. 1
  3. 2
  4. Next.
 
Sponsors: Web Design London