Breaking SVN Changes - Project Locations Changing

In order to maintain some form of order in the Axiom Contrib SVN, I am proposing we re-structure the SVN to the following:

Under SVN root: /

• trunk/
  
  • Axiom.Sound/
    
    • trunk/
      
    • branches/
      
  • Trunk build files (eg. Contrib.sln)
    

• branches/
  
  • Axiom.Contrib.Caelum/
    
    • trunk/
      
    • branches/
      
  • Axiom.Contrib.Hydrax/
    
    • trunk/
      
    • branches/
      

This structure will allow us to add projects to the SVN branches and when stable enough, to move them to the trunk.

In my mind, a measure of stability is that a project compiles and runs on both Windows XP/Vista and Linux (what is the binding linux factor? Tao version?) The actual progress of each project in the trunk is then monitored.

I aim to build and release a library (Axiom.Contrib.dll ?) each month, or thereabouts, so if you are developing a trunk Contrib project, please make sure to get important changes committed before the end of the month!

This plan would be great to impliment by month-end of May, so we have some time to discuss how to stage the Axiom Contrib library.

Thoughts please!

I'm particularly bad at setting up so you won't get much comments from me but wonder that any branches would be in the main trunk. Otherwise each project should have the common branches/trunk/tags structure, yes.

As to the sound plugin, that should not yet go to trunk IMHO (but you used that as example I think), to it's name, have choosen SoundSystems being inspired by RenderSystems, same as you have Xna/OGL/DX RSs there is OpenAL/Xna.Simple and hopefully a Xna subsystem one day.

Perhaps like that, unsure.

[Borrillis]

In order to maintain some form of order in the Axiom Contrib SVN, I am proposing we re-structure the SVN to the following:

Under SVN root: /

• trunk/
  
  • Axiom.Sound/
    
    • trunk/
      
    • branches/
      
  • Trunk build files (eg. Contrib.sln)
    

• branches/
  
  • Axiom.Contrib.Caelum/
    
    • trunk/
      
    • branches/
      
  • Axiom.Contrib.Hydrax/
    
    • trunk/
      
    • branches/
      

This structure will allow us to add projects to the SVN branches and when stable enough, to move them to the trunk.

I can't even begin to tell you how hard and confusing this will be to maintain. branches in trunk and trunks in branches. Instead of moving the entire project based on whether it's stable enough to be included in a composite distribution, consider the following

Under SVN root: /

• Axiom.Plugins.Contrib/
  
  • trunk/
    
  • branches/
    
  • tags/
    
• Axiom.SoundSystems/
  
  • trunk/
    
  • branches/
    
  • tags/
    
• Axiom.Caelum/
  
  • trunk/
    
  • branches/
    
  • tags/
    
• Axiom.Hydrax/
  
  • trunk/
    
  • branches/
    
  • tags/
    

Each Contrib porject has it's own identity, which is good because not everyone will want all contrib projects, and the Axiom.Plugins.Contrib can use the svn:external property to refer to the /{AxiomContribProjectRoot}/tags/{tagname} that is considered stable enough to be included in the composite distribution.

In my mind, a measure of stability is that a project compiles and runs on both Windows XP/Vista and Linux (what is the binding linux factor? Tao version?) The actual progress of each project in the trunk is then monitored.

You have forgotten Mac.

I aim to build and release a library (Axiom.Contrib.dll ?) each month, or thereabouts, so if you are developing a trunk Contrib project, please make sure to get important changes committed before the end of the month!

Good idea, and if you are using svn:external with tags, then you can also be sure to not get changes that aren't ready.

This plan would be great to impliment by month-end of May, so we have some time to discuss how to stage the Axiom Contrib library.

Thoughts please!

See above

I aim to build and release a library (Axiom.Contrib.dll ?)

Btw. how would you assemble the Axiom.Contrib.dll from the various packs, using ILMerge or like that? Potentionally NP, just what about native dependencies, xml files and alike?
EDIT Aye!

Btw. how would you assemble the Axiom.Contrib.dll from the various packs, using ILMerge or like that?

I think he just want to compile all libarys as one (assembly, w/o ILMerge) namespace .

ILMerge wouldn be a good idea in my opinion.

But in generally, i dont think its a good idea to merge all contribs into one libary. Let's declare each contrib as a plugin, this should be common design as we can see in the rest of axiom (ogre).

Maybe we replace the Axiom.Contrib.Dll as an SDK Package, where everything is inside, out-of-the-box.

just my 2DM

//bostich

I think he just want to compile all libarys as one (assembly, w/o ILMerge) namespace .

Aye anyway

But in generally, i dont think its a good idea to merge all contribs into one libary. Let's declare each contrib as a plugin,

Ye, how else

Maybe we replace the Axiom.Contrib.Dll as an SDK Package, where everything is inside, out-of-the-box.

