[ODE] New Joints format

[Jon Watte (ODE)]

If you put your code into source control, there's no manual work needed.

1) Check in plain ODE to your "trunk"
2) Pull a branch/copy for your own work (call it "working")
3) make changes in working
4) when new ODE comes out, check in changes into trunk
5) use source control merging tool to merge ODE changes into working

Note that you can run source control locally on your own machine, it 
doesn't need any particular kind of server or infrastructure. And 
checking in your code into a versioned respository every so often is a 
Good Idea no matter what you're doing (just like, say, turning off the 
circuit breaker before fixing an outlet, or making backups of important 
data).

I would recommend Subversion because it's free, robust, and featureful, 
but RCS, CVS, Perforce, Bitkeeper and other options are out there.

Cheers,

          / h+


Bill Sellers wrote:
> Hi All,
>
> Often the best way of achieving a particular effect (best as in  
> stable and quick) is to create a new joint. Whilst this isn't  
> particularly difficult in the current ODE (although some extra  
> documentation would help) once you've written your custom joint it is  
> a real pain to keep on top of code revisions because you need to keep  
> private copies of 5 different files and repatch the new ones. It  
> seems to me that we could probably come up with a format that allows  
> just a single custom_joints.cpp and custom_joints.h file - preferably  
> that can be defined at ./configure time. Certainly all the changes to  
> joint.cpp, joint.h, ode.cpp would be fine. The changes in objects.h  
> would also be fine since anyone using a custom joint can probably  
> cope with being careful not to use the non-public interface to their  
> new joint. The only real problem is common.h since you need to add  
> extra joint types and the easiest way I can think of to fix that is  
> to include a few dJointTypeUser1, dJointTypeUser2, dJointTypeUser3  
> definitions at the end of the enum. There isn't really any overhead  
> associated with doing that - I'd add 100 extra definitions to make  
> sure there are enough for anyone (and the enum will still fit into a  
> char if that is what your compiler wants to do).
>
> Cheers
> Bill
> _______________________________________________
> ODE mailing list
> ODE at ode.org
> http://mooshika.org/mailman/listinfo/ode
>
>
>