|
Donald does not wear a mask, just the cheapest toupet I ever saw.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
To (mis)quote Dolly Parton - "it costs a lot to look as cheap as that!"
=========================================================
I'm an optoholic - my glass is always half full of vodka.
=========================================================
|
|
|
|
|
Beavis a\'N Butthead - the maskerade
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
|
ha ha, nice try .
Fortunately it doesn't look like I'm becoming bald anytime soon
|
|
|
|
|
A set of clippers could soon fix that.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
Paris in the cellar
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Debbie vs Jason
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
The Elephant Man
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Mmmmhh, a movie with a mask ? The Mask ?
|
|
|
|
|
Hey now!
Software Zen: delete this;
|
|
|
|
|
Easy one today:
Artillery regiment crazy about Queen (7)
Slogans aren't solutions.
|
|
|
|
|
Battery.
Crazy - batty
about queen - ER.
Andy B
|
|
|
|
|
That's the one. Well done.
Slogans aren't solutions.
|
|
|
|
|
Why is Queen "ER"? just curioous. I thought it would be "Q".
"This new learning amazes me, Sir Bedivere. Explain to me again how sheep's bladders may be employed to prevent earthquakes"
|
|
|
|
|
Elizabeth Regina, it's on all the UK currency, postage stamps etc. but it might not be obvious to a non-uk person.
|
|
|
|
|
Actually it should be EIIR. No wonder I couldn't solve it.
|
|
|
|
|
Slogans aren't solutions.
|
|
|
|
|
Sorry, yes, a tad parochial of me (we Brits tend to specialise in that).
It's a standard substitution in UK crosswords so I just used it without thinking. Sometimes I forgot that our queen is no longer the queen of the known Universe.
Slogans aren't solutions.
|
|
|
|
|
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging.
What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes.
Meanwhile there are some issue on the production / release branch, which have been independently fixed.
But some serious problem remains and I was asked to fix the prod branch.
It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later....
How do you cope / handle such situation?
Are we doing something wrong?
|
|
|
|
|
I'd say that it was a bad idea to push changes directly onto the release branch if someone else was working on related code. That's going to cause merge conflicts. It happens but you should try to avoid it. You can use git merge --strategy-option theirs to resolve the conflicts when you merge prioritizing any changes on the release branch, or git merge --strategy-option ours to prioritize your (the dev) branch.
If some of your fixes rely on the same code that was changed in the release branch though you might have issues and should consult with the team about overwriting the release changes with yours (assuming your fixes are equivalent to the release fixes). My 2 cents.
EDIT: Also, is this an open-source project? I find it odd they would force only your code to be validated/checked while they're pushing changes directly to the release branch with no regards to other branches.
|
|
|
|
|
Nah it's for work.
I had a long list of bug and feature to work on.
Meanwhile the release / pilot product had issue (hey those were on Jira) and some independent fix were applied on that production build.
For the simple reason they wouldn't want to deploy (untested / unvalidated) feature / bug fixes I was working on.
So you have the silly version of that:
Code has bug X, fix it in dev branch. But product has bug X too! Fix it in release branch (separately) since we don't want new feature (i.e. whole of dev branch) in prod branch.
Makes only so far as I was also working on new and/or breaking feature (including database schema change)
The whole process seems largely clunky to me.. Not sure ow to fix it though...
|
|
|
|
|
For a case like this, we would fix X in the production branch and then merge back to dev.
If X fix is so large that it could put production stability at risk, then create a production.X branch to do the work. merge production.X -> production -> dev.
Once you create the next stable release candidate:
production.X (if necessary) -> production -> candidate -> dev
or for a new feature in candidate that is not in production
candidate -> dev
|
|
|
|
|
|
Don't try to do it from your desk. Talk to people.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|