DeleD Community Edition

[Paul-Jan]

First and foremost, anyone who is actually using an Open Source project like DeleD is already contributing to it in a big way... however, this particular forum focuses on those who want to get their hand dirty and mess with the source.

Getting the source
First, you'll need a subversion client. TortoiseSVN is nice. Use it to grab the source from https://deled.svn.sourceforge.net/svnroot/deled/trunk. Make sure you have a Delphi compiler (6, 7, 2005, 2006, Turbo Explorer Edition and 2007 should work properly... anything else will require a bit of aventuring). Open up DeleD.dpr, it should compile straight out of the box.

Running the source
The easiest way to get the source up and running is to download the binaries first (installer), install DeleD CE, and run it at least once. Then copy the deled.ini configuration file to the executable folder of the source (where DeleD.exe is compiled into) and you are good to go.

Changing the source
The easiest way to actually contribute to the code is to download the source from svn, pick any issue from the issue tracker, and fix it. Whether you have applied a fix or implemented a new feature, you'll have to submit your changes through a patch. A patch is a single file containing all your changes, and can be created from the TortoiseSVN context menu. You'll then need to submit this patch to the DeleD patch tracker. We'll review and merge the patch into trunk a.s.a.p., and you will have helped make the world a better place!

Direct commits
If you have submitted a couple of decent patches, or you really need direct access to the code for any reason, you can always request commit permissions. Just make sure yourself a SourceForge.net account first.

Delphi versions
As mentioned above, the DeleD source compiles with Delphi 6, 7, 2005, 2006, Turbo Explorer Edition and 2007. However, the target compiler for the official binary releases is currently Delphi 7, so please try to keep things compatible with that version. Don't sweat it though if you are unable to test this, we will let you know if things break and we'll figure out a solution together.

Plugins[/i]
If you would like to extend the functionality of one of the many plugins, or would like to use it as a template to start your own importer/exporter, head over to https://sourceforge.net/projects/deled-plugins/ . This is a sepated project where the plugins are open sourced.

[chronozphere]

Great. This is info we, developers need.

[paul_nicholls]

[Paul-Jan]

Yeah, like Paul said, a patch is simply one big file containing all the changes you made to all the files in the repository, in a formal file format. Every subversion client tool offers an option to create a patch of all the local changes you made to the source.

You then submit that patch, someone with commit access will very carefully look at what you did (a patch shows up like any other "diff"), then merge the patch into the source tree(perhaps tweaking the code a bit or discussing things with you). Sounds a bit elaborate but once everyone gets the hang of it the steps go rather smoothly, and it is a standard process in Open Source for good reason.

First of all, it prevents random evildoers from coming in and destroying your repository. Second, it makes for a really nice screening process: through patches we get to work with both you and your code for a bit, and if you want to you can then apply for direct commit access. That sounded a lot more elitist than I meant it really, everyone who submits a patch is a hero in my book!

[chronozphere]

Ok, I just read the following article:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html

Let me see if i get this right:

1. I do a checkout or update on a directory to download the contents of the repository.
2. I make changes to that code.
3. Then I right click the "trunk" and select "Create patch". This will compare my local repository with the one online and will generate the diffs, which will be packed in one file.
4. I submit that file as a patch at SF.
5. Someone with commit access downloads my patch from SF.
6. He applies it to his local repository and reviews/tests the changes.
7. He then commits the changes to the online repository.

Should I always make a patch at trunk level, or can I make it from a subdirectory aswell?

I assume I don't have commit acces now, correct? That said, I don't think I need this any time soon (as long as you guys have time to review and apply the patches ).

I've never contributed to an opensource project, so this is a great opportunity for me to learn how these things work.

[Paul-Jan]

You got that exactly right, good recap!

And yes, always make patches at the trunk level. And if for some pressing reason you don't, make sure to mention it somewhere so that the person applying the patch knows about it. Subversion patches are kinda dumb that way.

[Nocturn]

I've added a small Tutorial to the Wiki: http://www.delgine.com/wiki/index.php/Tutorial:_Getting_the_source

It is not complete yet, will finish it this evening, have now other stuff to attend to. I've also changed all Sites in the Wiki that mention DeleD Lite or Pro and changed it now to DeleD CE.

[Jeroen]

@Chronoz: good recap indeed!

@Nocturn: excellent work!
_________________
Check out Figuro, our online 3D app! More powerful 3D tools for free.

[Nocturn]

Does a patch need to be created off the whole trunk ? Or just the files which are affected by the change ? Because i have made some personal notes in the source for orientation, and they appear in Windiff if i create a new patch, but they don't make any sense to anyone else :p

Or does it not matter at all ?

[Paul-Jan]

We should really do a little experiment to confirm this, but IIRC, the patch has to applied at the exact same level where it was generated by whoever applies the patch to the actual source.

In other words, it's not really really necessary to generate it off trunk, but you then have to make it really clear to the one applying the patch where it needs to be applied.

[tpascal]

Question about the bug track list,

I have seen there is already 7 bugs reported in the list; bugs in these list should be considered as confirmed bug that need to be fixed (and maybe the bug is confirmed can be reproduced), or one should check first if the reported problem is really a bug or just somtimg the user is doing wrong?;

Are there any rules to report bugs in that list?

tp.

[Nocturn]

[paul_nicholls]

[chronozphere]

Huh ? I never installed SVN. I just have TortoiseSVN running here. Does the Tortoise Installer automaticly install SVN perhaps?

[paul_nicholls]