50 Versions of Shed Control Wars
-
"I'm editing this motherfucker and you can't until I'm done"
well that's not a nice attitude to take.
or as a denizen of GIT would tell you (living up to the name of their favorite VCS):
lrn2merge
-
We moved from Perforce to TFS. I still to this day miss changelists. :(
I worked with Perforce for about 15 years at various companies. LOVED IT. (And when shelving was introduced, ohhh sigh...)
Now I use git. There's a reason I have less hair (and it has nothing to do with age).
-
-
of course i would argue that the idea of exclusively locking a file is a dangerous on in the first place and should be avoided if possible
"Dangerous?" Seriously?
No, it's for repos that contain things like Excel files that simply cannot be merged. There's no way for Git to communicate to a fellow repo user "hey BTW, this file is being changed by someone else, and since I can't merge it if you change it too it'll be a huge clusterfuck and one of you dudes is gonna get your work deleted." THAT'S dangerous. That's a lot more dangerous than lacking file locking. Which is... uh... dangerous? Somehow?
Moreover, it's a feature that other "more primitive" SCMs have, so there's no excuse for a "more advanced" SCM like Git to lack it. If you're going to say, "hey Git is a replacement for Subversion", then Git needs to do the stuff Subversion does. It needs to be a superset of Subversion.
-
What when the file isn't a chunk of code, but is a representation of a database object in a proprietary format, and other related objects (like a form and buttons)? Merge isn't going to work there.
Or binary files? Won't work there.
-
What when the file isn't a chunk of code, but is a representation of a database object in a proprietary format, and other related objects (like a form and buttons)? Merge isn't going to work there.Or binary files? Won't work there.
You're late to the party :)
-
Or binary files? Won't work there.
aaah... GIT's weakness.... yeah GIT does not handle binary files well.
wish it did. but it doesn't.
sorry.
-
idea of exclusively locking a file is a dangerous
It's the not dangerous. I'm making changes, I'm the only one making changes and I know this for a fact because I've locked a file. That's fine, I'm not hoping that some downstream system merges a code file (because it doesn't work anywhere else) correctly with a change I wasn't expecting that was made half way through mine correctly, because it might not. Or it might merge it in a way that creates valid code but unexpected shenanigans because of previously mentioned changes.
-
Yeah. D'oh.
Hanzo by @blakeyrat too.
-
hmm... seelms GIT is not for your workflow then. try mercurial, or SVN, IIRC they both sup[port locking.
GIT doesn't and the developers are rather militant about it. I happen to mostly agree with them but then i'm not that militant about it.
-
So the makers of Git, those giants, those monarchs among mortal men, purposefully built a SCM which 1) doesn't handle binary files at all, and 2) is actually demonstrably worse at handling binary files than previous SCMs, and 3) think that handling binary files and making their product more useful is "dangerous".
Here they come, play their fanfare:
-
No, it's for repos that contain things like Excel files that simply cannot be merged.
Tell me how a spreadsheet cannot be merged with another spreadsheet -- couldn't you use a standard-ish merge algorithm, operating on a cell-by-cell basis, and reporting conflicts when the sources disagree about the value of a cell?
Or is it a matter of someone just needing to write diff/merge tools for Office files?
-
We have SVN but we don't use it heavily as currently all source control is done vendor-side (yeah, I know -
).
We're trying to bring it to our side, and as Git is the current corporate thing of choice, we use it for all our Java stuff and it'd be nice to use Git for everything.
Not being able to checkout/lock files is a big problem there, so maybe we're back to SVN.Also - I don't really want to go back to the Git terminology topic but a Google suggests there's a
git checkoutcommand but it does something completely different.
-
Well obviously a spreadsheet, or an image, or possibly even a video timeline could be reasonably merged with another. But you think the guys who built Git would ever bother with that? Hah! They think the product's "finished".
-
Seems like this is the current place for Git fans - can you checkout a file in the traditional sense that it stops other people touching it until it's checked back in?
Thankfully, no.
I'll never figure out in a million years why they thought it was a good idea to get rid of "online" mode.
It probably has to do with the whole thing about a checkbox increasing your required QA by 100%. This particular toggle would surely be even more than that, though.
-
"I'm editing this motherfucker and you can't until I'm done"
"Fuck off and die," I think, is the correct response to that. Erm.
-
Tell me how a spreadsheet cannot be merged with another spreadsheet -- couldn't you use a standard-ish merge algorithm, operating on a cell-by-cell basis, and reporting conflicts when the sources disagree about the value of a cell?
Or is it a matter of someone just needing to write diff/merge tools for Office files?
Or - I could avoid that sorry mess and CHECK OUT the bloody file and stop a co-working making a change which conflicts with mine. Unless I use Git.
-
Moreover, it's a feature that other "more primitive" SCMs have, so there's no excuse for a "more advanced" SCM like Git to lack it. If you're going to say, "hey Git is a replacement for Subversion", then Git needs to do the stuff Subversion does. It needs to be a superset of Subversion.
Goddamnit, why doesn't my car leave horse shit all over the road!
-
How so? Why is checking out a file a bad idea, especially with a lot of binary files?
No-one's explained this yet, just gone "locking files is bad MMMMMKAY".
-
Yeah, doesn't work so well for images...
Why? You can easily use an image editor two display three source images (original, latest server version, and your local copy), and let you create a third image to checkin and merge, incorporating both changes.
-
"Fuck off and die," I think, is the correct response to that. Erm.
i'm not going to disagree with that
-
How so? Why is checking out a file a bad idea, especially with a lot of binary files?
OK, I hadn't gotten to the binary file part. These are just not as nice as text files. There are some collaboration tools available on a tool by tool basis, of course (notable Office documents). But the nature of binary formats doesn't lend itself to this being a solvable problem.
Therefore, you just have to deal with this stuff out of band. Obviously, locking is one way. I just looked up how mercurial does it (wasn't aware there was a way, but @accalia pointed it out), and it has an extension that allows you do lock stuff. Of course, it seems to require that you push up your locks and everyone else pulls them down. I'm not sure what happens if this workflow isn't followed. I guess something similar to what happens if you didn't have it at all to begin with.
I've never worked on a project that had significant churn of binary files.
-
How so? Why is checking out a file a bad idea, especially with a lot of binary files?No-one's explained this yet, just gone "locking files is bad MMMMMKAY".
Because it's worse to force people to erase the read-only attribute and edit the binary files on their machines in order to get their work done because the file is locked by some tool who's gone on a four-day weekend. And they will do exactly that, every time. And then they'll have to merge anyway after the fact.
So what did you gain by having exclusive checkouts?
-
... why are people using source control to version binary files?
-
NFC..... binary files cannot (usually) be sensibly versioned.
-
We use it at work. I don't like it. Having never used it before, I find that most of the features I would find useful are baked into Visual Studio now.
In daily use the things I run into are:
- it fucked up all my snippets or the keyboard workflow I'd been conditioned to use over the previous 7 years
- it wants to refactor everything all the time into the densest possible form, regardless of actual readability, code flow or other intangible reasons I might want to leave things alone
- it complains about every instance of a variable name ending with
IDinstead ofIdof which there are thousands - it frequently puts annoying tooltips over code I am actively trying to read/type
- it gave me a new "find references" results window which I did not ask for nor can I disable apparently
probably more I can't immediately recall.
I've hammered on the settings enough that it's tolerable. I think I ended up deleting pretty much their whole list of snippets so I could use the VS snippets I like. I had to disable some other settings that were getting in the way as well but I don't remember what they were. I've considered turning the whole thing off put decided to leave it on for reasons I've forgotten. I do like the bracket matching, even though it doesn't work reliably and I frequently trip over it when typing new code. That's about it though.
-
... why are people using source control to version binary files?
It generally makes sense to put them into your source control to keep everything consistent. However, you shouldn't be relying on the SCM's diff / merge facilities.
-
... why are people using source control to version binary files?
So that everything's in a single repository?
EDIT - I'm also not versioning them perse. Just putting them in a central repo.But the nature of binary formats doesn't lend itself to this being a solvable problem.
It's quite easily solvable when you can lock a file.So what did you gain by having exclusive checkouts?
People don't change shit in files I'm editing. This is not a silly concept, it's pretty normal.How do people with a workflow which fits Git handle "co-worker makes change incompatible with one I made at the same time"?
-
r - I could avoid that sorry mess and CHECK OUT the bloody file and stop a co-working making a change which conflicts with mine. Unless I use Git.
Delete the file from the repo, edit it locally, and check it back in for add once you've finished?
-
It's quite easily solvable when you can lock a file.
And causes other problems. But, yeah, in the case of binary stuff, it's not quite the WTF that locking normal text files is.
-
So locking a file is dangerous, but deleting it from repro, changing it, then putting it back is normal?
No. That's waaaaay less efficient and also silly.Git clearly isn't the right tool for what we need, fine, but I still don't remotely get why locking a file is TWOTW .
Le Whoosh! -b
-
whoosh?
-
Seemingly. That's what the flags are for ;)
-
locking a file is dangerous
I've never claimed that it's dangerous (I'm aware that others did). Just terrible from a workflow standpoint when it prevents other people from doing their job. In the case of a binary monstrosity, it's a problem if two people are editing at the same time in a way that it often isn't for a text file. But leaving a lock in place after it finishes is a dick move.
And the distributed nature of DVCS makes locks less effective generally. But deleting the file before adding it back after editing probably works fairly similarly to a lock.
-
Just terrible from a workflow standpoint when it prevents other people from doing their job.
I'm not trolling or arguing here, I'm genuinely asking so I can get my head around it.
In a Git world, what stops me and someone else editing the same code and making a change where ChangeA makes ChangeB behave incorrectly but ColleagueB didn't even know ChangeA existed so wouldn't have known, or changes where ChangeB is irrelevant because ChangeA was made, at the same time which get merged together actually work?
-
So what did you gain by having exclusive checkouts?
People don't change shit in files I'm editing. This is not a silly concept, it's pretty normal.
How do people with a workflow which fits Git handle "co-worker makes change incompatible with one I made."
Exactly the same thing you do with text files, just without some of the automatic things happening for you. The tool warns you that there's a later version when you attempt to checkin. You checkout that later version to a local copy (and maybe the original version that both of your edits are based on). You compare to your local version. You manually merge the changes in whatever edits that binary file type. You check it in.
Many high-end tools have ways of not stepping on each other. Photoshop people may use exportable layers, for instance, and only work on "their" layers. Excel people may use different worksheets.
Have you ever tried to merge two large changes with tons of conflicting edits? Sometimes you have to do it the hard way with text, too, and not use the nifty auto-magic text diff/merge program.
A team that runs into this problem a lot has problems with resource allocation and planning, not source control.
-
i mean i know it's tied to visual studio
I dunno where you go that idea, there is a linux and mac client.
-
You checkout that later version to a local copy.
I what? is this the
git checkoutcommand which isn't actually the traditional sense of checkout?Many high-end tools have ways of not stepping on each other
Unfortunately I'm not using high-end tools.Have you ever tried to merge two large changes with tons of conflicting edits?
Yes because two people decided to edit a file with neither of them checking it out. Currently stuff is locked (centrally) before editing making that problem moot.
-
In a Git world, what stops me and someone else editing the same code...
In my hg world, you sort it out when you go to merge. It can be a PITA, but doesn't cause work to halt.
-
Currently stuff is locked (centrally) before editing making that problem moot.
If this sort of thing works for you, it sounds like git may not be the tool for you.
-
I dunno where you go that idea, there is a linux and mac client.
well true, but if you're using Linux and mac dev clients what exactly are the odds that you chose TFS as your VCS?
;-)
-
Well it was probably chosen for them ...
-
Well it was probably chosen for them ...
oh......
umm...... in that case...... flee for your life?
-
git may not be the tool for you.
I recommend a series of rants at people with different workflows and needs than you who nevertheless do not cater to all of yours.
-
I recommend a series of rants at people with different workflows and needs than you who nevertheless do not cater to all of yours.
do i need to reverse the order of clauses in the thread title? ;-)
-
If you're using Mac you've already made the wrong decision somewhere.
it sounds like git may not be the tool for you.
Quite. I'd have left it there if not for trying to work out why a) locking files is bad and b) merge rather than lock doesn't introduce different problems. It was part rant, part "I don't see where you're coming from but am prepared to find out". And, seemingly, part whoosh.
-
It generally makes sense to put them into your source control to keep everything consistent. However, you shouldn't be relying on the SCM's diff / merge facilities.
The only thing I can think it useful for is if you have third-party libraries you use with whatever you're developing.But then, if you're using VS, why aren't you using NuGet? For the libraries in NuGet. It can auto-fetch missing packages, after all.
-
In a Git world, what stops me and someone else editing the same code and making a change where ChangeA makes ChangeB behave incorrectly but ColleagueB didn't even know ChangeA existed so wouldn't have known, or changes where ChangeB is irrelevant because ChangeA was made, at the same time which get merged together actually work?
Effective project management. Same thing that stops you, in a checkout-lock world, checking out file A and making a change that breaks something your cow-orker is doing right now after checking out file B.
Semantic dependencies are no respecters of file boundaries.
-
-
So locking a file is dangerous, but deleting it from repro, changing it, then putting it back is normal?
No. That's waaaaay less efficient and also silly.Git clearly isn't the right tool for what we need, fine, but I still don't remotely get why locking a file is <abbr title="The Worst of the Worst">TWOTW</abbr> .
Le Whoosh! -b
If the joker and the jokee agree...
