SRL Archive - General

From: Coh3n
Okay, so I talked to Nava earlier today, and I (we) kind of came up with a new plan, that actually makes much more sense. He pointed out that it really doesn't make much sense to have two branches, so here's what I was thinking. This is a nice, organized way of development/distribution.

1. Git Repository
2. Currently only myself and NCDS have write access to it.
3. All SL's (including NCDS and myself) will have personal repositories (we'll each fork the one above).
4. This allows for users to download our versions to test things we've been developing as individuals.
5. Once you think your personal repository is stable enough to be merged with the main repository, you will send a Pull Request and either myself or NCDS will merge it if all is well.

To fork the repository:

1. Create an account at Git-Hub.
2. Fork the repository from here.
3. You'll also have to download and setup git. I used this guide, but it's up to you how you do it.
4. I think it's possible to develop without git installed (through git-hub), but I'm not sure how that works.
5. You can commit/edit/do whatever you want to your forked version, then send a pull request via git-hub whenever.

Now, an idea for users to update: We still use the MSI drop down menu, with the stable (master) branch option, but instead of having the second option for a less stable branch, we call it "Download from…". When clicked it will open a window where they can enter the link to anyone's repository. Not sure how simple this would be, though.

Thoughts?

This is a follow up from here.

Sorry if this post doesn't make sense, I just spent half an hour writing it and I accidentally hit the switch on my power bar and my computer shut off.

Again, sorry RM, but I don't remember discussing this with you at all. You did say it was a long time ago, so I may have just forgotten. Anyway, so you want to release MSI Phoenix V2.0 when SRL 5 is released?

I don't have anything against that, but here's what I'm thinking.

