-1

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

Community
  • 1
  • 1
BlueMonkMN
  • 23,447
  • 8
  • 73
  • 134

1 Answers1

1

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

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • You say there is no "server" or "client", but I do see a clear distinction between the repositories hosted on SourceForge, github and bitbucket versus those stored locally. That distinction is that you can commit to a local repository, but not to a "server" repository (that requires pushing and authentication). So what is the proper term? What you propose opens my eyes a bit; I have had a hard time shifting my paradigm to DVCS, but it's starting to become clear. Then would my SourceForge project simply pull the requested version(s) from users' hosted repositories to allow them to play? – BlueMonkMN Apr 19 '12 at 12:55
  • Still I wonder, though, there seem to be opposing forces at work in cyberspace today: Cloud computing invites everyone to put more of their work in the cloud and do less locally on your system, while DVCS pushes people to put content back on your local system so you can access it while not connected to the cloud. Can you see the usse case for an extremely thin client wanting to run their DVCS *client* from the cloud someday? – BlueMonkMN Apr 19 '12 at 13:00
  • By the way D is not decentralized its distributed :) – Learath2 Apr 19 '12 at 14:11
  • @Learath2 arg (shame): I have fixed the "typo" – VonC Apr 19 '12 at 14:27
  • @BlueMonkMN the proper term is "local repo" vs. "upstream repo": again http://stackoverflow.com/questions/2739376/definition-of-downstream-and-upstream/2749166#2749166 is a must read. – VonC Apr 19 '12 at 14:29
  • @VonC I'm still missing something basic in my understanding. I can clone an upstream repo. My friend can clone my repo. Now I am his upstream repo. However, even though I am an upstream repo, I can make commits to my repo. However, there is nobody that can make commits to my upstream repo on SourceForge. We can only push to it. Am I wrong in that assumption? If that's true, is there a term for a repo which nobody can commit to? – BlueMonkMN Apr 19 '12 at 14:55
  • @BlueMonkMN Being an "upstream" repo means others can clone your repo or push to your repo. The fact that the Sourceforge project isn't a repo anyone can push to (except its owner) isn't because of Git/Mercurial. It is because of the authorization layer put by Sourceforge in front of the repo in order to prevent any user to push to (except the one with a public key attached to the account of that repo). More details in http://stackoverflow.com/a/5685757/6309 : an "upstream" repo alone has no notion of authorization (or authentication for that matter) – VonC Apr 19 '12 at 15:49
  • @VonC I thought there was some difference between a commit and a push; that commit was a local operation that compared a whole set of local source code to a "current" branch in a repository, and did not require authorization, while push required authorization, already knew what the differences were, and dealt just with those. Am I thinking about it wrong? Are you saying that if I exposed my Mercurial repository via HTTP, anyone would be able to push or commit updates in it without any kind of authorization? – BlueMonkMN Apr 19 '12 at 18:54
  • @BlueMonkMN: nope, push itself requires no authorization. All you need is access. If you push to a shared path, you need to have access to it (a `dir \\server\shared\path` should work). If you use ssh, an ssh user@server should work. And so on. The authorization comes from an extra layer in charge of using the authentication (if present) including in the push request URL and matching that id with some authorization file. That would be Gitolite for git, or mercurial-server for Mercurial: http://stackoverflow.com/a/10173084/6309 – VonC Apr 19 '12 at 19:03
  • @BlueMonkMN Commit is a related to branching (you add a version to a branch), push/pull is about publication, which is orthogonal to branching: http://stackoverflow.com/questions/2563836/sell-me-distributed-revision-control/2563917#2563917 – VonC Apr 19 '12 at 19:04
  • @VonC Then I re-state that my point from the first comment has been that I see no way for a *commit* to happen directly on the SourceForge repository (without a push to get it there). That is what I see as the fundamental difference, which led my to refer to it as a "server". – BlueMonkMN Apr 19 '12 at 19:54
  • @BlueMonkMN you are right, in that there is a service listening to your request (which is what a server does) and transmitting it to: either the DVCS itself directly (in that case, there is no authorization at all) or to an intermediate authorization layer. When I said that there is no "server" or "client", I meant that considering only the DVCS running on those nodes. But if you take into account the services and authorization layers on top of said DVCS, then the upstream repo can be considered "on a server", and your local DVCS "on a client". – VonC Apr 19 '12 at 20:05
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/10297/discussion-between-bluemonkmn-and-vonc) – BlueMonkMN Apr 20 '12 at 00:59
  • @VonC In your last paragraphs you describe monitoring every user's repository and pulling changes. This being the primary part of the question (how to deal with the web-hosted part of the DVCS content), I could use a little more detail in that area. Where is the repository relative to the files (my understanding is they have to be in the same place, but I can copy the files to a web-visible directory, right?)? So I still need to create a DVCS repository acessible to PHP script. Can all users share 1 repository? What have I gained over my original idea which sounds quite similar now? – BlueMonkMN Apr 20 '12 at 11:29
  • 1
    @BlueMonkMN "monitoring" means regular `git fetch` in order to detect if any new commits have been published on a given remote repo since the last fetch, a bit like in http://stackoverflow.com/questions/7166509/how-to-build-a-git-polling-build-bot. You can considering fetching/pulling in a non-bare repo (in which case the files are where the repo is, in which case you wouldn't need http://stackoverflow.com/questions/9448682/git-submodule-on-remote-bare/9448794#9448794) – VonC Apr 20 '12 at 11:39
  • OK, apparently the piece I was missing from the beginning here was the notion of a bare repository. That's what I was talking about as the distinction I saw between "server" and "clients". SourceForge hosts a bare repository. Understanding this, I guess I either need to get files from a bare repository into a specified "working" (target) directory, where I might be hosting the HTTP-exposed site or create a non-bare repository in order to get the files. And I'd like to figure this out in Mercurial because TortoiseHg looks friendlier than Git UIs. Hopefully 1 non-bare repo can handle all users. – BlueMonkMN Apr 20 '12 at 13:24
  • @BlueMonkMN if you do polling, you are a client compared to the developers repos on sourceForge ("server", with bare repo). So you (the server with "hosted directory where the game can be played online)" don't need bare repo. You can pull directly in a non-bare repo, and copy the files wherever you need them, or even get the non-bare repo directly at target (the "hosted directory") – VonC Apr 20 '12 at 15:30
  • Right. Ideally I'd like to update from the *user's* existing bare repo to a local working directory and skip the middle repo, but I don't know that it's possible to do that, so I would need a local non-bare repo to pull into before doing a update/checkout. – BlueMonkMN Apr 20 '12 at 16:51