|
Be great in a bar. You could use it to see who might be interested in a little....chat. Save time, embarrassment, and expense.
|
|
|
|
|
Fillet of pork with chanterelle sauce (one pound of chanterelles!) with a bottle of Chablis and another bottle of Amarone.
My wife should have her birthday more often. 
|
|
|
|
|
Roasted chicken with mushroom in a cream sauce with green peas with a glass of water (at work)!
I'd skip the Amarone, and use a Meursault instead (but that's just me).
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: Roasted chicken with mushroom in a cream sauce
 I can do without the green peas though, the rest of that sentence sounds mega-delicious. 
|
|
|
|
|
Just a matter of taste.
There are some really great Bourgognes out there, but I have never tried a Meursault yet.
The place that's often overrated is Bordeaux.
My current favourite for affordable wines is Valdepeñas.
|
|
|
|
|
Jörgen Andersson wrote:
My father in law does the marinade and I do the grilling. Always comes out nice.
|
|
|
|
|
Your fil has the tougher job. 
Grill season hasn't really started yet here, you know seasons and stuff at the 58th latitude. Spring is basically starting just now.
|
|
|
|
|
We've nearly finished out penny buns (porcini), and it's months and months until we can go out looking for more 
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
2006 was an amazing year for Porcini, we picked the whole trunk of the car full. So ok it wasn't the biggest car, but still last for quite a while
And my wife is of the kind that can make a meal out of just mushrooms and butter!
|
|
|
|
|
With porcini can be dry and grinded into powder, useful for general purpose savory "umami" seasoning. Think : chicken salt
|
|
|
|
|
Dried porcini is great with sauces, but please don't grind them. There's a point in noticing they are there.
|
|
|
|
|
I have to agree, although I've never tried what was suggested, so may be wrong.
I have to admit that I love the smell of the house when the missus is drying them, though.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I'm only allowed to eat them rarely, because my wife loves my* mushrooms on toast for breakfast.
* Not really "mine", as such, but bluddy yummy!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Quote: My wife should have her birthday more often
Do you really think she wants to age faster? Find another reason to indulge! 
Get me coffee and no one gets hurt!
|
|
|
|
|
Damn right you are, lets just celebrate more often.
|
|
|
|
|
Quote: lets just celebrate more often
Yes! Who needs a reason?
Get me coffee and no one gets hurt!
|
|
|
|
|
Made me rememver an old Mad magazine "article'.
Reasons to believe you're an alcoholic: Celebrating groundhog day.
|
|
|
|
|
Just celebrate every day that's not her birthday.
There are two types of people in this world: those that pronounce GIF with a soft G, and those who do not deserve to speak words, ever.
|
|
|
|
|
You are indeed a very wise man. 
|
|
|
|
|
Yes, like Alice in Wonderland: Celebrate her unbirthdays! 
Get me coffee and no one gets hurt!
|
|
|
|
|
In continuation with my last post - Integration hell[^]
I agree with you all that more than anything it's a workflow issue and now finally I have taken out time to fix the workflow issue once and for all.
I am going through various documentation about SVN workflow best practices and a bit confused what should be the ideal structure.
First I will explain our development environment -
5 developers working from one location and 4 developers working from offshore location. Apart from this 2 product managers may need to push small css changes every now and then like colour change etc
Now my questions are:
1. Should I really consider distributed version control like GIT or stick to SVN as other team members are familiar with SVN more than GIT. So there will be learning curve for all if we switch to GIT also server is all set up for SVN so bit of cost issue as well.
But if it really adds value (like merging is way more easy in GIT) then I am sure I can try to convince to move to distributed version control.
2. If I stick to SVN what is the recommended way to structure Trunk, Branch and Tag?
Thanks for all your help.
|
|
|
|
|
We have now the same issues somehow. It is getting clearer, that Git wins because it has more advantages because branching and merging is better. And rebasing cleans up with messie trees.
Our tree will be more like different developments trees (sprints) and a master tree, which will get tags. After some discussion we are convinced that branching is temporary because every branch gets (somehow) merged in the master.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Where I work, we used a versioning tool similar to SVN and then we transitioned to GIT mainly due to reliability issues in the tool we used but also somewhat due to merging issues. The learning curve for most of us was steep and there was a lot of training given. For the most part, it seems that we are getting better at using GIT. One of the big advantages is the submodule functionality so that multiple projects can reuse one submodule which may be at different branches at different times. So that allows us to consume submodule changes only when we want to.
Things that GIT doesn't do too well:
1. History is important to us and the GIT merge feature basically rewrites history. So we decided to use only use rebase.
2. We have also had problems when rebasing on top of large number of changes. GIT did not merge/rebase correctly and it didn't give any indication that something went wrong.
3. GIT does not handle binary files very well - uses more space
4. It often happens that 2 developers try to rebase and push their changes at the same time and when pushing, they get an error that their branch is out of date and so they have to do that whole process again. After doing that a few times, I have abandoned the practice to make sure that everything still compiles before pushing. This has resulted in some build instability (not only due to me  )
5. It is not easy to find what version of a given file is actually included in a given build without first checking out to the SHA-1 of that build. This is more of an annoyance because you may need to check something while you are in the middle of modifying files. One of my pet peeves with GIT is that you can't tell from two SHA-1's of a file, which is the earlier version.
Having said all that, I would tend to stick with SVN for your situation but that may just be that I'm old school
With regards to the Trunk, Branch and Tag, I would only use a separate branch if there would be a lot of changes made before a new release is ready for the production server. We used a 'development' tag to indicate that a particular file was locally tested and deemed fit for production. This tag is then used to build a stable version of code. Changes could be made to the file and checked in but the development label would not be pulled up until local testing (whatever that entails) has been completed.
I hope this long-winded response helps. All the best with the decisions you need to make.
|
|
|
|
|
Give me good old PVCS, lock those files to make sure no one else can screw around in where you are working.
Half serious, but then I don't like change.
If you go to Git use either SourceTree or GitKraken, the GitHub windows app hides way to much of the functionality.
|
|
|
|
|
I'll never go back to file locking, but I do admit that the current development group I work with has no idea how to do a merge operation.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
