|
So while I'm waiting for TFS to download a whole new branch...
I would think that the best way to manage releases is to have a single development branch (maybe short lived branches there while WIP is occurring), maybe some QA branches, whatever, and a single "main" branch. When a release is made, main is updated, then a branch for that release version is made in case hot fixes need to be made.
The idea being, the developers always work on the development branch. Easy-peasy.
But no. Here, we have different developer branches for every release. And I because I keep VS solutions with projects pulled from here and there and the SLN is not version controlled (that's a whole other issue as to why, let's just say the SLN files everyone else uses are so bloated with projects, and the equipment is so archaic, that it takes 30 seconds for Visual Studio simply to figure out that there are no changes to 100 projects...)
Anyways, I now have to remap the projects in my custom solutions to new "developer" branch folders (granted, that's a problem I can mitigate.)
And of course, what's worse is, I was informed Monday, "oh, we forgot to tell you that your work should now be checked in to the "Dev_A" branch for this, and the "Oct17" for that. 
|
|
|
|
|
Never had a need for branches. More trouble than they're worth; a symptom of a broken process.
|
|
|
|
|
PIEBALDconsult wrote: More trouble than they're worth; a symptom of a broken process.
Not at all. We have a trunk which is where all the development happens. When our release is ready to go we branch the code so that the latest branch is what most customers are running. We often need to get bug fixes to customers before the next release so we merge the bug fixes into the branch and then the customer can get just the bug fix. Very simple and very important.
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.
|
|
|
|
|
Trunk should always be the current production release.
A branch should always be used for ongoing work.
Testing can be done from the branch code.
When the code is ready, it should be merged back to trunk for release.
Trunk should always be the current production release.
Otherwise your trunk (released code) gets contaminated.
|
|
|
|
|
Not how we do it and it works fine for us. To each their own. 
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
