- Tortoisehg workbench merging taking long time how to#
- Tortoisehg workbench merging taking long time code#
- Tortoisehg workbench merging taking long time windows#
But when I go to unshelve, the operation fails. I had dutifully renamed the file using the special Mercurial operation for it in the context menu, so that it can track the changes correctly.
Tortoisehg workbench merging taking long time code#
Since Delphi requires the unit name declared at the top of the unit to match the filename, this means both changing the code and renaming a file. You see, one of the changes I had made involved renaming one of the units in the project. Git is even worse about these things!) I merge the commits, push my changes, and everything is peachy… right up until I go to unshelve my code and get back to work. So I dutifully stick my uncommitted changes on a shelf named “Mercurial is stupid”, which is the one I use for performing this stupid operation that would not be necessary if DVCS wasn’t fundamentally broken.
Nothing I haven’t done dozens of times before.
Tortoisehg workbench merging taking long time how to#
Any experienced DVCS victim can tell you how to take care of that scenario: just shelve your uncommitted changes before you merge. For some moronic reason, if I try to merge, HG will commit those to my local repo too, and then you’re stuck in a huge painful mess of trying to back your changes out, because HG doesn’t know how to merge two commits and only merge that. This sounds like a pointless semantic difference, and there really shouldn’t be any difference at all, except… I was in the middle of working on another issue, so I have uncommitted changes. Except Mercurial doesn’t know of any such thing as “merge commits.” No, it knows how to “merge with local”, meaning it pulls the new commits on the new branch into your local working copy and then commits the changes from your local working copy into the local repository. That’s not a problem, right? Just merge the commits. Except that I have a commit in my local repo, and even though they’re on the same branch, Mercurial freaks out and turns it into a new branch of the branch I’m on. So you pull the changes to your local repo, and then you have to “update” to that revision, even though that really should be a no-brainer. For a couple years now, TortoiseSVN has even been able to automate that workflow for you. In a sane VCS like SVN, this doesn’t matter all that much you just grab the update, SVN integrates everything seamlessly unless there’s a merge conflict–which is rare in a well-managed project regardless of which VCS you’re using–and then you commit. This turned out not to be the best of times, because someone had checked in something since the last time I pulled changes. First you commit it to your local repository, then you push your local repository changes to the central repo. So checking in code is a two-step process as a best-case scenario.
And yet, we use Mercurial at work, and it likes to pretend we need all the stuff that enormous teams need.
Tortoisehg workbench merging taking long time windows#
(I heard it said once that if every developer on the Windows team were to only ever break the build once per year, they would literally never have a working build if everyone checked into the same repo.) But we don’t have a team anywhere near that huge. It was designed for much larger, more complicated projects than most people will ever work on, stuff like operating systems, that are so huge that distributed repositories are a necessity. In SVN, this is incredibly simple: select the changes to check in, write a commit message, click OK, and you’re good. The “just fix it” part is the same, but then I went to check in my changes. Well, yeah, that’s how it would go if you were using a sane version control system like SVN. No big deal, right? Just fix it, check in your changes, and get back to work. Yesterday at work, I was halfway done with an issue when a very minor but very urgent issue came up: I had checked in something that was breaking the build. But it keeps finding new and innovative ways to suck. You’d think that I’d be used to its quirks and glitches, all the little things it manages to somehow not get right, by now. It’s nothing particularly new to me I’ve been working with it ever since SDL, a major open-source graphics library that I’ve been using and contributing to for a long time now, changed over to a HG repository several years ago.
0 kommentar(er)
