|
It happens on a Wednesday morning at least once a month. When I turn on my laptop, a friendly message shows up:
Working on updates
xx% complete
Don't turn off your computer
If it is a lucky day, I enjoy this message for 30 to 40 minutes. Otherwise, it will be 2 to 3 hours. When it reaches 100% complete, I sigh a relief and then stare at the 100% for another 20 minutes. What a way to start the day.
TOMZ_KV
|
|
|
|
|
Strange. Nothing of theat kind happens on my Linux boxes...
Rule #1: If you want to sell something, don't get let your paying customers jump through all kinds of hoops, like licensing or updates. I don't want you to tell me what we are going to do today, I don't want a Mickeysoft account or mail address, I don't give a damn when something has not been activated or a license has gone 'stale'.
It's only the pirates who are spared all this, thickskulls.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: Strange. Nothing of theat kind happens on my Linux boxes... Rule #1: If you want to sell something
But Linux is free. I guess it's true then, that the best things in life are free???
|
|
|
|
|
You sure can't beat the ratio between cost and usefulness.
There is also personal freedom. If every company that I ever bought something from now wanted me to marry them...
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Maybe a new computer?
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
I am not a game player, but I understand even games are a lot more buggy now, and depend on updates to fix their bugs instead of thorough testing.
I remember that Microsoft use to have a lot of writers that were working on documentation, which was nice. Then when .net came out they had already gotten rid of them all, and so we got .net and an absolute minimum of documentation. When Microsoft finally got around to having a Wiki, it would not allow the public to update, and the documentation, as it is today is so bad. Now if you do a search for software help and you see it is a Microsoft site, you look at the next hit.
It appears that thorough testing is now considered optional by software developers...let the users find the bugs, and then fix them if you can reproduce them...or maybe not.
|
|
|
|
|
Tomz_KV wrote: It happens on a Wednesday morning at least once a month.
Not sure if trolling, or genuinely unaware of Patch Tuesday.
|
|
|
|
|
20 or so years of using Windows never had this problem, installing updates - 10 minutes later, done. You're doing it wrong!
|
|
|
|
|
NOT.
- Check out the dev branch.
- Start working on a new feature
- You're asked to fix a bug on the same project not related to the feature you're adding.
- Manually copy the code to somewhere else that you've been working on for the new feature.
- Revert your local branch back to the master version
- Fix the bug.
- Check in the change.
- Manually copy back the code that you were working on for the new feature.
- Manually add back in the bug fix.
- Keep working on the feature.
Yes, this is actually what I was told as "how to do it" because branching can get too complicated.
  
|
|
|
|
|
That's what I would do when I first encountered git. Sunshine would just elephanting dissapear when I would change branches.
But then, I was used to PVCS where I controlled the file until I was done with it. Everybody else had to keep their grubby hands off.
Do I love git now? No, but I can tolerate it.
|
|
|
|
|
Marc Clifton wrote: Check out the dev branch.Start working on a new featureYou're asked to fix a bug on the same project not related to the feature you're adding.Manually copy the code to somewhere else that you've been working on for the new feature.Revert your local branch back to the master versionFix the bug.Check in the change.Manually copy back the code that you were working on for the new feature.Manually add back in the bug fix.Keep working on the feature.
Way easier 
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
|
There is a shelf-feature in VS 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: There is a shelf-feature in VS
Yes, and a stash (not sure if that's the git equivalent though) but nobody uses it.
|
|
|
|
|
I have, obviously 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You should "upgrade" them to Visual Source Safe so they can see what they are doing 
Hogan
|
|
|
|
|
That's one of the main reasons I forced myself to learn git.
Branching can get complicate using svn and others but it's no reason to not do it.
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
In TFS you can shelve changes, which is better than branching. Does Git have something similar? I don't know.
But your description brought a smile to face.
|
|
|
|
|
|
When using git, there is no reason not to branch. Besides, I commit every 15 minutes or so while working, so can't just stash (git equiv. to shelve) and work on something else. Just make a branch (takes about 10 seconds or less) and fix it there. Merging is generally not an issue in git (I have only had one merge conflict in the last month on a team of 7 devs and used to have many in TFS).
|
|
|
|
|
Merge conflicts usually only occur if the same file was worked on by more than one person, prior to check in/merge. We do our best not to let this happen, and "that" is what controls merge conflicts, not the software.
|
|
|
|
|
If you like to manually control merge conflicts, that's great, but I would rather let the software be better at merging and only get involved when there is truly a bad conflict. There are always certain files that are frequently modified (configuration files, common UI, etc.) and if your software can intelligently merge the code for you, then I welcome it. I have used almost every source control software out there in my 30+ years of development (some of them as a build automation engineer) and git gives a better development experience than most (ok, I prefer Mercurial, but the industry chose git and I use github for collaboration on my private projects).
|
|
|
|
|
I've actually had that situation and resolved it relatively easily with Git.
I think Git makes that very easy using the git checkout command.
I'm sure you know that already, but it is quite amazing how you can switch branches in Git so easy.
Much easier than Subversion where I would often start working on the change, only to remember later I needed to branch first.
|
|
|
|
|
"git checkout" just about sums up GIT in a nutshell.
It's a wonderfully easy way to do something but it has an utterly non-intuitive and inappropriate name.
Sometimes it almost feels like the only naming rule in GIT is "be as obtuse as possible."
98.4% of statistics are made up on the spot.
|
|
|
|
|
You're checking out the branch, I don't see the issue with the name? Not that it's an amazing name, many non-Microsoft names do leave a lot to be desired ("Blame" springs to mind), but it's not the worst name either.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