1. We setup a git repository in the SRL group over at git-hub ASAP (not sure if Wizzup? has to set this up or not). This repository will have two branches (master and less stable). RM and myself will be the only ones able to commit to the master branch, while all other SLs can commit to the less stable branch.
2. We fork (or whatever it's called) the less stable branch with the current SVN repository so that the MSI updater will now update from git and any commits through the SVN will also be committed to the git repository.
3. We hold off on any major feature updates (if you're currently working on one, that's okay; finish and commit). We concentrate on bug fixes, tweaks and small features. The idea is to get the most stable version upon the release of SRL 5.
4. Upon the release of SRL 5, we begin converting the less stable branch to SRL 5. This will also give users the chance to test SRL 5 as well as how it changes MSI. For the next few days (maybe longer), we concentrate on making the SRL 5 version of MSI as stable as possible.
5. When things die down, and we're confident with the less stable branch, we merge this branch and the master branch. It is at this time we could officially release MSI Phoenix V2.0.

I think this plan makes a lot of sense. It allows us to get used to git before we officially release a stable version and it pretty simple and organized (just the way I like it). Following the official release

1. We continue to commit to the less stable branch as bugs, suggestions come up and features are developed.
2. What's left is for the user to choose which version (the stable or less stable) they want to use. I'm hoping this is possible:
• An option is added to the MSI drop down menu (Update to >).
• This option has two sub-options (Latest Stable and Latest). Latest stable will download from the master branch and the Latest will download from the less stable branch.
• There will also be a check mark beside the version the user currently has downloaded.
If possible, I suppose the same thing could be done for SRL and Reflection if people like the idea. It also kind of brings back the idea of "SRL" and "dev-SRL", which I like.

What do you guys think?

P.S. My first attempt at writing this was 1000x better. :( Hopefully this makes sense.

You keep the master branch. I'll fork from you.

And NCDS forks from you too.

SLs fork from NCDS.

MSI Contributors fork from NCDS

And testers fork from individual SLs.

General public… forks off Coh3n.

Sounds good? :)

I'm not sure you can do this:

"
We fork (or whatever it's called) the less stable branch with the current SVN repository so that the MSI updater will now update from git and any commits through the SVN will also be committed to the git repository."

Just sayin' that, everything else looks good though.

Perhaps MSIv2 can be released as an external with SRL5? Make sense at all?

Also, having the master branch with the organization then having the development forks stemming from Coh3n seems like a better idea.

From: Nava2

Also, having the master branch with the organization then having the development forks stemming from Coh3n seems like a better idea.

My thoughts exactly.

Coh3n forks from me and I push to NCDS

From: Sir R. M8gic1an
My thoughts exactly.

Coh3n forks from me and I push to NCDS

No.. that essentially defeats the purpose of git. :P

Its through a web of trust.

Coh3n and you can form from the main, SL's fork from you, and everyone else forks from them. They can ask to be pulled from on the main repos even if they are on a different one any ways.

From: Sir R. M8gic1an
You keep the master branch. I'll fork from you.

And NCDS forks from you too.

SLs fork from NCDS.

MSI Contributors fork from NCDS

And testers fork from individual SLs.

General public… forks off Coh3n.

Sounds good? :)

Yeah that was my original idea, but what about the users? They would have to learn how to download from a git repo rather than just using the extension if the want to test NCDS's or another SL's branch. That's why I liked the idea of having two. If we can choose to download them from a menu item it would be much much better. How about this.

I control the master branch. NCDS & I control the "less stable" branch. Other SLs fork from this branch so both NCDS and I can commit to the less stable branch and merge it with pull requests from other SLs. OR, my original idea, all SLs control the less stable branch (I still like this better, maybe I'm missing something from what you're suggesting).

From: Nava2
I'm not sure you can do this:

"
We fork (or whatever it's called) the less stable branch with the current SVN repository so that the MSI updater will now update from git and any commits through the SVN will also be committed to the git repository."

Right now I can commit to the SRL 4 SVN and it will automatically update the git repository. That's what I'm talking about doing.

From: Nava2

Perhaps MSIv2 can be released as an external with SRL5? Make sense at all?

We would have to start converting MSI to SRL 5 before SRL 5 is released then.

From: Nava2

Also, having the master branch with the organization then having the development forks stemming from Coh3n seems like a better idea.

Like, there's the master, then there's mine, and people branch from mine?

I definitely want to move to Git, but I'm not sure I understand the rest..

Not being able to commit…? :/
Why exactly do we need to release a 'new version'?
SRL 5 (at this point) is pretty similar to SRL 4, what will this 'SRL 5 version' consist of?

I really like the user updating options though.

Nah I don't think you're listening.

The MAIN web is the following:

RM -> Coh3n -> NCDS -> SLs + Devs

That's the main web, everything else triangulates from there.

— Coh3n – Devs – Marpis – Ray ? - ?
— RM — NCDS – N2 – EC – Markus -? - Fawk
SLs SLs SLs SLs SLs – Wizzup - Camaro
- MasterKill - U get the point?

~RM

Somewhere along those lines

@NCDS: SRL 5 is git based, moving to git is just preparing ourselves for SRL 5 release.. :)

From: Sir R. M8gic1an
Nah I don't think you're listening.

The MAIN web is the following:

RM -> Coh3n -> NCDS -> SLs + Devs

That's the main web, everything else triangulates from there.

— Coh3n – Devs – Marpis – Ray ? - ?
— RM — NCDS – N2 – EC – Markus -? - Fawk
SLs SLs SLs SLs SLs – Wizzup - Camaro
- MasterKill - U get the point?

~RM

Somewhere along those lines

Yeah after reading the other posts I get it more.

From: Sir R. M8gic1an

@NCDS: SRL 5 is git based, moving to git is just preparing ourselves for SRL 5 release.. :)

I know that, I've done work for SRL 5 already ;) I was asking more code related what would need to be changed.

So our v2 will really just be us moving to git and stabilizing things more?

Coh3n, when you commit to the SRL4 svn, you are doing just that. You are NOT committing to git. I highly doubt you could commit to the git repos and have it mirror the other way around.

no, I think svn can stay there.

Coh3n updates msi svn. Only person who updates the svn.

~RM

From: NCDS
I definitely want to move to Git, but I'm not sure I understand the rest..

Not being able to commit…? :/
Why exactly do we need to release a 'new version'?
SRL 5 (at this point) is pretty similar to SRL 4, what will this 'SRL 5 version' consist of?

I really like the user updating options though.

You'll be able to commit to the "less stable" one, then when we feel that one is stable, I merge it with the master branch.

