In the CVS/SVN world, there are various statistics/metrics tools. E.G., StatCVS, StatSVN. There are others I've seen.
However, I've not seen similar statistics and visualizations for Mercurial(aka hg).
(1) Are there any out there?
(2) If so, what are they?
Thanks.
We just made the project StatHG publicly available. The project had the goal to develop a tool to extract statistical information from a Mercurial repository and build reports about the work done within a group of developers in a similar spirit as StatCVS. Please take a look and see if it fits your needs. If it doesn’t let us know so we can list the requirements on the TODO list. Thanks for any feedback we can get!
Well as an initial tool, there's the churn extension that get's you some basic statistics about repository. For details on how to activate and use it see ChurnExtension on the mercurial wiki.
If you are interested in a specific (group of) changesets and what files the change, then diffstat is also a good help.
not sure, but your best bet is to ask on the Mercurial mailing list.
Hg is still relatively new so it's "behind" SVN when it comes to tools.
Distributed version control systems such as Mercurial are often used in a way that produces a complex history with lots of merges. That makes some of the plots that StatCVS produces such as lines of code against time harder to read.
Related
Very soon we are going to start on open-source (py+qt) project which is supposed to be multi-platform (we're using FreeBSD as native platform) and we're not sure which DVCS/hosting to use.
In the past we were using darcs for very long time, but moved away from it due to not having adequate public hosting available. Played for some time with Monotone - nicely designed, but mostly niche today. Fossil is nice, but it uses non-standard wiki and its tracker is functional, but we expect more.
Considering that we won't work on kernel-like sized project we do not nee Git which we consider too complex to deal with it, especially for potential contributors which might use Windows OS and prefer GUI tools.
So, the story comes to Bazaar/Launchpad and Mercurial/Bitbucket...
Here are some pro/cons which we gathered together, but would like to hear if we missed something which might help us to decide...
Bazaar pro/cons:
2.4 is probably quick enough for our needs ,
simple to use,
has nice GUI tool (explorer),
handles empty directories,
(probably) less popular than Mercurial,
does not have equivalent of hg's named branches
The last point is probably not to important 'cause there are nicks and there is colo-branches plugin, so one can get same/similar functionality.
The most problematic quirk we find in Bazaar it its revision numbers scheme and problem which can arise if one pushes from feature branch into upstream which would change revids.
Maybe it's a lesser problem when using Launchpad...
As far s Launchpad is concerned:
- it has very nice bug tracker with email interface
- it's (maybe) more project-oriented than Bitbucket
- no private repos as with Bitbucket
- no wiki for projects - bug (https://bugs.launchpad.net/launchpad/+bug/240067) is more than 3 years old and still with 'Low priority'. LP is the only one amongst {LP,Sourceforge,Bitbucket, Google, Github} which lacks this feature and it really sucks and degrades, otherwise, nice hosting solution.
What we've found in The other camp...
Mercurial is:
(probably) more popular than Bazaar,
quick,
simple to use,
there is nice TortoiseHG for non cli-savvy users,
we like named branches,
some quirks like handling empty directories (or https://www.mercurial-scm.org/bts/issue29)
However, what we like the most over Bazaar is, as we believe, great merging capabilities without the hassle of changed revids due to revno:hash schema.
As far as Bitbucket:
we like to have unlimited/private repos
we like having wikis available for the project(s)
we miss email interface for the tracker and the tracker is (maybe) not on par with the one at LP (reviews etc.)
At the end, let's say that there are some projects which we are interested in which are under Git #github, so we would like to use single DVCS which can helps us inter-operate with git#github projects.
We find that bzr-git plugin is very capable and do not have experience with hg-git.
Although there is bzr-hg plugin (not as mature as bzr-git), but we do not know about something like hg-bzr except hg's convert extension which does the job of hg-bzr conversion.
Is there any important feature which we did miss having important consequence in deciding about the two?
Finally, we use DVCS for all our needs (simple project, writings...) and we'd prefer to settle on one DVCS/hosting which can serve all our purposes and be useful in contributing to git(hub) projects as well.
What do you recommend?
In Bazaar:
You can avoid the problem of revision numbers being renumbered by setting append_revisions_only in branch.conf, which will make sure people only merge into trunk, rather than switching the trunk around.
I like bzr-colo a lot for dealing with named colocated branches.
I would certainly like to see Launchpad get wikis. It's assigned and in progress at the moment so perhaps it will get done soon.
Update: Seing this comment makes it easier for us to abandon bzr/LP and embrace hg/bitbucket.
Which best practice involved in software configuration management to help in improving project management?
It mitigates a whole bunch of project risks, including:
The risk of making a change which is found to be incorrect: SCM software allows you to see the change and roll back
The risk that you could lose all your source code (much less likely since everyone has a copy on their machine)
The risk that two people could make incompatible changes: good SCM will allow you to merge the two and get the best of both worlds.
Also, these days SCM is so easy and cheap to set up that embarking on a software project without it is madness.
Assuming you're really focused on best practices, I can outline a couple of possibilities.
Using the best (SCM) tools available. While this might depend on your specific goals and constraints, Mercurial and Git are hard to beat (distributed, excellent branch/merge capabilities, multiplatform, FOSS, really fast, flexible workflow etc.).
You can analyse the data in your source repository using a tool like PanBI (disclaimer: I wrote it). A short screencast shows off what you can learn from repository contents analysis. In brief:
general work dynamics on the codebase
breakdown per developer
daily work dynamics
type of changes to the codebase (add/remove/modify), part of the source tree
...and much more.
Connecting an SCM tool with an issue tracker can also add value. Developers place issue ID's in commit messages, e.g. "[#1455]: improved performance a bit" and the issue tracker relates the issue with the changes in the code repository. From a project management perspective, this allows you to loosely track the time spent on individual issues, project phases or complete projects. A simple commit hook refusing commits without an issue number can go a long way in ensuring data consistency. Such "measured" data can be compared to the baseline to understand what's working and what isn't.
Building official releases on a build server from a tagged source version pulled from the repository could also be considered beneficial from a project management perspective because it's a way to control quality. Building software this way detaches the build process from any dependencies or specifics of developer machine environments, provide reproducibility, allows robust automatic/semiautomatic publishing of the build etc., i.e. streamlines and shields parts of the deployment process.
These are just some of the possibilities, it doesn't stop here.
Later this year I want to release a PHP framework that I've been working on as open source. I do use source control (SVN), but it's on an extremely limited basis. I'm self-taught, I develop by myself and don't have the experience of working with large teams. I have some ideas about what can help make a project successful, but I'm fuzzy on some of the details. Since it's not yet released, I want to do everything I can to set up the right infrastructure from the beginning. What do I need to know in order to setup and manage a successful project?
Some ideas that I have to make it successful (beyond marketing it):
Good documentation and tutorials
Automated unit tests and builds to
push update to the website
A clear roadmap
Bug Tracking integrated with the
source control
A style guide to keep the code
consistent
A forum for the community to get
support, share ideas, etc.
A good example application built with
the framework
A blog to keep the community informed
Maintaining backwards compatibility
wherever possible
Some of my questions:
How do I setup and automate a one
step submit-test-commit-generate API
docs-push update to website process? Edit: Would Ant or Maven be good candidates for this? If so, do you know of any resources for setting up a PHP project using them?
How do I handle (technically)
submissions from other users? How can
I ensure that those submissions must
be approved before being integrated?
What are some of the pitfalls that
can be avoided in terms of the
project community? I'd prefer to have
it be as friendly and helpful as
possible without a lot of drama.
I'd love to learn from your experience on any of these points. If you think I'm missing anything big, please share that as well. Any resources (preferably geared toward a beginner) that you could point me towards would also be greatly appreciated.
I'm just getting started in community projects, but I'll give you some advice on what I know.
How do I setup and automate a one step submit-test-commit-generate API docs-push update to website process?
I've never implemented it as one process. You could just have a checklist, and possibly even create some scripts to do certain tasks. I've never worked with any source control that automates the uploading and such to be done by a script. Most of the time, there is some web interaction to be involved.
You don't want to push API changes until it's an official release.
EDIT: Working Environment
For PHP, most of the time, I either edit directly on the server and test it there, using a beta.example.com, or similar, before pushing to example.com. You could also set up an web environment on your home PC (using XAMPP for Windows, or the standard LAMP installation on Linux). You would probably just use a mirror of your repository here, so you'd do svn commit, or whichever is appropriate for the VCS or DVCS you choose.
The fun part is testing this with different PHP versions. I've not done this myself, but you could probably use a .htaccess file to run a different PHP binary in order to test it out. I'm not really sure what the best option is for this is.
I've not done much with API, as I've never created a library, but just doing a quick search I found http://www.phpdoc.org/. It looks like a mature project, so that might be a starting point.
As far as creating releases go, I generally create a script that only includes the files that are part of the distribution (it will filter out any VCS files, and anything that you don't want in the distributed file). You could write a script around find on linux (which is what I do most of the time), or there may be other better options.
How do I handle (technically) submissions from other users? How can I ensure that those submissions must be approved before being integrated?
This is mostly handled by the bug tracker, and limited access in the Version Control System. Usually, you, and the people you allow, can commit to the VCS. Other users can submit patches, but then you might have someone review the patch, test the patch, and commit. You could split these tasks up as a team, or assign a patch to one person and have them do it all.
What are some of the pitfalls that can be avoided in terms of the project community? I'd prefer to have it be as friendly and helpful as possible without a lot of drama.
I would just make sure to keep it as positive as possible with the project members and community. There's going to be some disagreements, and it will drive a few people away, but as long as you have a stable product that meets the needs of most people, I think that's all that anyone can expect.
One minor suggestion that's worked well for me: start using first-person plural pronouns, rather than singular ones. That is, talk about "we" and "us" rather than "I" and "me." It encourages other people to participate when they feel like part of team, rather than when they feel like they're contributing your own self-aggrandizement.
The most important thing you have to do is to attract users. Without users, you won't get any contributions and developers helping you out. Because developers are users first, and then they decide to extend/fix something they use and might become contributors.
So to get users, you should consider
describe what your framework does in one or two sentences at the top of your project page
mention how your framework can be used and for what, what situations it is most useful for
add a lot of examples on how to use it
mention whether your framework is stable, beta or alpha. That's important because user need to know that before they start using it
also mention whether you want to keep improving it and keep working on it - most users don't want to use a framework that's abandoned (also keep in mind that a lot of users check your commits to see whether you really are working on it - if your last commit to the repository was months ago then you're not really working on it, so cheating isn't possible)
If you got all this, and people start submitting patches, you can use a patch tool to apply those to your source. Depending on your version control system, you can either use the GNU patch, a diff/patch tool that comes with your version control or maybe even a GUI tool that helps you with this. SVN doesn't have a patch tool (yet), but 'svn diff' will create a patchfile which you can then apply with the GNU patch tool, or in case you're using TortoiseSVN, right-drag the patchfile to your working copy and have TortoiseMerge apply it for you.
And on how to best deal with the community:
answer questions in time, don't wait more than two or three days to answer questions
try to be nice, even with upset and angry people. Only if they keep bothering tell them to (still in a nice way if possible) go elsewhere
always keep discussions about the project on a mailing list. You don't want to repeat the same discussions over and over again - if you have a mailing list, just point users to the archives before the discussion starts all over again
And you should watch the talk "How Open Source Projects Survive Poisonous People (And You Can Too)" - it's really good and tells you a lot on how to deal not just with 'poisonous people' but also how to deal with all people involved in your project.
I'd like to add that you should make it as easy as possible for your users to get the whole thing running and modify the code - these 'power users' can be 'converted' into developers or at least people who send smaller patches.
Don't try to do it all yourself - for open source projects there are several hosting providers that solve most of the problems. I recommend codeplex or google code.
Setting up build scripts will depend a certain amount on what platform you set up, but in general it's easy to add any tool you want into the script once you start using any sort of build script.
If you really need the one step process you describe, you need a build server. I use TeamCity, which I have set up to watch for any changes in svn and trigger build/test whenever something is checked in. The build server will generally be able to perform any steps that you put into the build script.
Read up on Git as an alternative to SVN
free public repository/bug tracker/wiki/fork-enabled community in Github (which hosts symfony and PHPUnit amongst others)
"How do I handle (technically) submissions from other users? How can I ensure that those submissions must be approved before being integrated?" - with Git, pull what you/your closest team finds most interesting to the master branch
Consistent API
be inspired of other public API:s
only change in major versions
guessable
Interesting for both users & developers
clear goal (your roadmap - excellent)
useful, contra everything else available
easy to use, but still not easy-enough-to-write/maintain-yourself
You could check out either Ant or Phing to build your project. Include CodeSniffer in the build and you'll save time checking for basic formatting errors/differences.
These are all technical tips, about the soft part... treat humans with respect, a lot of interest and be overly excited about their contributions and make them feel that they're not wasting their time. That would appeal to me.
Take a look at Karl Fogel's book on Producing Open Source Software. It probably has everything that you asked.
You should also plan for engaging the community. I'd recommend reading Jono Bacon's The Art of Community [http://www.artofcommunityonline.org/].
You have a great set of ideas to start. You might have to start by trimming them down! Ask yourself what's necessary for a first release.
For automating the builds and tests, the scripting can be done with ant, maven or phing for PHP projects.
You'll probably need a host so you can demo the product. For PHP that is pretty easy to find.
You need an open source hosting provider-- especially github (but also google code, source forge, etc). Github provides bug tracking, default licenses, blog and great mechanisms for accepting changes from the community. Built on git, it facilitates distributed projects quite well.
Although it's good to have a one-step build and install in place, automating integration of others changes probably isn't important (or desirable) off the bat.
Good luck!
Does Mercurial offer any type of extensions that offer functionality similar to TFS's work items that when you check in changes that you can associate them to features/defects?
If there isn't much (or any) support for this, how do you handle ALM using Mercurial?
What you may be looking for is called a distributed bugtracker. There is a number of those available on top of that or another dvcs.
I've come across a couple of links:
Bugs Everywhere
DisTract
Distributed bug tracking
there is the Bugzilla extension but this isn't quite what you want out of the box i think? it may be a good starting point though if you want to write your own extension/hooks to do exactly what you want
if you want to pay money cash then there is fogbugz and kiln
I think that your best shot here is so far to add it yourself by using the hooks feature in Mercurial.
I've been looking at this for our in-house installation of TargetProcess. You can find more at this post which I've found in my own search for this: http://mattadamson.blogspot.com/2009/11/building-mercurial-external-hook-to.html
This should be feasible as long as your system for handling features/defects offer an API for manipulating its data.
You can check it out from this wikipedia, and go to "Revision Control System Integration" section which is at the end of the wiki.
I think your question should be what issue tracking systems can integrate with mercurial, not the way around since mercurial is just a source control system. Famous free issue tracking system like BugTracker.NET, Bugzilla, Redmine, Trac are all supporting mercurial integration, which means you can integrate your mercurial repository with them to keep track of your changes etc.
I stumbled upon this project : http://hgtfshook.codeplex.com/documentation
Am about to try it myself.
You can try the Artemis extension which is a lightweight issue tracking that handles each issue as an email thread, storing them in the same repository. It's easy to install, just download it and add one line to your .hgrc file. To add or modify an issue, just type hg iadd. I personally found it easy and simple to use. It's missing a web interface, though.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As many of us do, I have lots of software ideas, a couple of really good ones, and not enough time to do everything. (I am a developer, but only one). I would like to open source some software and ideas in progress but also retain direction and vision of the project. Up until now I've only worked in non-free-as-in-beer software and it escapes me how open source could meet my need for control of it.
Let me be clear I don't intend to commercialize open-sourced projects for money. That much I know. I just want to have control of my vision which I start.
To control my own open source project I would need to manage it by providing guidance but that facet escapes me also, about how to manage something that's effectively free.
Am I barking up the wrong tree?
I've gone through this cycle myself, and can tell you you're way out in front of the horse with the cart. Not to sound harsh, but there's a frame of reference you should definitely gain.
First, "control my own open source project" -- is conflicting. Open Source involves giving something away, in this case to a community. So, thinking about control and ownership of something you've given away is a mental hurdle you need to cross.
Second, you need someone other than yourself willing to participate in your project. Without them, you won't have anyone to divert any direction and vision you might have.
Third, control in terms of project guidance is earned in any open source projects with any sort of following. It doesn't matter if you're the original developer with the initial idea; if the community is willing to follow your guidance, they will. If not, they'll simply not participate.
Enough soapbox. In terms of project management, divide the role into two functions:
1) Getting developers involved, taking on tasks, code reviews, guidance and direction, etc. Trust me, this is as much a sales job as it is credibility-based. Top-down, hierarchical, seniority-based I-was-here-first type of expectations is a sure-fire way to drive volunteers away from your project.
2) Repository logistics. In the end, you can control who are/are-not committers, their permissions, etc. If you do #1 well enough, this will take care of itself.
As a last bit of commentary, open source projects are not easy to get off the ground. There are more projects than people willing to put forth the amount of sustained effort necessary to give your project legs.
Good luck!
Well, Captain Bligh, it all depends on how you hand out commit permission, now, doesn't it? If you make the source open, but tightly control commits, then the vision is all yours. Assuming, of course, that you can find anyone else who cares enough to submit patches for your review and evaluation.
Linus Torvalds had a great speech on google talk about how he is using (among other topics) git to avoid having to include all code from the open source community! It is deffently worth checking out!
You probably can't have your cake and eat it too. If you open your source under a "real" open source license, then anyone who wants to would be able to start their own project. You could maintain control of the "real" project. Then it is a matter of waiting and seeing which version users like better, and which version attracts most of the community. You will always have control of "your" branch of the project. What you must accept is that someone else may become more successful with your original code than you are, and thus also have control.
In general, there are more ideas out there than there are developers waiting to work on them. So your real problem will likely be getting anyone to care about your project enough to contribute patches, let alone care enough to usurp control.
Even if you make the source available in a repository for anyone to grab, you still maintain control over the repository: you decide who has access, you decide which patches are committed (or at least, you decide who gets to decide which patches are committed).
However, this doesn't stop people forking your project and taking their forks in a different direction. There aren't any easy ways to prevent that: some people are ornery and will fork every project they touch, while other people might just have a different idea about how your code could be useful.
The best way to minimise forks is to be engaged with the community: be involved in discussions on the direction of the project, accept patches that add features that people want (while maintaining your own coding style and standards of course). If it's easier for people to work with the community and you than it would be to maintain their own fork, most people won't bother forking.
Of course, this means you've ceded some control to the community, because if you stubbornly refuse to give them what they want they're going to make a fork..
Sounds like the missing ingredient is some enthusiastic developers who love your ideas and are prepared to work for free.
I don't think they just pop out of the internet; you will need to go find them.
And once you find them, you need to keep them interested, which may well mean giving up some or all of that control...
Ask yourself what is your goal here–to deliver a software innovation to the world, or to have a pet project?
Well it just depends on what kind of project you are opensourcing.
Are you opensourcing one tightly defined core functionality in a small library, like a Ruby Gem, or a PHP PEAR Package, or are you looking to create the next Wordpress where millions of users have an opinion?
I would suggest starting small. Use something that you've written before, and can be used by others:
A jQuery plugin.
A Wordpress Plugin.
A PHP PEAR Package or a proposal to the Zend Framework.
A Ruby Gem that creates a behavior that can be used in Rails.
A module, or add on to some open source CMS.
Create a specific functionality that you want. Put it somewhere that other users can fork or branch your code, but don't let them merge back to the main branch or trunk of your code.
That way people can work with your code, but ultimately, you have control of what goes back into the official project.
Basically, you can't.
You can't prevent someone else fork your code and start a new project.
At most what you can do is to pick a license that says the source code can't be used to the same product ( I don't know which license is this, but it exists )
And secondly, what you can do is to have a very good control of existing base and a list a features you want to include.
If your project is forked, your new features will make less attractive the other.
Finally, your project will be forked if you don't work on it and leave it die. Otherwise nobody will come and fork your project when you're doing all the hard work right?
Here's a couple of interesting videos on the subject:
http://www.youtube.com/watch?v=-F-3E8pyjFo
http://www.youtube.com/watch?v=0SARbwvhupQ
If it's open source, at the end of the day you cannot control it - anyone will be free to fork it and go on their own sweet way. The way to prevent this happening is to be a "benevolent tyrant" and take on board other people's views on the project's direction. This assumes anyone else is interested in what you are doing, of course.