The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Totally a coincidence that I put on some Karsh Kale last week. I had not listened to it in quite a while. It's pretty awesome though
Karsh Kale, producer, composer, and DJ, creates electronica (mostly dance-ish) with (classical) Asian, mostly Indian, elements.
With such awesomeness what else could I do than listen again and again and make this my song of the week?
I'm trying to work out a proper structure here for git repos and it is tres fun! We have two products, one is the container and the other the first containee, though there will probably be more. That is relatively easy and this then gets deployed to clients who are free [for a given value of free] to change some or all parts.
So we have a repo for each product and a repo for each client. The built components will then be put over to the client repos for deployment and other shenanigans.
Would anyone care to tell me how this is going to go wahoonie shaped, or do I have to wait and find out for myself?
Having used Git for a while, I can say with almost absolute certainty that that process will go all wahoonie shaped at the worst possible moment. That just seems to be the nature of Git. If it actually works, that will be a major WTF.
Git works, but it has some.... quirks.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
That just confirms my ideas for a single repo. My real problem is that we will be releasing to client repos, If you imagine the flow is build the products in their own areas, deploy them to a client repo, that gets mods on top, which then gets deployed to their hosted servers.
It's the going from internal to client repos that is getting me, I can't see the flow yet.
The page is about branching strategies within a single repo - you typically do this much more than with SVN or TFS, the merge support is much better so don't let it put you off.
Mode this through the fact I more or less do JS work not (I've stopped scrubbing myself clean every night, like every other language you can write it well or badly. Trouble is with JS there are a lot of people writing it badly).
The flow I've seen is to have the client pull & build it's dependencies - as long as the account on the build machine has access to all repos it should be OK. In JS land this is a doddle - the package.json allows you to set up dependencies and the node package manager can be told to install these. I dare say there is a way to do something similar via nuget (not sure though). That's assuming you're willing to allow the extra time to build the products with the time instead of distributing binaries.
It's a lot more complinated than letting clients pull or build what they want. The best I can describe things is that we build the framework, the clients add components on top and that is then what they use. The trouble comes in that we will not be giving them our core code, it is proprietary, and we will be managing their servers; think SaaS / Hosting model.
then gets deployed to clients who are free [for a given value of free] to change some or all parts.
Given what I've experienced, you are in for a lot of pain as soon as the first time you need to change something in the same file that the client has changed. First, they try to push a change they made, not realizing their repo is behind. They get an ugly error message. Then they try to do a pull, which probably asks them to stash their changes first. That's the first real WTF. How do you do that? If they figure that out, the next WTF is how to restore the stash. Then the third WTF is, how do I interpret this archaic <==== and >========= to understand which are my changes that I want to keep, which are not. If they get that far, then they can commit their changes and YOU have to do a pull to sync up.
It sounds like 1) you are and your clients are in for a world of pain and 2) source control is probably not the right solution to begin with. Unless you can 100% isolate allowed client changes from the repos you/they control, so in the end, you do not care one whit whether they make changes or not, and they don't have to worry about their changes being stepped on when you update the container and client-specific but not client-modifiable files.
 I would put together a bunch of scenarios you can think of and try it out, which some simple text files to simulate everything. [/edit]
My employment woes I have mentioned before...but, I went for an interview yesterday in area not too far from home. The job title was odd, I was expecting a can you solder this test. Instead I was greeted with a company that was right up my street! I got on with the Boss and the HR person very well, seemed to get on with the others I met. It all went well(?) I show them some of the stuff I worked on in the past which got the responce of 'Oooh, you can do that too...'. Just had a call from the agent that they are having a company meeting as the Boss & the HR felt I was the right fit to see what else everyone else thought... This looks hopeful! Please.