Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Currently we use FogBugz for tracking issues and found it to be ok. I'm looking for something else that can allow end users the ability to track their cases along with us. And something that actually works well with email. I've found a few alternatives that support those features but they don't integrate with version control. We've got all the SVN hooks in fog bugz and we use them - but I haven't really found them all that useful. Has anyone found a really good reason to need version control integration with the bug trackers?
Clearly, this kind of integration is not something that is essential to the operation of the software. With a bit of discipline every check-in can be accompanied with a bug number manually, and every bug resolution can manually have a version control tag added to it.
All else being equal however, I personally will always prefer automation over 'discipline of the users', because the latter will always sooner or later let you down from time to time. Not because the users are malicious or incompetent, but simply because people cannot be 100% alert all of the time.
I find the integration of SVN with TRAC very helpful. Through SVN hooks, commits to the repository with a ticket number insert a comment on the ticket with a link to a nice visual HTML representation of the revision number, showing inserts, deletes, and diffs.
As a supervisor over a small team of programmers, I find this as a helpful tool for me to do code reviews, so I can verify that the commit truly addresses the associated issue. I wouldn't exactly call this integration essential, but it was a nice free extra on my issue tracker that I've grown to love.
It is absolutely critical for us.
Here is a typical commit log for one of our projects (sample):
Make sure filedes is cleared in child list prior to reallocating
When p->child-filedes is > 0, the child list is active and can not
be collected.
[ Impact: Closes bug 123457 ]
Note the [ Impact: ] line, which could also be "Relates-To", "Caused" or any number of other things.
This lets us use simple greps and automated scripts allowing the person committing to automatically close, or even re-open a bug.
Though we typically use Git and Mercurial, these sort of hooks would work on (almost) any VCS, especially proprietary ones that do not feature some modular plug-in that you need.
If you think of your bug system as just another part of your VCS, its really easy to see how they depend upon each-other.
Other stuff, such as fetching patches submitted with bugs is possible, too.
It is a question about your code size, and how many bugs you need to track.
And it is also really useful for non coders in the organisation i.e. managers and customer support. They can find answers to questions like "When and where was this bug fixed"...
I think it's helpful to distinguish between bugs found internal to the development organization, e.g. from peer code review, versus bugs found by a test group that is external to the development organization.
The (small) benefit to coordinating version control with bugs found by an external test group would be for historical reference.
The larger benefit is in coordinating bugs found via peer code review with version control -- by doing so you can certify that all code is peer review bug free before releasing it to external test groups; a common requirement.
FYI, Code Collaborator from SmartBear, Inc. handles this nicely.
I have found version control integration to be extremely helpful in maintaining and managing multiple versions (stable, development trunk, etc.) of a project.
Using the version control integration and a bit of discipline from coders to reference bug tickets in commits (or some pre-commit hooks to forcibly require ticket references) has allowed us to quickly and easily generate lists of changesets that are required to fix any given bug. This is instrumental when merging the fixes into various stable branches of the code.
It's not a necessity, but it certainly makes life easier for release management.
I've used SVN + Trac and Atlassian's Jira product with Fisheye SVN plugin and have found both tools to be very good. Trac seems to be a bit simpler, but very easy to use. Jira, in my opinion, had a nicer look and feel and quite a few more bells and whistles, but was almost too much at times.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm a relatively inexperienced (recently graduated) web designer who often writes HTML and JavaScript and also works with large Photoshop files. I've long gotten used to keeping the files I work on in a Dropbox folder because of Dropbox's excellent Version History feature. If I make a serious mistake, I can always revert to a previous version of any file.
The prevailing opinion on StackExchange seems to be that Dropbox is much better than nothing but is still not nearly as good as a "real" version control system such as Git. But it seems to me that for a solo web designer, Dropbox provides the best advantages of a source control system (never lose your work) without its disadvantages (learning curve, maintenance).
The ability to fork my code doesn't seem valuable enough for me to justify
learning a new system, and
keeping up with "committing" a change every time I make a significant edit.
If I was collaborating with others on this stuff, that would probably change, but it's just me in here. And working with Dropbox is effortless; keeping my work safe requires no additional effort beyond saving it.
I want to follow industry best practices, and if there's an important feature that I'm missing out on, I'd like to know what it is. What value does a version control system provide for a solo programmer that counterbalances its increased overhead relative to Dropbox?
A VCS is about more than keeping files safe!
When you're working alone, it's easy to make changes as you go along. You've got a code base that's managable, and you're only ever interested in the very newest snapshot of your code. This is especially the case, when you're developing web sites, where users are always presented with the newest version available.
This mentality can be unhealthy! Imagine you deliver some version (possibly a binary) of something to a customer, but keep working on it. When the customer comes back to ask for changes, how do you easily figure out what changes were made since the customers version? What if you've made substantial changes since then, that the customer isn't interested in. In dropbox, you've just got 30 days of mess in your history. With git, things like commit logs and branches lets you easily work on, and manage, different versions of your code, without retorting to copying folders, leaving notes around and what have you.
Even more important - if you start collaborating with someone, you may come back from vacation, and loads of changes have been made to the software. You simply take a look at the commit log to see what's been changed. With dropbox, it's just file changes, not discrete units of explaniable updates made to the project, like it is with a VCS.
You may also want to start working on large new feature, or just try something out in your code base. With a new branch, you can hack away on that branch, while you (and others) keep working on the stable branch. You may want to include the changes made in the stable branch into your feature branch (merging), but you can sleep at night, because you know your non-complete feature branch doesn't interfere with the work on stable branch.
The main point isn't so much that a VCS has features that are better than Dropbox - it's that you should adopt the mindset behind a VCS when writing code. You're improving your application one feature at a time, and can explain and justify each one - not simply making changes as you go along, forgetting the hows and whys.
When you start using a VCS for yourself, you'll likely find that you end up forgetting about it, and commit at the end of the day, leaving "added some files, made some changes" as your commit message. In this case, a VCS is no better than dropbox. But if you stick to good etiquette, commit often with concise commit messages, even a simple repository with one master branch and labeling of versions, will automatically prove much, much better than dropbox. As you grow with your VCS, you'll likely start to use other features, such as branching, and you'll wonder how you ever made do with Dropbox.
For an example of a good git etiquette, take a look at the git flow branching model. I personally find it a great, simple way to use git together with Sourcetree, but there's more ways to use git, than there are atoms in this universe - just make sure you find one that suits you :-)
Some of advantages of working with a VCS are:
Easily diff your code, see what changes you've made
Determine why certain changes were made - often when committing changes you also add the reason for those changes. This can be valuable down the road (for example, this fixes bizarre IE 7 issue, etc.)
If you ever want to collaborate with someone, or give them access to your code, they have access not only to the code itself, but the entire history of it as well.
Most VCS support tagging and branching. This allows you to find certain versions of your code easily, and allows you to explore different solutions to problems while still maintaining a copy of the code that matches whatever is deployed.
Finally learning a CVS like git is always useful from an employment perspective.
Not sure how useful a version control system is for photoshop files though, but for code it's great if you need any of the above.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
At our company we've built a data integration tool that we have sold to several customers. Most of the customers have distinct requirements. We implemented these customer-specific extensions by using a self-made mechanism based on inheritance (so every installation knows which classes to load and which not). But all this customer-specific code is still in the same codebase as the standard code.
Now, this is no longer possible for several reasons (codebase getting ugly and large, clashing requirements, etc.)
For this reason we have decided to separate the codebases: one for the standard product, and several customer-specific codebases.
I am now trying to find a version control system that supports this approach. Here's my wishlist:
support for several "standard" codebases for different releases
1.0 release
1.1 release
2.0 beta/development
support for multiple "customer" codebases
ability to create a customer codebase by cloning a standard codebase
ability to change standard code in a customer codebase
ability to update a customer codebase with a new standard release (and somehow marking the conflicts that come from changed standard code in the customer codebase)
As our team is still very small (~4 programmers), it should also be easy to handle by the developers themselves.
Btw, our software is built using Spring with STS (so, an Eclipse plugin would be great too).
All VCS that I have researched so far seem to have that target of building one piece of software - not several. I am hoping for some suggestions or best-practice approches.
Simply
Simply get git, go for pull request process and take advantage of some GUI, supporting this workflow.
Are releases much different form custom development?
To clarify, what is the situation you are facing: "standard" development comes in versions, they might live independent for maintenance, you may need to get some fixes from new versions to be incorporated in older releases, you need a way to solve hotfixes.
All these things are well solved by distributed version control systems like git, hg or others. I have started with hg, but later found, git is used more often and in standard installation offers all what is need (what is not a case for some hg features).
Regarding custom development - in fact, they do not differ conceptually much from standard versions - you just need another modification of your program being identified under unique name, which will eventually denote, these are custom things.
Branching or pull request process?
Now how to approach different "swim-lines" for different versions and custom developments?
Branching workflow models
Obvious answer is "branching". There is a lot of tutorials on various branching models and they shall be solving your problem.
However, branching is not trivial either and you may find long disputes on what style is the best one.
Topical repos and pull request workflow
Fortunately, there are even simpler solutions - Pieter Hintjens article http://hintjens.com/blog:24 about "Branching considered harmful" provides simpler model, using topical repositories and pull request process. This is how many projects on GitHub and BitBucket are managed and I found this really the most effective solution with minimal risks.
Final recommendations
For pull request working process, it is handy to have some GUI, which supports related communication - and apart form GitHub and BitBucket, there are solutions on the market (incl. some open source solutions).
Prepare yourself for long run - starting with linked article by Pieter Hintjens may make your run a bit shorter, next step could be playing with a project on BitBucket or so, then design "the final" system (which will anyway evolve during time, but git repos are well suited to keep with the changes).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Which version control system would you recommend for:
single user
looking for simple, easy to use
generally small simple projects
working on windows
usually coding python
no server
Use would be more finding old code than complicated branching situations.
From other similar posts, Bazaar and Mercurial seem the best distributed version control systems for my needs. I'm somewhat leaning towards Bazaar as it seems simpler.
The main complaint I read about Baazar was that it was slow, but speed was to be improved in version 2, to be released this summer. The new version has not yet been released, but there is a 2.0.0rc2.
I'm wondering if anything has changed recently or if anyone has any strong feelings on the subject.
EDIT: After reading the responses and browsing some alternatives, I'm going with Bazaar, at least for the moment. For my needs, the products mentioned seemed rather similar. Bazaar has documentation specifically aimed at a solo developer and seems rather easy to use. Others seem more aimed at groups or those with central servers. Other systems may be as good, but I thought starting to use something was more important than spending time trying to find the perfect program.
Thanks, everyone!
(Should I have written this as an edit, an answer or a comment?)
If you're just single developer working on small projects, any version control system should be fast enough.
I'm a Mercurial developer myself and will of course recommend that :-) I like how Mercurial has one central concept: the changeset graph. The graph resides inside a repository (a clone). You can have several lines of development in the same clone. This can be in the form of multiple heads, perhaps marked with the bookmarks extension or as named branches. You can also use several clones to keep things separated, or you can go back and forth: it is easy to separate a combined clone (use hg clone -r REV to obtain part of the revision graph). See this blog post for pretty pictures.
For Windows (and other platforms too) you have TortoiseHg, which gives you a very nice graphical interface. TortoiseHg also integrates with many excellent plugins for Mercurial, in particular the record extension, which lets you pick out individual changes from a file when you commit. Using that, you can edit several files, and then commit those changes as several independent changesets.
Finally, you should also know about Mercurial: The Definitive Guide, the free online book about Mercurial.
Bazaar is very good for your needs, and I'm doubt you found speed issues with your projects. Bazaar has very nice GUI front-end called Bazaar Explorer which I'd recommend over TortoiseBzr. (Bazaar Explorer bundled into standard 2.0 installer now.)
Of course if you choose Mercurial you don't lose much.
So you'd better test one and another and make your choice. Every zealot will recommend you his favorite.
If you're a Windows user, nothing IMO can beat TortoiseSVN in terms of usability and ease-of-use.
Definitely Subversion....
It's free, very very easy to set up and use, doesn't require a server because it can just access the local filesystem, and you can find loads and loads of documentation and help if you get stuck because I think there are far more people who use SVN than bazaar or git for example....
You can just download TortoiseSVN (http://tortoisesvn.tigris.org/) en start using it....Nothing else is required for getting started because tortoisesvn has subversion built-in I believe....
I've done some playing with all of them.
The key thing that has attracted me to Bazaar is its flexibility.
Want to operate in centralized mode (ala SVN)? You can do that. Want to operate in distributed mode (ala Mercurial or git)? You can do that.
And here's where it gets better: you can do both. Say you're working with a guy that came over from SVN and he just doesn't like the distributed concept one little bit. Fine. Let him work in centralized mode while the rest of the team works in distributed mode. If he's away from the central repository, he can even take his checkout offline and do offline commits while he's gone. Then he can commit them all when he gets back.
While some of the other systems have ways to approximate different models, none seem as committed to flexibility as bazaar.
I have used SVN, Git and Bzr quite extensively on various different projects. I am currently using Bzr on a single user project and it is very easy to set up and use. No need to set up a server and comes with TortoiseBzr which works well, it may not be as feature complete as TortoiseSVN is but for a one-man project you should have everything you need. There are a few things missing such as the ability to Tag revision in which case you need to resort to using the command line interface. I considered Mercurial about a year ago, but I haven't used it in a real-world situation yet so I wouldn't be able to compare. I decided against it because TortoiseHG didn't seem very mature at the time, I expect it will have improved since then.
I quite like darcs, it uses something called patch theory which is, as far is I know, unique in version control software.
I have been using Bazaar for a while and was pretty happy with it. With all the hype going on about git, I gave it a try. And even though it has pretty complex concepts, I can only say that it was worth the switch. I now use it for all my projects. No matter how small. And I think TortoiseGit has become good enough to be usable.
I can see the following good points about it:
It's fast
Branching and merging is so simple you could even say it's fun
It's got funky commands I haven't seen anywhere else (f.ex.: stash and rebase)
It's hyped. Consequently the community is quite active and you can find a lot of material on it
You can grab a copy of gitorious to manage your projects privately
Some things I don't like as much:
branch display in gitk "feels" strange to me
I use git and it works great for me. I use msysgit on Windows.
I will recommend Git always. It is fast, doesn't need server, branching and merging is excellent. For Windows you need to get MsysGit.
Mercurial is also very good with a bit easier interface for user.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What arguments can be used against using zip files of source code as a form of version control?
In general each developer is working on their own program and has a responsibility for it. But there are times of course when other developers are involved in work on that program.
Each developer has their own naming convention for zip files ranging from appending the date, a number after the program name or even appending _old / _oldold _newversion etc… When there is collaboration on development of some code. It has to be checked who has the ‘latest’ version of the code – and where it resides, usually the correct version is identified.
There is no easy existing method to diff source trees and during development unwanted changes occasionally slip into code.
The zip file corresponding to software releases that have release to manufacturing are archived. This at least adds some traceability.
Also before RTM there the code is peer reviewed against the previously released version so quality assurance does exist.
Are there any formal white papers explaining the advantages of source control, making clear that the above isn’t a fully valid form of source control? Arguments exist here that since the end product (manufacturing releases) are under control and these are reviewed that there is no problem with the process. Developers do not have too much of a problem working with zip files in this way, but may not be aware of the advantages.
Creating and managing zip files is error-prone.
Real source control gives you tools to understand your code:
History browsing
Diffs between revisions
Annotation of source files to track the origin of a change
Real source control isn't difficult, there's lots of help out there.
The best argument is surely that using a version control system like Subversion or Mercurial is much, much easier and more secure than messing about with zip files. I doubt there has been much paper writing on the subject, as the use of
zip files for this purpose is fairly obviously wrong.
There are a number of SO questions on the general advantages of version control. For example How can I convince my department to implement a version control system? and https://stackoverflow.com/questions/250984/do-i-really-need-version-control
I assume you currently work at a company that practices this method of zip control, and you're looking for ammunition to help you change this practice. There are a lot of questions on StackOverflow about source control, and the community here are in near-total consensus on the benefits of proper source control and the horrors of working without it (for very good reason).
I'll add something here to benefit your battle: YOUR COMPANY IS #$#%&$## CRAZY!!! ZIP FILES??? ARE YOU ##$##% KIDDING ME???
I am assuming that this question was asked because the original poster is working in an office where the standard practice is to share zip files.
Zip files are obviously bad, for the reasons given by Ned Batchelder. The biggest reason I would suggest is that it's clunky, and difficult to merge changes, or get diffs between past revisions easily.
I would recommend you read A Visual Guide to Version Control for some good arguments about why version control systems are very useful, and a superior way of managing code.
I suspect there'll be as many white papers comparing zip files to proper source control as there'll be white papers comparing cutting one's genitals off with a rusty butter knife with buying a puppy.
Zip files work as a very basic form of version control. It's a way to separate "states" of the source. However, it's not a good form of version control because you have to do a lot of work to perform basic source control management tasks. For example:
Bob's team is working on a major feature that requires changing dozens of files. He works in his own private zip-controlled area for a while. He's created 30 new files, added features to 12 existing files, and made changes to existing behavior in 3 existing files over 4 months. How do you merge Bob's work with the main trunk that has also evolved over the last 4 months? Do you hand-diff thousands of lines of code and decide how to merge them? How do you ensure that anything that uses the 15 existing files isn't broken? How do you ensure that Bob's features or main trunk features aren't accidentally omitted?
Alice is investigating a bug in her code and realizes that one of Sam's classes has changed its behavior. Sam says he didn't make the change. How does Alice find when and why the change was made? How does Alice know who depends on the change?
A major customer has reported a bug in an older version of the program. This customer needs a fix and is important enough to warrant a patch. How do you add the code to the old zip file in a way that it also exists in the new files? Also, how do you record that there is a relationship between the two changes?
These are just three scenarios that a version control system handles well. Situation 1 is handled by development branches. Almost every version control system has a notion of branches that can be developed in parallel and merged as needed. Situation 2 is easily addressed by any source control system with a "blame" feature and less easily addressed by just searching commit logs. Situation 3 is a variant of situation 1, but when you merge branches most version control systems make a note. For example, you'd make a branch off of the old version, fix the bug, then merge that branch into the new code. Now when someone asks "Where did this change come from?" they see it was merged from the patch branch and the change was made to fix a bug.
By the way, I've been in each of these 3 situations and used both SVN and Perforce; both made finding a solution very easy.
These people already know all the arguments for SCM, there is nothing anyone can say to them that will sell them on it. These things must happen:
You install SCM on your local machine and use it. If you must, have it autogenerate these .zip files at every build, so no one outside your cube knows the difference.
Some kind of disaster occurs, like loss of work, show-stopper bug is re-introduced or some other worst-case scenario that is the real reason we all use SCM (the other features we learn to appreciate later).
You are unaffected by the disaster, and/or use your personal copy of the code in SCM to fix the problem/recover the lost work/whatever.
You are a hero and everyone wants to know how you did it.
Only by experiencing firsthand the pain of loss caused by poor SCM practices will your organization realize the benefits of SCM. You're smart enough to learn from the mistakes of others, but not everyone is. The rest of the time, you'll just be 2/3X more productive than the rest of the team and maybe, just maybe they'll wonder how.
By the way, this is how you get agile, continuous integration, unit testing, etc into the organization: lead by example.
The ZIP solution requires a pro-active step at the end of the development cycle when things tend to get dropped because no one outside the dev group notices when they doesn't happen. Sort of like that final code cleanup you always plan on doing when things slow down.
An SCM integrated into the dev environment pretty much enforces/encourages keeping a version history with a small amount of effort all the way through the process. This makes it more likely that a version history will actually be created.
On Using ZIP as a SCM
I'm not going to take as hard of a line as some of the others on the ZIP file solution. It is at least better than nothing. It is a perfectly valid way of keeping version histories, it is just a lot more labor intensive, error prone, and lacks a lot of useful features.
Know who you are selling to
Someone in the Dev Group: Focus your arguments on features like ease of troubleshooting by using change histories, safety to experiment with big code changes (because of rollback), and avoiding accidents where work is overwritten by other developers.
Non-Tech Managers/Bean-counters: There are free/low-cost tools that will reduce the labor cost of version control and give greater accountability/transparency into what each developer is doing/the source of coding mostakes.
I wrote a Version Control tool long ago for a company who did the authoring for DVD titles. Before that they had nothing, just a directory full of clips, icons, scripts etc. which anyone could hack away at, and no way to backtrack if it went wrong etc. HOWEVER these people were 'artists', not programmers, so they could not (would not???!) be trained to use a decent Version Control system. So as a bare-minimum, get-out-of-the-mud level tool I wrote a utility which zipped up the current state of the directory, gave the Zip a meaningful name (date + comment supplied by user) and stuck it in a Backups directory, and also allowed you to restore one of these backups.
So zips CAN provide minimum-level version control, and I speak as someone who endorsed that approach when it was right for the skill-level (in terms of programming, I don't want to imply that they couldn't manipulate pixels!) of the people using it.
But as a programmer, you should be thinking to use a tool which really helps you. As such you want to be able to compare differences for individual files, compare differences between complete milestone sets, and (if you are working on anything other than trivial programmes) handle branching and merging. If you want these features you need something BETTER than zip files.
I used to use ComponentSoftware RCS, and if it wasn't for its poor performance over a WAN we might still be using it: it is cheap (even free for single-developer use, in which form I used to use it at home) and simple to use. However nowadays I would suggest looking at SubVersion. It is very flexible, reasonably simple to understand, has a good set of Windows tools to make it even easier (e.g. Tortoise, Ankh), and ... best of all ... you can get it running for free.
It's not good as only creating a zip before a release means loosing a lot of power you get with version control.
Useually you should check in to the repository after you have added/removed/changed a functional aspekt. So that you can go back later when an error occurres that you think migth be because of this change. Or when you say "dammed this worked before the file format changed in someday in march." Naming revisions after changes makes it also easier to remember because you forgot what was done on 27 march 2009.
In general each developer is working
on their own program and has a
responsibility for it. But there are
times of course when other developers
are involved in work on that program.
In a normal development shop, this is not at all true. Different people work on the same source code all the time. XP makes it almost mandatory. Even if you separate the code into modules, there will still be interaction points with code that concerns at least two programmers.
Of course, it's almost impossible to collaborate without major problems if you don't use source control. But the scenario you describe is much more a way to adjust to this limitation than a sane project structure.
Having only a single person working on a module means that nothing will happen when that person is on vacation and you have a major problem when he leaves the company, gets sick for a long time, or dies.
How do you do a merge? How do you do an annotate? How do you bisect? Where are changelogs stored? Just go to wikipedia and look up "Version control" and go down the list: zip files can kind of sort of do about 2 things out of the whole page.
This is like asking "What arguments can be used against shorthand as a form of double-entry bookkeeping?". It's a completely different thing.
For arguments, there's Walter Tichy's original paper on RCS.
For missing features, among many others there's the ability to merge changes from different versions. This is especially well supported by tools like git and darcs, and to a lesser extent mercurial.
P.S. To Mercurial fans: the problem is that Mercurial delegates the merge process to external tools, and it's very difficult for the mercurial novice to know which tool to use, or to understand how they work—the mercurial model of merging seems far more powerful than others but correspondingly difficult to get a grip on.
I haven't seen an answer include Eric Sink's Source Control HOWTO, but it's a valuable reference. I haven't seen any formal white papers on version control, but I'm not sure the argument about "validity" is your strongest one. The problems you describe in your question indicate some pretty serious drawbacks with the current approach. If "the powers that be" in your environment aren't convinced by that, change the argument entirely.
If you make it a question of quality control, and point to continuous integration as a practice that encourages it, then the zip file approach to version control isn't a "not fully valid form of version control", but an obstacle to implementing continuous integration as a practice.
Your question doesn't indicate whether or not the end product "under control" is tested in any automated fashion (in addition to being reviewed). If the process you describe would prevent that from taking place as well, certainly add that to your argument too.
I think your best argument is showing a GOOD form of source control and showing how powerful it is. Don't trash what is currently being done (as someone is surely emotionally attached to that). You don't want to trash the "ZIP Source Control Method." Show the power of something like SVN. Make it very easy to explain. Show common use cases. (A solid demo would help.)
Let the source control version sell itself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We're currently using Mantis as our bugtracker, and we're pretty much sick and tired with it. The developers want more SVN integration, the customers want an easier system to work with.
As such, we're looking for a new bugtracker and at the moment we're looking at Redmine. However, in its default setup it doesn't match our desired workflow, or at least not much better than Mantis does.
We have the following workflow, and would like a bugtracker to match it.
A bug is reported (often by the customer), and is considered 'new'.
These bugs are regularly reviewed and either acknowledged (it's a bug) or marked as a feature (customer often needs to pay) and delayed until the financial part has been worked out.
The bugs are then assigned and handled by a developer
when finished, it's marked as 'ready-for-review' (by another developer)
when reviewed it's marked as 'reviewed'
when marked as 'reviewed', the original developer places the new code at the staging environment and marks the bug as 'ready-to-be-tested' (by the bug-reporter)
bug-reporter marks the bug as 'resolved'
when placed on production, bug-reporter closes the bug
Of course, feedback is often required especially during the early stages. We're looking for a way to distinguish between who is required to take the next step, and who the bug is assigned to (developer). We also want the customer to do so using a simple gui - asking them to change the assignee from their own account to the developer, or even more difficult: a 3rd party (think: design agency) has just too much to ask using the regular gui's.
The gui should show them what to do and which options there are - not search for them.
Does anyone have any experience with a bugtracker that works this way? Is our workflow really wack? How do you make sure everyone involved understands where the bug stands, and who is required to take which step?
Last year we had the same problem, and we figured out that the best solution for us was Jira.
With respect our workflow is more robust and complicated than yours.
We have pretty much the same kind of workflow which we are managing using Redmine with email integration. The customer logs bugs into Redmine directly. Notification comes to the project manager who decides which developer can work on the bug.
The developer opens the bug and puts it into the Investigating state.
If its a feature, he replies to it stating the reasons and puts it into the Replied state which is then revisited later.
If its a bug, then the developer starts development. Before this he puts the bug in Coding state.
Once the coding is over, he changes the state of bug as Review and the peer reviews happen.
If there is any rework, then the developer changes the state to Rework.
Once everything is ok, the developer changes the state to Delivered.
The QA verifies the bug and the finally closes it by changing the state to Closed.
We've defined all of this workflow in Redmine and have been using this pretty effectively without any hassles. Email integration makes everything easy for the project manager to track whenever any bug changes its state.
You can also create and save custom reports, which is a cool feature as well.
I've been using Trac for a small personal project, and at work we used Bugzilla for this.
The workflow you described also sounds like how Red Hat utilizes Bugzilla.
As other's have said, Jira is very good. I especially like its ability to create a custom issue workflow