@zarch said:
I've tried using Git a few times. Each time I've given up and gone back to SVN as stuff that should be really trivial seems to take for ever. In fact one simple thing (I'd made some changes locally, I wanted to ditch them all and go back to the original) I never did work out how to do. I ended up deleting the repository entirely and recreating it again.
I've been using various VCS for 15 years (clearcase, cvs, svn mostly) and of all of them I found git the most unfriendly, unintuitive and generally unhelpful. The windows tools I found were all worse than the clearcase tools I was using back in 2000!
It's not the concept of distributed I have a problem with... I can see how that makes a lot of sense...it's the dire user interface & experience git and every git tool I've ever tried offers.
I've to say that I've tried to use SVN in many different times and approaches, but every time I did ended up me liking SVN less and less. Today I say that SVN is unfriendly compared to Git.
SVN is really easy to grasp for users that are inexperienced with version control systems, checkout, update, commit. As soon as more advanced concepts as branch/merge is introduced git is by far more pleasant to work with, although a bit daunting to new users.
The cheap and easy branching and merging in git is the one feature I appreciate most.
IMHO version control is also best done at the command line outside the IDE, that way you know exactly what the VCS is doing This is probably only because I’m a linux/os x user and spend far to much quality time in the terminal
Correct me if I am wrong; however, in response to the first question back when I began looking into jME in late 2003, MojoMonkey used CVN as version control because it was what they used internally, I believe at NCSoft, at the time. At one point when jME1.0 was still in development, plans for 2.0 arose and Renanse a colleague of MojoMonkey became a core developer.
Around this time Mojomonkey made a conscious descion to move jME’s codebase away from CVN and to SVN in I beleive 2003. While jme was still in 1.0 and moving to 2.0. around this time the code also became more public and the community suddenly had a large rise in developers and members including myself who was really just watching everything the progress of jME until then, it became as active as it is today. It was around this time I think I remember seeing Zathras’s first set of tutorials.
A big contributor at this time and who helped spring a lot of the ideas relevant in jME3.0 today was darkFrog. He strayed away from the paradigm of the time whichw as set by SimpleGame and created standardGame. standardGame was slated to take over the world and darkFrog was to be ruler. The great thing about StandardGame was that it was differnt than simpel game and it worked with what was called gameStates which would be the precursor to appStates in jME3.0 .
Eventually Renanse decided to step back from development of jME in pursuit of another project and MojoMonkey had been inactive for some time. At this point the community was in a problem because there was no one to host the site.
Amidst all of this confusion Momoko_Fan began work on his jGE3.0. and was granted permission to develop it in an SVN branch of jME. No one knew where it would go and originally it wasn’t seen as the next logical step for jME as such work continued on jME2.0 though staggered.
At one point Erlend_sh came into the community and eventually became the voice of jME. He became the chief organizer and helped manage jME when the community wasn’t sure what it should do next. This was fine until the actual presence of jME on the internet was threatened and oddly enough sbook came into the community and offered server space for the site and project under his college polytechnic institute.
It was around this time Momoko_Fan’s GME became noticeable to everyone else as the next best thing and he changed the name of his project to jME3.0(effectively breaking the small projects I was fooling around with lol ) though some people where resilient to it being the successor at first. jME3.0’s concepts were based on previous revisions but it wasn’t simply a revision it was a rewrite. Where people could upgrade their projects from jME1.0-2.0 somewhat easily (with few annoyances) they would have to rewrite it for jME3.0. jME became a game engine instead of a sceneGraph that required other systems to work properly which essentially segmented everything…how many of us remembers the horrors of ODE ;(.
At some point jME3.0 took over and became head of SVN. Around this time normen came into the community and had plans to create modules for both eclipse and netbeans to help with development. At some point eclipse was dropped and plans for a dedicated IDE came into effect. Also I believe nehon came into the community around this time and helped greatly with the shader system jME currently uses, the most artistic and graphical of all the past core developers.
To ask why they decided to use SVN over GIT is irrelevant; GIT wasn’t available when it mattered to renanse and mojomonkey. Once more changing to GIT never became relevant because all of the core developers where already used to using SVN and GIT was seen as just another version control system.
Well the reason why we don’t switch to git quickly is that we don’t depend on its features but we plan to I completely fail to see the point of hiding a svn behind a git repo especially when you’re used to having issues with them ^^
It seems to me that possibly JME has so many lurkers as the politics in the community are… exemplary. Perhaps people might be more inclined to contributing if they didn’t have to deal with them as much if not at all by moving to a distributed source control strategy. Not that this can’t happen if the repo the core developers continue to use is SVN, but getting code to contribute into the hands of a committer can be a less than optimal experience. On the other hand… issuing a pull request is more direct with less ambiguity as there is a smaller opportunity for misunderstanding and peoples feelings getting hurt as what is being changed is readily apparent from the diff. Issues like the JOGL thread would almost vanish. An ecosystem would emerge. Competition would promote rapid evolution, the codebase would diverge in healthy ways. Everyones crap would just smell better–HA… but whatever.
I would love to see some large scale “refactorings” in JME (“super inspired mastermind style”), but currently as things sit, it is probably not going to happen unless a current core contributor gets a certain spark and somehow convinces the other contributors that is a good thing or if someone decides to branch off and leaves the entire community behind–which is just sad because your all so wonderful and creative. I think git would be a major upgrade to the overall health of the JME community. Just saying.
Well if I have a local fix supply the patch here, later when it is added to svn it will be automerged for me without hassle.
Since with the svn I cannot truly do branches without commit rights. (And even then it would not be good if everyone would do their branches on the svn server) While this way I can do my local branches for testing features ect.
I have to agree with the former post as well, in some other projects that use git, there is a frequent branch and merging, where for a problem 2 or even 10 solutions are commited, and the fittest one survives, since it’s the one that will be used. Currently all decisions are made central.
I totally agree with jappinen. I think the community as a whole would benefit from using a distributed version control system, there are many talented developers here that would love to contribute to the engine and SDK…
Although for the moment I think it’s more important to get the pending release out, not the right time to switch VCS
I think Empire presents a good point about SVN not limiting the community but I thought I would address a general point.
Regardless of source control tech, there are some distinct advantages to requiring contributors to supply their updates as patches:
it gets eyes-on immediately. When the patch topic comes in, I will read it. Others will read it. We will comment. When some kind of external thing is required instead, the source code won’t be viewed until some committer has time to look at it. Very few people will bother because it’s no longer right in their face. (Heck, I rarely even click on image links when they aren’t embedded.) So we go from post, response: “hey you left some printlns in”, response: “oops sorry”, repost all happening within a few hours, to commit… wait a few weeks… post: “hey, you left a bunch of debugging stuff in” (where would we even say this in the first place?)… wait a few days… new commit… repeat as necessary.
a little contribution friction is a good thing. It then motivates the contributor to double check their work, make the changes more surgical, etc… If I git-pull some changes and get a whole repository’s worth of whitespace reformatting then I’m just not going to git-pull anymore.
it forces the committer to actually look at and process the changes. It’s still possible to just green light something but it’s even more likely with a git pul + commit. “Gee I hope it still builds but I’m in a hurry”. And really, this sort of gate keeping is the point of having gate keepers in the first place. Those who want a relatively stable experience will appreciate the amount of thought that (usually) goes into applying patches. Everyone else can (and probably does) fork the source.
So if/when/whatever JME converts to GIT, I think it would be a huge step backwards to quality if we lose the process of posted patches.
I think pspeed has a very good point about the ease of reading a patch in the forum. But for larger changes (like refactorings) they aren’t easy to read. With a DVCS I think those kinds of changes are easier to handle.
I can imagine that posting patches on the forum would be the best way to argue for your change as a means to get a gatekeeper to actually bother to do a mercurial-pull, (yeah I went there )
The VCS and the “patch process” aren’t that tied together that we’d have to give it up because the VCS changes sometime.
Well, regardless of SVN or GIT, there could be a standard Code Formatting rules. That would avoid issues regarding formatting problems and identing. I know that in Eclipse you can create and change this really easily, as a profile, but I don’t know if that’s possible in Netbeans (jMESDK). In Eclipse I think you can bind to workspace. That would be really good thing IMHO, problems with this happens really often! (I’ve been through this while patching the Terrain Editor, and I almost generated a mess! Ended up making ctrl+c ctrl+v of my folder, reverted all changes and using a diff/merge tool just to apply the real code changes!)
Yeah you can but our code normally is formatted all the same, only the blender stuff is an exception sometimes as Kaelthas is the only one using Eclipse
What rules do you use on the Netbeans → Options → Editor → Formatting ? And the imports, how do you sort them? I think those things can be exported to a file and then any member that wants to make a patch, just uses that formatting standard.
Regardless of formatting rules, it is totally unacceptable in my opinion to reformat a file for a one line change. Completely horrendous to reformat dozens of files for a relatively minor change to one or two of them. Thus is the danger of git pulls and trying to sort out what actually changed versus patches where we can call them unacceptable five minutes after posting.
@pspeed All those problems are quite easily mitigated by simply extending and clarifying the “process of posted patches”, something that’s overdue for improvement anyhow. GitHub facilitates this with their contribution guidelines notification. GitHub also has a powerful API - I’m sure there’s a great number of ways for us to effectively facilitate patch visibility and scrutiny.
I personally approach Git (and to me, GitHub is the de facto gateway to Git goodness) as a community manager. I just look at how a project changes when it goes from one tool, platform or workflow to the other. Without exception, when projects move to GitHub, I’ve seen them become either more cooperative, transparent, communicative, responsive, efficient, or all of the above. I’ve yet to see a project that didn’t benefit from moving to GitHub. Months of observing and inquiring eventually resulted in an extensive writeup. So here’s my personal, non-developer take on GitHub for jMonkeyEngine:
@airbaggins There’s not much progress to speak of in the Git compartment. Feel free to get it started. If you successfully set up an SVN mirror on GitHub, we could consider following the WordPress example by keeping an official GitHub branch for Git users to pull from, but disallowing pull requests for as long as it’s not our default VCS.
Not really sure switching to git we’ll bring more contributors. Contributors always found their way in until now.
As long as SVN is not painful I don’t see the urge to switch.
However i’ll stand against switching to githuh for the reasons I already explained Erlend. I browse jME code online everyday and their online code browsing feature is beyond terrible.
@nehon said:
Not really sure switching to git we'll bring more contributors. Contributors always found their way in until now.
As long as SVN is not painful I don't see the urge to switch.
However i'll stand against switching to githuh for the reasons I already explained Erlend. I browse jME code online everyday and their online code browsing feature is beyond terrible.
Googlecode is fine and now offers git as a VCS.
Wow, I gotta say that I really prefer Github over GC. In any aspect I think GC get's owned by Github. Also Bitbucket is an alternative to consider (or not). @nehon I think that the process of submiting is just easier to be done in Github, as it's really well integrated.
I don't know just how would it be done with the forum and the discussions over here. It's somewhat similar to the problem of some of the issues in the forum and some other in the GC website.
This is probably only because I’m a linux/os x user and spend far to much quality time in the terminal 
Perhaps people might be more inclined to contributing if they didn’t have to deal with them as much if not at all by moving to a distributed source control strategy. Not that this can’t happen if the repo the core developers continue to use is SVN, but getting code to contribute into the hands of a committer can be a less than optimal experience. On the other hand… issuing a pull request is more direct with less ambiguity as there is a smaller opportunity for misunderstanding and peoples feelings getting hurt as what is being changed is readily apparent from the diff. Issues like the JOGL thread would almost vanish. An ecosystem would emerge. Competition would promote rapid evolution, the codebase would diverge in healthy ways. Everyones crap would just smell better–HA… but whatever.