From: Sir R. M8gic1an
Nah I don't think you're listening.

The MAIN web is the following:

RM -> Coh3n -> NCDS -> SLs + Devs

That's the main web, everything else triangulates from there.

— Coh3n – Devs – Marpis – Ray ? - ?
— RM — NCDS – N2 – EC – Markus -? - Fawk
SLs SLs SLs SLs SLs – Wizzup - Camaro
- MasterKill - U get the point?

~RM

Somewhere along those lines

You confused me with that post. =\

From: NCDS
Yeah after reading the other posts I get it more.


I know that, I've done work for SRL 5 already ;) I was asking more code related what would need to be changed.

So our v2 will really just be us moving to git and stabilizing things more?

We don't have to call it V2.0, it doesn't really matter to me, but yeah it's just a very stable, SRL 5 supported MSI.

From: Nava2
Coh3n, when you commit to the SRL4 svn, you are doing just that. You are NOT committing to git. I highly doubt you could commit to the git repos and have it mirror the other way around.

Oh sorry, I didn't mean to say that the SVN would update if we commit to git. Just if you commit to SVN, git would update.


I'm a little confused, I'd like to restate what I think's happening.


I feel like a dnumbass right now, but is there a reason why that's bad or wouldn't work? That way we can have the two options in the drop down menu for users to choose which to download. It seems much simpler to me than having 6 different lines in the tree. =\

I merge master and less stable when we feel less stable is stable enough for the master branch.

No that works perfect fine for me, it's that I wanted you and NCDS pushing to me and me pushing to you and then you guys do whatever you guys do and I do whatever I do and things would get around anyway, cus we'd be pulling from other git repos.. :)

~RM

From: Coh3n
Oh sorry, I didn't mean to say that the SVN would update if we commit to git. Just if you commit to SVN, git would update.

Again, I do not think it works like that. You cannot fork and have branches if you are using SvN.. o.O

From: Sir R. M8gic1an
no, I think svn can stay there.

Coh3n updates msi svn. Only person who updates the svn.

~RM

Ummm….what?

From: Coh3n
You'll be able to commit to the "less stable" one, then when we feel that one is stable, I merge it with the master branch.

We don't have to call it V2.0, it doesn't really matter to me, but yeah it's just a very stable, SRL 5 supported MSI.

Yeah, I guess that all works for me. I'm assuming that the reason your only allowed to commit to the master branch is because it's 'hosted' with SRL 5?

From: Nava2
Again, I do not think it works like that. You cannot fork and have branches if you are using SvN.. o.O

No no no, the SVN would only be used until we were completely moved to git. The SVN would be mirrored with the "less stable" branch until we merge it with the master.

From: NCDS

Yeah, I guess that all works for me. I'm assuming that the reason your only allowed to commit to the master branch is because it's 'hosted' with SRL 5?

No I don't think that would matter. The reason was simply so everything goes through me before marked as stable. Not that I don't trust anyone, it's just more of a precautionary thing. Plus the users can switch to the less stable branch easily enough with the menu items.

NCDS: I'm seeing two things

I'm seeing that I'm talking and you're wanting to be able to commit to svn, but that I'm saying only coh3n will committ.

I don't think that for MSI v2 you should be committing to svn. I one of the ideas of v2 would be to get rid of svn and use git.

I was just suggesting that coh3n holds the master stable branch (he can fork it to have his own branch) but he'd hold the master one and the master one would be the same as the svn.

One single stable svn.

nd for v2 it'd be git, so people, eg Camaro would be downloading ur version of MSI to test ur stuff, or you could push your code to other SLs and devs etc.

git is really much better for code management and I wouldn't want to see svn in v2, but as coh3n wants it I guess it can be there, but svn should just keep a stable version for users too lazy to switch to git, and the goodiewoodies would be kept it git.

Wanna know why? Cus with git I can send you my special MSI codes, but doesn't mean those codes will be put out to the whole public.

~RM

From: Sir R. M8gic1an
NCDS: I'm seeing two things

I'm seeing that I'm talking and you're wanting to be able to commit to svn, but that I'm saying only coh3n will committ.

