can see the usefulness of more granular checkins on a larger project though, because it's important to checkpoint your work.
I do try to commit mostly working stuff as much as I can. But in my day job, we commit far more often, and in logical sections. This facilitates easier log review and code reversion if necessary. I'd like to do this for add-ons too, if it's needed, since I can easily revert back to a known good state if I really mess things up.
I agree with the general train of thought that I see running through this thread as well. I'm not an addon developer (have dabbled a little with some minor changes to a few locally), but do work in software development. So, the whole Dev -> Alpha -> Beta -> Release process does seem to make more sense overall, to me. There have been plenty of times I've packaged something just for my own testing, that I don't want any others to mess with. Usually, this is because I know it's broken, and I've added some sort of debug logic that I can use to track down the problem. Nobody else would likely know what the hell that data it's spitting out means, and thus would never have any reason to ever see it in the first place. :p
So yeah, having a "dev" type default for check-ins that's not downloadable by the CC seems like a very good/useful idea to me. It allows those who want to test Alphas the ability to still download them through CC, and ensures the developer actually meant for it to be marked as "test-ready" for people outside of SVN access.
We're getting further and further from topic here, heh. If you use Tortoise, just right click the parent folder of all your code, click TortoiseSVN -> Properties. Click New... Pick "svn:eol-style" from the drop down. Under property value, type "native". Check "apply property recursively". Click OK twice. Do this again any time you add a new file, as the pre-commit hooks will complain.
yeah,,... ah well... but no, I dont use Tortoise, I am using the command line version from a nix box.
yeah,,... ah well... but no, I dont use Tortoise, I am using the command line version from a nix box.
Investigate autoprops. You should be able to modify the SVN config file and add eol-style: native to it for various file types. You can also modify mime-types and so on there.
He means committing untested code, which usually isn't a great idea, but in your case I think you have a good excuse.
Depends on the level of testing I guess.... but since part of what the packager does/can do is bring in your common libs in many cases you are not really testing the package delivered for sure till you at least have it build it for you, which should be an alpha, each check in should not be a release , just when you tell it to do a packaging.
I am not fine with ALpha being downloaded by a client set by a user who wants bleeding edge and is gonna complain when my alpha code overwrites their release and they lose all their data. That is just....well.....dumb.
At that point, that particular user us just...well...dumb. I don't see the point of locking the system down because of the possibility that it can be accessed by retards. If you want that, don't commit to SVN at all until you're ready for testing.
At that point, that particular user us just...well...dumb. I don't see the point of locking the system down because of the possibility that it can be accessed by retards. If you want that, don't commit to SVN at all until you're ready for testing.
As i said. That is not how i work. That is not how i will work. If Alpha is made readily available then i will have to find something that fits with how i work.
I think a DEV tag is a better option. As lots have pointed out, Alpha should be a test ready package. Since everything is tagged alpha by default, that is not really true.
Maybe the best option is this, we keep the default at Alpha, let users choose to d/l Alpha.
Ceate a DEV tage that we have to set at commit that is not available outside of SVN.
I think for now just telling the packager to not package alphas solves the problem just fine. The only disadvantage is it only leaves one "test" tag (beta), but that should be fine.
At that point, that particular user us just...well...dumb. I don't see the point of locking the system down because of the possibility that it can be accessed by retards. If you want that, don't commit to SVN at all until you're ready for testing.
Concur..
People should be allowed to use the version control system as they see fit. If I want to checkin uncompilable(I know. I'm being simple right now) code, because I'm doing work from multiple IRL locations(or for any reason I see fit), I should be able too.
If a user downloads this code and uses it, thats too bad for them.
Now there are a couple caveats here.
The user has the ability to not retrieve this version of the code, and I didn't mark my knowingly broken code as 'ready for use'.
At that point I demand that said user remove my foot from his arse.
you know, i don't disagree but my experience is that they will still be a PITA. why would we want to even expose ourselves to the possibility of dealing with morons?
I still say they should only have access through the client for what we want them to.....period.
Again, if the client is given access to what is currently known as "alpha", i will use another repository and just update releases to WowAce.
I am not saying this in anger, just saying it. I have been around WowAce for a while just as a lurking non-member. I think it's great.
I am not going to change the way i work and use the repo. It just fits with me and my routine.
ciscoh: Turn off alpha packages. I still think this'll solve the problem.
i did. i am just concerned that it appears that there are still plans to allow alphas via cc i assume that by not packaging alphas, i can prevent that, however, i do agree that this will impair the ability for wanted testers to test real alpha code that we still do not want to support for general users.
if things stay as they are, without allowing access to alphas via the client, its all good.
i do agree that this will impair the ability for wanted testers to test real alpha code that we still do not want to support for general users.
I would agree, except these are just add-ons, not full-blown software projects, so in reality the need for multiple levels of test builds probably isn't that high. But as I've said earlier in the thread, it might make more sense to label all commits as "dev" by default and allow alphas and betas to be manually tagged. But it's not really a big deal.
My svn reader hasn't been used for a while.. configuring it to do whatever testing needs to be done isn't that big of a deal.
Alphas are too... alpha.
We should be funneling out code to the masses.. i.e. the developer tries it out in a basic way, a few more people get involved, a few more people get involved/translate it, everyone gets it who wants it.
Each of those comma's should be a package... dev,alpha,beta,release.
If certain packages earlier in that list of commmas requires certain tools thats not such a big deal.
We know CC handles beta/release, and if Dev,alpha requires svn, it's really not that big of a deal as the idea would be that dev/alphas is a MUCH smaller list of people.
The only thing that we need to be careful of is to not let code stagnate in alpha/beta.. there are some good translation, and bugfixes in some addons that have been in alpha for months.. It's that sort of thing where people occasionally DO need to reach into alpha to get something they need that is rocking the boat.
I think the testers should take some responsibility for that, but if it really is a minor fix, like a mispelling or something, we probably don't need to do the full dev,alpha,beta,release stuff... just go from dev(unit test)->release.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYeah, there are definitely many ideologies at work here. This is just the way I prefer to do things.
I do try to commit mostly working stuff as much as I can. But in my day job, we commit far more often, and in logical sections. This facilitates easier log review and code reversion if necessary. I'd like to do this for add-ons too, if it's needed, since I can easily revert back to a known good state if I really mess things up.
maybe my idea of drycoding is off.
i always thought it meant Don't Repeat Yourself
kind of implies a method of coding where you modularize so you can reuse code.
i proudly wear that label
work smarter, not harder.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHe means committing untested code, which usually isn't a great idea, but in your case I think you have a good excuse.
So yeah, having a "dev" type default for check-ins that's not downloadable by the CC seems like a very good/useful idea to me. It allows those who want to test Alphas the ability to still download them through CC, and ensures the developer actually meant for it to be marked as "test-ready" for people outside of SVN access.
i think in projects where there are multiple developers, there is more of an issue with this.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumyeah,,... ah well... but no, I dont use Tortoise, I am using the command line version from a nix box.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumInvestigate autoprops. You should be able to modify the SVN config file and add eol-style: native to it for various file types. You can also modify mime-types and so on there.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDepends on the level of testing I guess.... but since part of what the packager does/can do is bring in your common libs in many cases you are not really testing the package delivered for sure till you at least have it build it for you, which should be an alpha, each check in should not be a release , just when you tell it to do a packaging.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorAt that point, that particular user us just...well...dumb. I don't see the point of locking the system down because of the possibility that it can be accessed by retards. If you want that, don't commit to SVN at all until you're ready for testing.
As i said. That is not how i work. That is not how i will work. If Alpha is made readily available then i will have to find something that fits with how i work.
I think a DEV tag is a better option. As lots have pointed out, Alpha should be a test ready package. Since everything is tagged alpha by default, that is not really true.
Maybe the best option is this, we keep the default at Alpha, let users choose to d/l Alpha.
Ceate a DEV tage that we have to set at commit that is not available outside of SVN.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumConcur..
People should be allowed to use the version control system as they see fit. If I want to checkin uncompilable(I know. I'm being simple right now) code, because I'm doing work from multiple IRL locations(or for any reason I see fit), I should be able too.
If a user downloads this code and uses it, thats too bad for them.
Now there are a couple caveats here.
The user has the ability to not retrieve this version of the code, and I didn't mark my knowingly broken code as 'ready for use'.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe problem comes when said user then demands support for said broken commit.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorAt that point I demand that said user remove my foot from his arse.
you know, i don't disagree but my experience is that they will still be a PITA. why would we want to even expose ourselves to the possibility of dealing with morons?
I still say they should only have access through the client for what we want them to.....period.
Again, if the client is given access to what is currently known as "alpha", i will use another repository and just update releases to WowAce.
I am not saying this in anger, just saying it. I have been around WowAce for a while just as a lurking non-member. I think it's great.
I am not going to change the way i work and use the repo. It just fits with me and my routine.
CiscOH
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumi did. i am just concerned that it appears that there are still plans to allow alphas via cc i assume that by not packaging alphas, i can prevent that, however, i do agree that this will impair the ability for wanted testers to test real alpha code that we still do not want to support for general users.
if things stay as they are, without allowing access to alphas via the client, its all good.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes, it will prevent it.
I would agree, except these are just add-ons, not full-blown software projects, so in reality the need for multiple levels of test builds probably isn't that high. But as I've said earlier in the thread, it might make more sense to label all commits as "dev" by default and allow alphas and betas to be manually tagged. But it's not really a big deal.
Alphas are too... alpha.
We should be funneling out code to the masses.. i.e. the developer tries it out in a basic way, a few more people get involved, a few more people get involved/translate it, everyone gets it who wants it.
Each of those comma's should be a package... dev,alpha,beta,release.
If certain packages earlier in that list of commmas requires certain tools thats not such a big deal.
We know CC handles beta/release, and if Dev,alpha requires svn, it's really not that big of a deal as the idea would be that dev/alphas is a MUCH smaller list of people.
The only thing that we need to be careful of is to not let code stagnate in alpha/beta.. there are some good translation, and bugfixes in some addons that have been in alpha for months.. It's that sort of thing where people occasionally DO need to reach into alpha to get something they need that is rocking the boat.
I think the testers should take some responsibility for that, but if it really is a minor fix, like a mispelling or something, we probably don't need to do the full dev,alpha,beta,release stuff... just go from dev(unit test)->release.