Question

Okay, I have been grasping as all sorts of solutions to my problems with questions like Recommended DVCS mechanism for hosting many independent patches and Using Mercurial patch queue repository on BitBucket for many users and patches, but hopefully this will be the last question I need to ask about how to establish source control for my project described at https://sourceforge.net/p/iotabuildit/wiki/Home/. Then I can accept some answer on my other questions and move on.

The requirements I am struggling to fulfill are:

  1. Contributing source modifications (patches) must be very easy for the user. That means they should not have to download a version control client.
  2. Any version of the code needs to be easily hosted online because it doesn't work in Chrome when run from a local set of files due to W3C security requirements (which IE apparently ignores, but Chrome honors).
  3. Users should be able to register by themselves and automatically have permission to contribute patches that anyone else can play and review (like Little Big Planet, but more integrated - allowing changes to anything instead of just adding content).

The paths I have tried so far have failed for the following reasons:

  1. Mercurial Patch Queue - after exploring this for a short while, I discovered it's far too complicated for an average player/user to get involved in. We're talking potential non-developers here.
  2. Github & BitBucket - These repositories still appear to require a local DVCS client, and require additional steps to contribute patches. In the end they are still to difficult for an average user, especially someone who simply wants to play some user's particular version of the game. There appears to be no way to host the files online.

So now my proposed solution is as follows, and I want to see if I am missing something that could be better handled in some other way. I will create some PHP scripts on my SourceForge project that will:

  1. Allow users to register their own email/account with a password so that only they can update their own "patches"
  2. Allow them to clone the standard repository or any other users repository.
  3. Create the clone online in a directory accessible to the PHP script, but not to HTTP.
  4. Allow them to submit a set of files to their working directory and commit the differences to their repository as a patch.
  5. Allow patches to be pulled from other user's repositories in the same directory. (Pulling and committing to your own repository doesn't require authentication, which is a stumbling block when I was considering more formal online repository hosting that already exists)
  6. Have a separate PHP script that copies your workspace into a hosted directory where the game can be played online. Any players could visit this workspace to play your version of the game (which may include patches pulled from any number of other repositories).

It seems odd that I can't use existing repositories to do this, but I can't think of a way around the authentication problem. So I need to create my own clones that I know the PHP script should be able to access and commit to without pushing. Other DVCS clients will probably not be able to pull from these online clients, unfortunately, but there are probably ways to export patches if need be. And I don't know what I'm going to do when a merge conflict comes along. But this is the closest I've come to a workable solution so far.

So what I end up with is an online DVCS client to avoid the users having to download a DVCS client and avoid having to find a host for their version of the game. Am I overlooking a simpler solution? (Am I violating SourceForge's terms of service? I could host it on Dreamhost too if (I can get) Mercurial installed there.)

Was it helpful?

Solution

Few comments/answers:

With a DVCS (with a 'D' as Distributed), there is no 'server' or 'client'.
If you want to access the code locally (on your workstation), you will need a DVCS (git or Mercurial), and you would clone an upstream repo (that is, a remote repo stored in GitHub or BitBucket).

For what I understand, each user would fork the main repo, creating one repo per user, still stored on the upstream server (GitHub or BitBucket), since it is the idea behind a fork (clone on the remote side).

That would address 1. since each user is the owner of his/her own fork, and have write access only there.
2. is a given (you can fork a repo)

The rest of the points won't be addressed by GitHub or BitBucket, but by a dedicated server, where you have a DVCS installed, and where you have added the relevant hook in order to automate what you want.
That dedicated server can monitor what is pushed on GitHub or BitBucket, for a given repo of a given user, do the required clone or update, and sync the repo to the right directories (accessible to the PHP script in your case, for instance).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top