Time for DVCS?

Germán

unread,

Oct 31, 2012, 12:27:55 AM10/31/12

to ode-...@googlegroups.com

Dear ODE developers,

I'm a light user of ODE and haven't yet contributed any code to the project. However, I would like to, as I am sure many others do. The current procedure for that is not simple, because write permissions to a centralized repository (like SVN) can not be given to everybody that request them, on the risk of breaking the code trunk.

I'm sure you've all heard of Github and git (or Bitbucket and Mercurial). The latter is currently the most successful SCM software out there (used by the Linux kernel project, among others). The former has revolutionized the software development collaboration techniques in a such a way that "Fork me on Github" is a common phrase in open source projects websites. Another alternative (not so popular) is bazaar, by Canonical, the creators of Ubuntu, the most popular Linux distribution ever.

Well, surely I'm not the best one to describe the benefits. There have been some opinions against this modern approach. Before these are repeated here, I leave this link to an article in Tech Republic: "Don't fear the fork: How DVCS aids open source development".

I am available to help with the transition, should it be decided to switch to git or mercurial (i.e. hg). That process is widely documented and there are many tools available because many projects and organizations have already gone through the transition.

Please comment on this. I think this change could have great benefits for ODE, broadening its reach, speeding up development and improving its documentation.

Best regards,

Germán Larraín

M@

unread,

Oct 31, 2012, 3:12:18 AM10/31/12

to ode-...@googlegroups.com

The nice thing is that none of the benefits of distributed version control require the use of _only_ distributed version control. If you'd like to fork off and publish without running the gauntlet to get centralized commit nobody will stop you (git svn clone svn://svn.code.sf.net/p/opende/code/trunk ode). Sure, you're not publishing to _the_ ODE, but then again, if everything was in git the same could be said. Nobody is stopping you from sending pull requests to SVN committers.

--M@

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J.
To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Danny Price

unread,

Oct 31, 2012, 5:14:24 AM10/31/12

to ode-...@googlegroups.com

Agreed

Oleh Derevenko

unread,

Oct 31, 2012, 6:10:13 AM10/31/12

to ode-...@googlegroups.com

Anything wrong with current SVN repository? At the moment I’ve only noticed one complain “The current procedure for that is not simple”.

Well, I personally am happy with SVN and consider it a great version control system. I did not work with Github but guys from another project in my company when they had to start using it complained that it had problems handling large files (just an example).

At present ODE is the system kept in “stable-from-trunk” state. Letting anybody in without him/her getting good grasp on what’s going inside is not going to be anything good. Similarly, making tens of different branches that deviate from each other would be a mess. If you can contribute anything useful for the library (in a form that it fits and agrees with other parts and not just breaks everything else) nobody will ever object it. My personal criterion is “I need not know if it is really useful – I only need to be sure it does not break the library”.

Oleh Derevenko

-- Skype with underscore

--

You received this message because you are subscribed to the Google Groups "ode-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J.
To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

This e-mail may contain privileged and confidential information. If you are not the intended recipient, be aware that any use, disclosure, copying or distribution of this e-mail or any attachments is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you.

Germán

unread,

Oct 31, 2012, 8:17:17 AM10/31/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

Well, why have almost long-time projects (e.g. more than 5 years old) switched from SVN to git or Mercurial? Certainly not because it is the "cool thing" right now (BTW, both have around more than 7 years, enough to have a mature codebase).

Again, others explain it better than me: http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

At the end, it depends whether you want to keep ODE development tightly controlled by a few developers without much community effort, or do the same thing with users trying new things, polishing them with the feedback of the rest, etc, always having the liberty to accept or reject pull requests.

Regards

Germán

unread,

Oct 31, 2012, 8:17:57 AM10/31/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

Sorry, I meant "Well, why have almost all long-time projects..."

Oleh Derevenko

unread,

Oct 31, 2012, 10:02:28 AM10/31/12

to ode-...@googlegroups.com

Ø Again, others explain it better than me: http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

Not convincing enough. That’s just the bargains of a guy who may know Git but pretends to not know SVN. He needed to write an article – there was a good topic – he just used it and did his job, (i.e. had written an article). It may be just as simple as that.

And in reality, there are just few people who collaborate on ODE and all those sophisticated schemas… there is no one who would spend time merging and gathering all that together.

If you need write access – that’s not a problem at all. Ask Daniel K. O. – I’m sure, he’ll enable it for you. All the rest is the gibberish.

To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ.

To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Germán

unread,

Oct 31, 2012, 10:43:56 AM10/31/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

And in reality, there are just few people who collaborate on ODE and all those sophisticated schemas… there is no one who would spend time merging and gathering all that together.

I think you are wrong on this one. Actually merging and all that stuff is a pain in the ass using SVN, not git. One of the reasons is that commits in DCVS tend to be smaller, atomic changes mainly because users work locally, and then decide to push some of all the changesets they created. Which leads to a huge benefit: distributed hosting of repository. SF is down or don't have internet right now? Does not matter, can commit anyway. Worried about backups? Does not matter, users clone the repository, there is no "checkout". Speed? Git is way faster.

Anyway, I really don't see why staying with SVN would be better than move to git or hg, apart from the small effort of doing that. Remember that new developers don't take much time to learn old technologies and certainly would not like a straitjacket as SVN is compared to DVCS.

I see some sort of resistance here to move on

Teravus Ovares

unread,

Oct 31, 2012, 11:10:30 AM10/31/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

My comment is... unless you have a really good reason to switch to Git, then stay with SVN... as a person who worked in SVN primarily with an Open Source Project.. that then switched to Git... There are actually still a lot of developers that are scared of it. I can tell you that three things happened as a result of using Git. Larger corporate code contributions increased. Individual code contributions decreased. The individual who championed Git in the project that I work on has left.

I can tell you that Git doesn't have any problems with large files. It's fully mature and not likely going to break the code or history... that said.. The champions of Git think that Git is easy for the masses.. and while I agree that Git is easy enough to use... in reality, it's /scary/ to the masses.

If you're thinking of switching to it, just make sure that you have a good enough reason.

Best Regards

Teravus

To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/jxCYXPK2hm4J.

M@

unread,

Oct 31, 2012, 12:16:41 PM10/31/12

to ode-...@googlegroups.com

Right. To say the same thing more simply; if it ain't broke, don't fix it. If the committers say it ain't broke, then it ain't broke.

German, the resistance is not to moving on, it's to wasting time on things that don't matter.

--M@

Dimitris Papavasiliou

unread,

Oct 31, 2012, 12:23:21 PM10/31/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

The fact that many large free software projects have started relying on Git is in itself not a necessarily a compelling argument in favor of using it for ODE as well. It depends on the collaboration model of these models and its relation to that of ODE. The Linux kernel for example needs to keep track of contribution from countless hackers into one huge source tree but ODE is not really like that. Furthermore there's the fact that ODE relies on the incorporation of a few external projects into its source tree and last time I checked, that was not easily handled with Git (I know of the relatively recent addition of git submodules but I'm not sure how well it would serve ODE or how easy it would be to set it up).

In any case, and since we're on the subject of collaboration, what exactly is the collaboration model for ODE? I've noticed there are a multitude of patches in the tracker (including a couple of my own) that _seem_ to be largely ignored, in the sense that they're pretty old and still open without any comments that would imply that someone has examined them. If this is due to lack of time then moving to Git would probably just encourage users to circumvent this issue by creating forks (perhaps with outstanding pull requests). We would then be in a situation where a multitude of forks exist which would only contribute to the mess with posts in the mailing list starting with "I'm using this or that fork of ODE and have trouble getting the FancyNewHingeJoint to work".

And speaking of patches, is there anything one could/should do to help out with the introduction (or rejection) of their patches to ODE? People writing patches usually intend to use them in their projects so lack of adoption (or perhaps feedback on whether adoption is likely) would encourage keeping private modified source trees of ODE which is again not in favor of ODE. I'm currently in the funny position of depending on a joint (the Gearbox joint) which I have written for ODE but which has instead been adopted by Bullet which I don't use, nor intend to. I hope this doesn't come out as complaint, I understand that people generally devote their free time to the project and that it is a scarce resource. Just wondering.

Dimitris

Germán

unread,

Oct 31, 2012, 1:12:01 PM10/31/12

to ode-...@googlegroups.com

Right. To say the same thing more simply; if it ain't broke, don't fix it

Absolutely true. However, can it improve? How does ODE shape up compared to other physics engines?

I think there are lots of room to improve. For example:

