To keep my own versioned app or not.

Question

Hi all.

I need some opinions here.

I'm working on a Django project using buildout to get the dependencies, etc... I use mercurial as DVCS.

Now... I need to customize one of the dependencies, so I can do one of the following: (* The changes may not be useful for everyone else.)

1- Do a fork of the project in (github, bitbucket, etc...) maintain my version, and get the dependency with (mercurial or git) recipe.
2- Clone the project, put it in the PYTHONPATH, erase DVCS dirs and add it to my projects version. So every change will be private. Here I need to erase all the info from their DVCS or something.

Any other you can think of.

I'm missing something? I'm too off?

Thanks!

Answer 1

Well if you're using DVCS then all your commits are kept as change sets, and people can choose to apply your change set or not. So as long as you comment that change, people can choose apply the change or not as they see fit. What's more if they don't want that change, but want your other changes, they can pick and choose. So the truth is the DVCS takes care of the problem for you (provided the people pulling from you are using the DVCS properly).

Personally, I recommend forking, but like I said, it doesn't really matter.

Answer 2

You ask this question in a rather confusing way, and I don't know if you really understand the point of a DVCS.

The whole point of a DVCS is to allow you to have your own private repository. You do not need to publish your repository on github or bitbucket or any of those places unless you want to, but I certainly would not erase the DVCS information.

If the upstream project makes changes you do want in addition to your own private changes, you will have a devil of a time merging them unless you keep the DVCS information around.

Using Mercurial, you can include a project in yours by using the Mercurial subrepo feature.

Answer 3

Esteban, take these steps: I'll talk in mercurial-speak, but this is all do able in git too.

1. clone their project
2. make your clone of their project a subrepo in your project

That gives you the best of all worlds. You can edit code in your project and their project without paying attention to which is which, and when you commit the changes to your code go into your repo along with a pointer to a new changeset in your clone of their project. Then when you want to update your clone of their project you can do so in place and merge simply.

So this is pretty much what you said in '1' but there's no need to do a fork or host that repo publically. Just edit their clone as a subrepo of your project and never push (which wouldn't work anyway since you don't have write access to their repo).

Your option two's primary drawback is that as they modify and improve their project on which you depend you'll have a hardtime pulling their improvements in and merging them with yours.