Horde3D

Git is currently not well supported under windows and that's the main development platform for marciano and me. TortoiseHG instead seems to be in a much more stable state than e.g. TortoiseGIT.
And I stumbled across something called Git-HG bridge so merging diffs from HG into your git repository should be possible.

Did you ever happen to be in the situation where your project used to work great two days ago but now doesn't? You are screwed without a versioning system, even if you develop the project alone. And as soon as you have 2 programmers, you don't ever want to look back.

With TortoiseHG, don't forget extensions like rebase/translate though (okay, the former only if you are coming from a git background -.-)


If that would work, that would be the perfect solution.


Oh, and btw: The decentralized nature of Mercurial would imply, that you don't need to finally choose now - you can move your complete repository somewhere else, without ANY problems. So go with the best that is there now, and the switch as soon as there is something better. BerliOS looks good so far.

EDIT: Btw, any opinion about my suggestion to split the repository, one without and one with all extensions?

EDIT2: IRC ftw for such discussions ;D

well, if anyone cares, I can provide a git repos. I can sync it regulary with what ever you choose to take officially.
I use gitosis, so if you plan to use it for commits, you need ssh and I your pubkey.

I friend of mine uses git on windows, inside cygwin, so not very userfriendly, so I can understand your decidion to choose mercurial over git. If you want, i may can host a mercurial too.

--Marenz

IMHO TourtoiseGIT or TourtoiseHG both work well and are complete.

For end users there are few commands to learn:
GIT CS: http://ktown.kde.org/~zrusin/git/git-ch ... medium.png
HG CS: http://www.ivy.fr/mercurial/ref/v1.0/Me ... 120dpi.png

Integrators should be the ones picking, since they will have the most work.

There are a few places to host projectkenai also offers git, mercurial, svn.

http://bitbucket.org/mgottschlag/horde3dext/
http://bitbucket.org/mgottschlag/horde3d/

Works and up-to-date

I've heard from several people now that tgit has tons of bugs still. Never tried myself though, git is definately the best choice for those using the console.

EDIT: I do have a raw clone of the SVN repo without my patches as well - hgsubversion is sloooooow.

For my own setup I'm using a shared SSH account [1], restricted to only allow mercurial operations and a script to control access to individual repositories (similar to [2]). This is conceptually close to how bitbucket does it.

Alternatively you can allow pushes through HTTP in hgweb, but setup the HTTP server to require authentication for POST requests on the URLs belonging to the repositories. This much less secure, but arguably easier to implement.

[1] http://mercurial.selenic.com/wiki/SharedSSH
[2] http://mercurial.selenic.com/wiki/HgLogin

I would recommend it.

Regarding SF, I'd say we are not tied to it at all. The website, forums and wiki are hosted on private web space. The only thing that we would need is a public repository and probably a file mirror but several alternatives for that were listed here. All other SF features have never been used by us anyway.


What would be the major advantage of that? It sounds similar to the community branch that we have right now: a repository to which more people have access to fix problems and adapt the existing extensions.

Sure, it is similar - but with the current setup conflicts with merging are much easier than if the terrain extension only would be in the other repository - and you always know that all extensions are working and up-to-date, not only the one the maintainers of the engine repo directly take care of.

A "community branch" as that is not necessary any more anyways as everyone has his own repo already with mercurial, with the ability to create hiw own branches at will. Rather create an "official" repository just for extensions then.

The point is that it is always required that someone maintains an extension. Even with a separate repository chances are high that some extensions are outdated/not compiling any more, otherwise all extensions in the repository would have to be updated at the same time by one person (which will probably not happen, especially if there is a huger number of extensions).

The rationale behind a community repository is that with a considerable number of people with write access, chances are higher that problems get fixed quickly by someone.

... by creating two different development lines. Imho this is not the correct fix to the problem, which rather would be quick merging to the main repository from the bugfix branches of the different community member clones. Only that way you have *one* repository which is guaranteed to have the newest code *and* all available bugfixes at any time. If this is not done on the main repository you will quickly get into the situation where the repositories get incompatible quickly because you create a different fix for the same bug on the main repo as it is on the community repo - and there is no way to edit the history of the community repo which would mean there is a "broken" changeset in there which makes merging unnecessarily hard. Which again leads to much less merges than what would be necesary for this two-repo development style.

That's why I clearly vote for *one* repository maintained by you and volker (or anyone you choose) which gets sent pull requests (maybe through a thread in the forum) and reviews and pulls the patches directly into the main repo.
And *maybe* another repo for just extension development. Which can, but does not have to be, maintained by different people, and which is the only one containing extensions.

I still didn't get the point where the main difference between the current situation and your proposal is. We have the main repository (currently at SourceForge) and every patch that is posted in the forum is merged into it after a review by marciano or me.
On the other side we have the community branch, that is mainly in Sync with the main repository. If a delay occurs, it is most of the time, caused by the need for some adjustments at one of the extensions, the gameengine or the editor. Because students at the university are using that repository I can't just commit the main repository patches without checking that all other things are still working.

Maybe because I never used HG so far, I didn't understand your points. But I guess if you want a public repository with all the extensions, that is compilable, you always have to take care that patches in the main repository are integrated correctly and not breaking any existing extension code, don't you?

The inly difference is in the terrain exension actually. But well, doen't matter that much. It's just that all core development imho should happen in *one* repository, with just pushing changes into the other one which then is used to develop extensions. That way you never get into the situation where someone pushes a change into the community repo that is *not* merged back which imho produces a quite ugly versioning history.

Any update on this? I'd really love to see a mercurial repo (independent on how it looks and where it is set up).
I currently do quite some maintainance work on H3D (we'll see how much of it ever succeeds in floating upstream) and really prefer to have my offline copy of the repo for this. My fork of the SVN repo doesn't really cut it as sending patches upstream gets messy when having to merge the (then duplicate) changes.

We thought about creating a mercurial repository after the next official release.