|
Yes, definitely, there are many processes that work for different companies.
The interesting thing is that I thought I was agreeing with you. Seriously.
Whatever works, works best. 
|
|
|
|
|
Marc Clifton wrote: different developer branches for every release
I simple shared disk, with a couple of subdirectories, with nightly backups, for all developers would be much better!!
OK seriously your suggestion is the way to go, and this is what big G and many others do: one dev branch for all. Short lived branches (call them "stabilisation branches", "release branches" etc) during release periods. This is to allow the majority of devs to keep doing their job. Hot-fixes are done on the temporary branch and ported to master after release. Never the other way.
... such stuff as dreams are made on
|
|
|
|
|
megaadam wrote: to master after release
Master is referred to as trunk.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Well, it's a damn sight better than popsicle sticks!
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
This GIT branching model seems to be very popular A successful Git branching model » nvie.com[^]
For now we like to keep things simple with only a Development and Master branch, for "dangerous" things separate branches can be created as needed.
|
|
|
|
|
As much as I hate git (Give me file locking any day of the week) That model does work well. I advocate a GUI for git because the command line is most cryptic mumbo jumbo I've come across. GitKraken is my current favorite.
But to the original post, you are not alone, part of our source is on subVersion and the group that controls the release of that code does something similar. You make changes on the trunk and then they call a lock period on the trunk make a branch and use the branch as the release.
|
|
|
|
|
I agree, using a GUI for GIT makes life easier, we are using TortoiseGIT. But in some situations you can't avoid the GIT command line, recently I had to port our GIT repository from an Open BSD server (brrrrr) to a more manageable Windows 10 server running GITEA.
Read the horror story here: Migrate from SSH · Issue #1635 · go-gitea/gitea · GitHub[^]
Don't get the impression that GITEA is a bad choice, it works fantastic and we are very pleased with it !
|
|
|
|
|
This cartoon: UserFriendly[^] got me thinking: 36 years ago this month, the PC was released to the world for the first time.
I was in the industry when it happened, and it didn't really make a splash immediately, but IBM made some huge mistakes back then: they made it extensible, expandable, and ludicrously expensive.
Seriously: the basic usable machine (64K RAM, one off 160KB floppy, monochrome text-only monitor, and a keyboard) was priced at around US$3,000. A top of the range model with CGA monitor (16 colours text, 320x200 graphics in any four colours of your choice from the available 16, and a printer) was US$4,500.
You could buy expansion cards to get more RAM - up to 640K! Two floppies!
You could swap out the 4.77MHz processor for a slightly faster working (but same clock speed) V20 one, or buy a floating point processor and plug that in!
So clones appeared. And boy, have they progressed! There are (from what I see on t'interwebs) well over 2 billion PC's in existence and working today. And every single one of them is thousands of times more powerful than the computers that got man to the moon and back in 1969.
We - nearly all of us - owe our whole job to that tank of a PC (heavy? Nah - the keyboard alone weighed in at only 6lb) and I've been coding on or for the damn things for well over thirty years.
Perhaps August 12th should be a worldwide public holiday?
[edit]CGA, not EGA!  [/edit]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
modified 23-Aug-17 8:26am.
|
|
|
|
|
OriginalGriff wrote: (64K RAM, one off 160KB floppy, monochrome text-only monitor, and a keyboard) was priced at around US$3,000. A top of the range model with EGA monitor (16 colours text, 320x200 graphics in any four colours of your choice from the available 16, and a printer) was US$4,500.
Go ahead and take a look what a TRS-80 Model 3 or 4 would have cost. These were still typical workhorses at that time.
Edit: Model 4 came later, that still leaves us with Model 3:
1980: July - Radio Shack introduces the TRS-80 Model III, priced from US$700 to US$2500.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
CodeWraith wrote: TRS-80
10 PRINT "Hello Adam!"
RUN
My first kiss!
... such stuff as dreams are made on
|
|
|
|
|
Yes, for me as well. Had a little trouble with the parents and fled to a shopping mall where I found a freshly unboxed TRS-80 (Model I), turned on and the manual lying in front of it.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
Or if you were a bit more advanced, add
20 GOTO 10
|
|
|
|
|
Not the frirst time around. First I just copied what I found in the manual, then I changed the text to be printed and sometime that afternoon I also learned the magic command GOTO.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
CodeWraith wrote: I also learned the magic command GOTO.
Yes and now we're being told to forget it 
|
|
|
|
|
Which I stubbornly refuse to do. These 'rules' are for those who are to dumb to understand at which point something becomes problematic. I do this very rarely, but sometimes it's more important to keep a piece of complicated code contained in a method. No refactoring into other functions! Let's keep these eggs in one basket, despite all wise rules. Add a note that only I may work on that thing, and even then only with signatures from at least three bosses and only on highest holidays. There should be reasons for doing this and playing by the rules will break it.
In such a thing it can be easier to get out of some nested code using a GOTO than doing it with the 'good' if-else way.
In C or C++ such a function may often contain some inline assembly, providing one more good reason to keep everything in one function. That's very volatile code which you don't want to spread out all over the application.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
Quote: These 'rules' are for those who are to dumb to understand at which point something becomes problematic.
For those of us who haven't used a GOTO in 20 years, we can say the same thing about you.
|
|
|
|
|
I did not want to offend you. It's just that I met enough people who could recite all kinds of rules as if they were holy commandments, but had not the slightest clue why it's not always a good idea to use these things. I don't think that those people are dumb. They have been made that way by training them to obey rules without questions.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
I also haven't used GOTO for many, many years. Not because of any "rule", just because my nicely structured code has never needed one - I haven't missed it.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
As it should be, but unfortunately not always is. The last time I saw that was a highly specialized and optimized core, around which practically all the company's products were built around. The normal (C++) compiler optimizations were not enough and time was really money in this case.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
No worries. We're good.
I stopped using GOTO because I started thinking more about the structure of my code and getting into finer compartmentalization. This made my code more reusable and extendable. I stopped because I started thinking through the problems to be solved better.
I didn't stop using it because of some code apologist or evangelical corner of the industry coming up with "the rule". It was a side effect of overhauling problem analysis and better algorithm generation.
|
|
|
|
|
CodeWraith wrote: all kinds of rules
For many years I did not even realise there was a "rule" that you should not use GOTO (or GOSUB). when I moved to .net (from vb6) it just never needed to be used, there were better structures available.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
And then one day (hopefully not) someone came and told you what you can or can't do - because Mr. SoAndSo said that. Basta.
I just don't need code monkeys. I don't want to become one myself and I don't try to make anyone a code monkey.
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
|
I don't have a problem with GOTOs that jump backward (to a lower line number in the source file) in code. It's the ones that jump FORWARD (to a higher line number) that I hate.
|
|
|
|
|
I literally shouvelled sh*t ti help my school buy 2 model II's.
Few months later was caned for playing on it when I was supposed to be in class (metalwork) - in font of the class.
Ah memories, stuff that today's kids will never get the chance to experience.
And I must admit:
1. caning (6 on the backside) really didn't hurt that much,
2. learning metal/woodwork back then means there's a lot of stuff I can do myself.
3. chainsaws are fun
signature upgrading ... please wait.
|
|
|
|
|
Lopatir wrote: 3. chainsaws are fun
Anything destructive is fun at that age. Right after school they drafted me and taught me how to operate these.[^] Shooting with rifles and machineguns got almost boring. 
The user can't update the up: we update it for them (Choice in the CP poll)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
