SVN Folder Structure

93 views
Skip to first unread message

Pixelbaker

unread,
Jan 9, 2012, 2:39:28 PM1/9/12
to 3ds-max-d...@googlegroups.com
Hi Christopher, Hi Thorsten, Hi everyone else.

I am picking up your conversation from the "Introduction" thread from Laszlo, regarding our SVN folder structure.
The discussion is well worth to be put in its own thread.
I copied over the last three posts and pasted them at the bottom. Hoping to give people a quick start on what has been said so far.

Lately I had to layout a SVN structure too, I like to give away some of my thoughts to our current SVN structure. 


Goal
The question which drives our SVN structure should be: What advantage does the 3ds-max-dev group wants to provide for its users.

The project home page states ...
A collection of open-source plug-ins and scripts for 3ds Max contributed by the developer community. This project is intended as both a learning resource for 3ds Max developers and to help accelerate their plug-in and script development.

... which I interpret as:
  • hosting plug-ins (with source code) & scripts
  • developers collaborating on different projects hosted here
The first point is what ScriptSpot.com, CreativeCrash.com, etc. already do. (without source code for plugins of course)

The second point is what this group should focus on and makes it unique.
I like to easily version control my project in close proximity to a lively Max developer community, which can jump in and support a project.

Breaking that down our SVN structure should allow:
  • simple setup of a new project
  • offering possibility for branch/tag/trunk workflow, but doesn't enforce it
  • simple hierarchy structure
  • capable of handling many different, not related projects

Proposal
I like to offer a different layout, one which Thorsten mentioned.
I will validate and explain it in the next sections.

projects\
    JSONExporter\
    maxtest\
        branches\
        tags\
        trunk\
    MiniSceneExplorer\
    Templates\
    XoliulShader2\
sandbox\
    aardolino\
    cdiggins\
wiki\


Explanation
It follows some words about the idea and concept behind the layout.

Flat hierarchy
projects holds all the different projects. No further differentiation, neither SDK/MAXScript/DotNetSDK/... or shader/modifier/...
Keeping the structure simple and flat. 

Categorization 
If categorizing projects is desired, a wiki page can be created, listing urls to the different projects falling under a certain category.
No need to complicate our SVN structure.

Encapsulation
All data regarding a project are consolidated under the project folder.
This gives a clear encapsulation of a project, which in most cases I assume has no dependencies to other projects anyway.
When working on maxtest, I had to checkout whole svn\ to get access to svn\branches\maxtest\ giving me all the other projects too, which I currently don't need.
The encapsulation would let me checkout svn\projects\maxtest\ which then only holds my project specific folders.

Branching
I like using branches/tag/trunk workflow, but I wouldn't enforce it. I like to leave that decision to the developer(s) creating the project.

Sandbox 
As already implemented, a per developer-place for versioning source code not intended for collaboration.


Validation
I like to quote some voices of the StackOverflow community, discussing SVN folder layouts.

Projects sharing a branches/tag/trunk structure vs Each project has its own branches/tag/trunk structure

SVNBook
There's nothing particularly incorrect about such a layout[Projects sharing a branches/tag/trunk structure], but it may or may not seem as intuitive for your users. Especially in large, multiproject situations with many users, those users may tend to be familiar with only one or two of the projects in the repository. But the projects-as-branch-siblings approach tends to deemphasize project individuality and focus on the entire set of projects as a single entity. That's a social issue, though. We like our originally suggested arrangement for purely practical reasons it's easier to ask about (or modify, or migrate elsewhere) the entire history of a single project when there's a single repository path that holds the entire history past, present, tagged, and branched for that project and that project alone.

For me the bottom line is, if projects don't depend on each other, each of them should have its own branches/tag/trunk structure for the reasons stated by the SVN book.


Conclusion
The proposed layout might not solve all our problems. e.g. I can see that when the community grows and we have 100+ projects under the projects folder, a long list unfolds, scaring anyone off. Having sub-categories like MAXScript, DotNetSDK, 3dsMaxSDK, etc. might be necessary.

But from a developers point of view, I like the idea of having my own space, leaving me with the decisions how to organize, document and advertise my project.
Our group should only provide as little as possible and as much as necessary for the developers.
I see the proposed SVN structure as more adequate in achieving this goal.


If an interested exist in changing the current layout, I am happy to assist.


Greets,
Pixelbaker


Previous conversation:
Sorry everyone for such a long delay.
Thanks Thorsten. I really appreciate your input. I read the chapter,
and I believe I understand what you are saying. It does make sense
that "releases" are simply tags of the trunk (which is effectively
what I was calling "dev"). In my mind the sandbox then is outside of
the trunk entirely for people's own experimentation.,
So does the following make sense?
Sandbox\
  digginc\
  aardino\
  someoneelse\
Trunk\
   MAXScript\
       MiniSceneExplorer\
   3dsMaxSDK\
        Templates\
   DotNetSDK\
       MiniSceneExplorerDotNet
