5 ms·

SourceTree is one of the few products I use where things have got a lot buggier as time moved on.

by locusm 9y ago

nwatson 9y ago
I work on a huge codebase and SourceTree handles it quite well on macOS. A year ago I'd occasionally see updates that were occasionally broken (solvable with a downgrade) but it's been pretty solid lately.
- therealdrag0 9y ago
  I use SourceTree daily and it regularly has very noticable lag on most window-related commands: close a window, open a repository, etc. And a lot of spinning beach-ball. Have you seen any of this?
  - BigChiefSmokem 9y ago
    I have experienced this. I think it happened when Atlassian switched over to WPF for the GUI in version 2 a few month backs. The new GUI has introduced a lot of bugs and performance issues that they still seem to be trying to figure out. The visualization features are amazing though but could use a little bit more design.
- locusm 9y ago
  I find its OK on macOS but on Windows the latest thing is the delay in displaying modified files. Newly modified files sometimes take minutes to turn up.
  - julianz 9y ago
    You have to click into the Sourcetree window for changes to show up. It updates instantly for me when I do that.
  - mark-r 9y ago
    Minutes? Today I hit F5 to refresh the window, and it still missed a checkin from 10 minutes earlier. If you're talking about locally modified files, I use the integration with Visual Studio to manage those and it is doing an OK job. The only gripe I have with it is that you can't change an already staged file or those changes won't get checked in. I don't remember it working like that a year ago so something must have changed.
whatever_dude 9y ago
Agreed. I use them a lot and love how it makes some advanced stuff much easier (committing hunks, interactive rebases). They're also cross platform, which is great. Still, it's incredible how crappier it gets over time. It feels like every year there's some kind of new major refactor or UI framework refresh that just destroys whatever little stability the application had, as if a new lead comes in and decides to start everything from scratch. As an engineer I kinda understand the reasoning (using a nuclear bomb to get rid of tech debt), but it's pretty baffling from a product lifecycle standpoint. I wish they had a more stable model and were charging for registration really. I'd gladly pay them $50 or whatever for some modicum of stability.
sdiupIGPWEfh 9y ago
I've been saying this for a while. SourceTree used to be fantastic a couple years ago. Yet each update since those glory days has brought not just bugs, but a worse overall user experience.
- contingencies 9y ago
  It's because they were purchased by Atlassian. I mostly only ever used it for branches, cherry picking and conflict resolution, and it was awesome for that. I don't use it now, and I don't use branches or cherry picking. My personal philosophy is that I am not keen on branches: never have been, never will be. I see repositories as a two pizza team concept. If you need branches, you should split the repo, make more iterative changes, or look at establishing or improving a test suite. It keeps things simple and cognitively low overhead for everyone (as per the sqlite team's comments).
  - AndrewDucker 8y ago
    I find branches really easy for ensuring QA. I work on a branch, raise a merge request to master, let my colleague do a check and point out any issues and then merge it once we're both happy with it. He does the same thing for me to check. Other than that, no branches.
    - contingencies 8y ago
      Whatever works. However, I am not keen on such hoops. Objectively, relative to "just commit to master" that is a pretty high overhead contribution process. It is not immediate, needs to wait for another human to be around and mentally present, demands some sort of QA standards are created and commonly understood, and creates the need to make and manage a forum for listing and discussing merge requests. You could get some of the way and retain instant feedback with automated tests, yet remove a lot of the overhead.

SourceTree is one of the few products I use where things have got a lot buggier as time moved on.

by locusm 9y ago

SourceTree is one of the few products I use where things have got a lot buggier as time moved on.

I work on a huge codebase and SourceTree handles it quite well on macOS. A year ago I'd occasionally see updates that were occasionally broken (solvable with a downgrade) but it's been pretty solid lately.

therealdrag0 9y ago
I use SourceTree daily and it regularly has very noticable lag on most window-related commands: close a window, open a repository, etc. And a lot of spinning beach-ball. Have you seen any of this?
- BigChiefSmokem 9y ago
  I have experienced this. I think it happened when Atlassian switched over to WPF for the GUI in version 2 a few month backs. The new GUI has introduced a lot of bugs and performance issues that they still seem to be trying to figure out. The visualization features are amazing though but could use a little bit more design.
locusm 9y ago
I find its OK on macOS but on Windows the latest thing is the delay in displaying modified files. Newly modified files sometimes take minutes to turn up.
- julianz 9y ago
  You have to click into the Sourcetree window for changes to show up. It updates instantly for me when I do that.
- mark-r 9y ago
  Minutes? Today I hit F5 to refresh the window, and it still missed a checkin from 10 minutes earlier. If you're talking about locally modified files, I use the integration with Visual Studio to manage those and it is doing an OK job. The only gripe I have with it is that you can't change an already staged file or those changes won't get checked in. I don't remember it working like that a year ago so something must have changed.

whatever_dude 9y ago

Agreed. I use them a lot and love how it makes some advanced stuff much easier (committing hunks, interactive rebases). They're also cross platform, which is great. Still, it's incredible how crappier it gets over time. It feels like every year there's some kind of new major refactor or UI framework refresh that just destroys whatever little stability the application had, as if a new lead comes in and decides to start everything from scratch. As an engineer I kinda understand the reasoning (using a nuclear bomb to get rid of tech debt), but it's pretty baffling from a product lifecycle standpoint. I wish they had a more stable model and were charging for registration really. I'd gladly pay them $50 or whatever for some modicum of stability.

sdiupIGPWEfh 9y ago

I've been saying this for a while. SourceTree used to be fantastic a couple years ago. Yet each update since those glory days has brought not just bugs, but a worse overall user experience.

contingencies 9y ago
It's because they were purchased by Atlassian. I mostly only ever used it for branches, cherry picking and conflict resolution, and it was awesome for that. I don't use it now, and I don't use branches or cherry picking. My personal philosophy is that I am not keen on branches: never have been, never will be. I see repositories as a two pizza team concept. If you need branches, you should split the repo, make more iterative changes, or look at establishing or improving a test suite. It keeps things simple and cognitively low overhead for everyone (as per the sqlite team's comments).
- AndrewDucker 8y ago
  I find branches really easy for ensuring QA. I work on a branch, raise a merge request to master, let my colleague do a check and point out any issues and then merge it once we're both happy with it. He does the same thing for me to check. Other than that, no branches.
  - contingencies 8y ago
    Whatever works. However, I am not keen on such hoops. Objectively, relative to "just commit to master" that is a pretty high overhead contribution process. It is not immediate, needs to wait for another human to be around and mentally present, demands some sort of QA standards are created and commonly understood, and creates the need to make and manage a forum for listing and discussing merge requests. You could get some of the way and retain instant feedback with automated tests, yet remove a lot of the overhead.