4 ms·
SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to
by w0rd-driven 13y ago
SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to upgrade for 2/x applications so I don't bother.
My first foray into DVCS was Mercurial through Kiln and subsequently TortoiseHg. It's always been great but the introduction of the workbench made everything gel. Having all of the UI in one spot made the experience that much easier. It makes discovery pretty simple compared to TortoiseGit/SVN where you have to know what each menu item maps to.
I've since moved to GIT for work and personal use. GIT flow sold me as hg flow really didn't feel equivalent. I also like submodules as they make proper segregation that much easier. Hg has patch queues which made working on items that weren't commit ready easy. At the time, I didn't understand feature branches so I should likely revisit Hg earnestly. Hg has always had a better user experience where error messages aren't cryptic but there's a wealth of knowledge online to solve any problem in either DVCS at this point. There's some spots in git where you still need the command line where TortoiseHg seemed to cover every need I had.
TFS finally supporting git as a repository, despite its caveats (convert once, only vs2012+) will likely push git pretty far. Having used Ankh, I was never impressed. I'd rather use tortoise + git source control plugin or git extensions as the experience is definitely sufficient. I actually prefer the tortoise workflow over doing it all in vs though but there's a bulk of what we do outside of vs anyway so being proficient there helps tremendously.
- voltagex_ 13y agoHave you tested 4.5? What breaks?
- bgrainger 13y agoA significant problem is that once .NET 4.5 is installed, a developer can no longer test how an app behaves under .NET 4, even if the app still has its target framework set to .NET 4. There are several major WPF bugs fixed in .NET 4.5; developers will no longer encounter those bugs locally, but can only find them on a dedicated .NET 4 testing machine, or (more likely) reported from a .NET 4 customer in the field. There's a detailed writeup of the problem here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c02-de67-47a9-b4ed-fd8b622a7e4a/if-i-target-net-40-but-run-on-a-machine-that-has-net-45-will-net-40-wpf-bugs-still-be-there?forum=wpf http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c... See also this suggestion: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3095632-make-vs2012-not-hide-net-4-0-bugs-when-targeting- http://visualstudio.uservoice.com/forums/121579-visual-studi...