Tags\
     MAXScript\
         MiniSceneExplorer\
             Release1\
     3dsMaxSDK\
          Templates\
             Release1\
             Release2\
          SomeSpecialPlugin
              Beta1\
              Beta2\
              Release1
     DotNetSDK\
         MiniSceneExplorerDotNet
             Release1\
Cheers,
Christopher
 
On Tue, Jul 5, 2011 at 4:55 PM, instinct-vfx <insti...@googlemail.com> wrote:
> Hey there,
>
>> My thought was that most people would not even bother perusing other
>> people's sandboxes, because if the community takes off, then we will
>> have so much content.
>
> True. That was rather an emotional comment rather then a real reason i
> guess hehe
>
>> I was hoping that some people might start using the 3ds Max dev google
>> code project as their own repo, to avoid them having to move things
>> back and forth.
>
> That's very well possible and up to everyone's preference i guess. I
> will likely always
> run a private repo myself basically mixing opensource and closedsource/
> proprietary
> sandboxes for convenience. But that's just me and might change even.
>
>> Here is an idea, what if we broke things up into the following areas:
>>
>> 1) Sandbox - Personal sandboxes.
>> 3) Dev - Projects under active development that will eventually become
>> release candidates.
>> 5) Release - Projects that have been voted on by the community
>> 6) Unofficial - Projects that were not unananimously accepted by the
>> community for release, but are considered by the author as release
>> ready.
>> 6) Bonepile - Abandoned projects that might get resumed by someone else.
>>
>> So here Thorsten once you don't mind people looking at your projects
>> you would migrate them to "dev", otherwise you can do whatever
>> craziness you want in the "sandbox" area.
>>
>> Possibly. To be honest I have only ever managed my own personal
>> repositories, and I tend to think in terms of folders. I know very
>> little about branching, merging, and tagging. I'm really hoping that
>> one of my developer colleagues at Autodesk will jump in here (I'm
>> going to ping them). If you can tell me more about this approach
>> (tagging) I would be appreciative.
>
> I can see what you are aiming for i think and i like most of it. In
> regards to
> "standard" svn layouts i was referring to the free svn book that
> basically
> suggests to standard layouts for svn repos:
>
>   project/
>      trunk/
>      tags/
>      branches/
>   ...
> or
>
>   trunk/
>      project/
>      
>   tags/
>      project/
>      
>   branches/
>      project/
>      
>
> The basic idea behind trunk, branch and tags is as follows:
> Trunk is the main working area where the most current main development
> is happening.
> Branch is a branch of the code created at some revision to play with
> code/test things without messing trunk and without beeing messed by
> changes in trunk.
> Tags are named snapshots of code at specific revision that are
> supposed to be static and not changing (=code snapshots of releases)
>
> Here's a link to the chapter in the book
>
> And here's the whole book. It's free and a good read on svn!
>
> Not that all these are community conventions and recommendations and
> svn does not enforce this or any other structure.
> It does match svn's lingo of course with branch/tag/merge. Inside the
> repo all these operations are essentially folder copies
> only.
>
> As you can see by the default layout here on google code this
> structure is also what is suggested here by default.
>
> Regards,
> Thorsten
>

Christopher Diggins

unread,
Jan 10, 2012, 9:11:41 AM1/10/12
to 3ds-max-d...@googlegroups.com
Hi Pixelbaker,
 
I trimmed the email below. I like what you propose. I am thinking of approving your proposed changes (would you mind making them yourself?). Let's wait a few days to see if anyone else has objections.
 
Christopher

Pixelbaker

unread,
Jan 10, 2012, 5:02:15 PM1/10/12
to 3ds-max-d...@googlegroups.com
Thanks for your feedback Christopher. I certainly can to the changes. I gonna wait until Sunday, 15.01. for further feedback.
Everyone please consider: Changing the structure breaks links to your projects, which you might have published in the web.

Christopher this also goes for your blog: the The Xoliul Shader article for instance

Greets,
Pixelbaker

Pixelbaker

unread,
Jan 15, 2012, 8:12:25 AM1/15/12
to 3ds-max-d...@googlegroups.com
I am starting restructuring our SVN layout now.

Pixelbaker

unread,
Jan 15, 2012, 9:36:02 AM1/15/12
to 3ds-max-d...@googlegroups.com
Alright, finished changing the SVN structure.
Please familiarize yourself with it and don't forget to update any web-links to your projects.


I took out the scripts JSONExporter and MiniSceneExplorer. They are now projects by themselves. 
I then renamed the folder 3dsMax2012 to 3dsMax2012Templates.
The Shared, TemplateExamples and Templates folders are all about SDK templates, right?
I left the LearningPath folder inside.
If you feel LeaningPath is not related to 3dsMax2012Templates please move it to its own project folder.

Have good Sunday folks.
Reply all
Reply to author
Forward
0 new messages