I don't think that for MSI v2 you should be committing to svn. I one of the ideas of v2 would be to get rid of svn and use git.

I was just suggesting that coh3n holds the master stable branch (he can fork it to have his own branch) but he'd hold the master one and the master one would be the same as the svn.

One single stable svn.

nd for v2 it'd be git, so people, eg Camaro would be downloading ur version of MSI to test ur stuff, or you could push your code to other SLs and devs etc.

git is really much better for code management and I wouldn't want to see svn in v2, but as coh3n wants it I guess it can be there, but svn should just keep a stable version for users too lazy to switch to git, and the goodiewoodies would be kept it git.

Wanna know why? Cus with git I can send you my special MSI codes, but doesn't mean those codes will be put out to the whole public.

~RM

Yeah I know about, and how to use Git (for the most part). Like I said I've been doing some things for SRL 5 through Nava on there. Now that I spoke with Coh3n last night I understand what's going on more. I was really just confused about the 'version change' and such.

I'm cool with Coh3n's understanding of the situation, and I'm assuming that's what your intent it as well? Meaning, only commit to the stable branch after bigger changes (New skills/Big features/form changes/etc.) but generally commit to the 'less stable' branch. Then the 'stable branch' becomes more of a back up in case a commit goes wrong.

That's how Coh3n explained it to me anyways, and I'm cool with that. :)

Yeh it's exactly that :p

And the change to the TScriptRecord forces a version changename in the code.

~RM

There is no need to maintain an SVN and a git repos. Thats a waste of time, RM.

You just tag stable releases in the git reposititory. Much like Simba does on the repos.

From: Nava2
There is no need to maintain an SVN and a git repos. Thats a waste of time, RM.

You just tag stable releases in the git reposititory. Much like Simba does on the repos.

No it's not a waste of time.

Coh3n was asking for it, I don't mind it, if he wants to do it he may as well go ahead and do it. More userfriendliness, anyone who just simply wants stable - no worries - updates can just simply use svn.

With git you'd have to be choosing who to pull from and so on, and this separates leechers from contributors.

Switching to git is a development step.