Between 0.11 and 0.12, more than 3 years went by. That can not be good by any measure (well, maybe it is by Microsoft Windows releases standards :) ).
Dimitris noted the issue about ignored patches and pull requests.
As time has gone by, there are less contributors and contributions. Ohloh shows some interesting summary about this, including the fact that "oleh_derevenko generated more than 50% of all commits during the past 12 months." That speaks great of Oleh, but not of ODE. What will happen to the project if he decides to stop contributing? Will it die?

I want to make clear that I am very thankful of what ODE developers have done, dedicating lots of time to its development and maintenance. However, IMHO ODE is not a baby any more (more than 10 years old now) and maybe it's time to loose the leash a little and let it grow.

Best regards,

Germán

Oleh Derevenko

unread,

Oct 31, 2012, 1:49:42 PM10/31/12

to ode-...@googlegroups.com

From: Germán
Sent: Wednesday, October 31, 2012 4:44 PM

To: ode-...@googlegroups.com
Cc: Oleh Derevenko
Subject: Re: [ode-users] Time for DVCS?

And in reality, there are just few people who collaborate on ODE and all those sophisticated schemas… there is no one who would spend time merging and gathering all that together.

I think you are wrong on this one. Actually merging and all that stuff is a pain in the ass using SVN, not git.

Not at all. I can’t say for Linux and similar, but on Windows with TortoiseSVN working with SVN is easy and pleasant.

One of the reasons is that commits in DCVS tend to be smaller, atomic changes mainly because users work locally, and then decide to push some of all the changesets they created. Which leads to a huge benefit: distributed hosting of repository. SF is down or don't have internet right now?

SVN supports local repositories. SVN supports branches. You are free to commit small changes into trunk after all. There are no restrictions.

Does not matter, can commit anyway. Worried about backups? Does not matter, users clone the repository, there is no "checkout". Speed? Git is way faster.

SVN is not slow. It’s just SourceForge that allows very tiny bandwidth and responds at a speed of a snail. Locally, at my project in LAN environment I do not have any bad experience with operation speeds.

As for Git, the speed ultimately depends on amount of data to be retrieved or merged in. And you can’t force me into belief that with SourceForge (as an example of slow hosting) Git would be faster at checking out complete history tree than SVN with getting just the latest version of trunk.

Oleh Derevenko

-- Skype with underscore

Oleh Derevenko

unread,

Oct 31, 2012, 2:06:31 PM10/31/12

to ode-...@googlegroups.com

From: Dimitris Papavasiliou
Sent: Wednesday, October 31, 2012 6:23 PM

To: ode-...@googlegroups.com
Cc: Oleh Derevenko
Subject: Re: [ode-users] Time for DVCS?

And speaking of patches, is there anything one could/should do to help out with the introduction (or rejection) of their patches to ODE? People writing patches usually intend to use them in their projects so lack of adoption (or perhaps feedback on whether adoption is likely) would encourage keeping private modified source trees of ODE which is again not in favor of ODE. I'm currently in the funny position of depending on a joint (the Gearbox joint) which I have written for ODE but which has instead been adopted by Bullet which I don't use, nor intend to. I hope this doesn't come out as complaint, I understand that people generally devote their free time to the project and that it is a scarce resource. Just wondering.

As for joint patches, the main problem is that there is no dedicated person who would monitor and carry out final decision whether the patch should be accepted or rejected. So generally, if new patch is posted and it is not a clear bugfix but something new, people may express their pros and cons (if at the moment there is anyone who has time to look at it at all) but after that the patch may remain in tracker forever since nobody takes responsibility to merge it in. Or the patch may remain out of trunk because people say it contradicts the primary principles of the system or brings redundancy in (at least in its present form).

So generally, I would suggest that admins who review the patches would add clear note to each one regarding its status: whether and what anything needs to be corrected in it and if it is going to be ever accepted. That would make it clear for patch contributors on what to do next and whether to expect the patch appearing in trunk in overseen future.

Oleh Derevenko

-- Skype with underscore

Bill Sellers

unread,

Oct 31, 2012, 2:49:50 PM10/31/12

to ode-...@googlegroups.com

Dear All,

I have some odd behaviour with my ray-trimesh collisions and I was wondering whether there were any known gotchas with this combination. What I find happens is that it works most of the time but occasionally the collider either misses completely or does not return all the collisions. I'm setting all the collision parameters (firstContact, backfaceCull, closestHit) to zero so it ought to just return all the collisions but occasionally it doesn't (about 1 in every 50 or so, but it gets worse with smaller triangles, larger meshes). I'm wondering whether it might be some sort of rounding error/floating point thing such that on-edge collisions get missed but actually it doesn't seem like that. It's really hard to debug of course because the meshes are quite large and getting the fault to show up repeatably isn't easy. I think my meshes are OK but they are potentially quite complex. Simplifying them helps but still every so often I don't get the collision.

I'm using the collision to detect where on a trimesh the user is clicking the mouse button. When it works (most of the time), it gets it exactly right, so I don't think my basic geometry is at fault. It just sometimes it fails to find any collision, and other times it doesn't find intersection it should. It's the fact that it is mostly right that is making things tricky.

Cheers
Bill

Germán

unread,

Oct 31, 2012, 3:40:52 PM10/31/12

to ode-...@googlegroups.com

Bill, I suggest you repost your question in a new topic so more people can help you.

Dimitris Papavasiliou

unread,

Oct 31, 2012, 8:55:49 PM10/31/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

As for joint patches, the main problem is that there is no dedicated person who would monitor and carry out final decision whether the patch should be accepted or rejected. So generally, if new patch is posted and it is not a clear bugfix but something new, people may express their pros and cons (if at the moment there is anyone who has time to look at it at all) but after that the patch may remain in tracker forever since nobody takes responsibility to merge it in. Or the patch may remain out of trunk because people say it contradicts the primary principles of the system or brings redundancy in (at least in its present form).

So generally, I would suggest that admins who review the patches would add clear note to each one regarding its status: whether and what anything needs to be corrected in it and if it is going to be ever accepted. That would make it clear for patch contributors on what to do next and whether to expect the patch appearing in trunk in overseen future.

So ultimately there are two matters that come into play here: One is whether a patch introducing a new feature is somehow logically compatible with the whole design of ODE so whether it should be accepted at all into mainstream, the other is whether it is currently mature enough for this to happen.

I feel that the first part could be resolved rather easily (in terms of time/effort needed by current maintainers). Most of the proposed patches I've seen lately were accompanied with posts to the list describing their rationale, interface and sometimes implementation. I feel it should be possible to discuss these and point out objections or suggestions for improvement and this has happened in the past (for example with my Gearbox joint or jcooper's Generic Motor Joints). The problem is that these never reach any conclusion since the people that have the final say rarely participate long enough if at all. The point is though that the whole procedure of initial approval shouldn't be too big a deal, at least for the reviewer. The one proposing the patch might have to rework the feature but in most of the recent cases people have been glad to do so.

About the matter of implementation quality: For one it's not a very big deal because it can come with time. New features aren't supposed to be stable between releases anyway and there's plenty of time to test the new features and fix bugs. Besides it's not that rare that a bug is detected and fixed in a long adopted feature. And let's not forget the fact that it's easier for a patch to receive attention by others if it's been adopted into the main trunk. There have been two recent occasions where people posting on the list could benefit from my recently (by ODE time standards) proposed prismatic double-ball joint but it's difficult enough to suggest compiling the latest snapshot from source, let alone checking out a specific version and applying a patch, especially if the interested party doesn't know whether to count on the joint or not in the end.

In any case though the matter of ensuring contributed code quality can be complex and time consuming. It's also important since I imagine that most people fiddling with ODE, like myself, are not too well acquainted with its inner workings. Most people suggesting patches include a demo but perhaps that's not enough. If some sort of unit-tests complete with "proof" of the correctness of the joints would be necessary or helpful in order to ease the review process then I'm sure most people would be happy to supply them. Maybe we can discuss some sort of semi-formal adoption procedure.

Dimitris

Germán

unread,

Nov 1, 2012, 1:04:21 PM11/1/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

Great post Dimitris.

Referring to the patch quality issue, I think demos and unit tests are fundamental, the latter even more so since it allows developers to see for themselves what that piece of code does, should do in other circumstances, and not do.

Maybe the workflow could be improved with a code review tool, so patches are listed in one place, its reviews and comments linked to them, easing management (e.g. know which patches are rejected, accepted, waiting response from maintainer or developer, etc.).

Germán

Teravus Ovares

unread,

Nov 1, 2012, 2:07:55 PM11/1/12

to ode-...@googlegroups.com, Oleh.De...@eleks.com

I second the importance of unit tests for long term project maintenance.

Unit tests provide ways for people who are not super familiar with a part of code to know if it's broken or not based on some other change in a patch. They don't necessarily know how to fix the code that's broken, but they do know if it breaks.

