|
I use FogBugz for issue tracking and VisualSVN (on my own server) for source control
|
|
|
|
|
I believe that was the first FogBugz comment today, Are you happy with it? Any specific gotchas?
|
|
|
|
|
FogBugz - I love it, I love it, I love it!
|
|
|
|
|
|
|
Why is that obvious?
I read Albert Holguins rant higher up in the Lounge, and he doesn't seem to happy with it.
|
|
|
|
|
Well, Jorgen, git may be somewhat fiddly, but it unifies teams both locally and remotely; it can be used by a lone programmer all the way up to a very large team, in case you grow, and this team can mix and match remote and local workers.
By using configuration a build-master can be appointed as with other systems, and it works with various OS's, so your team can do cross-platform development seamlessly.
Also it's free and integrated into Visual Studio from 2012 up, available in 2008 and 2010 also, if that's where your team works.
|
|
|
|
|
I'm surprised git didn't come up earlier in this thread.
GIT is a basterd to learn. Haven't found any tool that spares you learning the command line, the Linux culture is strong in this - and grating. Change in mindset may be steep.
Yet it also allows a few workflows that feel like magic.
For me, the biggest feature is interactive rebase: allows you to commit frequently and "dirty", then reorganize and clean the history before publishing it to public.
Conceptually, many commands do not operate on verisons, but on changes between versions - such as cherry-pick and rebase to move changes from one branch to another.
git blame is great for those "where the eff does this line come from?" moments.
It does change your workflow in a way I would miss with another tool.
|
|
|
|
|
It's "GIT is a basterd to learn" vs "I need those extra functions?
|
|
|
|
|
What I tried to convey is that it's not just *extra functions* but that is has a fundamental (supposedly net-positive) influence on the whole development process, one that isn't easily captured in "X% increased productivity" (which also means evaluation is subjective, so yes, YMMV.)
Mercurial is probably mature enough now to be a viable alternative. I'd still recommend because - despite obvious drawbacks - it has become the de facto standard in a wide range of the dev world.
|
|
|
|
|
SourceTree by Atlassian makes git much more approachable for windows users.
|
|
|
|
|
peterchen wrote: Haven't found any tool that spares you learning the command line, the Linux culture is strong in this - and grating.
It doesn't completely spare you, but source tree is good enough that my web designer wife doesn't have much trouble with git, and BTW don't ever get in a situation where your wife is on you about committing code.
|
|
|
|
|
Technical and life advice in one package!
|
|
|
|
|
I think the only time I touched the git shell while using TortoiseGIT on a few small projects was when working with someone who used the CLI version; at which point to get something I didn't know how to do done the 1st time it was easier to type his magic in now and find the equivalent in Tortoise later.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
It all comes down to your scenario.
My personal preference would be:
Source control - Github/BitBucket
Build server - Team City
Deployment server - Octopus Deploy
Issue tracking - Github Issues/Trello/Jira
All are free/minimal cost for small teams.
TFS could replace all of these but it does tie you to the MS workflow somewhat. My advice would be to shop around and try out a few different systems first. You may find that TFS fits your workflow but you may also find that a combination of other tools does it better. Does your source code need to be in the cloud? Does it need to be private? Do you need to be able to access issue tracking remotely? These are all things that are specific to your business and will define which tools are most appropriate.
|
|
|
|
|
At work, TFS for our C# code. SVN for our iOS/Phonegap code. At home Git via BitBucket. Previous job we used Git with JIRA.
I'll say this, Git (although can be difficult for some when using command-line only version) paired with JIRA was phenomenal. I love JIRA, so easy to use, and easy on the eye. We used Jenkins for our build process. I'm not a fan of TFS/TF build process.
|
|
|
|
|
MKS Source and MKS Integrity are working pretty well for us.
|
|
|
|
|
Not TFS. Probably SVN and jira.
TFS tries to be too much, and isn't great at any particular thing.
Sure, it's o.k. revision control. And it's o.k. for issue tracking and time tracking.
However, let's say (for example), you enter something as a bug, but later decide it's really a feature request. Sorry, you can't change the type. Go enter a new item.
I understand on some level, the type is tied to paths through the system, but that's frustrating. If they can't get something as (seemingly) small as changing a type attribute to work, how much faith do you want to put in the rest of their tools?
Maybe it's just been the administrators I've worked with, but places with TFS have had more problems with the repository acting strange than those with SVN or git, where it just cruises along. Though I must admin TFS has made huge improvements in the more recent versions on this reliability aspect.
For SVN vs git, I like git's local repo; I can check in some changes to have a 'go back to' point when working on a complex, multi-step implementation without affecting the source repository. However, I don't feel like the tools are there like they are with SVN for ease-of-use for most developers (myself especially). I think I'd go with SVN with the Tortoise add-ons for windows.
For issue tracking, seems like jira worked pretty well, but it's been quite a while since I used it. Same with FogBugz. We currently use the built-in TFS stuff, which I don't really care for. It gets the job done, as long as you follow Microsoft's ideas pretty closely, but I'm not a fan.
Again, little things. A task has a single text box where you enter the time spent. It doesn't track by segments (i.e., I worked on this from 3-4:30 on Monday, and 10-11:15 on Tuesday. It's just 2.75 hours).
IDK, I don't know that level of precision is really useful, but when I think about tracking time, I think of it in terms of start and stop times, not making the user enter a single total.
Also interface not great. Cut-and-paste from (say) SQL server management studio into the comment box; font/color changes to your source, but there's nothing on editing tools which allows you to set it back to TFS' normal font/color.
Again, can't get the little things right, how can we expect them to get the big things right? But it's fair to say these are nitpicks. Maybe they color my views of TFS more than they should.
|
|
|
|
|
Thanks for going a bit deeper in your reasoning.
|
|
|
|
|
AccuRev. Not sure on the price but I work for a huge company.
|
|
|
|
|
Source control: We use Subversion with TortoiseSVN front end UI that integrates nicely with Windows Explorer.
Bug tracking: Mantis
They aren't best of breed, but they work reliably and the price is right.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
|
|
|
|
|
Jörgen Andersson wrote: and to implement an issue tracking system at the same time.
Based on your other response you might want to take more time with this than the other.
When customers can open tickets it probably isn't not going to be a good idea to allow developers to respond to them like normal tickets. After all "RTFM" might be perfectly fine between two development peers but not so much if the CTO of a major customer is the one that opened the ticket.
|
|
|
|
|
Fair enough, that's also where I'm having more problems to choose.
On the code repository I've basically settled for Mercurial, we want distributed but don't need the f***up factor power of Git. Not all users are fit for it.
TFS is basically out on that reason plus price. I've got to convince the boss too.
As for the Issue Tracking system I'm mostly looking at FogBugz and Jira at the moment, both integrate well enough, but Jira seems to have the upper hand on functionality and also has a Service Desk for customers.
But Fogbugz can handle issues in a hierarchy/tree. Also here is price an issue.
|
|
|
|
|
I have used PVCS, SVN and Mercurial for source control over the years. Just recently got turned on to GitHub and I prefer it over all others that I've used. It has a really nice interface. Intuitive to use. A lot of my co-workers rave over Mercurial but it would be my least favorite. Don't even consider PVCS.
I use JIRA on multiple projects for bug tracking. I would only suggest using it if you integrate it with your source control tool (and integrate your source control tool with your continuous integration tool (i.e. Parabuild or TeamCity)...if you're not using one you should consider it).
|
|
|
|
|
Not a direct answer to your question but we use AJC Active Backup in addition to a source control system (TFS). This lets you go back to any save you did while editing your source code (and any other files). Its handy to have the granular control to protect from mistakes and corruption and when you just want to go back to that edit you did this morning. Or when you accidentally check out from source control over your local changes etc. It plugs into Visual Studio but will work on its own in any Windows environment.
See it here:
http://www.ajcsoft.com/active-backup.htm[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
