David Schwartz

Someone earlier asked about the flow we follow. Here's the current iteration. ------------------------------------------------------------------------------------------------------------ Start day Open git bash from I: or V: > git checkout master ...if not in master > git pull ...resolve conflicts > cd /i … or /v, I.e. CD to the other drive > git checkout master ...if not in master > git pull ...resolve conflicts Create a new branch – only create a ticket branch from master > git checkout master > git pull > git checkout -b <ticket-branch-name> Interrupt current work to change context > git commit [-m"<comment>"] ...changed files as work-in-progress > git checkout master > git pull … should be current Continuing work in existing branch > git checkout <ticket-branch-name> > git pull origin master ...resolve conflicts Commit branch changes (while in branch) > git add file1 [file2] […] > git commit -m"<commit message>" Commit branch to the repository > git checkout <ticket-branch-name> ...switch to the ticket branch > git pull origin master ...resolve conflicts > git checkout master ...switch to master > git pull ...pull changes from repo, resolve conflicts > git merge <ticket-branch-name> ...merge the branch into the local master > git push origin master ...merge local master into remote master > git branch –D <ticket-branch-name> ...delete the branch ------------------------------------------------------------------------------------------------------------ Would it make sense to set these up as macros that can be triggered by buttons in a tab that's got a memo set up as a command prompt window? Or have them done automatically in certain situations? For example, I have something I'm fiddling with that lets me manage things I'm working with for a given ticket. It records contextual info (project name, folder, files, notes, etc) for a that ticket. So if I were to create a new ticket in this tool to respond to a ticket I got in my ticketing system, it could set up a new git branch and enter it. And if I switched to work on another ticket, it could do the necessary saving and context switching in git. If I close the app, it could prompt me to do a commit of my current work and switch back to master, or just leave things as-is.

Personally speaking, I'd rather not have to deal with things in other folders than what I want to be working in. I can see situations where that kind of behavior (updating files everywhere) would be helpful. But in this case, it's not. It slows things down, it creates a distraction, and unfortunately it leads to conflicts that you have to deal with before you can continue doing your own work. If someone else is misusing a tool, why should you be impacted by it?

I've never figured out why they change so often either. And with or without them, in the rare cases where I select None for an alignment, it usually just leave the object in the same place and dimensions. I don't care if it reverts back to something else or not.

What are they used for? I could never tell why they even started showing up.

I'm not clear enough in what git is doing to explain this much better, but here's what I think is happening... You make some changes to code in folders A, B, and C, while I'm working in P, Q, and R. I set up a branch and do a pull from master. It updates the files in my local A, B, and C folders, because you made changes to them. I'm not touching them. I make some changes to P then go home. In the morning I come in and do a git pull and get a bunch of stuff from A and C that you've been working on today. I finish up work on P, commit it, try to push it, and then I get a warning from git saying it cannot push because of a conflict in some files in A. So I have to stop what I'm doing and figure out what in the hell is the problem with files in a unit I had nothing to do with that's preventing me from pushing my changes in P into master. I've got customer service people pestering me to get these changes pushed into production ASAP, and you're at lunch, and whatever I do to proceed is going to screw up your work. This is what we're running into. I'm probably not even explaining it fully accurately, and it probably suggests we're doing something wrong. But all that sticks in my mind is that this issue is arising because of timing dependencies between when you pushed some stuff to git, when it got copied down to my local repo, when you then made some updates, caused a conflict yourself, and that got pulled to my local repo before you resolved it. So that left it to ME to resolve locally. In these situations (which have come up at least a dozen times in the past couple of weeks), I can neither pull nor push anything until I "resolve" the issues in YOUR code on MY local repo. I notify my boss who goes haywire, immediately sets up an emergency video conf call with 8 people, and we all spend 45 minutes trying to fix this mess. And the bottom-line is that people point their fingers at ME for screwing something up. All I know is, I did not touch any of the files in either A, B, or C, and everybody gets their knickers in a wad when I say that because it makes me sound defensive and trying to shift the blame. From MY perspective, I just keep asking, "Why in the world can't I just work on the files in folders assigned to me and not have to deal with all these other folders getting their files updated and having issues when they have nothing to do with anything I'm working on?" I'm still relatively new here, and the guy who has been single-handedly maintaining this code for the past several years left, but he made it all look like a walk in the park. We are now tripping over ourselves every other day with weird stuff like this that everybody says should not be happening. I'm pretty sure we're doing something wrong in how we're interacting with git. But we've been given three different scripts to follow now, and they all seem to result in the same problems coming up, but at different times and contexts.

Nope. I think if you understood the problem better, how our solution is organized, and the environment more, you wouldn't say that. Some of our other facilities take that approach, and our effective down-time is an order of magnitude lower than theirs, if not more.

