2

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 new 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.

Kamyar
  • 18,639
  • 9
  • 97
  • 171

1 Answers1

5

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.

dls
  • 4,146
  • 2
  • 24
  • 26
  • Thank you for the answer. By "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. Is it possible? – Kamyar May 11 '11 at 12:13
  • @Kamyar: ok, I understand. I'm not familiar with the BlogEngine.net site/software, so I can't answer that for you. From a Mercurial perspective, there's no major difference between option #1 and #2 so if you have a problem it would be a BlogEngine.net issue. Good luck! – dls May 11 '11 at 13:14
  • Thanks dls. However, my concern doesn't have anything to do with blogengine.net. Better to put it this way: Can I create a new project in codeplex and set its repository to a forked repository? – Kamyar May 11 '11 at 13:34
  • @Kamyar: I'm unfamiliar with CodePlex, but I believe a similar feature exists in Google Code and cloning (forking) a repository inside Google Code **does** generate a new repository. Nothing prevents you from treating that forked repo like your main repo. Give it a try - it should be easy to test. – dls May 11 '11 at 14:44
  • Thanks dls. I'll post the results here. – Kamyar May 11 '11 at 15:07