I understand that in physics... unit tests are tough... and.. in a project like ODE that doesn't change significantly very often... probably dooable. The biggest thing to contend with is stability. There is also tradeoff. Some of the limited development time of the ODE devs will be spent on unit tests and not something else.

Best Regards

Teravus

--

You received this message because you are subscribed to the Google Groups "ode-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/V9HN47SNAqIJ.

Bill Sellers

unread,

Nov 4, 2012, 10:26:04 AM11/4/12

to ode-...@googlegroups.com

Dear All,

I've been playing around with this and it seems to be a triangle size thing. Once the triangles in my mesh drop below a certain size, then the collision is not reliable. I've had a look at the ray-trimesh collider and there is a hard-wired epsilon there. In addition the collision code is single precision irrespective of whether ODE is compiled as single or double (I'm using double). I think that could probably explain what's happening, although debugging this completely is going to be tricky. I tried recompiling using GIMPACT instead of Opcode but that didn't work at all - I'm not sure that GIMPACT in ODE supports all the ray-trimesh options. I've also tried the --enable-old-trimesh option but it doesn't affect anything (I don't think it affects this collision combination). At this stage it is probably simpler just to decimate my meshes a bit although I will have a bit more of a play with GIMPACT since I think it shouldn't fail completely.

Cheers
Bill

Tilmann

unread,

Nov 4, 2012, 10:45:51 AM11/4/12

to ode-...@googlegroups.com

Hi,
I remember a discussion from a while ago which may be related. In that case, collision towards the edge of a triangle didn't work reliably (no contacts were generated). There was even a small reproducible testcase with a single (or two) triangles and an object that was moved in very fine steps across the triangle.

The thread was labelled "Trimesh collision seems to fail sometimes".

Here is the resulting bug report (still open)
http://sourceforge.net/p/opende/bugs/73/ (+ example code)
http://sourceforge.net/p/opende/bugs/72/

I paste the resulting map below.

Cheers,
Tilmann

The Map
========

The result now looks like this:
'.' means no collision
'*' means collision with no contacts
'X' means collision with at least on contact

........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................**XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX**.............*X*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............X**XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*.............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX***.............*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX*X*.............**************************************************************************.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

Oleh Derevenko

unread,

Nov 4, 2012, 1:17:02 PM11/4/12

to ode-...@googlegroups.com

Hi!

People, whom are talking to? There is nobody here except for yourselves. You need it – you have to fix it.

Oleh Derevenko

-- Skype with underscore

--

You received this message because you are subscribed to the Google Groups "ode-users" group.

To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Teravus Ovares

unread,

Nov 4, 2012, 1:29:34 PM11/4/12

to ode-...@googlegroups.com

Interesting Oleh,

Logically, that means that there are no official maintainers.. unless that triangle mesh abnormality is desired and intended.. and I don't think it is.

If that's the case, I'll keep that in mind going forward.. with Bullet.

Teravus

Tilmann

unread,

Nov 4, 2012, 1:34:16 PM11/4/12

to ode-...@googlegroups.com

> People, whom are talking to? There is nobody here except for yourselves. You need it – you have to fix it.

I only stated that there is an open bug that might be related. Is that somehow inappropriate?

Tilmann

M@

unread,

Nov 4, 2012, 1:44:12 PM11/4/12

to ode-...@googlegroups.com

Oleh's point has nothing to do with any one person, it's an observation about the state of affairs. It's a failure of an OSS project's community to have recreatable bugs continue to get in people's way for years at a time. You can talk about the responsibility of core people all you want (and with a certain degree of correctness, don't get me wrong), but the people who best understand the bug are the ones most complicit when it doesn't get solved, and that's not always the maintainers.

--M@

Mikko Rasa

unread,

Nov 4, 2012, 1:45:00 PM11/4/12

to ode-...@googlegroups.com

On 04.11.2012 20:17, Oleh Derevenko wrote:
> People, whom are talking to? There is nobody here except for yourselves. You need it - you have to fix it.

Really? Is that your attitude towards ODE? I've noticed you can be
sort of obnoxious with certain issues, but this takes the cake. You're
practically announcing that ODE development is dead. While you may be
somewhat entitled to that judgement, seeing as half the commits have
been coming from you lately, that's still a rather blunt and even rude
way to put it.

I'll think twice when choosing the physics engine for my next big
project. I wouldn't want to use an unmaintained library (or one whose
primary contributor shows a complete disinterest in user issues at the
very least) in a commercial product.

--
Mikko

Rodrigo Hernandez

unread,

Nov 4, 2012, 1:53:44 PM11/4/12

to ode-...@googlegroups.com

Trimesh support was not part of the initial design of ODE, it was added later by some contributor (sorry I don't quite remember who it was, might have been OPCODE's own author Pierre Terdiman), but it was for the most part a patch, a patch that requires an external library to provide contact joints.
Later someone else replaced OPCODE with GIMPACT, which was another patch.

What I am trying to get at is that yes, due to the nature of how trimesh support was implemented there are no official maintainers, anyone is welcome to provide fixes, but most of the time, if you find a problem with trimeshes,
the problem is on either OPCODE or GIMPACT which are completely different projects from ODE, and as such may not be as fine tuned to interact with ODE as ODE's own primitives are.

Now, for simple Ray-Trimesh collision, you may consider writing your own custom routine, after all, all ODE needs are the contact joint data, you don't really need to use ODE's internal collision detection.

Rodrigo.

On 11/4/2012 12:29 PM, Teravus Ovares wrote:

Interesting Oleh,

ï¿½

Logically, that means that there are no official maintainers..ï¿½ unless that triangle meshï¿½abnormality is desired and intended..ï¿½ï¿½ï¿½ and Iï¿½don't think it is.

ï¿½

If that's the case, I'll keep that in mind going forward..ï¿½ï¿½ï¿½ with Bullet.

ï¿½

Teravus

ï¿½

ï¿½

On Sun, Nov 4, 2012 at 12:17 PM, Oleh Derevenko <Oleh.De...@eleks.com> wrote:

Hi!

ï¿½

People, whom are talking to? There is nobody here except for yourselves. You need it ï¿½ you have to fix it.

ï¿½

Oleh Derevenko

-- Skype with underscore

ï¿½ï¿½

ï¿½

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of Tilmann
Sent: Sunday, November 04, 2012 5:46 PM
To: ode-...@googlegroups.com
Subject: Re: [ode-users] Re: Ray-trimesh collision gotchas

ï¿½

Hi,
I remember a discussion from a while ago which may be related. In that case, collision towards the edge of a triangle didn't work reliably (no contacts were generated). There was even a small reproducible testcase with a single (or two) triangles and an object that was moved in very fine steps across the triangle.

The thread was labelled "Trimesh collision seems to fail sometimes".

Here is the resulting bug report (still open)

http://sourceforge.net/p/opende/bugs/73/ï¿½ï¿½ (+ example code)

Dear All,

ï¿½