And maybe that way we can even keep a scar / simba version available on the svn. Dunno, if someone wants to work on it, a scar brach can just simply be made from a main repos (I'd suggest NCDS' or Coh3n's Dev branch). Of course it'd be up to whoever wishes to contribute

From: Sir R. M8gic1an



No it's not a waste of time.

Coh3n was asking for it, I don't mind it, if he wants to do it he may as well go ahead and do it. More userfriendliness, anyone who just simply wants stable - no worries - updates can just simply use svn.

With git you'd have to be choosing who to pull from and so on, and this separates leechers from contributors.

Switching to git is a development step.

And maybe that way we can even keep a scar / simba version available on the svn. Dunno, if someone wants to work on it, a scar brach can just simply be made from a main repos (I'd suggest NCDS' or Coh3n's Dev branch). Of course it'd be up to whoever wishes to contribute

No, you're not listening.

Stable branches can easily be distributed using tags.

Example:
https://github.com/MerlijnWajer/Simba/tree/simba-0.96rc
https://github.com/MerlijnWajer/Simba/tree/simba-0.95
https://github.com/MerlijnWajer/Simba/tree/simba-0.94

Those all come with zip/tar.bz2 files of source packages. You wanted to easily distribute something? What do you think those are for?

From: Nava2
No, you're not listening.

Stable branches can easily be distributed using tags.

Example:
https://github.com/MerlijnWajer/Simba/tree/simba-0.96rc
https://github.com/MerlijnWajer/Simba/tree/simba-0.95
https://github.com/MerlijnWajer/Simba/tree/simba-0.94

Those all come with zip/tar.bz2 files of source packages. You wanted to easily distribute something? What do you think those are for?

It's not that I'm not listening, it's that I didn't know that :)

Sounds good to me, on Coh3n. I dont see the negatives of an svn being kept anyway if SLs find it better off.

~RM

You should add a poll:
Will we release a whole new version of MSI, called MSI v2, or do we just keep updating this without making it a big deal?

My vote is a big NO, I don't see any point in starting to call it v2.

Oh wow. So many posts to catch up on from being at school with friends after school…

I'd very much like to move to git and the master -> less stable -> Users & Contributers system thing that Coh3n posted seems alright.

I don't really have an opinion on if we should call it MSIv2 or not, but my thinking is that this is a giant update, and a lot is being re-made and cleansed, but it will be less confusing for people if we just keep on calling it MSI.

E: After some thinking and looking at other posts, I've decided I don't want to call it MSIv2

Well let's just say MSIv2 everytime we mean something to do with git ;)

~RM

From: Sir R. M8gic1an
Well let's just say MSIv2 everytime we mean something to do with git ;)

~RM

After MSI has changed to git, it'll still be MSI

From: Sir R. M8gic1an
Well let's just say MSIv2 everytime we mean something to do with git ;)

~RM

Makes no sense? It's just our distribution system changing, not MSI?

Well it's MSI, but it's MSI Phoenix and it's not MSI Phoenix v1, it's MSI Phoenix v2.

It's a name change? What the hell does everyone have up their, to be so annoying about a name change?

I said roll, Coh3n said roll, what is everyone still barking at?

~RM

From: Sir R. M8gic1an
Well it's MSI, but it's MSI Phoenix and it's not MSI Phoenix v1, it's MSI Phoenix v2.

It's a name change? What the hell does everyone have up their, to be so annoying about a name change?

I said roll, Coh3n said roll, what is everyone still barking at?

~RM

"MSI Phoenix isn't v1, it's v2"… That's exactly what we don't want it to be.

"I said roll, Coh3n said roll, what is everyone still barking at?" Even though you two say roll, doesn't mean we'll automatically follow in your footsteps. I do not approve of this change, marpis doesn't approve either and NCDS is confused about if this really is such a big update as you are making it.

It's a name. Not an entity. I'm off.

RM, I didn't mean for it to seem like I wanted to keep maintaining the SVN. The idea was meant to be temporary so that any commits made to the SVN will update the git repository until everyone moves to git (exactly how SRL 4 works right now). So no, I do not want to keep the SVN maintained; although, I think a thread could be made in the archives about it.

As to the name change. I think you guys are making it seem like it's more important than it really is. We don't HAVE to change it, but I think it makes sense. No, there won't be some massive update (actually, cooking may be done, depends how NCDS is doing), V2.0 would label MSI as stable with most if not all of the major bugs gone.

As an alternative (now that I think about it, I like this better), we don't change the name yet, we just switch to git and mark the master branch as stable after the switch to SRL 5. Then, once we start pumping out updates like new skills, major changes to records, hybrid systems, etc. we call the less stable branch MSI Phoenix V2.0 Beta from which anyone can test by switching branches via MSI's drop down menu. Make a little more sense?

Okay, so I talked to Nava earlier today, and I (we) kind of came up with a new plan, that actually makes much more sense. He pointed out that it really doesn't make much sense to have two branches, so here's what I was thinking. This is a nice, organized way of development/distribution.

1. Git Repository
2. Currently only myself and NCDS have write access to it.
3. All SL's (including NCDS and myself) will have personal repositories (we'll each fork the one above).
4. This allows for users to download our versions to test things we've been developing as individuals.
5. Once you think your personal repository is stable enough to be merged with the main repository, you will send a Pull Request and either myself or NCDS will merge it if all is well.

To fork the repository:

1. Create an account at Git-Hub.
2. Fork the repository from here.
3. You'll also have to download and setup git. I used this guide, but it's up to you how you do it.
4. I think it's possible to develop without git installed (through git-hub), but I'm not sure how that works.
5. You can commit/edit/do whatever you want to your forked version, then send a pull request via git-hub whenever.

Now, an idea for users to update: We still use the MSI drop down menu, with the stable (master) branch option, but instead of having the second option for a less stable branch, we call it "Download from…". When clicked it will open a window where they can enter the link to anyone's repository. Not sure how simple this would be, though.

Thoughts?

From: Coh3n
Okay, so I talked to Nava earlier today, and I (we) kind of came up with a new plan, that actually makes much more sense. He pointed out that it really doesn't make much sense to have two branches, so here's what I was thinking. This is a nice, organized way of development/distribution.

