|
I thought hare spray was when you fired bunnies out of those T-shirt guns at the stadium!
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
Is raising rabbits for meat a hare-raising experience?
|
|
|
|
|
We use a 3rd party web API that supplies a WSDL downloaded and set as a web reference in our .NET app, which is, itself, an internal web API compiled to a DLL. Like most good service providers, they have both sandbox and production environments, and the WSDL for each are different.
Our Git repo maintains at least two branches, dev and master, which naturally map to the 3rd party's sandbox and production.
We want these included in the Git repo so that the proper web reference is checked out with the associated branch. But this causes Git to whine about differences in the web reference files when we merge new changes from dev into master.
Is there a simple solution to this?
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Perhaps like so: put both WSDLs in both branches prod/wsdl test/wsdl. Select WSDL by build configuration?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Wouldn't that require dev and master code to use different web references, and shift the problem to the code files?
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Can't you just resolve the merge conflict using "yours\theirs"?
|
|
|
|
|
I don't know what the "yours/theirs" thing is. Can you explain?
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Most git clients allow you to resolve conflicts by either replacing the remote copy with your local one (resolve using yours) or to ignore your local copy and use the remote copy (resolve using theirs).
|
|
|
|
|
I'll look into this. I use the Git bash shell, and when the Git configuration references to WinMerge don't disappear, WinMerge.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: they have both sandbox and production environments, and the WSDL for each are different.
Sounds like a poor design. The WSDL should be the same for both; you should just need to change the endpoint in the config file to switch between environments.
As it stands, you've got two completely different services. There's no guarantee that code written against one version will work against the other.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
It may be poor design, I don't know. It's Salesforce, and I've been impressed by the design behind most of their stuff. It's not perfect, but it's very clever.
The differences are only in the user-customized pieces, and in the endpoint URL embedded in the WSDL.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
|
You could use a post-checkout hook to make sure the appropriate DLL based on the branch name is copied in from an external location.
I've never tried it but can't see why it wouldn't work?
|
|
|
|
|
Thanks, I'm still fairly new to Git, and didn't know about post-checkout hooks. This is promising!
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
One solution might be a submodule.
Git submodules are versioned, so a branch can point at a specific version of the submodule (or, better yet, a specific branch or tag).
You could have your wsdl code in a submodule which you reference from the main repo. The dev branch references the submodule commit with the dev wsdl and the prod branch references the submodule commit with the live wsdl. When merging from dev into master, you could ignore the submodule (ie, use the "take mine" approach mentioned elsewhere in this thread). The advantage is that it's really easy to see which wsdl you're using, especially if you use branches, because a "git branch" in the submodule folder could show you, for instance:
* production
development
(meaning you have the production branch of the wsdl) -- in this way, you don't have to manually check the contents of the file, just that you're pointing at the correct branch.
|
|
|
|
|
|
I ran across a job advert (well TBH the advert ran across me [but that is beside the point]) for a freshly founded cloud based service where they are doing development in Java.
Does backend-Java strike you as fresh? I would say GoLang, C++, .Net and Scala are fresher but what is your opinion/impression?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Their former project was COBOL based.
BTW, C++ though heavily revamped, it is not exactly 'fresh'.
|
|
|
|
|
A language that can get as close to the hardware as C and as high level as ... well, C++, will never become stale. JavaScriptors avert your eyes.
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.
|
|
|
|
|
So, in your opinion, the C language is 'fresh', isn't it ?
|
|
|
|
|
And always will be.
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.
|
|
|
|
|
Amen. 
|
|
|
|
|
I did not mean the technical freshness of the language. I meant the use of the language [in a web backend].
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
megaadam wrote: Does backend-Java strike you as fresh?
No, it smells. Quite badly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
