|
return0 posted:Here are the cases when DVCS is inappropriate: git lfs! or dont use textual source control for artifact management or binary versioning
|
#
?
Jan 24, 2016 19:12
|
|
|
|
| # ? May 28, 2024 13:55 |
|
|
jony neuemonic posted:I live in Vim + Tmux, but I still keep an IDE around for debugging because doing it on the command line is balls. Yeah maybe. As someone who lives in gdb all day, I appreciate command line debugging. Emacs has gud.el (Grand Unified Debugging) which allows you to set and interact with breakpoints via the source code while also giving you easy access to the command-line gdb stuff. I've found most IDEs only expose the most top-level gdb functions and I'm not clever enough to get to the gdb shell from the IDE to run most of the commands I commonly use. I don't blame that on IDEs, though, even `ddd` has a bad debugging UI; I think it's just hard to design a debugging suite that is easy-to-parse and comprehensive.
|
|
#
?
Jan 24, 2016 19:17
|
|
|
KaneTW posted:In the vast majority of software dev cases, offline history and lightweight branching are really good practice. Asset repos in game dev are about the only thing I can think of where you wouldn't want offline history.
|
|
#
?
Jan 24, 2016 19:19
|
|
|
Which reminds me of my favorite TFS behavior: if you go to check in a file and someone else has checked that file in since you started working, you will just overwrite their work with no warning at all. Never use TFS.
|
|
#
?
Jan 24, 2016 19:30
|
|
|
Malcolm XML posted:git lfs! I've been moving part of the test system for our renderer to git lfs. It has much the same constraints as a game's resources does, the baseline renderings for a given test are valid for a specific version of the code that renders them so test data, test baselines and code all need to be revisioned together. git lfs is not the worst system, but things about it that belong in the thread include...
At first I moved all the images in the slice of the test system I was working with to lfs and I ended up with a two-hour checkout on a pretty modest 500 GB repo. The full test suite is several times that size. For this slice it's manageable by just putting most of the binaries in regular git, but that requires being careful about how we filter to just use lfs where it's really needed which is exactly the sort of thing we don't want to spend time doing. The core notion of "replace binary with url + hash" is a fine idea (and used by plenty of other source control systems) but lfs as is really doesn't feel ready for primetime. Perforce is -- to my profound sadness -- far better, at least for our use case.
|
|
#
?
Jan 24, 2016 19:45
|
|
|
fleshweasel posted:Which reminds me of my favorite TFS behavior: if you go to check in a file and someone else has checked that file in since you started working, you will just overwrite their work with no warning at all. Never use TFS. When was the last time this was true? The behavior I've experienced for this exact use case, circa 2 days ago, is that: 1. If your delta and other-user's delta are conflicts, Automerge will fail and it will bring up the Merge tool for you to figure out what you want to do. 2. If your delta and other-user's delta are not conflicts, it will *not* check-in, but will instead warn you that there was an edit that just got automerged, please maybe take a look before you click Check-In again.
|
|
#
?
Jan 24, 2016 19:49
|
|
|
return0 posted:Here are the cases when DVCS is inappropriate: See, here's the thing: A lot of the posters in this thread are developers who work for software companies, where software is the primary focus of the company and the company tends to attract developers who are up on the latest tools and technologies. There's an entirely different "tier" of developers out there, and there are a lot more of them than there are of you. These are the developers that work for large, slow-moving organizations (think banks and insurance companies) and aren't up on the best, latest technologies. These teams frequently have developers that range in experience from "fresh out of college" to "been here for 30 years and I'm staying until I die", and in technical adeptness ranging from "up on the latest techniques and technologies" to "I've used the same tools for 30 years and I'm using them until I die". I see a lot of these teams. I see them force-migrated to DVCS by someone who isn't a part of the team and doesn't understand how the team does development. Hell, some of the teams have requirements that are really easily enforced in CVCS but require a lot of hoop-jumping to enforce in a DVCS (think of something like "restrictions to who can view/edit certain folders" -- sure, you can resolve it with multiple repos and submodules and the like, but try explaining that to a team that doesn't understand DVCS and used to just manage restrictions like that with AD groups with zero impact to the developers). Here's how their source control workflow goes prior to the migration: Edit some files, check files in. Resolve conflicts if there are any. They might not even do that every day. Is it great that they do things that way? Not particularly. But it also doesn't cause them any pain, because they aren't doing daily builds, or automated releases, or unit testing. Should they be? Yeah, sure. Will they ever? Ehh, maybe. Suddenly, they're using DVCS. No one on the team really knows or understands it. They struggle, a lot. "Wait, you mean I can't pull changes if I have uncommitted changes? But I always work that way!" Their productivity tanks for a few weeks while they adapt and figure out how to sort-of replicate the workflows that they're used to in DVCS, but in the meantime there's a lot of gnashing of teeth and "gently caress this, I'll just save my work and re-clone the repository into another folder and copy my changes back over". At the end of the transition, here's what they have: A DVCS that is being used as a CVCS, except it has some bits dangling off of it that are poorly understood and never used. The team has gained nothing. Understand, I have seen this exact scenario literally a dozen times. And again, it's not great that they don't want to learn (or are incapable of learning) new stuff. But it happens, in the real world, all the time. Please understand, I like a lot of things about DVCS, and I use Git all the time for projects I'm working on. I just don't think it's the best fit for every team, and I think the "if it ain't broke, don't fix it" adage applies.
|
|
#
?
Jan 24, 2016 19:52
|
|
|
Ithaqua posted:A bunch of true stuff. We went through an SVN -> Git transition at work recently, and it was awful for something like 50% of our developers, including our team lead. We were only able to convince them that the Git transition really had to happen by pointing out that we were an open source project and if you're an open source project and you aren't on GitHub then you're automatically shutting out like 75% of the developers who might otherwise contribute. Even then there was a ton of grumbling and I don't think the team lead ever really figured out how to make Git work as Git instead of as some weird Frankenstein Git/SVN hybrid (and yes, I'm aware of git-svn).
|
|
#
?
Jan 24, 2016 20:04
|
|
|
Ithaqua posted:And? DVCS is absolutely overcomplicated for what some teams are doing. If the team doesn't need to work offline and rarely branches and their existing VCS tools work for them with no pain or angst, why should they change to DVCS? There's way too much DVCS cargo culting happening and it drives me crazy. I'm quite new to software development (second year of uni, only had an actual developer job for a year now), so I guess SVN was before my time, but unless you're doing some crazy magic with git, I really don't understand how it's overcomplicated. It takes like maybe half an hour to go through the basics and maybe play around with it a bit and that will probably cover 99% of everything you'll need to do with it. I don't see any downsides to using git, but I see many benefits compared to SVN. sunaurus fucked around with this message at 23:29 on Jan 24, 2016 |
|
#
?
Jan 24, 2016 21:04
|
|
|
By the way when you try to get a bunch of devs who previously used the "we store everything on one dude's computer and he has a share you can get the source from" method of version control, SVN is a culture shock too. The previous way was "working" in that situation too, and when we moved to SVN we had people essentially doing what you describe: oh, I have some modifications so SVN won't let me check out without merging, I'll just zip up my source and copy it over top of everything after checking out. At least three times we had someone essentially just revert the whole repo to a previous state so they could check in a two line change. E: also, this was a software development consulting company.
|
|
#
?
Jan 24, 2016 21:50
|
|
|
SVN forces you to structure your history in its master in a linear way without explicit branching. This is a lot simpler conceptually than git, especially when you never or rarely branch in SVN. You can look at a linear history of commits and there's not a brainfuck DAG that someone non-technical can't untangle. Achieving a mostly linear history in git as above requires being fairly competent in git, and I think most people want a linear history except for long-running branches. Git also re-uses verbiage from SVN and other similar tools but the verbiage now means something completely different. That can be really confusing for people switching. Git's CLI is inconsistent and confusing (it's improved a bit). Git historically had bad GUIs on different platforms (this shouldn't be an issue anymore). Git makes some aspects of development (in a team or solo) simpler, but if people don't care about those aspects then git is adding a bunch of unnecessary conceptual overhead. comedyblissoption fucked around with this message at 21:53 on Jan 24, 2016 |
|
#
?
Jan 24, 2016 21:51
|
|
|
I think that DVCS is cool in theory, but in my experience with Git it's always easier to push code to a central server (say BitBucket or GitHub) and then ask people to pull from that (and then branch off and merge as needed) than it is to set up distributed remotes. Disclaimer: I never worked on a project that had more than two people coding.
|
|
#
?
Jan 24, 2016 22:02
|
|
|
Git has many advantages even if everyone is pulling and pushing to a centralized server. Managing repositories locally is the biggest one. Branching workflows that don't suck is the other.
|
|
#
?
Jan 24, 2016 22:06
|
|
|
The main advantage of DVCS is that I can work and create revisions while you work and create revisions, all without having to worry about merging right now. I forgot how awful SVN was until this thread reminded me.
|
|
#
?
Jan 24, 2016 22:19
|
|
|
Oh I found that Git-explained-with-simple-filesystem-operations thing again! http://tom.preston-werner.com/2009/05/19/the-git-parable.html
|
|
#
?
Jan 24, 2016 22:34
|
|
|
Cuntpunch posted:When was the last time this was true? The behavior I've experienced for this exact use case, circa 2 days ago, is that: It might be a vestige of our clients' old TFS systems that we VPN into to do contract work, but I have definitely seen coworkers blow out each other's changes because people didn't get latest before check-in in the last month or so.
|
|
#
?
Jan 24, 2016 22:41
|
|
|
nielsm posted:Oh I found that Git-explained-with-simple-filesystem-operations thing again! Explain to me burrito metaphor for git, please.
|
|
#
?
Jan 24, 2016 22:42
|
|
|
Suspicious Dish posted:Explain to me burrito metaphor for git, please. Git is like a burrito.. ah gently caress it I'm hungry let's go get Mexican.
|
|
#
?
Jan 24, 2016 23:07
|
|
|
Ithaqua posted:See, here's the thing: A lot of the posters in this thread are developers who work for software companies, where software is the primary focus of the company and the company tends to attract developers who are up on the latest tools and technologies. I agree with you, We are having enough trouble where i work trying to get people to use Gradle as Maven Builds take 90 minutes and Gradle only 15. Trying to get them to move from SVN to Git would be pretty hard, I must admit the way we work in the office does lend itself to SVN but with travis i could see how upgrading to git would work as the Tech leads could be the ones to merge the Pull requests from the sub teams, but its learning the new terms and the way that you commit local then push to remote then PR to main repo
|
|
#
?
Jan 25, 2016 08:15
|
|
|
fleshweasel posted:It might be a vestige of our clients' old TFS systems that we VPN into to do contract work, but I have definitely seen coworkers blow out each other's changes because people didn't get latest before check-in in the last month or so. They might just be reflexively pressing the "Keep Mine!" button when the merge conflict dialog comes up. TFS definitely doesn't let you overwrite conflicting changes by default. Edit: Recent versions, that is. I have no idea what the situation was in early TFS versions. LOOK I AM A TURTLE fucked around with this message at 14:38 on Jan 25, 2016 |
|
#
?
Jan 25, 2016 12:58
|
|
|
Illegal Move posted:I'm quite new to software development (second year of uni, only had an actual developer job for a year now), so I guess SVN was before my time Thanks for making me feel old  (First RCS I used was SCCS, and then the one that's literally called RCS).
|
|
#
?
Jan 25, 2016 13:48
|
|
|
My first job, every server had RCS folders sprinkled everywhere. And sometimes *,v files. We used them for administration.. password files and stuff like that. Anyone who never had to use rcs should read the man page. A lot of syntax used in modern tools trace straight to that command.
|
|
#
?
Jan 25, 2016 15:15
|
|
|
comedyblissoption posted:Git historically had bad GUIs on different platforms (this shouldn't be an issue anymore).
|
|
#
?
Jan 25, 2016 16:31
|
|
|
mjau posted:It's still an issue on Linux. Solution: dont use Linux
|
|
#
?
Jan 25, 2016 16:54
|
|
|
Malcolm XML posted:Solution: dont use Linux
|
|
#
?
Jan 25, 2016 16:57
|
|
|
Malcolm XML posted:Solution: dont use Linux Solution: Don't use a GUI. 
|
|
#
?
Jan 25, 2016 17:23
|
|
|
LOOK I AM A TURTLE posted:They might just be reflexively pressing the "Keep Mine!" button when the merge conflict dialog comes up. TFS definitely doesn't let you overwrite conflicting changes by default. At least the last ~three versions. The merge tool is hot garbage though, so I can see how it might look that way. E: by "that way" I mean "stomps on the other guy's file by default". TFS doesn't do that - the merge tool can+will and I think that's just a VS issue Munkeymon fucked around with this message at 17:38 on Jan 25, 2016 |
|
#
?
Jan 25, 2016 17:29
|
|
|
Make has built-in rules for checking out of ,v files, even.
|
|
#
?
Jan 25, 2016 17:35
|
|
|
Yeah, the other thing is that I think the default AutoMerge setting is disastrous. Nothing quite like getting latest and seeing "some files were merged, but no need to look, I did it automatically!" Merging needs to be at a minimum done like: "User, I took a guess as to what you might want, now look over all this poo poo and make sure it's ok." Is it possible that the check-in wiping out other people's file changes is some kind of idiotic policy my company's clients have set up?
|
|
#
?
Jan 25, 2016 18:26
|
|
|
HardDisk posted:Have you ever been kept awake at night, desperately feeling a burning desire to do nothing else but directly import JSON files as if they were python modules [1]? Now you can! I like how the readme includes uninstallation guidelines.
|
|
#
?
Jan 25, 2016 18:55
|
|
|
I can hear a million angry nerds who love to use the word "pythonic" angrily banging long winded explanations why this should never have been done because they missed it's a joke.
|
|
#
?
Jan 25, 2016 18:58
|
|
|
This is more of a funny/cute one, than a horror story. On one of my company's legacy projects there is a developer for the client company. Every time he writes a function, or modifies one, he has to preface it with his own initial. For instance, something like SQLCONNECT() would become G_SQLCONNECT() etc I honestly almost died laughing when i first figured out what was going on.
|
|
#
?
Jan 25, 2016 20:04
|
|
|
DVCS is cargo culting! Everyone already uses SVN so we should use that.
|
|
#
?
Jan 25, 2016 20:08
|
|
|
Pie Colony posted:DVCS is cargo culting! Everyone already uses SVN so we should use that. Choosing a tool based on the success of other organizations without giving any thought as to whether that tool is a good fit for you and your team is practically the textbook definition of cargo cult as it applies to software development.
|
|
#
?
Jan 25, 2016 20:21
|
|
|
TooMuchAbstraction posted:I like how the readme includes uninstallation guidelines. I'm loving everything in that repo
|
|
#
?
Jan 25, 2016 20:32
|
|
|
fleshweasel posted:Yeah, the other thing is that I think the default AutoMerge setting is disastrous. Nothing quite like getting latest and seeing "some files were merged, but no need to look, I did it automatically!" Merging needs to be at a minimum done like: "User, I took a guess as to what you might want, now look over all this poo poo and make sure it's ok." It's a Microsoft product, so I'm sure there's a config option for everything if you look hard enough. They probably just asked for it to work like good ol' Source Safe did back in the days before those meanies at Microsoft abandoned it and someone hosed up the config partway there.
|
|
#
?
Jan 25, 2016 22:20
|
|
|
fleshweasel posted:Yeah, the other thing is that I think the default AutoMerge setting is disastrous. Nothing quite like getting latest and seeing "some files were merged, but no need to look, I did it automatically!" Merging needs to be at a minimum done like: "User, I took a guess as to what you might want, now look over all this poo poo and make sure it's ok." The behavior of TFVC/Visual Studio when pulling down changes is pretty much as follows: Grab changed files. If nothing local is modified, everthing's cool. If something local is modified and it can be cleanly merged, cleanly merge it and show in Pending Changes. If something local is modified and it can't be cleanly merged, show a conflict resolution window containing each file a conflict and allow conflict resolution (manual merge/take server/keep local). Show it in Pending Changes. So you still have the opportunity to review the merge before committing anything. The behavior of TFVC when committing changes is pretty much the exact same thing in reverse. There should just never be a circumstance under which someone else's changes are overwritten. I can't speak for earlier versions, but I have never once seen that happen in the real world using TFVC in TFS 2010, 2012, 2013, or 2015.
|
|
#
?
Jan 26, 2016 00:39
|
|
|
Ithaqua posted:If something local is modified and it can be cleanly merged, cleanly merge it and show in Pending Changes.
|
|
#
?
Jan 26, 2016 01:03
|
|
|
|
| # ? May 28, 2024 13:55 |
|
|
Ithaqua posted:The behavior of TFVC/Visual Studio when pulling down changes is pretty much as follows: Sometimes people trust the auto-merge tool in TFS blindly, and the auto-merge in TFS is really, really stupid - it's otherwise hard to gently caress up though.
|
|
#
?
Jan 26, 2016 04:05
|
|
