forums.ps2dev.org

FYI, I set up a mirror of the PS2SDK sources at https://bitbucket.org/misfire/ps2sdk/ which uses Mercurial instead of SVN.

Feel free to clone the repository and commit changes to your local copy as you please:

$ hg clone https://bitbucket.org/misfire/ps2sdk/

This is in particular useful when you don't have write access to the "official" SVN repository, but still want to keep track of your changes.

Is this really a good idea ?

I fully agree with the idea of having a backup repository, in case anything happens to interfere with the workings of the original one. But having everyone make their updates in both places will not work. Especially not when they use different updating methods.

That will inevitably lead to a situation where the two repositories are badly out of sync for some projects, and may also lead to confusion for new developers about where to get the real deal...

So I'm in favour of such a site copy purely for backup purposes, but for a real mirror we'd need automatic scheduled mirroring, and that is never going to work with incompatible repository systems.

Perhaps I missed something (in case there is some compatibility mode), but I think this idea needs some reworking...

Best regards: dlanor

As I said, it's only a mirror, not a fork. Except for the .hgignore file, I'll not push any changes to it which are not part of the "official" repository.

However, people can clone the Mercurial repository and commit changes to their local copy. When they feel they've created something worth sharing, they can create a patch from it and post it here.

I think it's perfectly reasonable. Actually, distributed revision control tools give you more freedom. There's no distinction between people with commit access and people without. Not to speak of the many powerful features of Mercurial.

misfire wrote:As I said, it's only a mirror, not a fork.

Yes, but if/when people start committing to it, without also committing to the main repository, they thereby start creating forks.

Except for the .hgignore file, I'll not push any changes to it which are not part of the "official" repository.

However, people can clone the Mercurial repository and commit changes to their local copy. When they feel they've created something worth sharing, they can create a patch from it and post it here.

I think it's perfectly reasonable. Actually, distributed revision control tools give you more freedom. There's no distinction between people with commit access and people without. Not to speak of the many powerful features of Mercurial.

Sorry, but I still don't get how this can avoid being in 'competition' with the main SVN repository.

Assume that a maintainer of important PS2Dev projects adopts this method, and switches to 'Mercurial' commits, how is that then to be combined with SVN commits of the same material, without forcing this developer into maintaining double repository 'trees'. And if he drops out of the habit of making SVN commits, what happens to the main PS2Dev repository then...?

Perhaps I missed something, not having used 'Mercurial' myself, but it all seems a rather odd way of doing things, having two different systems for the same purpose.

What exactly was so wrong about the SVN methods, making you think that it is not suitable also for a backup mirror site ?

IMO a true mirror should have identical content, thus using the same system.

Best regards: dlanor

I guess you completely miss the point/benefits of distributed version control systems like Mercurial or Git. Probably because you've never used one yourself...

I recommend reading the chapter The forking non-problem from http://hgbook.red-bean.com/read/how-did ... -here.html

It has been suggested that distributed revision control tools pose some sort of risk to open
source projects because they make it easy to “fork” the development of a project. [...]

What distributed tools do with respect to forking is they make forking the only way to develop a
project. Every single change that you make is potentially a fork point. [...]

If every piece of work that everybody does, all the time, is framed in terms of forking and
merging, then what the open source world refers to as a “fork” becomes purely a social issue. If
anything, distributed tools lower the likelihood of a fork:

* They eliminate the social distinction that centralised tools impose: that between
insiders (people with commit access) and outsiders (people without).
* They make it easier to reconcile after a social fork, because all that's involved from the
perspective of the revision control software is just another merge.

Some people resist distributed tools because they want to retain tight control over their
projects, and they believe that centralised tools give them this control. However, if you're of
this belief, and you publish your CVS or Subversion repositories publicly, there are plenty of
tools available that can pull out your entire project's history (albeit slowly) and recreate it
somewhere that you don't control. So while your control in this case is illusory, you are forgoing
the ability to fluidly collaborate with whatever people feel compelled to mirror and fork your history.

If I want to contribute patches to PS2SDK (I actually do), it doesn't matter if I create a diff from my working copy of the SVN repo or "my" Mercurial repo.

And if I really wanted to create a fork for a project where the SDK doesn't fit my needs, I would simply do it because it's the best technical solution.

misfire wrote:I guess you completely miss the point/benefits of distributed version control systems like Mercurial or Git. Probably because you've never used one yourself...

I already said I haven't used it, and hinted that I might have missed some point thereby, but I am very sure that I have not missed them all completely.

I recommend reading the chapter The forking non-problem from http://hgbook.red-bean.com/read/how-did ... -here.html.