I did. You don't seem to like that idea. Why? They're all independent. Actually, what I have in mind more specifically is moving towards a folder structure more like this: <client>/<account>/<type> Where each <client> would have their own repo. I'm guessing we have maybe 75 active clients at the moment. Some of them only have one or two accounts, but some have 50. The accounts a given client manages sort of cross-pollinate each other because there's a lot of stuff the client sets up that's common across several accounts. Otherwise, there's virtually nothing shared between the clients other than structural stuff (eg., they all use the same types of files, etc.) The <type> relates to the thing getting printed, like a Statement, Letter, Invoice, Flyer, etc. Right now, everything is flat: ABC035_stmt_imp would be ABC/035/stmt in this new scheme. We have around 850 of these folders (like ABC035_stmt_imp) right now, and there's on repo that manages all of them. In my mind, having a single repo per client makes a lot more sense. At the moment, management is totally opposed to any changes at all, but the last man standing who knows how all of this works left recently and all of the plates he has been juggling for so long are starting to come crashing down around us. This is all process-oriented stuff that has very little to do with Delphi other than that's what the import apps are written in.

I think I forgot to save a reply I made to this ... unfortunately, we don't have either DevExpress or TMS here, and I know they've both got components that would be handy. I got something working based on a TScrollBox, which is surprising to me because I think it's the first time I've ever gotten one to work right! The 3rd item reflects a problem I had that is probably due to rendering the subpanels directly on the panel controlled by the splitter. I changed the implementation so I have a TObjectList<TPanel> to hold the subpanels. Actually, these are not TPanels but a helper class for them to provide access to the objects added to the panels. Again, I find this a much simpler approach than using TFrames. I also added a helper class to the scrollbox that adds a method to display the list in the scrollbox' display area. I realized it's probably easier to add a way to move items up and down in the display if they're in a list and I can move them relative to each other in the list versus on a panel or something, where they can get rearranged due to logic of the thing they're sitting on. With the list, I can rearrange elements, then just tell the scrollbox to refresh itself from the list. It works great. I implemented the scroll wheel with an increment = the height of each subpanel (they're all the same). You can adjust the splitter up and down, and it smoothly shows more or less of each row with no flicker at all. One little trick I did was put the mouseEnter/Exit and double-click event hooks in the scrollbox even though it doesn't use or need them. But when I tell the scrollbox method to set or refresh the list, it goes through each item and copies these hooks from itself to each of the panels, so I don't have to tell the list or the panels this information. They're informed by their host. (The panels have the same hooks as the host, so it's a simple matter for the host to copy them when it attaches them to its back, so to speak.) The only quirk in this whole approach was that because I used some helper classes, I couldn't add any data members anywhere. So there's no way to inject the list itself anywhere. (I'd prefer to add it to the scrollbox helper, actually, but I can't.) Because the scrollbox is a visual control on the form, creating a child class from it can pose challenges with the form (in my experience). So I resorted to setting the list var up as a global var in the implementation section. This just seems so much simpler than other approaches I could think of at the time. Luckily, I've only got one, and its lifetime is equal to the life of the form. So ... meh. It works. 🙂

That's also very nice and organic. I've set something up using a kind of "drill-down" approach, and I'm not sure I like that it hides the overall process. I like that this approach also resembles a progress bar.

no, there's ONE repo -- it handles EVERYTHING in the whole virtual I: drive. It's certainly an unusual approach based on my experience. I'd set up a repo in each folder that only captures changes for that project, because they're independent of all others. Why mash them all together? In the bigger picture, most of the work is the same: changing things like branding (logos, colors, etc.); changing the monthly message on statements; address / phone# changes; and verbiage for things that changes to local laws require be adjusted. (We support a lot of collection agencies, for example, and we are constantly updating those little paragraphs on the back of their notices that specify your rights and whatnot depending on what state you're residing in.) Virtually none of it is programming.

I think you're thinking we spend months working on stuff. Our work is very quick turnaround -- sometimes less than an hour. We can be faced with git conflicts several times a day. I've spent more time "resolving" conflicts on code I had no hand in than it took me to do my ticket. It's a serious distraction.

Boy, this terminology is making mincemeat of the discussion.... We have 850+ project folders that are used to build standalone EXEs for parsing unique input data formats and turning them into something similar to PDFs. The original developers could just as easily have chosen to make them DLLs since they all have the exact same "footprint". They're all for "clients" of one kind or another. All 850+ of them. Our routine work involves very little with Delphi, however. I may need to change a logo, or a return / remit address, or a monthly greeting on a statement. There's virtually no programming involved, although they call us "programmers". I suspect they see the value of having Delphi experts on hand is exemplified by a request I got today: we have a data file that aborts; after looking closely at the data, I can't find anything unusual. Please spend some time stepping through the code and let us know what the problem is." Such fun. Back to git ... personally speaking, I think the repos should be set up on a per-project / import EXE / folder basis. That way there would be no interference with other projects when it comes to managing the stuff we do on a day-to-day basis.

I've never really seen any discussions about this kind of a workflow in git, and it's very different from anything I've been around before. A couple of the others at work find it very unusual as well. But if it's familiar to you, then you can probably help. This is exactly what we're running into. Not just me, but others. I don't understand what's meant by "use pull requests to merge into Master". I see people on GitHub say that if someone wants to make changes, ask for a pull request. Anybody can download files and change them. I don't get why you ask for a pull request when you basically want to "push" stuff up to the repo. I did do something in master after making some changes in a branch, and effed everything up. I think I collapsed origin onto master with a "git pull origin master" from master when I thought I was in a branch. I think in pictures, and I've never seen any good illustrations about what goes on when you're working in git. Everything is text. I just haven't had that "aha!" moment yet where I can visualize what's going on in my head. It seems to be like you're interviewing yourself. You start out in one chair, do some stuff, switch seats, talk for a while, switch to the other seat and process what you said earlier, then say some stuff, go back to the other seat and process that, and so on. Nobody likes that we do work in one folder and git is constantly shuffling around files in other folders, and throwing up conflicts because someone else is in the middle of doing some work that has nothing to do with what you're working on. Branches only seem to make things worse. When I do a branch, I only want to focus on a given folder. What happens is we pull along a ton of other unrelated crap, and if someone happens to push an update to any of it while we're working, it can cause a conflict with stuff we didn't touch. I'm trying to figure out if we could reorganize things so that each client (reseller) has their own repo and folders beneath them for each of their customers, rather than at the I:\ root. So we'd go into a folder and then create a ticket there and it would only affect that repo. I don't know what would happen if we switch to another folder / repo and work on a ticket there. Honestly, having a file system with no history and a history manager that fiddles with the file system is quite confusing to me because it leaves it up to you to remember to tell the history manager that you moved somewhere else in the file system or the history manager gets totally confused.

This is a nice idea for a summary dashboard, for sure. But in this case, I'm looking for something that only applies to individual tickets. It's a tool to help both show the person what's needed as well as signify what's done and what's left, sort of like a check-list.

I'm looking for some help with our particular usage model, not individual commands. It seems it has been working fine with one guy and a part-time assistant when they could coordinate things, but with three people now working in parallel, it's got us all tied in knots. I suspect most folks here are mainly using git alone. This is a small but growing virtual team of devs we've got and most of them are familiar with TFS. Git has them scratching their heads. And our production schedule / model is not what something like gitflow was designed for. I'm wondering if anybody here knows of any public discussion groups (of whatever kind) that focus on this kind of topic?

Yes, that's our thinking exactly. Which is why I'm looking for some input from others about this. I'm not very fluent with git myself; mostly it confuses me.

Ok, well, I posted the issue in a separate thread if anybody wants to look at it. It's a "real world" scenario, not something over-simplified as a class exercise. Maybe I provided too much info, but I tend to try explaining all relevant aspects rather than just one piece and wait for people to ask about other sides of the issue.

I'd have a list of unprocessed requests that feed the sending agent. If the agent dies, the list sticks around. The challenging part is the potentially diverse time dynamics involved. You could use a multi-threaded design to feed hundreds of messages per minute to an API for a commercial SMTP service, like SendGrid, or just use a simple loop that sleeps for sending to a shared hosting account that limits you to 100 per hour or 500 per day. If you try sending through your ISP, like your cable company, you risk getting shut down if you exceed certain limits that they don't like to disclose. Sending stuff through an SMTP relay is, on the surface, one of the simplest things you can do. But the practical implications of it -- being that it's probably the single most widely abused resource in the entire internet world -- are that your sending agent needs to be highly resilient and pay close attention to the error codes it's getting. It needs to be programmed like that song about The Gambler -- know when to hold 'em, know when to fold 'em, know when to walk away, know when to run... You do not want your SMTP host to shut you down, especially when it's your ISP or web host b/c they could just as easily shut down your entire frigging account! That's a really big benefit of using a 3rd-party SMTP host -- the worst they'll do is shut of your SMTP account. And it's easy to find another one. (Better yet, set up several before you even get started.)

in this case, we know its hierarchical. But there are probably dozens of ways to display and navigate a hierarchy. 🙂 * vertical (trees), horizontal (org charts), or free-form (mind-maps) * bubbles, boxes, graphics, text, both * lines or not * static or dynamically expandable/collapsible * background colors / graphics / highlights * editable (inline, popup, separate form) or not (configurable vs. hard-coded) For what I described, I'm curious what comes to mind most naturally. I rather doubt something like a mind-map would flash up immediately. We don't have either DevExpress or TMS, unfortunately. They've got some stuff that would be great for what I'm building here.

I'm kind of limited on vertical space. What about a combo-box with the main items, and that displays a different list of check-boxes below. Maybe when you click the down-arrow on the combo, it shows the list of radio items. Pick one and it shows that item in the combo as the one you're working on and the check-boxes below. Or start with the radio buttons; pick one and it disappears but shows the selected item at the top with its related check-boxes below. Kind of a "drill-down" effect. Do you think you would you find something along this line easy to use as well as compact? Thoughts?

Ahh, this is what I was trying to avoid -- storage details. 🙂 Forget what's under the hood. What does it LOOK LIKE? A treelist is sort of my automatic go-to choice for the UI. What I'm looking for is ... something different. I'm curious what others might come up with.

There's clearly a hierarchy. I'm mostly curious how folks would handle it, which is why I didn't bring it up. (My mind seems to be locked-in on a tree-view, so I'm looking for some other ideas.) I'm guessing you'd start with what I showed (the main tasks) and then when one of those items is clicked you'd show this in a popup? Then once all of the required sub-steps is complete then the parent would show complete? I had not thought of this. Thanks!

I've had very poor luck getting general questions like this answered on SO. They usually get downvoted and then locked. I'm thinking more like git-specific forums that help folks understand git better. It's an open-source project; aside from discussion boards about specific tools, all I can think of is the tool vendors. This is a forum about Delphi. It's not run by the vendor, but by people who are engaged with this product. Are there any similar forums on git?

No matter what solution can be put forth, you can always come up with a scenario that invalidates it. That only leaves you stuck where you are with very little interest in anything. It's the ultimate demotivator. Apple started out as a hobby. Only instead of listening to Woz' arguments about why nobody would by even 10 of his 6502-based home-brew computer boards, Jobs said, "Let's build 100 of them!" I'm not interested in all the reasons you can find not to embrace anything at all. I have stuff stored in my garage that by all accounts should be totally unreadable today. You know what? Everything I've tried to read that wasn't so brittle that it shattered ... worked fine. It'll outlive me. But according to your view of the world, none of it would be here because all the "experts" say it would not survive this long. These "experts" base their opinions on statistical data based on accelerated environmental testing with known limitations. Once I had a contract to help some guys show how so-called commercial off-the-shelf (COTS) hardware fared against similar mil-spec equipment that cost 3 orders of magnitude more for the same (or worse) functionality. The guys doing the testing put both sets of hardware through the most severe shake-and-bake testing they had, and the fully-ruggedized mil-spec hardware had a 50% greater failure rate than the COTS hardware. So I don't put a lot of stock in what statisticians say when it comes to the longevity of electronic components. The stuff tends to fail early within 90 days; or it starts dying at around it's projected MTBF. But fully half of it will last 3-5x it's rated MTBF. That's statistics for you. Of course, you can always pull out that Joker card and argue that no matter what the MTBF is, there's always a scenario they didn't account for that will kill it off immediately. And don't forget that a meteor could fall out of the sky and kill you right where you are ... any time of the day or night, wherever you are on the planet. Even if you're driving down the road, flying, or whatever you're doing. You could also spontaneously combust.

You obviously haven't had cloud services you subscribed to that were supposedly "secure" and said to be on solid financial footing, go belly up one night. I have. Nor have you had servers you were paying to be "secured" get raided by law enforcement just because they were co-located near someone who they were investigating for criminal activity and so they were able to get search warrants for every machine inside the "secured" area -- as if all of that equipment was owned and/or operated by the crooks they were after. They seized ALL of the equipment in that "secured" area and hauled it all away. For weeks. I have. But burglars ... they don't know much about tech. They go after TVs, stereos, microwaves, and stuff that looks familiar to them. Things they see at Best Buy with big price tags on them. If you have specific valuables in the house, and they know they're there, they'll head for them. If you're gone for a while and they can spend the time to toss your entire place, then a safe isn't going to be very "safe". But things that look like cable boxes and modems that can be bought at Goodwill for $5 aren't worth their time. They'll steal a Bluetooth speaker worth $50 and not even think twice about your $10,000 Marantz 6-tube stereo amp and FM receiver that look like something their grandparents used. If you had one of those big old computer tape drives in a rack that was spinning and had lots of blinking lights, they'd take that before much else. Sometimes "security" is more about "playing the odds" than building a better Cheyenne Mountain.