Directory Structure Proposal

[ingen-lab]

I propose the following changes to the directory structure.

To summarize:

1. Move the Animations folder one level up
2. Move The 04_LSL folder one level up and rename to LSLscripts
3. Create additional folders inside the LSLscripts folder to separate release from currently being develop
4. Create Current Release folder inside Mesh/Ruth and move UV maps, Textures, and Uploads folders
5. Only 3 Blend files for current release

6. Current Release & Upload filenames should not change and old files will be overwritten

   Ruth -Annimations -Apparel -Attachments -Documentations -Licenses -LSLScript --Ruth ---HUD ----Current Release ----EleniaB ----MDickson
   -Mesh --Ruth ---Current Release ----UV maps ----Textures ----Uploads ----head.dae ----feet.dae ----etc.dae ---Ruth2CurrentReleaseSource.blend ---Ruth2CurrentReleaseAlphaCut.blend ---Ruth2CurrentReleaseDevKit.blend

   ---Ada Radius ---Leona Morro ---Sundance Haiku ---HUDs & Misc -Photos -Skins

[typhartez]

Why using things for current release? You want to provide side by side the different versions from various people? Otherwise, GIT branching made for that :)

[Outworldz]

I like it. Add a --Roth folder with a .keep file. Or a note on him, or any WIP you want to save in case of a crash.

I think branches should be for WIP, not releases.

[ingen-lab]

typhartez -- how do you branch and later merge blender files?

[Outworldz]

Shin, I should probably add a .gitattributes file, which prevents merging two DAE files by treating them as binary.

[typhartez]

I didn't thought .dae were treated as binaries, as they are xml files. I never had the occasion to treat one. So excuse me for the comment.

For blender files, there is no merge option, as they are binaries. So for that kind of files (like images) the commited files override the complete original. For merging branches, that means a manual resolve of the pull request. The issue is that even if using different folders for people's version, there is no way to merge them afterwards.

2018-01-22 2:41 GMT+01:00 Fred Beckhusen notifications@github.com:

Shin, I should probably add a .gitattributes file, which prevents merging two DAE files by treating them as binary.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Outworldz/Ruth/issues/21#issuecomment-359302662, or mute the thread https://github.com/notifications/unsubscribe-auth/APytPqwoOWG2XN-nSmt7IzH1pTYq8Au_ks5tM-csgaJpZM4Rl1WT .

-- It is easier to disintegrate an atom than a prejudice (Albert Einstein)

[ingen-lab]

It is my fault for not using the original discussion as part of the issue which you can find here . It might help understand the need for such structure.

[ingen-lab]

Fred -- I am running into a bit of a problem organizing the LSLScript directory. This is what I wind up doing and let me know if that will mess up the way you work with solutions and projects with the LSL editor.

Summary:

1. Created a solution called HUD inside the LSLScript directory
2. The HUD solution is consist of 2 projects namely Roth and Ruth
3. Each project will have objects(contributor name) that will contain a complete implementation package for the HUD they are working on.

My reasons for having complete implementation package per contributor is simply because we have 3 different releases. One for OpenSim close grids, second is for OpenSim hypergrids and third is for Second Life. Whether we want to admit it or not, sooner or later we are going to have different requirements for each particular type of grid. This way, whoever is creating the inworld release package have a choice of different implementation or improvement.

[Outworldz]

Sounds and looks good. This editor will help keep code clean - like variables that are declared but unused.. I really like this approach.

[SundanceHaiku]

Sorry for the late reply . . . but fine with me Shin.

[EleniaBoucher]

Yes I'm so late. Perfect for me. I have rewrite my library to work directly on 32 bits. It's ready I have to do the hardest : testing !