Add Mogre samples to core code repository?

User zarifus and mcdonte made improvements to Mogre. Thanks!
Since one month both of them have write access to the official Mogre repository.

Later I got a question as private message related to the Mogre development.
I think it's useful to share and discuss such questions within the Mogre community.
If you want to share your opinion, just do it.

Thanks again for access to the repository. I did my first commit last night and it went well.

One of my next tasks is getting the source code for the Mogre samples into the repository. I was wondering if it's a good idea to create a separate repositroy for samples? e.g. MogreSamples

Ideally, I'd like to add the option to the MogreBuilder to download and compile the samples as part of the build process.

In general it's a nice idea to include a build option for Mogre samples to the MogreBuilder.
It's useful for some tests. Then you see quickly if the fresh compiled Mogre binaries works in general.

Which samples you mean in detail?

I know the "Mogre-Samples", which contains:

1. CelShading[/*:m]
   
2. Dot3Bump[/*:m]
   
3. EnvMapping[/*:m]
   
4. Fresnel[/*:m]
   
5. MogreForm[/*:m]
   
6. SkeletalAnimation[/*:m]
   
7. TextureFX[/*:m]
   
8. Transparency[/*:m][/list:u]
   
   They are on my hard drive, but I don't know its current place in the internet.
   I suppose in any repository, but I didn't find it.
   
   This simple examples should be fine for quick tests.
   If we add them to the Mogre repository (core code), maybe we should rename the directory from "Mogre-Samples" to "QuickTestSamples" or similar?
   (Then the users see the main purpose. If the name is just "Mogre-Samples", users could wonder why some samples are in the core code repository and others in the SDK repository.)
   
   On the one hand it's useful to keep the core code repository clean. (Don't blow it up if not needed.)
   On the other hand a quick binary test would be fine.
   
   
   If zarifus means the samples of the MogreSDK - Then I disagree to add them to the core code repository.
   It's the wrong place and additionally the media files would blow it up massively.
   
   
   
   ________________________
   Off topic:
   
   The current MogreSDK repository is not on BitBucket. It's an SVN repository at code.google.
   I think would be no good idea to move the SDK to BitBucket. It should stay where it is.
   
   My main reason:
   It contains large binary files, which can be replaced again and again.
   The precompiled binaries are good for an SDK, because the end user just need to call the samples. (Instead of compiling every depency, which is very complex.)
   If somebody wants to check out the SDK repository, he just needs to download the last revision.
   If the SVN repository becomes a Mercurial repository (e.g. by moving to BitBucket), when we have a problem:
   With Mercurial you only can clone the whole repository. It's not possible to get only the last revision. So you need to download all files (e.g. binaries), which were added in the whole past. The download size could be huge, which is bad especially for users with limited band width (e.g. ISDN or classical telephone modem).
   
   
   By the way:
   In the last weeks I wasn't active very much, because I need to concentrate to my diploma thesis (which also includes simulations with my Mogre application.). I want to leave my university with a good mark.
   Nevertheless still try to follow the Mogre topics. I'm not lost.

User zarifus and mcdonte made improvements to Mogre. Thanks!
To be a little more specific the changes we made are improvements to the MogreBuilder project including bringing it up to the current version of Ogre (1.7.4) and including the Terrain and Paging components. You can find the details on my blog and in therelated forum topic.

A special thanks to Cygon for helping out too.

In general it's a nice idea to include a build option for Mogre samples to the MogreBuilder.
It's useful for some tests. Then you see quickly if the fresh compiled Mogre binaries works in general.
Which samples you mean in detail?
They are on my hard drive, but I don't know its current place in the internet.
I suppose in any repository, but I didn't find it.
I think ALL of the samples belong in a repository somewhere. They are no good to anyone sitting on people's hard drives.

Including the samples in the MogreBuilder shouldn't be hard. The main problem is that they currently don't seem to live in any repository. From the MogreBuilder's point of view shouldn't really matter what repository they live in, however, if they are in an SVN repository it adds another dependency to the MogreBuilder which isn't a good thing either.

This simple examples should be fine for quick tests.
If we add them to the Mogre repository (core code), maybe we should rename the directory from "Mogre-Samples" to "QuickTestSamples" or similar?
(Then the users see the main purpose. If the name is just "Mogre-Samples", users could wonder why some samples are in the core code repository and others in the SDK repository.)
Actually, I don't think they belong to the core Mogre repository, that should remain clean.

If you go up one level to the list of repositories under the mogre user you'll see there are a bunch of repositories as follows:
Mogre - Main Mogre repository
MogreAddons - Mogre addons and contributions.
MogreBuilder - The automated builder
MogreQuickstart - Projects for VS2008 and VS2010 to quickly start using Mogre. Contains code to initialize a render window and show a rotating ogre head. Uses the current Mogre 1.7.1 libraries.
MogreSDK - Development of an up-to-date version of the Mogre SDK with support for VS2008/.NET2 and VS2010/.NET4.

Is there any reason why we can't add another one for MogreSamples. That way we'll be keeping the samples out of the way of everything else.

If zarifus means the samples of the MogreSDK - Then I disagree to add them to the core code repository.
It's the wrong place and additionally the media files would blow it up massively.
Actually, I didn't know about this respositroy. If those samples cover what we need then keeping it that way is one option. Although, as I mentioned before it does add another dependency on SVN and it's a little confusing having the code split across multiple places like that.

It contains large binary files, which can be replaced again and again.
Are you sure that's how it works? I don't think there is any reason to load the compiled DLL's into the repository and I don't think the media folder is going to change very often so they shouldn't get replaced over and over again anyway.

With Mercurial you only can clone the whole repository. It's not possible to get only the last revision. So you need to download all files (e.g. binaries), which were added in the whole past. The download size could be huge, which is bad especially for users with limited band width (e.g. ISDN or classical telephone modem).
The whole repository is going to be around 32MB which is a little large I agree, but keeping the samples in a separate repository on bitbucket largely gets around this issue for people who do not wish to download the samples. In comparison to downloading the source code of Ogre (over 100MB) it's still reasonably good.

I know the "Mogre-Samples", which contains:
CelShading
Dot3Bump
EnvMapping
Fresnel
MogreForm
SkeletalAnimation
TextureFX
Transparency
I should probably also mention that I have a new sample for TerrainAndPaging sitting on my hard drive ready to be loaded into a repository once we have sorted these issues out.

I think ALL of the samples belong in a repository somewhere. They are no good to anyone sitting on people's hard drives.
I fully agree. In the past I saw several code snippets, tutorials and samples, which are lost, because they were only on a private website or filehoster. It's very sad.

Now I found the Mogre-Samples. Currently they are in the MogreSDK repository at directory:
sdk_fs\Samples

Is there any reason why we can't add another one for MogreSamples. That way we'll be keeping the samples out of the way of everything else.
Currently they are in the MogreSDK repository, because they are part of the SDK. When the SDK builder script (based on Inno Setup) builds the SDK, it has all needed files in it's repository revision.
I'm not shure how useful it is to create a seperate repository for samples. People can get them by installing the SDK or checking out the SDK repository.

it does add another dependency on SVN
To copy (not move) them to the Mogre core directory "QuickTestSamples" would be ok.
For the cloned samples the functionality (of the individual samples) can be merged to one test application.
(e.g. Run each sample for a few seconds and then run the next.)



It contains large binary files, which can be replaced again and again.
Are you sure that's how it works? I don't think there is any reason to load the compiled DLL's into the repository and I don't think the media folder is going to change very often so they shouldn't get replaced over and over again anyway.

The SDK contains binaries like OgreMain.dll, Mogre.dll, MOIS.dll, plugins (all as Debug and Rease version), MogreNewt, MHxdrax, ...
It's easy for Mogre newcomers to have all this precompiled binary files. So they can just use them and concentrate to the first Mogre experiences. (Instead of search and compile everything themself.)
When the SDK is updated (e.g. for a new Mogre version), most binaries have to be replaced, too.
With SVN, just the Server needs to store all revision data.
With Mercurial you need to clone (download) the whole history including all files.

The whole repository is going to be around 32MB
I checked the size of the current MogreSDK revision. It's 190 MB.

keeping the samples in a separate repository on bitbucket largely gets around this issue for people who do not wish to download the samples.
Currently the users have the same option. If they want to grabb the samples, they can checkout the SDK repository (or install the SDK).

I have a new sample for TerrainAndPaging sitting on my hard drive ready to be loaded into a repository
This would be very nice for the SDK.
(Well the SDK is a little bit outdated now ... I hope somewhen somebody has the motivation to fresh it up. There are also a few new samples inside, e.g. rendering a webcam/video stream to a texture)

I think ALL of the samples belong in a repository somewhere. They are no good to anyone sitting on people's hard drives.
I fully agree. In the past I saw several code snippets, tutorials and samples, which are lost, because they were only on a private website or filehoster. It's very sad.
it's why I try to always upload things either to the forums or the wiki as an attachment because I know how annoying it is when something from years ago gets lost

it's why I try to always upload things either to the forums or the wiki as an attachment because I know how annoying it is when something from years ago gets lost
Uploading to the forums or wiki is better than nothing but there are also some disadvantages:
- Forum attachments are limited in size
- Forum threads become old are not always easy to find
- The wiki doesn't allow attachments, so you need to host files somewhere else anyway (or does it?)
- When the code is updated a new attachment is created and the old one is left behind making it more difficult to know which is the newest
- It makes it much harder for multiple people to work on something together

Source code repositories are a far better option for solving the above problems.

The wiki doesn't allow attachments, so you need to host files somewhere else anyway (or does it?)
It's possible to attach files to each wiki page.
This was one (of several reasons) why we switched from MediaWiki to the TikiWiki. (Although jacmoe had to put a huge amount of effort to do the job.)
To attach a file to the wiki, you need to log in, scroll to the buttom and click to "attach file".

Source code repositories are a far better option for solving the above problems.
Forum and Wiki attachements are better then external download links.
But I fully agree that repositories are more better. (Although it depends to the content. E.g. for tiny snippets you don't need a repository.)

I found further samples. Also located in the Mogre SDK repository.
Here an overview of both "sample collections":

smiley80\mogre_samples\

1. BezierPatch[/*:m]
   
2. ExampleApplication[/*:m]
   
3. Lighting[/*:m]
   
4. ParticleFX[/*:m]
   
5. RenderToTexture[/*:m]
   
6. SkyBox[/*:m]
   
7. SkyDome[/*:m]
   
8. SkyPlane[/*:m]
   
9. Smoke[/*:m]
   
10. Terrain[/*:m][/list:u]
    
    sdk_fs\Samples\
    
    1. BSP[/*:m]
       
    2. CameraTrack [/*:m]
       
    3. CelShading[/*:m]
       
    4. Compositor[/*:m]
       
    5. Dot3Bump[/*:m]
       
    6. EnvMapping[/*:m]
       
    7. ExampleApplication[/*:m]
       
    8. Fresnel[/*:m]
       
    9. Hikari[/*:m]
       
    10. MogreForm[/*:m]
        
    11. SkeletalAnimation [/*:m]
        
    12. TextureFX[/*:m]
        
    13. Transparency[/*:m]
        
    14. WebcamDemo[/*:m][/list:u]
        
        
        Note for the first:
        They were created/ported by smiley80 (details in topic Additional samples, year 2009).
        The related media files are here:
        http://ogre.svn.sourceforge.net/viewvc/ ... les/Media/
        
        
        Note for the second list:
        The solution and build command files are in the parent directory.
        
        I want to put some of them (or all?) to the MogreBuilder repository.
        The aim is to quickly test the created binaries.
        Media files I will not upload to the repository direcly, because I don't want to blow it up with binary files.
        Instead I want to figure out the realy needed media files and upload them as zipped file.
        This can be downloaded and embedded to the samples later by a MogreBuilder task.