50 Versions of Shed Control Wars
-
Are you sure about this? I can understand some niche
format having no mergetool, but merging changes in things as common as images and Excel files should definitely be doable....
You've clearly never done any real image editing.Worker A edits an image to slim down the star's arm by nudging the edges of her arm to the left.
Worker B edits the image to slim down the star's torso by nudging the edges to the right.The merged result is that her arm is now unattached to her body. Oops.
As for other formats:
Microsoft's legacy Office formats and OOXML both contain ridiculous binary blobs where only Microsoft's codebase knows how they work.
Thus only MS could write a merging algorithm, and they haven't (otherwise Sharepoint could do it). It might be effectively impossible to do or merely very hard. Who knows.However, ODF is a ZIP containing one or more XML files. Merging it is entirely possible, and is already being done.
- All you need is to add automated pre-commit/post-checkout steps and an XML diff & merge tool. All decent VCS support these.
So VCS of spreadsheets and other office documents are in fact a problem that open source has solved.
Just use the genuine ISO standard for office documents.
-
The merged result is that her arm is now unattached to her body. Oops.
You can have the same result in code though; person A edits a source file to rename functionfoo()and person B edits the same or a different source file and adds a call tofoo()in a different location. Textual merge works fine; compile doesn't. And of course you can have semantic problems where the compile works but it doesn't run correctly.Thus only MS could write a merging algorithm, and they haven't (otherwise Sharepoint could do it).
Word has supported diffing and merging two doc files for a while now. It... isn't great, but it kinda works.
-
if you only call the property once, it won't have side-effects.
So you're fault.
-
Microsoft's legacy Office formats and OOXML both contain ridiculous binary blobs where only Microsoft's codebase knows how they work.
Point of order (and pendantry): the OOXML group of formats are actually reasonably well behaved ZIP files of XML. The main non-text thing you'll find inside are usually images, which tend to be in little-known formats like JPEG, PNG, etc. (depending on what pictures you used). I can't say that all OOXML documents are like this, but the substantial selection I've examined during the writing of this post (documents, spreadsheets and presentations) all followed the pattern. I'm not saying they can't contain blobs, but real-world ones (a selection from my previous projects
) only do so for images, and that's reasonable…In fact, this has been super-useful to me in the past, as it has let me recover a broken document by unzipping it and reading the parts that mattered (which weren't broken) so that I could merge them into another version (which wasn't broken). Totally saved my bacon.
-
:fail.xlsx:
I do not disagree with this at all.
@dkf said:That's why history rewriting is a terrible thing. I know it has use-cases, but it's such a catastrophe in the hands of an authorized ass-hat…
Nor this. That's why I turned it off the moment that happened. I am now the ONLY one who can rewrite history, and I will not do so unless there is a very good reason to. No, "not merging nicely" is not a good reason. I thought these guys would be smart enough to ignore the "You really shouldn't do this!" warnings, but evidently that is not the case...No one has been complaining about merging text.
Correct. That was an off-topic rant about my own environment
-
It might be useful to distinguish between file types that can or can't be merged, and processes where merging might or might not make sense. I noticed that I was getting them mixed up earlier; using the word ‘binaries’ both to mean ‘large files’ and ‘unmergeable changes’. The two generally go together, but not always, which is what makes this kind of confusion hard to detect.
-
400 posts and nobody told @blakeyrat to talk to his colleagues instead of trying to rely on technology to solve his communication problems?
People here seem to be focussed on "lock files". I think you've failed to realise that there are usually many interdependencies within a repository and that files are just an implementation detail of how source code is stored. You're not just modifying a file, you're editing code in the repository.
I lock file A (in which branch? Problem 1), colleague locks file B (same branch? Problem 2 - no such thing in git) and we both get to work. Pretty soon I need to make a change that affects B before I can commit not-broken code and colleague wants to edit A or his commit will be broken. One or both of us is going to have to do some merging.
-
talk to his colleagues
I did mention that in passing, but seriously, who wants to have to go and talk to somebody when they're at work. It's much more effective to solve political problems with technical solutions isn't it?
-
Absolutely. Also, creation of deadlocked checkout locks is clearly the correct tool for communicating about unclear demarcation of project responsibilities, and any version control system that doesn't make that very easy to do has no future at all as a replacement for Microsoft Outlook. Or maybe Excel.
The Unix philosophy was never any good. You have to build every facility into every tool, and it doesn't matter how badly any of them actually work. As long as none of your tools have any configuration options, and as long as visual mockups of your tools look the same across all combinations of application and platform, you can't be Doing It Wrong!
-
I seem to recall several people had mentioned that this is a management problem, not a technical one
Hard to check on mobile, so perhaps it was my shoulder aliens.
-
People here seem to be focussed on "lock files".
It was a use case that @loopback0 brought up, because it's how they do business. We were legitimately focused on that.
-
It's much more effective to solve political problems with technical solutions isn't it?
But not as common as solving technical problems with political solutions, as many front page articles can tell you.
-
This has been stated before, but I suppose needs to be repeated. This is not about source code. Source is text, text can be merged relatively painlessly when not automatically, locking isn't necessary. This requirement is about file types whose modifications need to be synchronized because it's not possible to merge or because it doesn't make sense to merge.
The better your tooling, the less locking is required. But it's sometimes more economical to simply establish a synchronous workflow than it is to create tools you don't have.
That aside, locking IS a way of communicating with your colleagues. With the advantage that you can't be screwed by someone that refuses to check his mail, then sneaks changes in while you are working and expects you to clear it up because he committed first.
And the "problems" you point out only exist because you demand a general solution that can't fail under any circumstances. Here's how it would need to work in reality: You tell the central repo (which of course exists because you cloned your repo from it and you will eventually commit to it so that other people can see your changes, because you are not going to send pull requests to everyone in the team because that's dumb) "I want to lock this file".
Forget about branches, you are in a synchronous workflow for this operation so you don't care about branches. So long as you have the lock, no one in any branch can modify the file. The central repo checks that you have the latest version, that no one has a lock already, and if so tell you "Ok, you get the lock." Then you start working on the file.
If the central repo notes that someone updated the file and you didn't pull that change into your branch, it tells you to pull the change first, then request the lock again.
Then a second person tries to get a lock. They ask the central repo for it. The central repo says "sorry, someone else has a lock already" and they don't get a lock. They then move on to do something else or pester you about needing to make a change and could you please hurry? After you finish your work you push your changes and release the lock. The second person is then free to pull the changes and request the lock.
Possible issues: You don't have a connection to the central repo. Result: pester IT until you do. In the meantime, work on something that doesn't require locks. Most of the reasons that would keep you from connecting to the central repo would likely keep you from coordinating with the rest of the team, anyway. If you really have nothing else to work on, then you can fall back to the inferior alternative of talking to people (assuming your connectivity issues still allow you to communicate with the team). If you are completely isolated and have no other tasks, go do something else. Watch TV, read a book, etc.
-
Ok, I can see one objection. "What if I'm working in a different version of the project, that is independent of the version the other person is working on but still on the same repo, so that there is a need for two different versions of the file that will never be merged?" Say, you're doing support for a legacy version while someone else is working on the latest version, and the icons are different in each.
This complicates the solution, although that's simply because the situation itself is more complex. The solution is still fairly straightforward. You could tell the locking mechanism "there are two (or more) versions of this file, keep track of changes to each version separately." You then lock the version of the file you care about. Fixed.
-
The solution is still fairly straightforward. You could tell the locking mechanism "there are two (or more) versions of this file, keep track of changes to each version separately." You then lock the version of the file you care about. Fixed.
Take it to the logical extreme, and give everyone their own branch. No lock files actually needed at all! (OK, you can lock things locally if you want. Like anyone really cares.) That's one of the key insights of DVCSs…
-
Notice the caveat I placed at the beginning. This means the files can't merge again. If you don't care to merge the files, of course you don't need locks. But then, you're not collaborating any more.
-
But then, you're not collaborating any more.
I think we've already passed that point long ago when we started having people able to arbitrarily block each other from working.
-
Yes, you can prevent it. But it's not straight-forward, and not even exposed by the git binaries. You have to use the git filesystem api/hooks to do that.
That's what github brings to the table. It's not just raw git hosting. It's a custom front-end using git as the file system.
-
It was a use case that @loopback0 brought up, because it's how they do business. We were legitimately focused on that.
I think his description of the use case was too focussed on "lock files", and the discussion followed that focus. I still don't think that focus is right.
-
I'm not so sure. I know of people that would add more to a project if they could be blocked from ever committing to it.
-
description of the use case was too focussed on "lock files"
It was the only bit I was interested in.
-
And the "problems" you point out only exist because you demand a general solution that can't fail under any circumstances.
Not really, because I won't use it because locking VCS is far more trouble than it's worth. What I demand is that those who say "It's so easy!" and "git's not finished until it does this!" must answer the tough questions to demonstrate how easy it is.
You tell the central repo
What's the cental repo? You can clone from anywhere, that doesn't make it central. You can clone from a clone. Is your upstream supposed to communicate with its upstream, all the way to the top? So then any time anybody edits a file, all the repositories need to communicate upstream to acquire the lock?
Forget about branches
... that's not how DVCS works.
The central repo checks that you have the latest version
From which branch?
Then a second person tries to get a lock.
Every time they edit a file they have to communicate all the way upstream?!
You could tell the locking mechanism "there are two (or more) versions of this file, keep track of changes to each version separately."
Holy crap, the complexity. I thought people were saying this locking this was supposed to be easy.
-
What's the cental repo?
Central*. And I described what the central repo is in the parenthesis following that exact description. To reiterate:
@Kian said:you cloned your repo from it and you will eventually commit to it so that other people can see your changes, because you are not going to send pull requests to everyone in the team because that's dumb
that's not how DVCS works.
You object to things I explain in the following sentence, and don't address the point. I didn't say "forget about branches forever". I said, and this is right after what you quoted:you are in a synchronous workflow for this operation so you don't care about branches.
From which branch?
I explained this in the exact previous sentence to what you quoted:So long as you have the lock, no one in any branch can modify the file.
And a bit later:
@Kian said:If the central repo notes that someone updated the file and you didn't pull that change into your branch, it tells you to pull the change first, then request the lock again.
I understand it might be difficult to follow if you skip sentences at random since the idea builds on what's been described before. What it means is that the history for the file will (assuming everyone follows the rules and doesn't try to subvert the system) look like a tree with no loops. You can only add changes at the top, or branch. If you branch, it means you can't merge your changes back.This would be due to the limitations of the file format itself. Merging some files makes no sense at all as an operation. If I have a set of icons, and I paint them red and someone else paints them green, that's impossible to merge. You wouldn't want to combine the colors. You have to choose which version you want.
Every time they edit a file they have to communicate all the way upstream?!
First, if you'd bothered to follow the conversation at all, you'd see it's intended only for binary formats for which you don't have a merge tool. So no, you don't need to communicate all the way upstream for every change. Only for those to the set of files where people would have to coordinate anyway because otherwise they'd step on each other and have to redo the work.Second, "all the way" is, in most cases, one step. But yes. The same way you have to communicate "all the way" upstream when you want to get the changes other people did. I imagine your continuous integration build system acts as a central repository, but the very idea seemed to confuse you a few lines up, so I'm growing less sure of what development looks like where you work.
Holy crap, the complexity. I thought people were saying this locking this was supposed to be easy.
Trees are not especially complex data structures.
-
The old ‘irreducible complexity’ argument.
It's a complex problem. We're not asking git to provide a perfect solution. The problem is that there isn't anything: not a rudimentary command line tool for checking file availablity, not a set of best practices that would help a newcomer to a git-hosted project to easily acquaint themselves, nothing.people able to arbitrarily block each other from working.
We've been over this. It's a strawman; an unintended consequence of the first generation of tools. Fuck you.
-
But if one of the locks turns into a check-in of a goat, should we stay with breaking the lock we picked or switch to the third lock?
-
Talking to another_sam is a waste of time. Guy's brain is like 68% Jell-O. (Grape.)
-
I think his description of the use case was too focussed on "lock files", and the discussion followed that focus. I still don't think that focus is right.
I suppose you do understand his issues better than he does.
-
Not really, because I won't use it because locking VCS is far more trouble than it's worth. What I demand is that those who say "It's so easy!" and "git's not finished until it does this!" must answer the tough questions to demonstrate how easy it is.
What I love about these folks is that they tell us that the failure modes of such a scheme don't matter to them and they just want the goddamned locking implemented. Except they bitch about that sort of thing already. Usually because they don't understand (or won't admit it). Or at least won't admit that the sort of thing they want to happen requires violating the laws of physics.
Holy crap, the complexity. I thought people were saying this locking this was supposed to be easy.
+Ʀ
-
-
they had to retcon so much history because of him....breaking the laws of physics is practically what he did for a living.
-
-
-
EDIT: WTF is that?!
-
-
-
Did you know that off-hand, or did you have to look it up?
I knew it offhand. that show is awesome!
-
I'm confused. I saw someone name that horse thing, assumed it was @RaceProUK then he posted next.
-
I'm confused. I saw someone name that horse thing, assumed it was @RaceProUK then he posted next.
If there is one thing I'm definitely not a fan of, it's My Little Pony: Friendship Is Magic.
-
Gotta draw the line somewhere.
-
What I love about these folks is that they tell us that the failure modes of such a scheme don't matter to them and they just want the goddamned locking implemented.
"Hey, gimme this shitty half-arsed locking implementation because I can't talk to the people I work with! That Torvalds prick in charge of git is a piece of shit know-it-all who won't implement this feature I want!"
"God damn this shitty half-arsed locking implementation is a shitty, half-arsed implementation! I fucking hate shitty half-arsed software! God damn open sores, nobody in charge so none of the not-fun work ever gets done!"
-
And it all ignores the fact that the hypothetical locks-needed scenario is unrealistic anyway. Most of the people who would want it are also egotistical enough to think in terms of getting the lock removed because they want to work, causing problems for the person who thought they had the lock in the first place. The DVCS model avoids all that sort of shit; changes are not forced on you until you're ready for them (though by the flip side of that, your changes are not forced on others either).
-
The DVCS model avoids all that sort of shit; changes are not forced on you until you're ready for them (though by the flip side of that, your changes are not forced on others either).
Git: the solution to Rape Culture.
-
I don't understand why you need locking when you have this magical concept of a branch.
-
Did you read this thread?
-
I don't understand why you need locking when you have this magical concept of a branch.
Think of a lock as being like a soft blanket and pacifier…
-
So, did we figure out how to lock a file in git, yet?
-
Yup:
Talk to your colleagues.Unfortunately it seems to be too scary a solution for some people.
-
Unfortunately it seems to be too scary a solution for some people.
I second this. I like personal interaction, that's why I advocate reading the contents of patches to your colleagues instead of pushing or pulling.
-
But how can you talk to your colleagues when they are [spoiler]distributed[/spoiler]?
Filed under: the reason why it doesn't work is rather deep
-
But how can you talk to your colleagues when they are distributed?
IRC? Skype chat? [spoiler]Discourse?[/spoiler]
