Horde3D

Next-Generation Graphics Engine
It is currently 28.03.2024, 10:13

All times are UTC + 1 hour




Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: 27.01.2010, 16:27 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
Marenz wrote:
hmm is Mercurial a must-have req.?
Ever thought about git?
--Marenz

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.


Top
 Profile  
Reply with quote  
PostPosted: 27.01.2010, 17:28 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
Quote:
Then again, I am used to being the sole programmer in my projects.

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

Quote:
I personally like the idea of hosting Horde3D at the university's server

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


Top
 Profile  
Reply with quote  
PostPosted: 27.01.2010, 17:44 
Offline

Joined: 15.07.2009, 13:45
Posts: 8
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


Top
 Profile  
Reply with quote  
PostPosted: 27.01.2010, 17:53 
Offline

Joined: 26.03.2008, 02:58
Posts: 160
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.


Top
 Profile  
Reply with quote  
PostPosted: 27.01.2010, 17:56 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
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.


Top
 Profile  
Reply with quote  
PostPosted: 27.01.2010, 20:42 
Offline

Joined: 06.06.2009, 23:13
Posts: 7
Volker wrote:
I haven't used Mercurial so far, but just read a bit of the documentation,... one of the things I haven't completly understood is how a public repository is managed to allow pushing from different users.
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


Top
 Profile  
Reply with quote  
PostPosted: 27.01.2010, 20:48 
Offline

Joined: 27.01.2010, 08:28
Posts: 1
I would recommend it.


Top
 Profile  
Reply with quote  
PostPosted: 27.01.2010, 23:23 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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.

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

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.


Top
 Profile  
Reply with quote  
PostPosted: 28.01.2010, 16:31 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
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.


Top
 Profile  
Reply with quote  
PostPosted: 29.01.2010, 22:15 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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.


Top
 Profile  
Reply with quote  
PostPosted: 30.01.2010, 15:26 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
Quote:
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.


Top
 Profile  
Reply with quote  
PostPosted: 30.01.2010, 23:05 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
Quote:
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?


Top
 Profile  
Reply with quote  
PostPosted: 30.01.2010, 23:11 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
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.


Top
 Profile  
Reply with quote  
PostPosted: 15.03.2010, 17:44 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
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.


Top
 Profile  
Reply with quote  
PostPosted: 16.03.2010, 09:21 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
We thought about creating a mercurial repository after the next official release.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 18 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group