It may be just a temporary problem, but right now that link only produces a '404' error page.

The parts you quoted contain things that I can agree with as well as some that I disagree with. Surely you didn't expect me to accept it all as gospel just because someone published it somewhere.

It has been suggested that distributed revision control tools pose some sort of risk to open
source projects because they make it easy to “fork” the development of a project. [...]

This part I do agree with

What distributed tools do with respect to forking is they make forking the only way to develop a
project. Every single change that you make is potentially a fork point. [...]

And this part as well. And I do see that this opens roads to BOTH advantages and disadvantages, when it comes to project maintenance.

Ifanything, distributed tools lower the likelihood of a fork:

This conclusion lacks any basis in the quoted text, and I disagree with it completely.

* They eliminate the social distinction that centralised tools impose: that between
insiders (people with commit access) and outsiders (people without).
* They make it easier to reconcile after a social fork, because all that's involved from the
perspective of the revision control software is just another merge.

These things I do agree with, and are part of the advantages I mentioned above.

Some people resist distributed tools because they want to retain tight control over their projects, and they believe that centralised tools give them this control.

That is definitely not my issue, since I have NO control over the current SVN repository.

However, if you're of this belief, and you publish your CVS or Subversion repositories publicly, there are plenty of tools available that can pull out your entire project's history (albeit slowly) and recreate it somewhere that you don't control.

This is obviously true, but completely beside the point I was making. Control as such is not the issue.

So while your control in this case is illusory, you are forgoing the ability to fluidly collaborate with whatever people feel compelled to mirror and fork your history.

That depends on how we define 'fluidly'. For anyone who really wants to do it there is no problem in creating a fork of PS2SDK, for example. Anyone can do that, and that is not the kind of thing I was worried about.

But when an alternate repository is presented as a full semi-official mirror, and project maintainers are urged to switch to using this for their commits, that is an entirely different case.

If I want to contribute patches to PS2SDK (I actually do), it doesn't matter if I create a diff from my working copy of the SVN repo or "my" Mercurial repo.

Perhaps not. But I doubt that most developers want to commit in two different directions, as would be required for properly updating a project in both these repositories. The majority will choose one method and stick to it alone.

And if I really wanted to create a fork for a project where the SDK doesn't fit my needs, I would simply do it because it's the best technical solution.

Of course, and I have absolutely no issue with that. I only objected to a new repository method being presented as a direct alternate to the existing one. Whatever forks you (or any group of people) have in private is your own business, and none of mine... :)

Best regards: dlanor

Sorry, I fixed the link.

But I doubt that most developers want to commit in two different directions, as would be required for properly updating a project in both these repositories.

Alright. But just assume you're working on a really cool new feature for the SDK including a lot of changes, and you don't have commit access. What do you do to keep track of your changes before sending in a patch? That's exactly where Mercurial prevails - you can even commit while being offline.

Nobody is "urged to switch". It is simply an alternative you can choose if you prefer a system like Mercurial to do your version control. Nothing more. If you prefer the "SVN way", fine. But if somebody wants to take advantage of the "distributed way", my repository can serve as a starting point.

For developers, there's no black and white here. It's about diversity and choosing the best technology.

misfire wrote:Sorry, I fixed the link.

Thanks. Now it works fine.

Alright. But just assume you're working on a really cool new feature for the SDK including a lot of changes, and you don't have commit access. What do you do to keep track of your changes before sending in a patch? That's exactly where Mercurial prevails - you can even commit while being offline.

Nobody is "urged to switch". It is simply an alternative you can choose if you prefer a system like Mercurial to do your version control. Nothing more. If you prefer the "SVN way", fine. But if somebody wants to take advantage of the "distributed way", my repository can serve as a starting point.

Agreed. I have no issue with such usage, and I see that it can be a useful way of handling development particularly for things that are not suitable for commiting to the 'real' PS2SDK in an intermediate form. (Because the PS2SDK libs need to always form a functional whole.)

Then Mercurial can be used for maintenance while getting past the critical humps, with commit to the 'real' PS2SDK when the project has a form more suitable for public use. At least that is how I would consider using it myself for PS2SDK-related projects.

Best regards: dlanor

Exactly. That was one of the reasons I considered the mirror in the first place.

also i remember ps2dev svn having some reliability issues in the past, at least for me.

i usually check out svn via git-svn.

the most notable advantage is that i only need svn server to check out new revisions or pushing my changes (in case of ps2dev - unlikely ;-)). for everything else (switching revisions/branches/diffs/etc) - i do not need it.