I've been playing around with this and it seems to be a triangle size thing. Once the triangles in my mesh drop below a certain size, then the collision is not reliable. I've had a look at the ray-trimesh collider and there is a hard-wired epsilon there. In addition the collision code is single precision irrespective of whether ODE is compiled as single or double (I'm using double). I think that could probably explain what's happening, although debugging this completely is going to be tricky. I tried recompiling using GIMPACT instead of Opcode but that didn't work at all - I'm not sure that GIMPACT in ODE supports all the ray-trimesh options. I've also tried the --enable-old-trimesh option but it doesn't affect anything (I don't think it affects this collision combination). At this stage it is probably simpler just to decimate my meshes a bit although I will have a bit more of a play with GIMPACT since I think it shouldn't f
 ail com
pletely.

ï¿½

Cheers

Bill

ï¿½

On Wednesday, October 31, 2012 3:49:55 PM UTC-3, wisellers wrote:

Dear All,

ï¿½

I have some odd behaviour with my ray-trimesh collisions and I was wondering whether there were any known gotchas with this combination. What I find happens is that it works most of the time but occasionally the collider either misses completely or does not return all the collisions. I'm setting all the collision parameters (firstContact, backfaceCull,ï¿½ closestHit) to zero so it ought to just return all the collisions but occasionally it doesn't (about 1 in every 50 or so, but it gets worse with smaller triangles, larger meshes). I'm wondering whether it might be some sort of rounding error/floating point thing such that on-edge collisions get missed but actually it doesn't seem like that. It's really hard to debug of course because the meshes are quite large and getting the fault to show up repeatably isn't easy. I think my meshes are OK but they are potentially quite complex. Simplifying them helps but still every so oft
 en I do
n't get the collision.

ï¿½

I'm using the collision to detect where on a trimesh the user is clicking the mouse button. When it works (most of the time), it gets it exactly right, so I don't think my basic geometry is at fault. It just sometimes it fails to find any collision, and other times it doesn't find intersection it should. It's the fact that it is mostly right that is making things tricky.

ï¿½

Cheers

Bill

ï¿½

ï¿½

ï¿½

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

This e-mail may contain privileged and confidential information. If you are not the intended recipient, be aware that any use, disclosure, copying or distribution of this e-mail or any attachments is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you.

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Oleh Derevenko

unread,

Nov 4, 2012, 1:56:45 PM11/4/12

to ode-...@googlegroups.com

There are authors of the library parts here. But mostly they are busy with other things and given up supporting their code base (let’s admit – in fact it’s true). So if you can fix it – go on and do it and then everybody will be grateful to you.

There is Daniel, there is Bram, there is Pierre, there are others – let them speak for themselves.

As for myself… In theory I could fix it, but in practice (1) I am overloaded with work on my project; (2) my project uses only very few of the library’s features and for me it is a problem to test the changes. So, alas I’m out of the game.

I can only promise to fix glitches in implementations of others if it will be at least 95% correct and functional and if fixing will be necessary, of course.

Oleh Derevenko

unread,

Nov 4, 2012, 3:10:07 PM11/4/12

unread,

Nov 4, 2012, 6:23:43 PM11/4/12

to ode-...@googlegroups.com

By the way, I made corrections to trunk on your behalf and fixed comparisons with LOCAL_EPSILON in all the places. Please try it out and see if it helps.

Oleh Derevenko
-- Skype with underscore

-----Original Message-----

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of Oleh Derevenko
Sent: Monday, November 05, 2012 1:20 AM
To: ode-...@googlegroups.com

Oleh Derevenko

unread,

Nov 5, 2012, 2:16:56 AM11/5/12

to ode-...@googlegroups.com

Bill, could you please remind me what private data do you have to use and why? Let us think once again - if there is something not available in public interface we may be able to improve it.

Oleh Derevenko
-- Skype with underscore

-----Original Message-----
From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of Bill Sellers

Sent: Monday, November 05, 2012 1:03 AM

To: ode-...@googlegroups.com
Subject: Re: [ode-users] Re: Ray-trimesh collision gotchas

However I already have to maintain a private version of ODE because I have had to expose some of the private data anyway for other reasons so I can always just add this to my version. It doesn't have to be fixed in the trunk with any great urgency.

Cheers
Bill

Bill Sellers

unread,

Nov 5, 2012, 3:22:02 AM11/5/12

to ode-...@googlegroups.com

Thank you - I'll try it out. I'm sure I won't notice any performance issues though. When I was stepping through the code I only got to the actual tests a few dozen times.

Cheers
Bill

Bill Sellers

unread,

Nov 5, 2012, 3:37:56 AM11/5/12

to ode-...@googlegroups.com

Hi Oleh,

I use it for restart of the Amotors. I find I need to store and restore the Euler reference vectors. I think you may be able achieve the same thing by setting up the joints in their original position and moving the bodies to their current locations. It's just that I don't set up my simulation world that way - although I think I probably ought to. My restart code isn't perfect by any means but it is mostly good enough and I think fixing it properly is going to be quite a lot of work. I wouldn't change the trunk for this.

Cheers
Bill

Germán

unread,

May 7, 2013, 11:43:51 PM5/7/13

to ode-...@googlegroups.com, Oleh.De...@eleks.com

Today I was learning to use a tool to migrate SVN repositories to Git. Just to see what happened, I tried it with ODE.

ODE in svn / ODE in git

Total size: 296.3 MB / 21.7 MB, i.e. 13.7x

Number of files: 38769 / 986, i.e. 39.3x

tar.gz size: 73.5 MB / 13.2 MB, i.e. 5.57x

It's the first time I compare repositories. The difference is extraordinary. Even more so, the Git repository is 21.7 MB having all the information within it (revisions, tags, branches, etc) i.e. you can checkout to any revision/changeset locally. The SVN repo does not (although I may be wrong; not really familiar with subversion internals).

PS: I'm not arguing to migrate to git :)

On Wednesday, October 31, 2012 11:43:56 AM UTC-3, Germán wrote:

And in reality, there are just few people who collaborate on ODE and all those sophisticated schemas… there is no one who would spend time merging and gathering all that together.

I think you are wrong on this one. Actually merging and all that stuff is a pain in the ass using SVN, not git. One of the reasons is that commits in DCVS tend to be smaller, atomic changes mainly because users work locally, and then decide to push some of all the changesets they created. Which leads to a huge benefit: distributed hosting of repository. SF is down or don't have internet right now? Does not matter, can commit anyway. Worried about backups? Does not matter, users clone the repository, there is no "checkout". Speed? Git is way faster.

Anyway, I really don't see why staying with SVN would be better than move to git or hg, apart from the small effort of doing that. Remember that new developers don't take much time to learn old technologies and certainly would not like a straitjacket as SVN is compared to DVCS.

I see some sort of resistance here to move on

On Wednesday, October 31, 2012 11:02:21 AM UTC-3, Oleh Derevenko wrote:

Ø Again, others explain it better than me: http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

Not convincing enough. That’s just the bargains of a guy who may know Git but pretends to not know SVN. He needed to write an article – there was a good topic – he just used it and did his job, (i.e. had written an article). It may be just as simple as that.

And in reality, there are just few people who collaborate on ODE and all those sophisticated schemas… there is no one who would spend time merging and gathering all that together.

If you need write access – that’s not a problem at all. Ask Daniel K. O. – I’m sure, he’ll enable it for you. All the rest is the gibberish.

Oleh Derevenko

-- Skype with underscore

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of German
Sent: Wednesday, October 31, 2012 2:17 PM
To: ode-...@googlegroups.com
Cc: Oleh Derevenko
Subject: Re: [ode-users] Time for DVCS?

Well, why have almost long-time projects (e.g. more than 5 years old) switched from SVN to git or Mercurial? Certainly not because it is the "cool thing" right now (BTW, both have around more than 7 years, enough to have a mature codebase).

Again, others explain it better than me: http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

At the end, it depends whether you want to keep ODE development tightly controlled by a few developers without much community effort, or do the same thing with users trying new things, polishing them with the feedback of the rest, etc, always having the liberty to accept or reject pull requests.

Regards

On Wednesday, October 31, 2012 7:09:40 AM UTC-3, Oleh Derevenko wrote:

Anything wrong with current SVN repository? At the moment I’ve only noticed one complain “The current procedure for that is not simple”.

Well, I personally am happy with SVN and consider it a great version control system. I did not work with Github but guys from another project in my company when they had to start using it complained that it had problems handling large files (just an example).

At present ODE is the system kept in “stable-from-trunk” state. Letting anybody in without him/her getting good grasp on what’s going inside is not going to be anything good. Similarly, making tens of different branches that deviate from each other would be a mess. If you can contribute anything useful for the library (in a form that it fits and agrees with other parts and not just breaks everything else) nobody will ever object it. My personal criterion is “I need not know if it is really useful – I only need to be sure it does not break the library”.

Oleh Derevenko

-- Skype with underscore

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of German
Sent: Wednesday, October 31, 2012 6:28 AM
To: ode-...@googlegroups.com
Subject: [ode-users] Time for DVCS?

Dear ODE developers,

I'm a light user of ODE and haven't yet contributed any code to the project. However, I would like to, as I am sure many others do. The current procedure for that is not simple, because write permissions to a centralized repository (like SVN) can not be given to everybody that request them, on the risk of breaking the code trunk.

I'm sure you've all heard of Github and git (or Bitbucket and Mercurial). The latter is currently the most successful SCM software out there (used by the Linux kernel project, among others). The former has revolutionized the software development collaboration techniques in a such a way that "Fork me on Github" is a common phrase in open source projects websites. Another alternative (not so popular) is bazaar, by Canonical, the creators of Ubuntu, the most popular Linux distribution ever.

Well, surely I'm not the best one to describe the benefits. There have been some opinions against this modern approach. Before these are repeated here, I leave this link to an article in Tech Republic: "Don't fear the fork: How DVCS aids open source development".

I am available to help with the transition, should it be decided to switch to git or mercurial (i.e. hg). That process is widely documented and there are many tools available because many projects and organizations have already gone through the transition.

Please comment on this. I think this change could have great benefits for ODE, broadening its reach, speeding up development and improving its documentation.

Best regards,

Germán Larraín

--
You received this message because you are subscribed to the Google Groups "ode-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J.

To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

This e-mail may contain privileged and confidential information. If you are not the intended recipient, be aware that any use, disclosure, copying or distribution of this e-mail or any attachments is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you.

--
You received this message because you are subscribed to the Google Groups "ode-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ.

To post to this group, send email to ode-...@googlegroups.com.
To unsubscribe from this group, send email to ode-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ode-users?hl=en.

Ricky

unread,

May 8, 2013, 12:10:25 AM5/8/13

to ode-...@googlegroups.com

Most interesting. I wonder what HG's stats would be.

(Says someone who is curious, but not curious enough to spend the time to try it himself. So feel free to ignore if you don't have the time either! :P )

Ricky

> --
> You received this message because you are subscribed to the Google Groups "ode-users" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to ode-users+...@googlegroups.com.

> To post to this group, send email to ode-...@googlegroups.com.

> Visit this group at http://groups.google.com/group/ode-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

Oleh Derevenko

unread,

May 12, 2013, 5:34:45 PM5/12/13

to ode-...@googlegroups.com

Don’t you think that you might just have moved latest version and discarded all the history?

Oleh Derevenko

unread,

May 12, 2013, 5:54:41 PM5/12/13

to ode-...@googlegroups.com

OK, sorry for that post. I had not read the original mail carefully.

Regarding

> i.e. you can checkout to any revision/changeset locally.

Yes, SVN also supports checking out any revision. This is basic functionality and without it any version control system would be incomplete.

Regarding repository size – I don’t really understand why that matters for you as long as you are not paying for storage at sf.net. During checkouts/updates you only download latest version or changes – not the repository.

Oleh Derevenko

-- Skype with underscore

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of Oleh Derevenko

Sent: Monday, May 13, 2013 12:35 AM
To: ode-...@googlegroups.com

To unsubscribe from this group and stop receiving emails from it, send an email to ode-users+...@googlegroups.com.

To post to this group, send email to ode-...@googlegroups.com.

Visit this group at http://groups.google.com/group/ode-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Germán

unread,

May 12, 2013, 6:50:30 PM5/12/13

to ode-...@googlegroups.com, Oleh.De...@eleks.com

Oleh, perhaps you had to read it even more carefully.

"you can checkout to any revision/changeset locally" is true for git/hg and not for SVN because the whole repository is stored locally thus you can examine any part of its history without a connection to the remote repository (which is just a copy/clone in this case). Maybe that could be done with SVN but it is certainly not the default case. The same is true for local branching, merging, tagging. With DVCS all that works fine out-of-the-box.

Regarding repository size, probably it is not a relevant issue, just an example of how basic SVN is. Besides polluting each directory with a annoying, large ".svn" folder in it, it stores file revisions instead of the changes between them (that explains most of the difference between both SCM software), being grossly inefficient in file management. That's why updating the working directory to a given revision is so slow when it shouldn't be.

For me, really, it all comes down to the following (which has to do with the collaboration mode in this project): imagine person A is working with ODE and after some time he (or she) thinks he can contribute to the project code. What are his options?

Actual collaboration workflow

Start a conversation in this mailing list trying to explain what he intends to work in (he probably hasn't yet coded anything properly i.e. submit atomic and understandable commits)
Wait for other developers to reply to the issue, possibly never getting an answer.
If he gets a reply, a discussion will begin which very possibly will take many messages to resolve or reach some agreement. No commits have been submitted yet (yeah, maybe some patches have emailed, soooo 1990s -and inneficient-).
At some point, he might code some reasonable patch. However, he will need to insist a lot if he expects it to ever be approved (Dimitris and J. Cooper can confirm on this).
Great, he has finally been given write access to the repository (although that scares the shit out of some people because they don't know how good a developer he is and might start breaking things!)
Finally submit his contribution in a few fat (large) commits that modifiy lots of files.

Github/Bitbucket mode

Fork the repository (please don't confuse this with forking a project, it is a whole different story). (optional) In the fork description, state what he wants to do.
Submit small, atomic commits with his contributions.
Anyone (literally) can make comments to what he is doing.
After some time and when the developed feature seems mature enough, he creates a pull request (if you don't what that is, read this).
The lead developers (i.e. the only ones with write privileges in the origin repository) check the proposed contribution and comment on it.
(BTW, all that has happened above is publicly recorded at Github/Bitbucket at the correct places, preventing time-wasting searchs in the mailing list, patch management tool and what else. Commits, branches, people and else are referenced in comments, notifying the corresponding people, generating hyperlinks to the references: making the process efficient!!)
The contributor submits more commits according to the replies to his pull request.
The feature is ready to be merged into "origin/master" and pull request is accepted.

(let's not even discuss about the cases where different people are working in different features in parallel. It becomes a mess with a lineal and centralized SCM such as SVN.)

For me, it's evident that the second is the proper way of working in an open source project that encourages collaboration from whoever wants to (I'm assuming that's what we all want). The first mode certainly discourages contributions from other than the core developers. IMO the current state of this project is a proof of that, and not changing the collaboration mode won't change the current semi-dead condition of the ODE project.

Best regards,

Germán

Danny Price

unread,

May 12, 2013, 7:36:10 PM5/12/13

to ode-...@googlegroups.com

Sorry to interrupt but I wanted to correct some mis-conceptions regarding svn/subversion:

On 12 May 2013, at 23:50, Germán <germanl...@gmail.com> wrote:

"you can checkout to any revision/changeset locally" is true for git/hg and not for SVN because the whole repository is stored locally thus you can examine any part of its history without a connection to the remote repository (which is just a copy/clone in this case). Maybe that could be done with SVN but it is certainly not the default case. The same is true for local branching, merging, tagging. With DVCS all that works fine out-of-the-box.

How often do you checkout the whole repository?

Also most subversion clients will cache the log history with the checkout. It's not continually dialling into the server.

Regarding repository size, probably it is not a relevant issue, just an example of how basic SVN is. Besides polluting each directory with a annoying, large ".svn" folder in it,

That hasn't been the case since subversion 1.7 and possibly earlier. If you do a fresh checkout, you get a single .svn folder in the root.

I haven't used git but I have used mercurial and it does the same thing.

Another advantage of svn/subversion is that revisions are numbered. In git, they're cryptic hashed values. Not an improvement.

I'm not sold on the whole git thing yet. git has a steep learning curve; I just want to write code not fight the version control system.

Also the git GUI clients that are available aren't very mature - I use Cornerstone on the Mac and it's so good you forget you're using svn/subversion.

Germán

unread,

May 12, 2013, 10:10:02 PM5/12/13

to ode-...@googlegroups.com, deepb...@googlemail.com

Thanks for your comments Danny

Checking out to versions: maybe logs are cached, but what about file history, the specific changes introduced in a revision, etc? That is what really is useful, not the messages by themselves.
Subversion 1.7: sorry, it's quite new. I'm using the just released (May 2013) latest Debian OS (7.0) and includes subversion 1.6.17.
Single .svn folder: nope, I just checked and they are eveywhere. And yes, I did perform a fresh checkout.
Numbered revisions: true, hard to argue with that. For those not familiar with DVCS, the cryptic hash-like revision ids are inherent to the distributed nature of the system.
Learning curve: yes, maybe git can be a little complex, but only for operations not available in SVN (or at least that is my impression).
Mercurial is definitely my choice. I had an SVN background and could use it right away. It seems to me easier to learn and use than Git. Also, GUI matters.
GUI

for Git: the github client is available for Mac and Windows. Integration with Eclipse exists too.
for Hg: TortoiseHg is an excellent piece of software, and available for Linux, Mac, Windows.

Ian Macinnes

unread,

May 13, 2013, 12:50:55 AM5/13/13

to ode-...@googlegroups.com, Oleh.De...@eleks.com

Hi,

I'm a very long time ODE user, but never contributed to the source code. I have an opinion to contribute here however.

Subversion works well and is a great tool. But in my opinion Germán is dead on here:

On Mon, May 13, 2013 at 5:50 AM, Germán <germanl...@gmail.com> wrote:

For me, it's evident that the second is the proper way of working in an open source project that encourages collaboration from whoever wants to (I'm assuming that's what we all want). The first mode certainly discourages contributions from other than the core developers. IMO the current state of this project is a proof of that, and not changing the collaboration mode won't change the current semi-dead condition of the ODE project.

Both svn and git are great tools. But as methodologies, it is dramatically easier for others to contribute and comment on new code, and to discuss whether to merge new code, using git(+github) than it is using subversion. This is the current main problem with the ODE project, is it not? The use of git is simply more democratic.

How about putting it up on Github as-is, with the develop branch mirroring the svn repo? Git can do this easily enough. If there is overwhelming more people forking+sending pull requests using git, then perhaps thinking about moving from svn to git will be in order.

It's true there are external projects, so perhaps they can be stashed in the same repo for now.

Best wishes,

Ian

P.S. I disagree that there aren't mature GUI's for git. Try SourceTree for Mac or Windows.

--

Latest doings may be found here: http://www.ianmacinnes.net

Danny Price

unread,

May 13, 2013, 11:50:08 AM5/13/13

to Germán, ode-...@googlegroups.com

On 13 May 2013, at 03:10, Germán <germanl...@gmail.com> wrote:

Thanks for your comments Danny
Checking out to versions: maybe logs are cached, but what about file history, the specific changes introduced in a revision, etc? That is what really is useful, not the messages by themselves.

Is it really such a big deal? How often do you work offline?

Subversion 1.7: sorry, it's quite new. I'm using the just released (May 2013) latest Debian OS (7.0) and includes subversion 1.6.17.

Yes it's the same with OSX. It still only ships with 1.6 even though 1.7 has been around for years. I had to update it manually.

Single .svn folder: nope, I just checked and they are eveywhere. And yes, I did perform a fresh checkout.

Definitely not the case with 1.7.

kwi...@aeongames.com

unread,

May 13, 2013, 1:47:05 PM5/13/13

to ode-...@googlegroups.com

We're not switching the current code to Git because there is no reason
to fix what is not broken, most of German's pros for it are really pros
about the github infrastructure and I do not think there is any desire
to switch from sourceforge to github (or any other open source hosting
service) at the moment, we cannot do it out of one persons whim, if
we're to switch, we'd have to evaluate the options and see poll
everyone's opinion.

That said, everyday I do see that everyone is moving towards
distributed models, and SVN is falling into disuse, perhaps the much
needed ODE refresh can be started using Git or Mercurial as a way to
move forward and start anew.

On 2013-05-13 10:50, Danny Price wrote:
> On 13 May 2013, at 03:10, Germán <germanl...@gmail.com> wrote:
>
>> Thanks for your comments Danny
>>

>> * Checking out to versions: maybe logs are cached, but what about

>> file history, the specific changes introduced in a revision, etc? That
>> is what really is useful, not the messages by themselves.
>
> Is it really such a big deal? How often do you work offline?
>

>> * Subversion 1.7: sorry, it's quite new. I'm using the just released

>> (May 2013) latest Debian OS (7.0) and includes subversion 1.6.17.
>
> Yes it's the same with OSX. It still only ships with 1.6 even though
> 1.7 has been around for years. I had to update it manually.
>

> * Single .sv

>
>> hecked and they are eveywhere. And yes, I did perform a fresh
>> checkout.
>>
>> Definitely not the case with 1.7.

> span style="line-height: normal;">Numbered revisions: true, hard to

> argue with that. For those not familiar with DVCS, the
>

>> on ids are inherent to the distributed nature of the system. *

>> Learning curve: yes, maybe git can be a little complex, but only for
>> operations not available in SVN (or at least that is my impression).

>> * Mercurial is definitely my choice. I had an SVN background and

>> could use it right away. It seems to me easier to learn and use than
>> Git. Also, GUI matters.

>> * GUI
>>
>> * for Git: the github client is available for Mac and Windows.

>> Integration with Eclipse exists too.

>> * for Hg: TortoiseHg is an excellent piece of software, and available

>> for Linux, Mac, Windows.
>>
>> On Sunday, May 12, 2013 7:36:10 PM UTC-4, Danny Price wrote:
>>
>>> Sorry to interrupt but I wanted to correct some mis-conceptions
>>> regarding svn/subversion:
>>>
>>> On 12 May 2013, at 23:50, Germán <germanl...@gmail.com> wrote:
>>>

>>>> "_you can checkout to any revision/changeset LOCALLY_" is true for
>>>> git/hg and not for SVN because THE WHOLE REPOSITORY IS STORED
>>>> LOCALLY thus you can examine any part of its history without a

>>>> connection to the remote repository (which is just a copy/clone in
>>>> this case). Maybe that could be done with SVN but it is certainly
>>>> not the default case. The same is true for local branching, merging,
>>>> tagging. With DVCS all that works fine out-of-the-box.
>>>
>>> How often do you checkout the whole repository?
>>>
>>> Also most subversion clients will cache the log history with the
>>> checkout. It's not continually dialling into the server.
>>>
>>>> Regarding repository size, probably it is not a relevant issue,
>>>> just an example of how basic SVN is. Besides polluting each
>>>> directory with a annoying, large ".svn" folder in it,
>>>
>>> That hasn't been the case since subversion 1.7 and possibly earlier.
>>> If you do a fresh checkout, you get a single .svn folder in the root.
>>>
>>> I haven't used git but I have used mercurial and it does the same
>>> thing.
>>>
>>> Another advantage of svn/subversion is that revisions are numbered.
>>> In git, they're cryptic hashed values. Not an improvement.
>>>
>>> I'm not sold on the whole git thing yet. git has a steep learning
>>> curve; I just want to write code not fight the version control
>>> system.
>>>
>>> Also the git GUI clients that are available aren't very mature - I
>>> use Cornerstone on the Mac and it's so good you forget you're using
>>> svn/subversion.
>>>
>>> On Sunday, May 12, 2013 5:54:41 PM UTC-4, Oleh Derevenko wrot
>>>

>>>> il_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc
>>>> solid;padding-left:1ex">

>>>>
>>>> OK, sorry for that post. I had not read the original mail
>>>> carefully.
>>>>
>>>> Regarding
>>>>
>>>>> i.e. you can checkout to any revision/changeset locally.
>>>>
>>>> Yes, SVN also supports checking out any revision. This is basic
>>>> functionality and without it any version control system would be
>>>> incomplete.
>>>>
>>>> Regarding repository size – I don’t really understand why that
>>>> matters for you as long as you are not paying for storage at sf.net

>>>> [1]. During checkouts/updates you only download latest version or

>>>> changes – not the repository.
>>>>
>>>> Oleh Derevenko
>>>>
>>>> -- Skype with underscore
>>>>

>>>> FROM: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] ON
>>>> BEHALF OF Oleh Derevenko
>>>> SENT: Monday, May 13, 2013 12:35 AM
>>>> TO: ode-...@googlegroups.com
>>>> SUBJECT: RE: [ode-users] Time for DVCS?

>>>>
>>>> Don’t you think that you might just have moved latest version and
>>>> discarded all the history?
>>>>
>>>> Oleh Derevenko
>>>>
>>>> -- Skype with underscore
>>>>

>>>> FROM: Germán [mailto:ger...@gmail.com]
>>>> SENT: Wednesday, May 08, 2013 6:44 AM
>>>> TO: ode-...@googlegroups.com
>>>> CC: Oleh Derevenko
>>>> SUBJECT: Re: [ode-users] Time for DVCS?

>>>>
>>>> Today I was learning to use a tool to migrate SVN repositories to
>>>> Git. Just to see what happened, I tried it with ODE.
>>>>
>>>> ODE in svn / ODE in git
>>>>
>>>> Total size: 296.3 MB / 21.7 MB, i.e. 13.7x
>>>>
>>>> Number of files: 38769 / 986, i.e. 39.3x
>>>>
>>>> tar.gz size: 73.5 MB / 13.2 MB, i.e. 5.57x
>>>>

>>>> It's the first time I compare repositories. THE DIFFERENCE IS
>>>> EXTRAORDINARY. Even more so, the Git repository is 21.7 MB having

>>>> all the information within it (revisions, tags, branches, etc) i.e.
>>>> you can checkout to any revision/changeset locally. The SVN repo
>>>> does not (although I may be wrong; not really familiar with
>>>> subversion internals).
>>>>
>>>> PS: I'm not arguing to migrate to git :)
>>>>
>>>> On Wednesday, October 31, 2012 11:43:56 AM UTC-3, Germán wrote:
>>>>
>>>>> And in reality, there are just few people who collaborate on ODE
>>>>> and all those sophisticated schemas… there is no one who would
>>>>> spend time merging and gathering all that together.
>>>>
>>>> I think you are wrong on this one. Actually merging and all that
>>>> stuff is a pain in the ass using SVN, not git. One of the reasons is
>>>> that commits in DCVS tend to be smaller, atomic changes mainly

>>>> because USERS WORK LOCALLY, and then decide to push some of all the

>>>> changesets they created. Which leads to a huge benefit: distributed
>>>> hosting of repository. SF is down or don't have internet right now?
>>>> Does not matter, can commit anyway. Worried about backups? Does not

>>>> matter, users CLONE THE REPOSITORY, there is no "checkout". Speed?
>>>> Git is WAY FASTER.

>>>>
>>>> Anyway, I really don't see why staying with SVN would be better
>>>> than move to git or hg, apart from the small effort of doing that.
>>>> Remember that new developers don't take much time to learn old
>>>> technologies and certainly would not like a straitjacket as SVN is
>>>> compared to DVCS.
>>>>
>>>> I see some sort of resistance here to move on
>>>>
>>>> On Wednesday, October 31, 2012 11:02:21 AM UTC-3, Oleh Derevenko
>>>> wrote:
>>>>
>>>> Ø Again, others explain it better than me:
>>>> http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

>>>> [2]

>>>>
>>>> Not convincing enough. That’s just the bargains of a guy who may
>>>> know Git but pretends to not know SVN. He needed to write an article
>>>> – there was a good topic – he just used it and did his job, (i.e.
>>>> had written an article). It may be just as simple as that.
>>>>
>>>> And in reality, there are just few people who collaborate on ODE
>>>> and all those sophisticated schemas… there is no one who would spend
>>>> time merging and gathering all that together.
>>>>
>>>> If you need write access – that’s not a problem at all. Ask Daniel
>>>> K. O. – I’m sure, he’ll enable it for you. All the rest is the
>>>> gibberish.
>>>>
>>>> Oleh Derevenko
>>>>
>>>> -- Skype with underscore
>>>>

>>>> FROM: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] ON
>>>> BEHALF OF German
>>>> SENT: Wednesday, October 31, 2012 2:17 PM
>>>> TO: ode-...@googlegroups.com
>>>> CC: Oleh Derevenko
>>>> SUBJECT: Re: [ode-users] Time for DVCS?

>>>>
>>>> Well, why have almost long-time projects (e.g. more than 5 years
>>>> old) switched from SVN to git or Mercurial? Certainly not because it
>>>> is the "cool thing" right now (BTW, both have around more than 7
>>>> years, enough to have a mature codebase).
>>>>
>>>> Again, others explain it better than me:
>>>> http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

>>>> [2]

>>>> FROM: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] ON
>>>> BEHALF OF German
>>>> SENT: Wednesday, October 31, 2012 6:28 AM
>>>> TO: ode-...@googlegroups.com
>>>> SUBJECT: [ode-users] Time for DVCS?

>>>>
>>>> Dear ODE developers,
>>>>
>>>> I'm a light user of ODE and haven't yet contributed any code to the
>>>> project. However, I would like to, as I am sure many others do. The
>>>> current procedure for that is not simple, because write permissions
>>>> to a centralized repository (like SVN) can not be given to everybody
>>>> that request them, on the risk of breaking the code trunk.
>>>>
>>>> I'm sure you've all heard of Github and git (or Bitbucket and
>>>> Mercurial). The latter is currently the most successful SCM software
>>>> out there (used by the Linux kernel project, among others). The
>>>> former has revolutionized the software development collaboration
>>>> techniques in a such a way that "Fork me on Github" is a common
>>>> phrase in open source projects websites. Another alternative (not so
>>>> popular) is bazaar, by Canonical, the creators of Ubuntu, the most
>>>> popular Linux distribution ever.
>>>>
>>>> Well, surely I'm not the best one to describe the benefits. There
>>>> have been some opinions against this modern approach. Before these
>>>> are repeated here, I leave this link to an article in Tech Republic:

>>>> "Don't fear the fork: How DVCS aids open source development [3]".

>>>>
>>>> I am available to help with the transition, should it be decided to
>>>> switch to git or mercurial (i.e. hg). That process is widely
>>>> documented and there are many tools available because many projects
>>>> and organizations have already gone through the transition.
>>>>
>>>> Please comment on this. I think this change could have great
>>>> benefits for ODE, broadening its reach, speeding up development and
>>>> improving its documentation.
>>>>
>>>> Best regards,
>>>>
>>>> Germán Larraín
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ode-users" group.
>>>> To view this discussion on the web visit

>>>> https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J [4].

>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> ode-users+...@googlegroups.com.
>>>> For more options, visit this group at

>>>> http://groups.google.com/group/ode-users?hl=en [5].
>>>>
>>>> -------------------------

>>>>
>>>> This e-mail may contain privileged and confidential information. If
>>>> you are not the intended recipient, be aware that any use,
>>>> disclosure, copying or distribution of this e-mail or any
>>>> attachments is prohibited. If you have received this e-mail in
>>>> error, please notify us immediately by returning it to the sender
>>>> and delete this copy from your system. Thank you.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ode-users" group.
>>>> To view this discussion on the web visit

>>>> https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ [6].

>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> ode-users+...@googlegroups.com.
>>>> For more options, visit this group at

>>>> http://groups.google.com/group/ode-users?hl=en [5].
>>>>
>>>> -------------------------

>>>>
>>>> This e-mail may contain privileged and confidential information. If
>>>> you are not the intended recipient, be aware that any use,
>>>> disclosure, copying or distribution of this e-mail or any
>>>> attachments is prohibited. If you have received this e-mail in
>>>> error, please notify us immediately by returning it to the sender
>>>> and delete this copy from your system. Thank you.
>>>>

>>>> -------------------------

>>>>
>>>> This e-mail may contain privileged and confidential information. If
>>>> you are not the intended recipient, be aware that any use,
>>>> disclosure, copying or distribution of this e-mail or any
>>>> attachments is prohibited. If you have received this e-mail in
>>>> error, please notify us immediately by returning it to the sender
>>>> and delete this copy from your system. Thank you.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ode-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to ode-users+...@googlegroups.com.
>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/ode-users?hl=en

>>>> [5].

>>>> For more options, visit https://groups.google.com/groups/opt_out

>>>> [7].
>>>>
>>>> -------------------------

>>>> This e-mail may contain privileged and confidential information. If
>>>> you are not the intended recipient, be aware that any use,
>>>> disclosure, copying or distribution of this e-mail or any
>>>> attachments is prohibited. If you have received this e-mail in
>>>> error, please notify us immediately by returning it to the sender
>>>> and delete this copy from your system. Thank you.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ode-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to ode-users+...@googlegroups.com.
>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>> Visit this group at http://groups.google.com/group/ode-users?hl=en

>>>> [5].

>>>> For more options, visit https://groups.google.com/groups/opt_out

>>>> [7].

>>
>> --
>> You received this message because you are subscribed to the Google

>> Groups "ode-users&quo
> /> To unsubscribe from this group and stop receiving emails from it,

> send an email to ode-users+...@googlegroups.com.
> To post to this group, send email to ode-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ode-users?hl=en

> [5].
> For more options, visit https://groups.google.com/groups/opt_out [7].
>
>
>
> Links:
> ------
> [1] http://sf.net/
> [2]
> http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
> [3]
> http://www.techrepublic.com/blog/opensource/dont-fear-the-fork-how-dvcs-aids-open-source-development/2199
> [4] https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J
> [5] http://groups.google.com/group/ode-users?hl=en
> [6] https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ
> [7] https://groups.google.com/groups/opt_out

Ian Macinnes

unread,

May 13, 2013, 7:32:54 PM5/13/13

to ode-...@googlegroups.com

Hi,

On Tue, May 14, 2013 at 12:47 AM, <kwi...@aeongames.com> wrote:

We're not switching the current code to Git because there is no reason to fix what is not broken, most of German's pros for it are really pros about the github infrastructure and I do not think there is any desire to switch from sourceforge to github (or any other open source hosting service) at the moment, we cannot do it out of one persons whim, if we're to switch, we'd have to evaluate the options and see poll everyone's opinion.

OK, but there's no harm in putting a mirror of the svn repository on github. There's now one here:

https://github.com/minimind/open-dynamics-engine

I won't develop this repo, it'll just mirror the svn repo.

The master branch is set to up to the last tagged 0.12 release.

The develop branch is complete up to the latest svn trunk update.

All the tags, branches, etc. are here. Within a couple of days, the develop branch will automatically mirror the svn repo to within a couple of hours.

If anybody does want to take it and starting running with it using git, it's now up there.

Ian

P.S. To whoever said it, I don't agree there are no mature GUI's for git. Try SourceTree for Mac/Windows.

send an email to ode-users+unsubscribe@googlegroups.com.

To post to this group, send email to ode-...@googlegroups.com.

Visit this group at http://groups.google.com/group/ode-users?hl=en [5].
For more options, visit https://groups.google.com/groups/opt_out [7].

Links:
------
[1] http://sf.net/
[2] http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
[3]
http://www.techrepublic.com/blog/opensource/dont-fear-the-fork-how-dvcs-aids-open-source-development/2199
[4] https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J
[5] http://groups.google.com/group/ode-users?hl=en
[6] https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ
[7] https://groups.google.com/groups/opt_out

--
You received this message because you are subscribed to the Google Groups "ode-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ode-users+unsubscribe@googlegroups.com.

To post to this group, send email to ode-...@googlegroups.com.

Visit this group at http://groups.google.com/group/ode-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Danny Price

unread,

May 13, 2013, 8:22:22 PM5/13/13

to ode-...@googlegroups.com

On 14 May 2013, at 00:32, Ian Macinnes <ian.ma...@gmail.com> wrote:

Hi,

On Tue, May 14, 2013 at 12:47 AM, <kwi...@aeongames.com> wrote:

We're not switching the current code to Git because there is no reason to fix what is not broken, most of German's pros for it are really pros about the github infrastructure and I do not think there is any desire to switch from sourceforge to github (or any other open source hosting service) at the moment, we cannot do it out of one persons whim, if we're to switch, we'd have to evaluate the options and see poll everyone's opinion.

OK, but there's no harm in putting a mirror of the svn repository on github. There's now one here:

https://github.com/minimind/open-dynamics-engine

I won't develop this repo, it'll just mirror the svn repo.

The master branch is set to up to the last tagged 0.12 release.

The develop branch is complete up to the latest svn trunk update.

All the tags, branches, etc. are here. Within a couple of days, the develop branch will automatically mirror the svn repo to within a couple of hours.

If anybody does want to take it and starting running with it using git, it's now up there.

Ian

P.S. To whoever said it, I don't agree there are no mature GUI's for git. Try SourceTree for Mac/Windows.

I said that. I've used Atlassan SourceTree and while it's the 'best' git GUI client I tried, it's still not great. Very cluttered UI.

kwi...@aeongames.com

unread,

May 13, 2013, 9:32:49 PM5/13/13

to ode-...@googlegroups.com

Yes, that's fine, no one would object to mirroring, we do appreciate
proactive endeavors like yours (who implicitly just volunteered to
maintain the mirror :-))

Thanks!

On 2013-05-13 18:32, Ian Macinnes wrote:
> Hi,
>
> On Tue, May 14, 2013 at 12:47 AM, <kwi...@aeongames.com> wrote:
>
>> We're not switching the current code to Git because there is no
>> reason to fix what is not broken, most of German's pros for it are
>> really pros about the github infrastructure and I do not think there
>> is any desire to switch from sourceforge to github (or any other open
>> source hosting service) at the moment, we cannot do it out of one
>> persons whim, if we're to switch, we'd have to evaluate the options
>> and see poll everyone's opinion.
>
> OK, but there's no harm in putting a mirror of the svn repository on
> github. There's now one here:
>

> https://github.com/minimind/open-dynamics-engine [9]

>>>> mal;">Numbered revisions: true, hard to
>>>>
>>>> argue with that. For those not familiar with DVCS, the

>>> uote class="gmail_quote" style="margin:0px 0px 0px
>>> 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

>>> on ids are inherent to the distributed nature of the system. *
>>> Learning curve: yes, maybe git can be a little complex, but only for
>>> operations not available in SVN (or at least that is my i
>>>

>>>>>> the original mail carefully.
>>>>>>
>>>>>> Regarding
>>>>>>
>>>>>>> i.e. you can checkout to any revision/changeset locally.
>>>>>>
>>>>>> Yes, SVN also supports checking out any revision. This is basic
>>>>>> functionality and without it any version control system would be
>>>>>> incomplete.
>>>>>>
>>>>>> Regarding repository size – I don’t really understand why that
>>>>>> matters for you as long as you are not paying for storage at

>>>>>> sf.net [1] [1]. During checkouts/updates you only download latest

>>>>>> [2] [2]

>>>>>> https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J [3] [4].

>>>>>>
>>>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> ode-users+...@googlegroups.com.
>>>>>> For more options, visit this group at

>>>>>> http://groups.google.com/group/ode-users?hl=en [4] [5].

>>>>>>
>>>>>> -------------------------
>>>>>>
>>>>>> This e-mail may contain privileged and confidential information.
>>>>>> If you are not the intended recipient, be aware that any use,
>>>>>> disclosure, copying or distribution of this e-mail or any
>>>>>> attachments is prohibited. If you have received this e-mail in
>>>>>> error, please notify us immediately by returning it to the sender
>>>>>> and delete this copy from your system. Thank you.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the
>>>>>> Google Groups "ode-users" group.
>>>>>> To view this discussion on the web visit

>>>>>> https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ [5] [6].

>>>>>>
>>>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> ode-users+...@googlegroups.com.
>>>>>> For more options, visit this group at

>>>>>> http://groups.google.com/group/ode-users?hl=en [4] [5].

>>>>>>
>>>>>> -------------------------
>>>>>>
>>>>>> This e-mail may contain privileged and confidential information.
>>>>>> If you are not the intended recipient, be aware that any use,
>>>>>> disclosure, copying or distribution of this e-mail or any
>>>>>> attachments is prohibited. If you have received this e-mail in
>>>>>> error, please notify us immediately by returning it to the sender
>>>>>> and delete this copy from your system. Thank you.
>>>>>>
>>>>>> -------------------------
>>>>>>
>>>>>> This e-mail may contain privileged and confidential information.
>>>>>> If you are not the intended recipient, be aware that any use,
>>>>>> disclosure, copying or distribution of this e-mail or any
>>>>>> attachments is prohibited. If you have received this e-mail in
>>>>>> error, please notify us immediately by returning it to the sender
>>>>>> and delete this copy from your system. Thank you.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the
>>>>>> Google Groups "ode-users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to ode-users+...@googlegroups.com.
>>>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>>>> Visit this group at

>>>>>> http://groups.google.com/group/ode-users?hl=en [4] [5].

>>>>>> For more options, visit https://groups.google.com/groups/opt_out

>>>>>> [6] [7].

>>>>>>
>>>>>> -------------------------
>>>>>>
>>>>>> This e-mail may contain privileged and confidential information.
>>>>>> If you are not the intended recipient, be aware that any use,
>>>>>> disclosure, copying or distribution of this e-mail or any
>>>>>> attachments is prohibited. If you have received this e-mail in
>>>>>> error, please notify us immediately by returning it to the sender
>>>>>> and delete this copy from your system. Thank you.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the
>>>>>> Google Groups "ode-users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to ode-users+...@googlegroups.com.
>>>>>> To post to this group, send email to ode-...@googlegroups.com.
>>>>>> Visit this group at

>>>>>> http://groups.google.com/group/ode-users?hl=en [4] [5].

>>>>>> For more options, visit https://groups.google.com/groups/opt_out

>>>>>> [6] [7].

>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ode-users&quo
>>>> /> To unsubscribe from this group and stop receiving emails from
>>>> it,
>>>>

>>>> send an email to ode-users+...@googlegroups.com.

>>>> To post to this group, send email to ode-users@g
>>> om.

>>> Visit this group at http://groups.google.com/group/ode-users?hl=en

>>> [4] [5].

>>> For more options, visit https://groups.google.com/groups/opt_out

>>> [6] [7].
>>>
>>> Links:
>>> ------
>>> [1] http://sf.net/ [7]
>>> [2]
>>> http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
>>> [2]
>>> [3]
>>> http://www.techrepublic.com/blog/opensource/dont-fear-the-fork-how-dvcs-aids-open-source-development/2199
>>> [8]
>>> [4] https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J [3]
>>> [5] http://groups.google.com/group/ode-users?hl=en [4]
>>> [6] https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ [5]
>>> [7] https://groups.google.com/groups/opt_out [6]

>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "ode-users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to ode-users+...@googlegroups.com.
>> To post to this group, send email to ode-...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/ode-users?hl=en

>> [4].
>> For more options, visit https://groups.google.com/groups/opt_out [6].
>
> --
>
> Latest doings may be found here: http://www.ianmacinnes.net [10]

>
> --
> You received this message because you are subscribed to the Google
> Groups "ode-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to ode-users+...@googlegroups.com.
> To post to this group, send email to ode-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ode-users?hl=en

> [4].
> For more options, visit https://groups.google.com/groups/opt_out [6].

>
>
>
> Links:
> ------
> [1] http://sf.net

> [2]
> http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
> [3] https://groups.google.com/d/msg/ode-users/-/LLCC68L1140J
> [4] http://groups.google.com/group/ode-users?hl=en
> [5] https://groups.google.com/d/msg/ode-users/-/eg9I2TV_9HQJ
> [6] https://groups.google.com/groups/opt_out
> [7] http://sf.net/
> [8]
> http://www.techrepublic.com/blog/opensource/dont-fear-the-fork-how-dvcs-aids-open-source-development/2199
> [9] https://github.com/minimind/open-dynamics-engine
> [10] http://www.ianmacinnes.net

Reply all

Reply to author

Forward