introduction

[LaszloSebo]

Hi,


Somehow i missed this whole initiative, so am coming in a bit late :-)
My name is Laszlo Sebo, and i have been doing custom plugin
development and scripting for 3dsmax / Maya for several years now.
Mostly at Frantic Films, Digital Pictures Iloura and for the last 3
years Prime Focus in Vancouver.

I hope that i could take some of my freebie pet projects i had that i
never finished and upload them here if possible. Simple modifiers,
shaders, controllers etc. I will have to dig through my archives
though, and see if they still compile :-)


cheers,
laszlo

[Christopher Diggins]

Welcome aboard Laszlo!
I look forward to your contributions. Let us know when you are ready
to post something.
By the way, do you have experience using SVN or a similar repository system?

Christopher

[LaszloSebo]

Yeah, i have also used cvs, hg and git, but i have the most, about 8
years of experience with svn.

I see you have categorized projects by user. Would it make more sense
to have them by type? Modifier, Shader etc?
Based on commits, its easy to see who is maintaining what anyway. But
either way works for me :)


cheers,
laszlo

On Jul 1, 6:25 am, Christopher Diggins <cdigg...@gmail.com> wrote:
> Welcome aboard Laszlo!
> I look forward to your contributions. Let us know when you are ready
> to post something.
> By the way, do you have experience using SVN or a similar repository system?
>
> Christopher
>

[instinct-vfx]

Great to see you aboard Laszlo!

And i do agree that splitting by topic is more intuitive to look
for things than splitting by user.

Kind Regards,
Thorsten

[Christopher Diggins]

Hi Laszlo,

Sorry for the delay, I had a long weekend here.

On Fri, Jul 1, 2011 at 11:58 AM, LaszloSebo <laszl...@gmail.com> wrote:
> Yeah, i have also used cvs, hg and git, but i have the most, about 8
> years of experience with svn.

Great!

> I see you have categorized projects by user. Would it make more sense
> to have them by type? Modifier, Shader etc?

Yes this makes sense, especially for release projects.

> Based on commits, its easy to see who is maintaining what anyway. But
> either way works for me :)

I was thinking of the "named" folders to be sandboxes for
contributors. The intention is for each contributor to have a place
where they can manage their own projects, whether or not it ever
reaches a state where it could be considered "release" worthy. The
idea being that released projects are those that share some kind of
standard of quality which will likely increase over time. For now I
was thinking of it as a "we as a community deem this a worthy
representative work".

Perhaps we could achieve this via a community review process? I had a
process similar to the one used by the Boost.org C++ library community
http://www.boost.org/community/reviews.html.

So what are your thoughts? Some questions to get you started:

* Should we have a sandbox? If so, how should it be structured?
* Should we have a concept of "released projects"? If so, how should
it be determined what makes up released projects?
* Does a community review process make sense?

Cheers,
Christopher

[instinct-vfx]

Thanks for the explanation Christopher,

that's a tough one to answer for me. When i am REALLY sandboxing then
i usually
would not want the world to see all i do. For one i write really bad
code and second
things might just lead completely nowhere. So i guess i would do this
in my own
repo and move things over when they are cleaned up to some extent.

It would make sense for me for collab projects tho i guess. To share
code and
let others review it before releasing.

But then i wonder if the "releases" shouldnt be moved to the tags
directory and be
tagged as releases ? Updates and additional work could then be done in
trunk.

Maybe some (prolly esp the maxscript people) do not have access to a
repository
of their own so it might make sense for them.

To put a long story short: I am not sure. Laszlo ? :P


Regards,
Thorsten

[Christopher Diggins]

On Tue, Jul 5, 2011 at 4:08 AM, instinct-vfx <insti...@googlemail.com> wrote:
> Thanks for the explanation Christopher,
>
> that's a tough one to answer for me. When i am REALLY sandboxing then
> i usually would not want the world to see all i do. For one i write really bad
> code and second things might just lead completely nowhere.

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.

> So i guess i would do this in my own
> repo and move things over when they are cleaned up to some extent.

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.

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.

> It would make sense for me for collab projects tho i guess. To share
> code and
> let others review it before releasing.
>
> But then i wonder if the "releases" shouldnt be moved to the tags
> directory and be
> tagged as releases ? Updates and additional work could then be done in
> trunk.

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.

> Maybe some (prolly esp the maxscript people) do not have access to a
> repository
> of their own so it might make sense for them.
>
> To put a long story short: I am not sure. Laszlo ? :P
>
>
> Regards,
> Thorsten

Cheers!
Christopher

[instinct-vfx]

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
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

And here's the whole book. It's free and a good read on svn!
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

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]

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