1. Git Repository
2. Currently only myself and NCDS have write access to it.
3. All SL's (including NCDS and myself) will have personal repositories (we'll each fork the one above).
4. This allows for users to download our versions to test things we've been developing as individuals.
5. Once you think your personal repository is stable enough to be merged with the main repository, you will send a Pull Request and either myself or NCDS will merge it if all is well.

To fork the repository:

1. Create an account at Git-Hub.
2. Fork the repository from here.
3. You'll also have to download and setup git. I used this guide, but it's up to you how you do it.
4. I think it's possible to develop without git installed (through git-hub), but I'm not sure how that works.
5. You can commit/edit/do whatever you want to your forked version, then send a pull request via git-hub whenever.

Now, an idea for users to update: We still use the MSI drop down menu, with the stable (master) branch option, but instead of having the second option for a less stable branch, we call it "Download from…". When clicked it will open a window where they can enter the link to anyone's repository. Not sure how simple this would be, though.

Thoughts?

Sounds good to me :)

For users to download perhaps by default it should download from the master branch, but the user can input the URL from anyone's git repos to DL from, much like you said.

From: NCDS
For users to download perhaps by default it should download from the master branch, but the user can input the URL from anyone's git repos to DL from, much like you said.

Like when it's first downloaded?

From: Coh3n
Like when it's first downloaded?

Oh nevermind, I read that part of your post wrong. I was just trying to say exactly what you said lol.

From: NCDS
Oh nevermind, I read that part of your post wrong. I was just trying to say exactly what you said lol.

Okay, just need to figure out if it's possible.

Sounds great, Coh3n :)

Damn, I am convincing. :)

Good plan, Coh3n. You never did tell me how you deleted that branch!

If you are going to be doing project management, I really do suggest you switch to git bash.. It will make your life much easier and faster.

I deleted the origin branch through TortoiseGit. I would guess with bash it'd be something like rm origin [branch] or something. And, how would it make it easier? Bash and Tortoise do the same thing do they not? Tortoise just has a UI.

From: Coh3n
I deleted the origin branch through TortoiseGit. I would guess with bash it'd be something like rm origin [branch] or something. And, how would it make it easier? Bash and Tortoise do the same thing do they not? Tortoise just has a UI.

Tortoise is not macroable. ;)

From: Coh3n

Currently only myself and NCDS have write access to it.

If person A gets sick, goes on vacation, or has lots of studying to do etc, person B can temporarily appoint another SL to take person As place, so that you always have 2 people with write access. If you don't do this and person B then has a problem, or if both of you have a problem at exactly the same time, people will have to use one of the person forks.

From: Boreas
If person A gets sick, goes on vacation, or has lots of studying to do etc, person B can temporarily appoint another SL to take person As place, so that you always have 2 people with write access. If you don't do this and person B then has a problem, or if both of you have a problem at exactly the same time, people will have to use one of the person forks.

Yeah the only problem is, Wizzup? has to add people. We can't add/remove people's access. IIRC, Wizzup and Ray have admin powers on the git-hub SRL group.

Everything has been moved. Repository can be found here. For right now, we only make small bug fixes to the SVN (until Wizzup? replies about the extension updating from git rather than SVN). Any feature updates should be pushed to your personal git repository.

From: Coh3n
Yeah the only problem is, Wizzup? has to add people. We can't add/remove people's access. IIRC, Wizzup and Ray have admin powers on the git-hub SRL group.

Ah ok, then never mind what I said as there is a lot smaller chance of all 4 of you being out at the same time than 2.

http://villavu.com/forum/showthread.php?t=62342

And what do you guys think about calling it v2.0 when multiple script support is finally added? I would say that's a pretty significant feature.

From: Coh3n
http://villavu.com/forum/showthread.php?t=62342

And what do you guys think about calling it v2.0 when multiple script support is finally added? I would say that's a pretty significant feature.

Doesn't much matter to me. By that time Cooking should be done as well.

From: NCDS
Doesn't much matter to me. By that time Cooking should be done as well.

Awesome. :)