PNP stands for "practically not possible" in this case, IMHO. EDIT: eh, that's some nonsense from mine, sorry

Me just feel a bit larky today

I think I haven't understood yesterday

One base namespace is of course possible, but that would be 'Axiom'. Eventuall 'Axiom.Contrib' only for the work in progress if I got it, but I don't understand this point really anyway! Move Namespace is not a refactoring that would be automated by common. That will be making some trouble.

Under SVN root: /

• Axiom.Plugins.Contrib/
  
  • trunk/
    
  • branches/
    
  • tags/
    
• Axiom.SoundSystems/
  
  • trunk/
    
  • branches/
    
  • tags/
    
• Axiom.Caelum/
  
  • trunk/
    
  • branches/
    
  • tags/
    
• Axiom.Hydrax/
  
  • trunk/
    
  • branches/
    
  • tags/
    

Each Contrib porject has it's own identity, which is good because not everyone will want all contrib projects, and the Axiom.Plugins.Contrib can use the svn:external property to refer to the /{AxiomContribProjectRoot}/tags/{tagname} that is considered stable enough to be included in the composite distribution.

Great!

Hi again, I thought it might be useful at this point to explain what the branches/tags/trunk SVN folders are most commonly used for, not everybody is used to that concept. Although am not aware of any strict rules that would apply all over the world, I believe there is some common approach though:


Trunk: contains the most current development effort that targets the next release. It's a good habbit to keep trunk code as stable as possible at all times. Trunk shall not contain any subfolders with variations of the same application similar to how branches/tags do.

Branches: contain variations of trunk. Everything from new feature set additions, experimental branches, bug fix branches, or even release branches that are a copy of trunk at the time of a release.

Tags: contain snapshots of code at certain development stages that won't be touched anymore. Most likely snapshots of trunk at the time of a release.


So this is what I think Axiom.Contrib project SVN folders should reflect.

2c

Hi andris11,

100% agree

//Bostich

the Axiom.Plugins.Contrib can use the svn:external property to refer to the /{AxiomContribProjectRoot}/tags/{tagname} that is considered stable enough to be included in the composite distribution.

That's certainly a fine idea. But because it may take a while before there will be any Tags, it might be interesting to setup two distribution folders using svn:external. One marked 'unstable' and reffering to trunks, the second marked 'stable' and referring to tags.

Perhaps the actual projects could be moved from root to a {root}/Projects folder and in root keep only:

  Code:

Axiom.Contrib-stable/
Axiom.Contrib-unstable/
Projects/


(whatever the base contrib namespace will be)

[Borrillis]

Perhaps the actual projects could be moved from root to a {root}/Projects folder and in root keep only:

  Code:

Axiom.Contrib-stable/
Axiom.Contrib-unstable/
Projects/


(whatever the base contrib namespace will be)

Or :

this

Can I edit the page a bit? (have no permissions) EDIT I mean if you can enable that please, will leave what's there and add to the bottom

Or

• /
  
  • Axiom.Plugins.Contrib/
    
    • trunk/
      
      • Axiom.SoundSystems *=> /Axiom.SoundSystems/trunk
        
      • Axiom.Caelum *=> /Axiom.Caelum/trunk
        
      • Axiom.Hydrax *=> /Axiom.Hydrax/trunk
        
    • branches/
      
    • tags/
      
      • stable/
        
        • Axiom.SoundSystems *=> /Axiom.SoundSystems/tags/{lastRelease}
          
        • Axiom.Caelum *=> /Axiom.Caelum/tags/{lastRelease}
          
        • Axiom.Hydrax *=> /Axiom.Hydrax/tags/{lastRelease}
          
      • unstable *=> /Axiom.Plugins.Contrib/trunk
        
  • Axiom.SoundSystems/
    
    • trunk/
      
    • branches/
      
    • tags/
      
  • Axiom.Caelum/
    
    • trunk/
      
    • branches/
      
    • tags/
      
  • Axiom.Hydrax/
    
    • trunk/
      
    • branches/
      
    • tags/
      

==Legend
*=> : svn:external reference
+=> : svn copy of location

Didn't see why the Axiom.Plugins.Contrib package should have any branches? Commiting shall always happen into a branch of the concrete project I guess.

/Axiom.Plugins.Contrib/tags could be also +=> instead *=>

Hi guys!

Some great discussion!

You certainly do have a good point in mixing trunk/branches/etc. I've had a look at the page Borrillis linked to above - I like the current edit of it. It seems to be relatively straightforward.

The Axiom Contrib package is, imo, intended to be a complete package with components. If people don't want a certain functionality, then they don't use it - but we still provide it in an easy to use way: one library. The library will have associated files with it, so any XML/data/etc files will be included with the release.

How would we go about making a build available each month that is compatible with Mac/Linux/Win? Are there people here who are available and willing to do such testing? (If we provide a "run this program" and tell us if it worked setup).