Mercurial source control - pros and cons of Forking

I'm customizing BlogEngine.Net to support custom local features (Farsi calendar, RTL theme, etc.)

BlogEngine.Net uses mercurial source control and I am able to create a fork of the project and commit my changes to it. But I'd like to release it as a separate project since there are major modifications in the code to support Persian language and I do not intend to send a pull request to the main project. AFAIK I have two options:

1. I can download BlogEngine.Net's source code, create a n开发者_如何学编程ew project, commit the original source files and then commit my changes to the repository.
2. I can fork the main project and have a clone repository. then I can commit on that repository.

Now what are the benefits of using a fork? if I create a fork, will I be able to release my project in its own page just like an independent project (option no.1)? By saying "its own page' I mean I'd like to have an address like "FarsiBlogengine.CodePlex.Com" and make binary version, source code version available to download, have a discussion forum, etc. Just like the features I have when I do not use forking.

Generally, what are the pros of using forking instead of downloading the main project, creating a new project and committing to the new project?

Thanks.

The primary benefit of forking (aka: cloning) (aka: option #2) is that your repository will contain the entire history of the parent repository, enabling the option to push or pull from that repository if needed. Using option #1, you are starting from a snapshot of the parent repository and losing the project history/lineage.

When determining if two repositories are related Mercurial will look for a common ancestor - in the case of option #1 you will not have that, and in the case of option #2 you will. Even though you explicitly stated that you don't want to perform any synchronization with the parent repo (push/pull/etc..) you might find that BlogEngine.net releases a critical bug fix that you want to pull over and perform a pull occasionally. Option #1 will prevent you from doing this because it will not find common ancestry, but option #2 will allow it.

In terms of releasing your code, I'm not exactly sure what you mean by "it's own page", but I don't think you'll have any issues releasing with either option. In both cases all you have is a simple repository. In case #2 you just have a larger repository with more commits and more history.