50 Versions of Shed Control Wars
-
If you cannot go online, you cannot begin any work.
And how do I pull anything from Git if I don't go online at least once?
EDIT: Or push anything to.
-
If you cannot go online, you cannot begin any work.
Not true. For any VCS, D or not.
-
If they're not talking to the server, they're presumably editing a local copy and not one from the server?
No, presumably, they're working in their local working copy.
Either way, they can't commit until I have, and that's still not an issue solved with Git.
The problem is, they go to update the next time and their shit gets fucked up by the changes you committed. I suppose if they're lucky, there are conflicts, and they can salvage the work they've done. Maybe that's likely with a binary file.
With git, both changes would be separate and preserved, so while someone has to do some extra work, at least it's there so you can reference it or whatever.
Now, if they'd seen your lock, they'd email you to hurry up or something, I guess, but you're actually more SOL with svn, whose biggest problem is its merge-commit paradigm, not its central nature.
-
You have to go online before you can start or end the work, thus you can only work by going online.
But not to "check out/lock" the file at the instant you want to edit it. You just had to check out the repository to a working copy at some point. With svn, you just can't commit/save anything to a repository without communicating with the remote repository.
This ability to begin work at any moment is a core feature of DVCS.
It's that you can do anything repository related. Not that you can't do any work when you're not able to talk to a central server in a CVCS.
-
With git, both changes would be separate and preserved, so while someone has to do some extra work, at least it's there so you can reference it or whatever.
Edit: I have reread what you said and I think you agree with me. I'll leave what I wrote for posterity though. ;-)Now, if they'd seen your lock, they'd email you to hurry up or something, I guess, but you're actually more SOL with svn, whose biggest problem is its merge-commit paradigm, not its central nature.
I actually have a complaint about a similar situation, but what you say isn't really right in that case. If you have a conflict, svn preserves both sides of the conflict in their original form -- they're called something of the form
foo.txt.r100for the version from the repository andfoo.txt.minefor an unchanged version from what you had at the point of issuingsvn up. (You also get the base version from the 3-way merge, but that's by definition in the repository and preserved. I guess that's true of the opposite side of the conflict from you too.) You can't commit without resolving the conflict, so unless you're really working on autopilot you're not going to destroy information from a conflicted file without realizing it.(With Git your copy would be committed to your local repo of course, which is slightly better... but only slightly.)
Ironically, the situation is actually worse with files that don't conflict: if I change
foo.txtand runsvn upand svn pulls down some changes tofoo.txtthat do not textually conflict, you can't go back to the state you were in before theupunless you have that info stored separately.
-
You know, it's kind of sad though, because what loopback wants to do is a legitimate use case, and having a way for artists and designers and what not to coordinate their workflow with a git workflow could be of great help to a lot of oss projects, but thanks to Torval dickwaving and reactionary everybodies, it will never get worked on.
-
"I expected it to work one way and when it didn't I forever decided that is total rubbish"
The Blakeyrat Axiom
(should totally be the title of a Robert Ludlum novel, a screen adaptation with Steve Buscemi in the title role rapidly following)
-
And how do I pull anything from Git if I don't go online at least once?
EDIT: Or push anything to.
Sorry, I phrased it badly - thanks @boomzilla for rephrasing.In a DVCS you can do any repository-related work offline.
You only need to go online when you are ready to show everybody else what you have done.Thus you can do a series of different pieces of work without affecting anyone else - for example you can try out multiple ways of implementing something, each of which would touch different files.
When you have decided the best one, you should go online and push it.
All the other stuff you tried out does not affect anyone else.In a locking VCS you can't do that.
You have to lock all the files you might want to touch, including files that you later realise weren't necessary. (Or keep going online to lock them)In both cases you can fuck your colleagues.
The locking approach stops them doing any work on the locked files, while the DVCS method runs the risk of you both changing the same file in a way the DVCS can't merge automatically.
The difference is that the DVCS will let you both work on the same file at the same time and keep your own histories of it, only complaining when merging - and even offering access to both histories when that merge needs to happen.
I suppose DVCS is automatic multiple-branch-per-developer that's usually totally transparent.
PS: git handles binary files just as well as any other VCS.
The complaint is that it doesn't know how to merge them - but neither does any other VCS!
They could all be configured to ask another tool that does know how, if such a tool exists.
Unfortunately merging such files requires detailed knowledge of the internal meaning.
Some formats are effectively impossible to merge - WTF do you do to merge something using lossy compression?
-
The difference is that the DVCS will let you both work on the same file at the same time and keep your own histories of it, only complaining when merging - and even offering access to both histories when that merge needs to happen.
How is this different from shelving?
-
It's not particularly different, it's just automatic.
@lightsoff said:I suppose DVCS is automatic multiple-branch-per-developer that's usually totally transparent.
-
but thanks to Torval dickwaving and reactionary everybodies, it will never get worked on.
The real tragedy is that there are no alternatives.
-
In a DVCS
In a locking VCS
Now you're comparing non-opposites. You can do your entire use case in SVN, a non-distributed version control system, as well: run an update on your working copy, go offline and play to your hearts content, and only commit when you're back online -- committing is the part that affects other people. This isn't a distributed vs centralized thing, but a locking vs non-locking thing.
-
go offline and play to your hearts content
But when you're offline, do you get a full VCS to play with or just a work tree that you need to do ad-hoc rename-shit VC with instead?
-
But when you're offline, do you get a full VCS to play with or just a work tree that you need to do ad-hoc rename-shit VC with instead?
No. All you have is a work tree - you cannot commit, branch, merge or rollback locally.
Amusingly there are plugins for git that allow you to use git to talk to a svn repo, primarily to give you this offline workflow.
PS: I know they aren't exact opposites as a CVCS may or may not offer locking, however a DVCS cannot be locking by its very nature.
-
a DVCS cannot be locking by its very nature.
Surely you could prevent people from syncing with the main repo? My knowledge of git is entirely through using github, but you could theoretically prevent anyone from syncing with the github repo despite what they did locally. Isn't that basically what a pull request does?
-
No the point is, you want a way for Git to communicate to someone before they start editing a binary file that it's locked. That's the only way this scenario works.
Any other "solution" involves manual merges or deleting someone's work. Preventing someone from syncing with the main repo doesn't prevent them from wasting their time working on a file at the same time as someone else.
-
No. All you have is a work tree
Thought so. In which case, "go offline and play to your heart's content" is rather overstating the case.
-
Preventing someone from syncing with the main repo doesn't prevent them from wasting their time working on a file at the same time as someone else.
If your team is mismanaged badly enough that VCS locks are the only thing preventing significant time being lost this way, it will certainly be losing far, far more time to other kinds of screwup.
VCS checkout locks are one of those things that people simply think of as a timesaver and a safety feature. People who are accustomed to having them are amazingly resistant to the idea that industry experience shows that on balance they waste more time than they save, but it's true all the same.
-
Any other "solution" involves manual merges or deleting someone's work.
Git doesn't delete someone else's work. You may accuse it of many things — may I suggest being “difficult, confusing, and developed by misanthropes” — but it doesn't lose commits unless you deliberately take special steps to force it to do it.
Git might force you to figure out what you're going to do about the conflicts in files it doesn't know how to auto-merge when you come to actually do a merge between branches. (The git model has everyone working in effect on their own branch, separate from everyone else's.)
-
If your team is mismanaged badly enough that VCS locks are the only thing preventing significant time being lost this way, it will certainly be losing far, far more time to other kinds of screwup.
Possibly; but I'd still rather have the software enforce it.
VCS checkout locks are one of those things that people simply think of as a timesaver and a safety feature.
Do you have any evidence otherwise?
People who are accustomed to having them are amazingly resistant to the idea that industry experience shows that on balance they waste more time than they save, but it's true all the same.
Oh "industry experience" shows it. Right.
Git doesn't delete someone else's work. You may accuse it of many things — may I suggest being “difficult, confusing, and developed by misanthropes” — but it doesn't lose commits unless you deliberately take special steps to force it to do it.
Ok; then delete that part so it reads "any other 'solution' involved manual merges". BETTER? YOU GIGANTIC DOUCHE?!
-
I believe blakey's hypothetical time loss scenario goes like this:
Developer A makes some changes to file foo, and centralizes a changeset including those. Meanwhile, unbeknownst to developer A, developer B is completely independently making changes to the same file and also wishes those to be incorporated in a unified version. There is no reasonable way to merge those changes automatically because no automatic merge tool is available for the given file format, and a manual merge effectively involves either developer A or developer B effectively redoing work they've already done. The claim is that had a locking mechanism of some sort been in place, forcing the two developers to serialize their changes, that redo time would be avoided.
It's a perfectly reasonable hypothetical scenario. Nothing wrong with it.
What is unreasonable is claiming without a shred of evidence that time lost to this hypothetical scenario will in general exceed time lost to the other scenario, where Developer A puts a lock on the file and forces Developer B to wait before starting to make changes.
Edit: actually the hypothetical scenario contains a hole. Expensive Developers A and B both having exercised their skills to make the changes they wanted, it's surprising how often the resulting manual merge is simple enough to foist on the intern.
-
What is unreasonable is claiming without a shred of evidence that time lost to this hypothetical scenario will in general exceed time lost to the other scenario, where Developer A puts a lock on the file and forces Developer B to wait before starting to make changes.
I've been in the locking scenario (with RCS over NFS, long ago) and it was really painful to have to wait for the month for the “owner” of the file to unlock it so I could work on it again. Why was it that long? Because he'd got interrupted one Friday afternoon by his boss, then was at a conference the following week, then he got married and went on his honeymoon, then straight off to another conference after that. And our admins didn't like changing permissions on files for some reason; I just had to wait (and do other things).
Did I mention that I don't like locking?
More to the point, once you go distributed, locking is basically impossible in any meaningful way. You've got to stop thinking in terms of having a single sequence that represents the history, and instead think of having a tree with many twigs and branches sticking out of it, some of which you can't see and others you can't write to. But you can always write to your own branches. The reason that locking doesn't work is that there's no central authority to enforce it. (You could check in a file saying “hey, I'm working on this other file” but that's really just like putting a README.txt asking people not to fiddle with things.)
Ultimately, if you have changes being done by two people, you've got to merge them somehow. All locking ever did was force this merging to be done serially, with no chance of people ever working on something in parallel. Parallel working, when merges work, is a great way to boost overall performance of people. Of course, merges can be tricky anyway, even with text formats. I know of files that are text (well, XML; that's text, amirite?) that contain serializations of objects in an application, and some of the things in there are unsorted collections. Each time they're written out, they're in a different order. Merges? Diffs? Forget about 'em; they're useless.
If you have a conflict, svn preserves both sides of the conflict in their original form -- they're called something of the form foo.txt.r100 for the version from the repository and foo.txt.mine for an unchanged version from what you had at the point of issuing svn up.
That's not really preserving them; they're only in the local checkout, not on a branch visible to other people (who might be able to help with the merge if it is tricky).
-
Each time they're written out, they're in a different order.
Fix your tooling. It's not just the merging that will become more smooth, you'll have human-readable diffs and useful blame/annotate results, if you ever need to investigate why stuff broke.
-
he'd got interrupted one Friday afternoon by his boss, then was at a conference the following week, then he got married and went on his honeymoon, then straight off to another conference after that. And our admins didn't like changing permissions on files for some reason; I just had to wait
That's pretty much the canonical anti-blakey-scenario scenario. It doesn't happen terribly often. In fact most of the time wasted by waiting for locks is usually spread over a large number of instances of less extreme versions of this.
It's been my experience, having worked on comparable projects with both locking (SourceSafe) and merging (CVS) version control systems, that neither scenario actually happens often enough to justify anything like the amount of passion that folks put into defending their favoured model - unless the project manager and/or team lead is useless, in which case all VCS difficulties pale into insignificance anyway.
-
-
Fix your tooling.
We are doing. Because we're not just fixing that bit (there were many other things wrong too) it's taking a lot of time to do. And the
smartass idiotcolleague in charge of the format migration picked a compressed archive (filled with RDF formatted as JSON-LD) as the replacement.Some fights I just leave alone. I haven't the energy to fight 'em all.
-
a compressed archive (filled with RDF formatted as JSON-LD)
Would it be possible to store that uncompressed in the VCS, treating it as "source code" for compressed versions spat out by the build?
-
Would it be possible to store that uncompressed in the VCS
Would still be kinda pointless if they haven't fixed the unsorted collection problem.
It might be because I am in data processing, but I hate unpredictable behaviour.
-
But you can always write to your own branches. The reason that locking doesn't work is that there's no central authority to enforce it.
I think that's the Nexus of all my complaints about Git.
Why isn't there one?
I'm not saying you should require users to have one, but shouldn't the option exist? If it did, then Git would have at least feature-parity with TFS/SVN/Etc. Right now, it doesn't. I don't buy the argument that it's "impossible".
That's pretty much the canonical anti-blakey-scenario scenario. It doesn't happen terribly often. In fact most of the time wasted by waiting for locks is usually spread over a large number of instances of less extreme versions of this.
Most systems which allow locking make it optional and discouraged anyway. TFS allows you to do it, but you have to go way out of your way. 99.9% of the time it's an entirely lock-free system. Subversion is the same.
I think people have sour experiences from using ancient archaic systems (SourceSafe? Which I've personally never used, I don't think) that do locking by default, and I agree that's a dumb idea.
-
-
And our admins didn't like changing permissions on files for some reason; I just had to wait (and do other things)
In this particular scenario, it seems like your admins are TRWTF. Were you the only person who wanted access to this locked file during the 3-4 weeks it was locked?
What if there was a zOMG BIZNESS kRITICAL!!1 fix that needed to be made in that locked file? Would the admins have budged if the company was losing $millions/hr over it?
-
[central authority]
I think that's the Nexus of all my complaints about Git.
Why isn't there one?
I think the argument is that there can't be one, because there's no central repository by design, there's no way for me to enforce that you can't do something to your copy of my files in your repositoary.
I suppose we're all expected to go and talk to other developers about who wants to edit the file first, or other such administrative tedium...
Filed under: Consider replying to several posts at once Rather than many sequential replies to a topic, please consider a single reply that includes quotes or @name references to previous posts.You can edit your previous reply to add a quote by highlighting text and selecting the quote reply button that appears.It's easier for everyone to read topics that have fewer in-depth replies versus lots of small, individual replies.
-
I think the argument is that there can't be one, because there's no central repository by design,
Well duh. But they didn't have to design it that way. They could have added a special flag or something on a repo that says "anybody who pulls this repo has to talk to me." A lot of corporate customers would love a feature like that.
-
A lot of corporate customers would love a feature like that.
So fork git and do it 😝
Hm. How do I smiley on mobile?
-
A lot of corporate customers would love a feature like that.
The Git project doesn't have customers, only users.
-
The Git project doesn't have customers, only users.
A lot of corporate users would love a feature like that.
HAPPY?! FUCKING RETARD!?!? ARE YOU HAPPY NOW?!?!?!??!!!
-
-
A lot%.
-
By which you mean, as usual, blakeyrat%.
-
-
-
They could have added a special flag or something on a repo that says "anybody who pulls this repo has to talk to me."
That's what authentication is about.
A lot of corporate customers would love a feature like that.
And they already have it and I'm sure a lot of them use it. Are there still companies that don't have stuff like user accounts and passwords on everything?
-
By which you mean, as usual, blakeyrat%.
And other people with the same difficulty in understanding stuff that he has.
-
The Blakeyrat Axiom
(should totally be the title of a Robert Ludlum novel,
Doesn't he hate The Big Bang Theory? That sure sounds like a Big Bang Theory episode title. It's the one where Sheldon does something annoying and gets everyone mad because he's an egomaniac.
-
I'm not sure if you're being facetious here. Are you talking about tools that actually do the job we're talking about, or are you including tools that can be abused for that purpose?
-
It was a joke.
There are lots of great tools in the world (of all sorts, not just software), and using the wrong one for the job is not as good as using the right one. Having the right tool is awesome. For any tool, there are jobs for which it's wrong.
-
But they didn't have to design it that way. They could have added a special flag or something on a repo that says "anybody who pulls this repo has to talk to me." A lot of corporate customers would love a feature like that.
It's definitely addable (ignoring edge cases around offline downstream repos when the lock flags change on a file).
But then the opportunity would be lost to be smugly superior about it ("Locking? Pffft. We don't even have locking in our VCS, you caveman!").
-
And then blakey'd complain that the locking doesn't always work.
-
-
It's the one where Sheldon does something annoying and gets everyone mad because he's an egomaniac.
Isn't that every episode?
