Windows Switch To Git Almost Complete: 8,500 Commits and 1,760 Builds Each Day (arstechnica.com)

← Back to Stories (view on slashdot.org)

Windows Switch To Git Almost Complete: 8,500 Commits and 1,760 Builds Each Day (arstechnica.com)

Posted by BeauHD on Wednesday May 24, 2017 @11:10AM from the bigger-and-better dept.

An anonymous reader quotes a report from Ars Technica: Back in February, Microsoft made the surprising announcement that the Windows development team was going to move to using the open source Git version control system for Windows development. A little over three months after that first revelation, and about 90 percent of the Windows engineering team has made the switch. The Windows repository now has about 4,400 active branches, with 8,500 code pushes made per day and 6,600 code reviews each day. An astonishing 1,760 different Windows builds are made every single day -- more than even the most excitable Windows Insider can handle.

221 comments

Min score:

Reason:

Sort:

Linus Wins Again by Anonymous Coward · 2017-05-24 11:17 · Score: 5, Insightful

Say what you will about Mr. Torvalds, but that magnificent bastard has smacked down many a foe over the years. This is really sweet. If the only thing Linus ever did was to invent git, then that would have been enough. But no, he had to write an operating system besides. When history is written, Linus's inspiration will shine forth from the Pantheon of greats.
1. Re:Linus Wins Again by chispito · 2017-05-24 11:40 · Score: 5, Funny
  
  When history is written, Linus's inspiration will shine forth from the Pantheon of greats.
  And those historians should take caution, lest they call his operating system "Linux" and are forevermore haunted by Stallman's ghost.
  
  --
  The Daddy casts sleep on the Baby. The Baby resists!
2. Re:Linus Wins Again by fisted · 2017-05-24 11:59 · Score: 2
  
  So Linus essentially helped streamline Windows development. Yeah, what a win.
  
  --
  CLI paste? paste.pr0.tips!
3. Re: Linus Wins Again by Anonymous Coward · 2017-05-24 12:04 · Score: 5, Insightful
  
  Software is not a zero sum game. Windows' wins are not Linux's losses.
4. Re: Linus Wins Again by Anonymous Coward · 2017-05-24 12:06 · Score: 3, Funny
  
  He helped create the perpetual year of the windows desktop
5. Re:Linus Wins Again by scdeimos · 2017-05-24 12:19 · Score: 5, Interesting
  
  If you read TFA you'd have noticed that Microsoft isn't using Vanilla Git. Using their normal embrace-extend-extinguish mindset they've created their own GVFS (Git Virtual File System) and forks of Git server and client that only work in a GVFS-enabled ecosystem so that they can handle the massive number of files in the Windows source code.
6. Re:Linus Wins Again by Rutulian · 2017-05-24 12:59 · Score: 3, Interesting
  
  Interesting read, actually. They call it GVFS, but it is really just a more asynchronous mode for local git repositories. Traditional git downloads the whole repository as a local copy. It's a feature by design because it allows a developer to work completely offline and only do a git pull when ready to merge branches. It sounds like the Windows repository is a) large and monolithic, so a given developer team does not work on the entire codebase, and b) they frequently sync their changes to the central repository (ie: it is not really decentralized), so the traditional git model has shortcomings for them. One can argue about the structure of the Windows repository, but GVFS sounds like a nice feature to have regardless. The only question I have is...
  
  The third thing the company has done is build a Git proxy server
  
  Why didn't they just clone the Azure repository to somewhere on the East Coast? Git is designed to handle this type of replication, so why did they write a "proxy server" (not entirely sure what they mean by that).
7. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 13:07 · Score: 1
  
  So Windows is still a big ball of spaghetti code even after being "rewritten from the ground up" before every release since Windows 3.11.
  Isn't that special.
8. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 14:02 · Score: 2, Insightful
  
  But no, he had to write an operating system besides.
  Actually, he wrote a kernel...
9. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 14:15 · Score: 5, Funny
  
  Stallman's not dead, he just smells that way.
10. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 14:26 · Score: 3, Informative
  
  >embrace-extend-extinguish
  it's MIT license, you are free to make your own fork: https://github.com/Microsoft/GVFS
11. Re:Linus Wins Again by sodul · 2017-05-24 14:51 · Score: 1
  
  Why didn't they just clone the Azure repository to somewhere on the East Coast? Git is designed to handle this type of replication, so why did they write a "proxy server" (not entirely sure what they mean by that).
  Maybe to avoid merge conflict resolution required when you are decentralized. With a proxy model at least you can guarantee some form of locking. As you pointed out they do not truly embrace the full decentralized nature of git since in a corporate environment it is not appropriate due to the need to lock read and write access to certain sensitive files if only for government compliance reasons. Yes you could split the repository in multiple small chunks that are independent but when the system in the end needs to be monolithic things get a little harder to track since you need to track unrelated histories. Google (not Alphabet) uses a central repository with a single commit index (they use a in house Perforce re-implementation to support the scale), this is very much opposite to the Git way but works well with their development practices. Note that Perforce provides a Proxy server and it only proxies content, mostly to reduce bandwidth usage, while the transactions still go back to the central server (yes that include every single file update since the server keep s track of every single file you sync down).
  What Microsoft has done looks very similar to what Google implemented internally when they deployed Blaze and Forge internally almost 10 years ago.
12. Re: Linus Wins Again by Anonymous Coward · 2017-05-24 15:22 · Score: 2, Funny
  
  We know already Richard, we know. Go finish Hurd, then maybe you can stop being so bitter.
13. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 16:15 · Score: 0
  
  If you read TFA you'd have noticed that Microsoft isn't using Vanilla Git. Using their normal embrace-extend-extinguish mindset they've created their own GVFS (Git Virtual File System) and forks of Git server and client that only work in a GVFS-enabled ecosystem so that they can handle the massive number of files in the Windows source code.
  Yes, they're running their own version of git - one that they cramped their broken functionality from VSS and other tools around which their workflows were designed and the functionality of Visual Studios centered - f.e file locking.
  Their customizations have little if anything to do with the number of files in the Windows source code and more to do with how they are trying to use the system.
14. Re:Linus Wins Again by OrangeTide · 2017-05-24 16:46 · Score: 5, Interesting
  
  We have Linus' famous picture on posters and t-shirts at my work. (NVIDIA)
  My boss was sitting just a few feet beyond the camera when Linus had his rant too. It was epic, many of the Nvidians were squirming in their seat.
  
  --
  “Common sense is not so common.” — Voltaire
15. Re:Linus Wins Again by lucm · 2017-05-24 17:00 · Score: 1
  
  Git is a piece of shit revision control system.
  "revision control system" is not a category, it's a specific utility. Learn the meaning of words, then you can come back and throw in dirty language if you still think that makes you look cool and savvy.
  
  --
  lucm, indeed.
16. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 17:05 · Score: 1
  
  He didn't invent git so much as make git as a reimplementation of BitKeeper, a proprietary VCS system, which was a monumental fuckup he was responsible for using for the Linux kernel.
17. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 18:01 · Score: 0
  
  Git is already on the majority of desktops. WTG!
18. Re:Linus Wins Again by Quietti · 2017-05-24 18:53 · Score: 1
  
  Ah so they adopted GNOME's filesystem abstraction layer? ;)
  
  --
  Software is not supposed to be about how to work around a useability issue. - Ken Barber
19. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 19:15 · Score: 0
  
  Ah, the good old days of file locking. The only place where that is useful is when the VCS is used to store binary document files. And being Microsoft, they most likely have files such as readme.docx and evilplan.docx's spread everywhere.
  Another reason for having silly wrappers on git might be that Windows virus scanners generally don't behave well with a system with huge amount of files. The scanners may have a cached scanning result of ~10000 files, but when the git starts accessing more files, the whole system grinds to halt when the stupid scanners calculate the hashes of each file and query reputation for them from the "cloud". And since windows' source files are not that common, the scanners will not get definite answer and they ask reputation again after some time.
  Also the Windows' own search indexer usually does not handle a system with lot of files and it starts scanning the filesystem in a eternal loop.
20. Re:Linus Wins Again by m.alessandrini · 2017-05-24 19:25 · Score: 1
  
  So Windows is so much more complex than Linux, that it cannot be handled by vanilla Git like the other OS? I was thinking the opposite, unlike Windows Linux includes code for almost all the existing hardware platforms out there, and all the hardware drivers already in the kernel, just to name something.
21. Re:Linus Wins Again by m.alessandrini · 2017-05-24 19:28 · Score: 2
  
  Yeah, someone once said something like: the quality of code is measured in how many lines you delete at the end of the day, not how many you add (I can't find the exact reference).
22. Re:Linus Wins Again by thegarbz · 2017-05-24 19:32 · Score: 1
  
  There's nothing EEE about that, unless you call changing some code that didn't suit your needs EEE. In which case you could criticise every fork ever for the same policy.
23. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 19:40 · Score: 0
  
  You could actually use something like this, https://github.com/PressLabs/gitfs, and use GIO to make a gvfs module and show git repos in nautilus. But this gvfs by microsoft is something different.
24. Re:Linus Wins Again by mysidia · 2017-05-24 20:33 · Score: 1
  
  But the Windows tree includes cool art media like Dancing Pigs screen savers, right?
25. Re:Linus Wins Again by exomondo · 2017-05-24 20:57 · Score: 2
  
  If you read TFA you'd have noticed that Microsoft isn't using Vanilla Git.
  Of course they haven't, Git can't handle repos that large particularly well (in fact very few DVCSs would be able to).
  
  Using their normal embrace-extend-extinguish mindset
  Extinguish what? The version control system they themselves have just moved to? That wouldn't really make much sense now would it?
  
  they've created their own GVFS (Git Virtual File System) and forks of Git server and client that only work in a GVFS-enabled ecosystem
  Where did you get the impression that their forks only work with GVFS? Understandably the client and server would need to be GVFS-aware but that doesn't preclude them from being used without that virtual file system and in fact it would make much more sense for them not to so that support for GVFS could end up in mainline Git which would reduce maintenance and allow people to use the same Git client/server whether GVFS is present or not.
  If they do as is suggested in TFA and develop in the open that would be hugely useful to anybody with large repositories that want to use Git.
26. Re:Linus Wins Again by TheRaven64 · 2017-05-24 21:57 · Score: 3, Interesting
  
  And Microsoft is not using Linus' implementation of git, they have written their own (permissively licensed) version written in C#. So they're using their own VCS, which uses ideas from BitKeeper, and is interoperable with git.
  
  --
  I am TheRaven on Soylent News
27. Re:Linus Wins Again by Anonymous Coward · 2017-05-24 23:50 · Score: 0
  
  Git is a fine revision control system. It does everything you need, and there's lot of tools on top of it to present the data in any way you like.
  Yours is just more of the same tired old screeching and ranting that we've always heard from people who can't cope with learning new things.
28. Re:Linus Wins Again by deKernel · 2017-05-25 01:35 · Score: 1
  
  You do realize that Linux is just the kernel right? Windows includes a kernel plus a whole lot more like a GUI and userspace. Sheesh people think about it. The closest there is in the free software world would be the BSDs where they include not only the kernel but the userspace....minus the GUI. So now imagine taking the Linux kernel, all the bintools, X and a single desktop (Gnome or KDE) and placing all of that into a single repo.
29. Re:Linus Wins Again by Junta · 2017-05-25 01:44 · Score: 1
  
  Not more complex, just mismanaged.
  Take a typical linux distro. Hundreds of packages, each has their own repository. Many of them are git, but not all. Only one of those is the kernel, which is what people keep trying to compare.
  In MS, they have a single repo, for everytihng. This is crazy. Even in my org which has way less complexity, we have several git repositories because we know, for example, that work on one portion is not related to the other. Sure, there are cross-functional people that might touch more, but they just have clones of the projects they work on, not merging them.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
30. Re:Linus Wins Again by Anonymous Coward · 2017-05-25 02:21 · Score: 1
  
  We have Linus' famous picture on posters and t-shirts at my work. (NVIDIA)
  My boss was sitting just a few feet beyond the camera when Linus had his rant too. It was epic, many of the Nvidians were squirming in their seat.
  Squirm yes. Change? No.
31. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 02:59 · Score: 1
  
  GVFS was implemented because the Windows filesystem don't support the same features as the ones available for Linux. As such git is much slower on Windows. In typical Microsoft fashion, rather than fix their borked filesystem they borked their use of git instead.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
32. Re:Linus Wins Again by petermgreen · 2017-05-25 03:04 · Score: 1
  
  The problem with git is that branches don't have proper history. There is the reflog but it is disabled by default on bare repos (main project repos are usually bare), can't be accessed remotely and is generally intended as more of a disaster recovery feature than a long term history feature.
  Commits have history but that history doesn't tell you when the commit was pushed to the main project repo, it doesn't tell you what branch the commit was created on, it doesn't tell you who promoted the code from a test branch to master, it doesn't even reliably tell you when the commit was created or who created it.
  It is thus easy to fall into a trap with git of thinking you are recording history but then when push comes to shove and you need to answer questions like "what code was on branch x of the main repo at time y" or "who decided this awful code was ready for pushing to the master branch" you are in a pickle.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
33. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 03:06 · Score: 1
  
  Use the tool properly. It works great. git-mv your directories and got tracks them just fine. The problem is not git. The problem is that you are incompetent.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
34. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 03:08 · Score: 1
  
  He didn't invent distributed version control. He DID implement git from the ground up. He also didn't invent operating systems, device drivers, daemons, etc. Your ignorant rant exposes your ignorance and bias quite nicely jealous one.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
35. Re:Linus Wins Again by gnasher719 · 2017-05-25 03:44 · Score: 1
  
  So Windows is so much more complex than Linux, that it cannot be handled by vanilla Git like the other OS? I was thinking the opposite, unlike Windows Linux includes code for almost all the existing hardware platforms out there, and all the hardware drivers already in the kernel, just to name something.
  Total misunderstanding what Microsoft is doing. They have a repository of 300 GB. You know what happens if you have a 300 GB repository and type in "git clone"? A 300 GB download starts. It doesn't matter what operating system, a 300 GB download takes time.
  
  While git can handle this all without problems, it takes time. What Microsoft has done is added a virtual file system on top. When you clone the repository with that virtual file system, all that gets copied is the directory structure and the hashes (at the time you cloned). When you open a file, that's when it gets copied.
  
  This will be useful for anyone with truly large repositories. Say starting with a few Gigabyte. Especially those with repositories with 20 years history, that nobody cares about much, but that you really don't want to destroy.
36. Re:Linus Wins Again by uM0p+ap!sdn+ · 2017-05-25 04:44 · Score: 1
  
  You sound like a Newbie that don't know how to use git
  Are you Steve Ballmer
  https://c.o0bg.com/rf/image_37...
37. Re:Linus Wins Again by OrangeTide · 2017-05-25 05:29 · Score: 1
  
  Well much of Linus' criticism was against the ARM SoC group at NVIDIA. And over the last few years they've really took upstreaming seriously and have been doing a good job at using upstream frameworks instead of rolling everything themselves. (I'm biased obviously). You can boot an upstream kernel on most (all?) of the Tegra development kits, which was frustratingly not the case a few years ago.
  As for NVIDIA's desktop GPU drivers, many of the key open source people accept that there isn't going to be an open source release of the currently proprietary drivers. There is a good project to do a clean room open source driver as an alternative to the proprietary one, and it is sufficient for many basic use cases. And even the Nouveau project is somewhat controversial in upstream Linux. Either because of the practices/process the Nouveau team uses, or because of efforts of free software advocates to "deblob" the kernel of firmware binaries.
  
  --
  “Common sense is not so common.” — Voltaire
38. Re:Linus Wins Again by Anonymous Coward · 2017-05-25 06:11 · Score: 0
  
  Welcome to the embrace phase.
39. Re: Linus Wins Again by Anonymous Coward · 2017-05-25 06:37 · Score: 0
  
  So he didn't steal code, only ideas, which any slashdotter will attest, are useless, and should be free.
40. Re: Linus Wins Again by Anonymous Coward · 2017-05-25 06:57 · Score: 0
  
  You might say that WINdows are not LOSSnixes! :p
41. Re: Linus Wins Again by brantondaveperson · 2017-05-25 09:53 · Score: 1
  
  Well, Mr Kelvin, since I wasn't the one who moved the directory, but just the one that attempted the merge, I guess I must be.
  I thought git was supposed to do rename tracking all by itself? And also, that it didn't track directories, just files. And in any case, I tested it, and a merged-in directory rename does not move newly added files to that directory, so you're basically wrong. Oh well.
  I know perfectly well how git works, thank you very much, and there's nothing in the way in which it's designed that would permit directory rename merges to work.
42. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 10:00 · Score: 1
  
  You need to do a git status, use git add, etc. Again, the problem isn't git. The problem is you. Learn to use the tool properly. Your first hint that you don't understand something should have been that hundreds of thousands of people use it daily. If it really had all these problems that would not be the case. Seriously, learn to use the tool rather than complaining that your lack of understanding is git's fault.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
43. Re: Linus Wins Again by brantondaveperson · 2017-05-25 10:34 · Score: 1
  
  Oh Mr Kelvin, you doth protest too much.
  Look mate. If you merge in a directory rename, files that you've added to that moved directory prior to the merge, are not moved. That's the beginning and the end of it, sorry. Fine, I get that git doesn't do that, because it doesn't really believe in directories. no amount of typing 'git status', 'git add', is going to make any difference.
  Just because hundreds of thousands of people do something daily, doesn't make it any bloody good. I mean, do you have any idea how many people are listening to U2 right now? Exactly. I rest my case.
44. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 10:45 · Score: 1
  
  You have to git add them dumbfuck
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
45. Re: Linus Wins Again by brantondaveperson · 2017-05-25 11:00 · Score: 1
  
  git add what, Lord Kelvin?
46. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 11:08 · Score: 1
  
  Either you accept that you don't know what you are doing and educate yourself, or you keep claiming you do know what you are doing and blaming git for your ignorance. I don't really care which one you choose. Also, you need to read this. Off you go now.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
47. Re: Linus Wins Again by exomondo · 2017-05-25 12:40 · Score: 1
  
  What filesystem on Linux operates in the way that Microsoft's GVFS does? For reference they put it here. There is the concept of virtual files already which is how cloud storage plugins work, the file is presented but how fetching and storing is handled is abstracted away, though there seems to be more to GVFS than just that.
48. Re:Linus Wins Again by Anonymous Coward · 2017-05-25 12:42 · Score: 0
  
  You're complaining about workflow issues. Git can be tweaked to do what you're asking for, except for maybe "when was this pushed to master?" If that information is important, it should be gathered in the middleware (i.e. hooks). Git itself doesn't need to know when something was pushed or pulled. Commit time is what's important for its job.
  As for branches, what are you talking about? Git certainly keeps track of branches; check out a branch and do "git log", and you'll see all the history up to the current HEAD (or more specific if you're hunting certain things). An easy way to detect a branch (or an orphan commit) is to check for two commits with the same parent. This should be done automatically by Git, so methinks you (and/or your team) either haven't learned Git yet, or your workflow isn't giving you the results you need.
49. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 12:48 · Score: 1
  
  All Linux filesystems are abstracted through a VFS in the kernel already.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
50. Re:Linus Wins Again by Anonymous Coward · 2017-05-25 12:54 · Score: 0
  
  And that's entirely on Microsoft. Every technical decision has benefits and drawbacks. It just so happens that vertical integration results in huge, hard-to-work-with repositories.
  Shoving the entirety of an OS into a single repository is simply retarded. Naturally, they get to keep the pieces when they break it.
51. Re: Linus Wins Again by brantondaveperson · 2017-05-25 12:59 · Score: 1
  
  Doctor Kelvin, I must apologise for having riled you to the extent that you called me a dumbfuck, but here's what I'm talking about.
  git init
  mkdir A
  touch A/file.txt
  git add A/file.txt
  git commit -m 'a'
  git checkout -b Branch
  git mv A B
  git commit -m 'b'
  git checkout master
  touch A/file2.txt
  git add A/file2.txt
  git commit -m 'c'
  git merge Branch
  ls
  And lo and behold, the added file is still in the old directory, even though the merged branch had re-named the directory. How about that? I read your link, seems like a very long excuse for being rude to me, but hey, I guess some people are just too damn busy to behave otherwise.
52. Re:Linus Wins Again by Anonymous Coward · 2017-05-25 13:07 · Score: 0
  
  To me, each major component of a system needs its own repository. Especially things like networking or security libraries that will be used across the entire system. With each library getting its own repo, they can develop or tweak independently without downloading the OS's entire codebase. Then when you test integration, the library can be in a git submodule or provided in some sort of bootstrapped test harness.
  When shit breaks (and it always does), you can simply target the repository in charge of that particular subsystem instead of grepping 300+GB of code (or whatever Windows has as an alternative... do they even have a grep competitor?). That approach strikes me as cleaner and better tweakable. You can roll back a submodule update if it breaks things.
53. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 13:34 · Score: 1
  
  Well you must have read at least the beginning of Eric S. Raymond's excellent writings on how to ask questions the smart way, because you finally actually did so, at least to a minimal degree.
  
  I have no idea what you are talking about. When I follow the steps you listed I get a master branch with two directories, A and B. A contains file2.txt and B contains file.txt. And the rude person is you, who feels it was rude for me to expect you to ask a question in an intelligent way rather than wasting our time.
  
  Now, things you didn't include, which a more thorough reading of the link would have made it clear you should: What OS are you using? What version of git are you using? What is the underlying filesystem? Would you by any chance be using Microsoft's borked git implementation?
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
54. Re: Linus Wins Again by exomondo · 2017-05-25 13:45 · Score: 1
  
  All Linux filesystems are abstracted through a VFS in the kernel already.
  The same on Windows with the IFS, that isn't what GVFS does though.
55. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 13:55 · Score: 1
  
  I realize that. I was answering the earlier question. GVFS borks git by breaking distributed SCM because it changes the way clone works.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
56. Re:Linus Wins Again by Anonymous Coward · 2017-05-25 14:06 · Score: 0
  
  The EEE part would be when MS's hack gains traction. They then put that into a proprietary product with a set of custom Microsoft git extensions, then sell it to Windows developers and act like the distributed repository model was their idea all along.
  It's the primary reason that overly permissive licensing like the MIT and BSD licenses are bad for libre software in general because it grants people the right to copy the code without giving back.
57. Re: Linus Wins Again by exomondo · 2017-05-25 14:15 · Score: 1
  
  So specifically how is it you think the Linux filesystems solve the problems that GVFS does?
58. Re: Linus Wins Again by brantondaveperson · 2017-05-25 14:20 · Score: 1
  
  But I renamed the directory 'B' in my branch. So, for instance, the branch decided to move an entire library into another directory. However, my merge did not apply that directory rename to the existing tree, which is what a directory rename should really do, but instead completely ignored it, and only added the (now re-named) file. At the very least, this should generate a conflict. Maybe, say, a tree conflict. Ha. See what I did there?
  Anyway, the outcome isn't what I wanted, and is what the text "If you merge in a directory rename, files that you've added to that moved directory prior to the merge, are not moved." means. The same instructions work the same way on different OS's, because this is part of git's implementation, which is to say that it does not track, or even really believe in, directories. Empty directories cannot be stored, as we know, for the same reason. It also doesn't track branches, it just tracks where each of their tips currently are.
  I'm using git 2.10.1 on Windows, as it happens, and don't worry, I don't feel like my time is wasted. What's more fun than arguing about near-irrelevant things on the internet? Other than dissing U2, that is.
59. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 14:37 · Score: 1
  
  When you ask the wrong question no answer is correct.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
60. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 14:41 · Score: 1
  
  Wrong. The problem is Windows. On Linux a directory IS a file. I don't have time to find out who is at fault, but it isn't git. That much I know. I DO know that version 2 of the real git was released a decade ago, so you don't have the real git.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
61. Re:Linus Wins Again by TemporalBeing · 2017-05-25 15:25 · Score: 1
  
  So Windows is so much more complex than Linux, that it cannot be handled by vanilla Git like the other OS? I was thinking the opposite, unlike Windows Linux includes code for almost all the existing hardware platforms out there, and all the hardware drivers already in the kernel, just to name something.
  Total misunderstanding what Microsoft is doing. They have a repository of 300 GB. You know what happens if you have a 300 GB repository and type in "git clone"? A 300 GB download starts. It doesn't matter what operating system, a 300 GB download takes time. While git can handle this all without problems, it takes time. What Microsoft has done is added a virtual file system on top. When you clone the repository with that virtual file system, all that gets copied is the directory structure and the hashes (at the time you cloned). When you open a file, that's when it gets copied. This will be useful for anyone with truly large repositories. Say starting with a few Gigabyte. Especially those with repositories with 20 years history, that nobody cares about much, but that you really don't want to destroy.
  All true - the problem is they mismanage their code. There's no reason it should be one big massive git repository. It should be about 30,0000 repositories. Each library, executable, driver, etc should be its own repository. Even common headers should be in their own repository. Then version everything and make every project depend on the versions they need - upgrading appropriately and in timely manners. Works very well and fewer people needed to handle larger amounts of code as a result.
  
  --
  Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
62. Re: Linus Wins Again by brantondaveperson · 2017-05-25 16:07 · Score: 1
  
  Oh Kelvin, Kelvin, Kelvin. You could be more wrong, but it would be difficult. That a directory 'is' a file makes no difference to git. If a directory were a file, in any meaningful sense, then I'd be able to write data into it, wouldn't it? I suppose it depends on what your definition of a file is, so for the sake of this particular argument, it's something I can write data into, and stand a good chance of getting it back out again. Can git store empty directories now? No, of course not. Will my instructions, which you followed remember, presumably using the 'real' git, ever actually merge the directory rename into my tree? No, of course not. Or even generate a conflict? Again, no.
  Of course you don't have time to figure out who's at fault, since we've already established your busyness, so I'll help you out, and save you some time.
  It's git. Git is at fault.
63. Re: Linus Wins Again by exomondo · 2017-05-25 16:10 · Score: 1
  
  GVFS was implemented because the Windows filesystem don't support the same features as the ones available for Linux.
  Specifically what features are you referring to?
64. Re:Linus Wins Again by brantondaveperson · 2017-05-25 16:32 · Score: 1
  
  This is a typical response to the perfectly well articulated, and one-hundred-percent correct complaints outlined above by petermgreen. He's completely right, git's branches don't actually exist, it's easy to lose commits, it's very hard - the the point of being impossible - to figure out what went on in the past.
  But raise all this information, and you'll just be told that you either don't know how to use git - whereas by the time someone knows git well enough to understand where it gets things wrong, they certainly know how to use it. Or, once you get past that particular defense by demonstrating your knowledge to your correspondent's satisfaction, you'll instead to informed that git has no business solving those problems, because those problems don't matter.
  Now, I get that Linus created something to solve his particular problems, and I understand that. But the fact is that git was pretty much hacked together over a couple of weeks, and it really shows. Everyone's jumped on it, despite that other options are superior, for no reason that I can completely understand. Probably because it's free.
65. Re:Linus Wins Again by brantondaveperson · 2017-05-25 16:35 · Score: 1
  
  It's a feature by design because it allows a developer to work completely offline and only do a git pull when ready to merge branches.
  No it's not. Not being able to partially check out code, is not a feature. It's a lack of a feature. There's no reason at all that git couldn't perform partial checkouts, there's nothing in its data model that would prevent it, as far as I can tell, so it's even less of a design 'feature' than you suggest.
66. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 21:39 · Score: 1
  
  The VFS and inotify for starters. See also.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
67. Re: Linus Wins Again by Zero__Kelvin · 2017-05-25 21:49 · Score: 1
  
  You are an idiot. Sorry, but it's true. If you knew anything about what you were talking about you would know that in all Unix derivatives, including the *BSDs, and yes, even OS X, everything is a file. I just got done telling you that I did exactly what you wrote and it works perfectly. You can blame a bug in the porting of git to Windows, or you can blame Windows, or you can discover that you have uncovered a bug in the particular version of git you are using, but again git, which was designed for Linux and was never intended to be cross platform, works perfectly well for the use case you are complaining about. It has been used for more than a decade by some of the smartest people on the planet to do the thing you are crying about not working for you every day. Either learn something from people much more knowledgeable than you or don't, but stop wasting the time of people with a clue and stop making ridiculous statements like git doesn't work properly. Please get an education, or simply STFU and go fuck yourself.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
68. Re:Linus Wins Again by Rutulian · 2017-05-26 00:57 · Score: 1
  
  How are you going to do local builds if you don't have the whole repository? In Microsoft's example, there is a separate build server and testing is sent off to a dedicated team, so the developer doesn't do any of that themselves. Git was designed to allow developers to checkout a repository and develop (which includes building and testing) completely offline. This model doesn't work for a large monolithic repository like Microsoft's; that's a fair criticism. But it wasn't the intended use case of git to be able to do that.
69. Re: Linus Wins Again by brantondaveperson · 2017-05-28 09:28 · Score: 1
  
  If I merge in a directory rename, newly added files to that directory are not moved. End of story, you strange and weird person.
70. Re:Linus Wins Again by brantondaveperson · 2017-05-28 09:32 · Score: 1
  
  That's the thing with git, sure it's not designed for particular use-cases, but people end up using it for those use-cases all the time. Maybe some more thought should have been put into its design - I find that everyone is using this software with quite limited use-cases for everything quite unsettling. It's not as if there aren't better alternatives.
  Also, not everything that is interested in things in a repository is a build process. Test systems may wish to pull out only the test areas, for instance.
71. Re: Linus Wins Again by exomondo · 2017-05-28 10:19 · Score: 1
  
  And how is it you believe these relate to GVFS?
72. Re: Linus Wins Again by Zero__Kelvin · 2017-05-28 11:37 · Score: 1
  
  Again, they are in fact handled correctly by git, and millions of people do it daily.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
73. Re: Linus Wins Again by Zero__Kelvin · 2017-05-28 11:41 · Score: 1
  
  GVFS is an attempt to get the performance these Linux kernel level features afford to git by taking a shortcut and rather making the Windows kernel better, sacrificing correct functionality of the application in exchange for the illusion of performance. Do you not know that git on Linux is much faster than git on Windows, and the reason is because the Linux kernel has these features and the Windows kernel does not? Perhaps I'm not entirely clear on where your ignorance lies.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Distributed Hg. by Anonymous Coward · 2017-05-24 11:26 · Score: 1

How come they didn't go with Mercurial?
1. Re:Distributed Hg. by Daltorak · 2017-05-24 11:55 · Score: 4, Informative
  How come they didn't go with Mercurial?
  Some obvious reasons off the top of my head:
  
  - Visual Studio and TFS already have full CLI, GUI, and web-based support for Git. No such tooling exists for Mercurial.
  - Microsoft has contributed to libgit2 for years.
  - Mercurial is written in Python -- it's a small thing, but it's one more thing for a dev to maintain on their system.
  - Git is easier to hire for.
  You can also make the argument that Git was designed from the beginning to be suitable for developing an operating system. Or, put more bluntly, it was designed to be used by programmers who are smart enough to work on an operating system, Yes, the Mercurial CLI is generally easier to come to grips with, but that isn't a compelling enough reason on its own.
  Keep in mind also that the overall direction of Mercurial is increasingly being driven by the needs of Facebook's dev teams. Which is great to see, in the sense that they're returning their enhancements to the community..... but by and large they're building web properties, not operating systems, so the priorities may be different.
2. Re:Distributed Hg. by Anonymous Coward · 2017-05-24 12:15 · Score: 2, Funny
  
  git's interface wasn't "designed" at all, and it shows badly. That's why there's almost one tutorial on the web per person who figured out how to use it.
  The article summary also leaves out the minor point that MS had to write an entire abstraction layer underneath Git because it's so incapable of handling a large repository. And yes, there are actually good reasons to have a "monolithic" repository. Just because your favorite version control system can't do something doesn't mean it's a bad idea.
3. Re:Distributed Hg. by Rutulian · 2017-05-24 13:34 · Score: 4, Insightful
  
  The article summary also leaves out the minor point that MS had to write an entire abstraction layer underneath Git because it's so incapable of handling a large repository.
  Not completely true. They call it GVFS, but all it really does is prevent the entire repository from being downloaded when you clone it. Instead it downloads "only what you need". And there are a couple of patches to make git aware that this is happening, so that it stats only what is local and not the whole repository. One might argue that since the developer teams are not working on the entire codebase at once but rather on, let's call them "modules", within the larger repository, then the repository itself should be made more modular that match this development pattern. That would be more inline with the way Git was designed in the first place, and these extensions would not be as necessary. Still, to have the capability is nice.
  
  Just because your favorite version control system can't do something doesn't mean it's a bad idea.
  No, but pick the right tool for the job. If you are not developing modular, self-contained code in a decentralized fashion, don't use a source control system designed with those explicit goals in mind.
  Notice how LibreOffice splits up their fairly large codebase into several smaller repositories,
  https://github.com/LibreOffice
  Seems to work pretty well for them.
4. Re:Distributed Hg. by Billly+Gates · 2017-05-24 14:18 · Score: 1
  
  I may add getvfs is opensource and Microsoft provided the patch. It's up to the Git team to include it.
  
  --
  http://saveie6.com/
5. Re:Distributed Hg. by Anonymous Coward · 2017-05-24 16:07 · Score: 0
  
  Because they aren't retarded.
6. Re:Distributed Hg. by Anonymous Coward · 2017-05-24 18:33 · Score: 0
  How come they didn't go with Mercurial?
  Some obvious reasons off the top of my head:
  - Visual Studio and TFS already have full CLI, GUI, and web-based support for Git. No such tooling exists for Mercurial.
  Mercurial has TortoiseHG, which is better than any GUI for Git that I know of. (Well, any free one. There is a commercial one or two that look promising.)
7. Re:Distributed Hg. by EmyrDerfel · 2017-05-24 21:55 · Score: 1
  
  Seems easier than trying to manage independent source repos for dependencies. Nuget works great for release-versions of public packages, but if you need to add something to a dependency and to the consuming project AND test them both together before releasing, it all gets a bit messy and your build/CI process becomes a project to create and maintain... Not that they'll be using NuGet. Time to re-implement more of Windows in C#?
8. Re:Distributed Hg. by TheRaven64 · 2017-05-24 21:59 · Score: 0
  
  I've found that this is actually a feature of git. The CLI is so spectacularly bad that it's actually motivated people to write decent GUIs so that they don't have to use it. In contrast, the svn and hg CLIs are just mediocre and so persevere trying to use them directly.
  
  --
  I am TheRaven on Soylent News
9. Re:Distributed Hg. by Rutulian · 2017-05-25 01:14 · Score: 1
  
  Seems easier than trying to manage independent source repos for dependencies.
  If that's the only reason, then that's pretty silly. A decent dependency-management system is the right solution.
  Let's say package A depends on packages B and C. B makes an incompatible change that breaks A, so A has to know that only the previous version of B will work without a patch. Patch goes in to A, and now new version of A works fine with new version of B. Meanwhile, a new feature in A requires an update to C, so C is updated and A development continues. A build/runtime-dependency system should be able to sort all of this out easily. Package A needs to specify which versions of B and C it is known to work with, and every time B and C are checked out, it is only those versions that are used. When B or C are updated, the new changes have to be vetted by the A team before they are incorporated into the build. If multiple packages also use B and C as dependencies, the respective teams either a) coordinate their updates to B and C so as to not break each other, and/or b) open separate branches of B and C and merge them at some later date, verifying that all of their unit tests are successful in the process. As a bonus, it should be relatively easy to rewind history a bit and build a prior version of A against older versions of B and C as well if you want to do some sort of differential code analysis. Everything is in the respective change histories, and all of the diffs are saved, so software should be able to do all of this.
10. Re: Distributed Hg. by Zero__Kelvin · 2017-05-25 03:10 · Score: 1
  
  No. It's up to the git team to reject breakage.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
11. Re: Distributed Hg. by Anonymous Coward · 2017-05-25 12:49 · Score: 0
  
  No. It's up to the git team to reject breakage.
  What breakage?
12. Re: Distributed Hg. by Zero__Kelvin · 2017-05-25 13:10 · Score: 1
  
  Not cloning the whole repo at clone time completely breaks the distributed model. The whole purpose of distributed SCM is that you don't need network connectivity to do your work, only to push and pull changes. Microsoft breaks git the way they break everything else and for the same reasons. They have no idea what they are doing and do things differently without understanding why it was done that way to begin with.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
13. Re: Distributed Hg. by Anonymous Coward · 2017-05-25 14:10 · Score: 0
  
  Just like things like gitlfs do. How exactly do you handle large files in Git in a performant way without lazy evaluation? There is also much more to git than just being distributed.
  when you work on large repositories you do need to mitigate those issues and even on linux with large repos you are still bound by the efficiency of lstat when doing operations like a 'git status' so having the whole repo there rather than lazily evaluating files is very often a valid tradeoff, hence the popularity of Git LFS for example.
14. Re: Distributed Hg. by Zero__Kelvin · 2017-05-25 14:27 · Score: 1
  
  "How exactly do you handle large files in Git in a performant way without lazy evaluation?"
  You are kidding right? gitlfs is a git extension implemented by someone other than the git maintainers. It hasn't been accepted in the git mainline for a reason. It is specifically for large files. If you have large files in your source code you are doing it wrong. Defaulting to the behavior is phenomenally stupid. Furthermore, gitlfs has nothing to do with the size of the repository.
  
  "having the whole repo there rather than lazily evaluating files is very often a valid tradeoff"
  You misspelled "almost always, and certainly for every use case for which git was designed". You just came right out and said it, and don't seem to know it. Having lazy evaluation as the default is fscking stupid.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
15. Re:Distributed Hg. by TemporalBeing · 2017-05-25 15:33 · Score: 1
  
  Seems easier than trying to manage independent source repos for dependencies.
  If that's the only reason, then that's pretty silly. A decent dependency-management system is the right solution.
  Let's say package A depends on packages B and C. B makes an incompatible change that breaks A, so A has to know that only the previous version of B will work without a patch. Patch goes in to A, and now new version of A works fine with new version of B. Meanwhile, a new feature in A requires an update to C, so C is updated and A development continues. A build/runtime-dependency system should be able to sort all of this out easily. Package A needs to specify which versions of B and C it is known to work with, and every time B and C are checked out, it is only those versions that are used. When B or C are updated, the new changes have to be vetted by the A team before they are incorporated into the build. If multiple packages also use B and C as dependencies, the respective teams either a) coordinate their updates to B and C so as to not break each other, and/or b) open separate branches of B and C and merge them at some later date, verifying that all of their unit tests are successful in the process. As a bonus, it should be relatively easy to rewind history a bit and build a prior version of A against older versions of B and C as well if you want to do some sort of differential code analysis. Everything is in the respective change histories, and all of the diffs are saved, so software should be able to do all of this.
  And that is why you have tools like SVN Externals and Git Submodule. You version A, B, C, and their shared headers all separately. Each makes releases.
  
  So A depends on B and C. All three depend on D - the shared headers. If the interface for B or C changes, then D makes a new release with the change and then B or C get updated to match the new interface and released at the same time. Once B and C are released, then A gets the updated and makes it's release.
  
  Now if B or C get a fix but the interface doesn't change - then A can update its reference to B or C and just keep moving without having to also change the reference to D.
  
  Yep...been there done that, and been able to move projects very quickly as a team and on my own in a very stable fashion and without having bug fixes regress (which Microsoft is also well known for).
  
  That's what project management is suppose to help accomplish.
  
  --
  Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
16. Re: Distributed Hg. by Anonymous Coward · 2017-05-25 16:40 · Score: 0
  
  If you have large files in your source code you are doing it wrong.
  nobody said anything about "source code", you are confused.
17. Re: Distributed Hg. by brantondaveperson · 2017-05-25 16:50 · Score: 1
  
  They have no idea what they are doing
  Hi, Kelvin. I've got a feeling that they do know what they're doing, and they know perfectly well how git works, and what a distributed model means, and I suspect that Microsoft contains lots and lots of people that are much smarter than you and me. Microsoft is not a distributed company, it is a centralised organisation, and - like 99% of the corporate world - has no need of a distributed model.
18. Re: Distributed Hg. by Zero__Kelvin · 2017-05-25 21:50 · Score: 1
  
  Really? Microsoft has switched to git to keep track of their downloaded porn then I suppose? Idiot.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
19. Re: Distributed Hg. by Zero__Kelvin · 2017-05-25 21:54 · Score: 1
  
  Well you would be quite wrong, and referring to your level of intelligence and mine in the same sentence is absurd as you proved when you went around saying git doesn't work properly when I proved it does, or saying that directories aren't files on a Linux system. Smart people learn from people with far more knowledge than they have. You, sir, are not smart. You are the classic idiot who thinks he is smart
  
  " Microsoft is not a distributed company, it is a centralised organisation, and - like 99% of the corporate world - has no need of a distributed model."
  Holy shit. You are one dumb motherfucker. Why did they switch to a distributed SCM again? Oh that's right, because they have no need for it. I was reading your post while taking a sip of coffee, and you owe me a new keyboard motherfucker. :-) . Now off you go.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
20. Re: Distributed Hg. by brantondaveperson · 2017-05-28 09:27 · Score: 1
  
  Look man, you're just a rude and unpleasant person. Perhaps you just play one on the internet, and maybe in real life you're generally lovely and nice to people. It's interesting reading your comments though, they seem to take irrational and weird contrarian viewpoints, and spent most of their time missing the point and insulting people. There's clearly no point actually arguing with you, as the whole 'directories are really files' thing demonstrates. It's entirely irrelevant whether they are, or aren't, because that's an implementation detail, and is of no practical importance when writing actual userland code. Git doesn't track them, end of story.
  Please enjoy the rest of your commenting, and do try to be a more pleasant person if you possibly can. It's surprisingly not all that hard, and you might even find yourself liking it.
21. Re: Distributed Hg. by Zero__Kelvin · 2017-05-28 11:35 · Score: 1
  
  I specifically proved that git works. Claiming otherwise makes you an idiot. If you don't want to be called an idiot, don't keep making the ridiculous statements you keep making. Again, I followed your steps and got the correct results, not the ones you claim you got. I don't know if you are incompetent or lying, but git handles the use case you describe just fine, so stop spreading misinformation.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
22. Re: Distributed Hg. by brantondaveperson · 2017-05-28 12:07 · Score: 1
  
  No you didn't, you silly person. You ended up with two folders, I wanted to end up with one, because I'd merged in a folder move. Silly.
23. Re: Distributed Hg. by Zero__Kelvin · 2017-05-28 13:36 · Score: 1
  
  OMFG. Please tell me you aren't that incompetent. Please tell me that you don't think that a merge should have resulted in one directory named B containing file.txt and file1.txt. That isn't how SCM works. SCM doesn't track commands nor should it. Suppose I merge in 200 different changes from 200 different people, all who change the directory name. How will I do those 200 merges? One guy moves A to B while another moves A to C and yet another A to D. I merge the guy who moved A to D first. Then I merge the guy who moved A to C. But there is no A to move to C! I hate to break it to you but SCM tools don't keep track of actions, they keep track or results. There is no properly working SCM Tool that does what you describe. You are literally complaining because git works properly, and you want it to be broken. Now seriously, I can see you have never used an SCM Tool before. You might want to learn the basics before criticizing the masters.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
24. Re: Distributed Hg. by brantondaveperson · 2017-05-28 14:10 · Score: 1
  
  The thing that astonishes me the most, is that you just realised what I'm on about. At least we got there in the end. I didn't read the rest of what you wrote, because it looked boring.
25. Re: Distributed Hg. by Zero__Kelvin · 2017-05-28 14:17 · Score: 1
  
  In my defense I didn't think that anyone that fucking stupid could actually operate a computer. It never occurred to me that you could know what git is and be that clueless, or that your keyboard would still work with all the drool that must be on it you drooling fucking idiot.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
26. Re: Distributed Hg. by brantondaveperson · 2017-05-28 14:34 · Score: 1
  
  It is a problem, I admit. I have to regularly replace my keyboard, since the drool-proof ones are nowhere near as impervious to saliva as you might expect.
  It's weird though, isn't it? I mean, I know how git works, know all about the hashes and the merging and the lack of branch metadata, etc etc etc. Despite that, here I am believing that because I renamed a directory on one branch, and merged that action back into another, the directory should actually be re-named. Or, at least, a conflict should be generated if someone added new files to that (now renamed) directory. Such a strange idea. It must be the massive amounts of alcohol that I consume while working on this software for the airline industry, that'll probably cause the damn thing to fall out of the sky. Don't fly, Zero, don't fly, it's not safe up there. You know they have three identical computer systems in planes? And they, like, vote to see which one says what? And if they all disagree, well, god knows what happens. Plane probably bloody explodes, I expect.
  Now, where was I? Oh, I remember, having a pointless argument with a rude and arrogant internet human. Right. So, your defense for not understanding what I was talking about, despite my perfectly clear explanations, was that you didn't think anybody could be so stupid to have advanced an argument that you didn't actually try to understand, and thus were in no position to judge the stupidity of? Gotcha.
  You're quite a sophisticated a probably genius-level troll, really. What are you working on at the moment?
27. Re: Distributed Hg. by Zero__Kelvin · 2017-05-29 00:19 · Score: 1
  
  A isn't A dumbshit. Suppose I have a directory named mydir and rename it to hisdir. Someone else has a dir named herdir and renames it to mydir. Yet a third developer has a dir named hisdir and renames it to herdir. Now git comes along and does what when merging all three developer's changes? Stop believing the problem is that I am rude, and start realizing that the problem is that you are clueless and have decided git should do something that would not only be stupid, but impossible to do properly.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
28. Re: Distributed Hg. by brantondaveperson · 2017-05-29 09:16 · Score: 1
  
  I believe that would be a conflict, sir.
29. Re: Distributed Hg. by Zero__Kelvin · 2017-05-29 09:22 · Score: 1
  
  I don't doubt that you do. Off you go now ....
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
30. Re: Distributed Hg. by brantondaveperson · 2017-05-29 12:20 · Score: 1
  
  It's only an impossible problem if you try to do it before breakfast.
31. Re: Distributed Hg. by brantondaveperson · 2017-05-29 12:22 · Score: 1
  
  Also, the irony that what you claim is impossible for directories, is already implemented for files, while earlier explaining to me how directories and files were the same thing, is making me smile. This means you have made one person smile today, which is probably a fairly unusual outcome for you, given how rude you seem to normally be.
32. Re: Distributed Hg. by Zero__Kelvin · 2017-05-29 12:38 · Score: 1
  
  Files have hashes. Directories don't. Off you go now ...
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
33. Re: Distributed Hg. by Zero__Kelvin · 2017-05-29 12:39 · Score: 1
  
  The only thing I have found impossible to do today is to get you to realize what a complete moron you are actually.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
34. Re: Distributed Hg. by brantondaveperson · 2017-05-29 13:03 · Score: 1
  
  But I thought they were the same thing? You said they were, earlier on. I'm trying to learn from you, Kelvin, but if you keep on changing your tune, it's going to be very hard.
  Luckily, just like every single other objection in your entire screed, this one is totally irrelevant. Hash the empty string, if you really want a hash, since that must be what git does with an empty file, right? Or - how about it stores some extra metadata? Who cares? Implementation detail. Figure it out, you're a smart guy. Point is, git doesn't handle the situation that I argued it should, and you banged on for ages about how I was wrong, and when you finally troubled yourself to read my original point, you told me that what I think should happen is impossible. Which is nonsense, of course.
35. Re: Distributed Hg. by Zero__Kelvin · 2017-05-29 13:12 · Score: 1
  
  Again, you are a idiot. I am not so stupid I will try to teach an idiot. If you can't see why your idea is broken, and can't accept that people MUCH smarter than you understand all of this, then I really don't care. Keep saying git is broken. It is a red flag for all of us so we don't hire you or have to work with you. Thank you for continuing to believe and insist that you are smarter than Linus Torvalds and the rest of the world. Seriously.
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
36. Re: Distributed Hg. by Anonymous Coward · 2017-05-29 14:42 · Score: 0
  
  > you are a idiot
  gold, just gold. He is a idiot indeed. You a idiot too yes?
  What I don't understand is how someone like you can be embarrassed over and over again, have egg on your face over and over again, yet keep coming back with insults.
  just got done dissing a parody account for "making mistake" w/o reading the user name he was replying to. Literally went on and on - the best clown show I've seen in a while. Then ignores all that and goes on the attack of someone else like nothing happened. Does having egg on your face so much just get you used to the egg?
  He a idiot. You a idiot too. If you can't accept that the people you usually attack here are MUCH smarter than you, I guess you have to just get used to being wrong in a funny way, and the joke of the site. Like Criemer. I mean Creimer. I mean Cdreimer. I mean Creamer. Damn. What was I talking about again? Oh yeah - take your pills, it'll stop that thing like someone is turning a screw too tight in your head. Clown.
37. Re: Distributed Hg. by Anonymous Coward · 2017-05-29 15:05 · Score: 0
  
  Some people post from phones. Smart people get that and its implications.
What were they using before? by muphin · 2017-05-24 11:36 · Score: 1

anyone know how they managed the code before moving to Git?

--
It's not a typo if you understood the meaning!
1. Re: What were they using before? by Anonymous Coward · 2017-05-24 11:40 · Score: 0, Funny
  
  Visual Source Safe.
2. Re:What were they using before? by DaHat · 2017-05-24 11:42 · Score: 2
  
  Source Depot... which is a modified version of Perforce.
  
  --
  Help Brendan pay off his student loans
3. Re:What were they using before? by Anonymous Coward · 2017-05-24 11:42 · Score: 1
  
  SourceSafe, Team Foundation.
4. Re:What were they using before? by Anonymous Coward · 2017-05-24 11:43 · Score: 1
  
  sourcesafe :)
5. Re: What were they using before? by Anonymous Coward · 2017-05-24 12:09 · Score: 1
  
  Somewhere, a group of developers Redmond just spontaneously burst into laughter.
6. Re: What were they using before? by zippthorne · 2017-05-24 13:18 · Score: 1
  
  Does that require or forbid use of the Volume Shadow Service on the drives it resides on?
  
  --
  Can you be Even More Awesome?!
7. Re:What were they using before? by sconeu · 2017-05-24 17:08 · Score: 1
  
  I thought they had an "eat your own dog food" policy, so I'm going to guess Team Foundation Server.
  
  --
  General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
8. Re:What were they using before? by lucm · 2017-05-24 17:39 · Score: 1
  
  It's in the article.
  
  At the time, Microsoft was using SourceDepot, a customized version of the commercial Perforce version control system, for all its major projects.
  
  --
  lucm, indeed.
9. Re: What were they using before? by lucm · 2017-05-24 17:53 · Score: 3, Insightful
  
  Get real. Windows has owned the market for 25+ years already and the Western Civilization has become consistently more computerized during that period, which definitely didn't happen because of OpenVMS or QNX or some other wonder of software engineering.
  Besides John Deere or Tupperware, not a lot of products have enjoyed such stability.
  
  --
  lucm, indeed.
10. Re:What were they using before? by mrun4982 · 2017-05-25 02:33 · Score: 1
  
  Source Depot, which is a custom version of Perforce. Some other teams at least eventually started using Team Foundation Server, howerver.
11. Re: What were they using before? by lucm · 2017-05-25 13:13 · Score: 1
  
  The web began to have some kind of economical relevance around or after the first dot-com bubble. The first mainstream version of Windows came out in 1989. And already at the time Microsoft had done a lot to promote end-user computing (i.e. PC).
  It's okay to dislike Windows but don't rewrite history, even if you feel the need to mention iPhones.
  
  --
  lucm, indeed.
12. Re: What were they using before? by TemporalBeing · 2017-05-25 15:34 · Score: 1
  
  Visual Source Safe.
  Microsoft has famously never used VSS itself. ;)
  
  --
  Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
13. Re:What were they using before? by TemporalBeing · 2017-05-25 15:35 · Score: 1
  
  I thought they had an "eat your own dog food" policy, so I'm going to guess Team Foundation Server.
  TFS is just a wrapper around other VCSes. It supports git, svn, cvs, vss, and a bunch of other tools. So yes, they've been using TFS but TFS itself doesn't do VCS.
  
  --
  Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
I liked the Microsoft with confidence much, much m by Anonymous Coward · 2017-05-24 11:40 · Score: 0

ore. The new "Sissy MS" sucks.
Re: In Awe by Anonymous Coward · 2017-05-24 11:43 · Score: 0, Funny

Thanks you fucking moron!
-Linus
Re:But they're still allowing some of us... by 0100010001010011 · 2017-05-24 11:44 · Score: 1

Is Source Depot better than Clear Case?
VSS ? by mikaere · 2017-05-24 11:44 · Score: 1

When did they stop using Visual Source Safe ?

--
It's good luck to be superstitious
1. Re:VSS ? by Gravis+Zero · 2017-05-24 12:00 · Score: 5, Funny
  
  When did they stop using Visual Source Safe ?
  Microsoft Visual SourceSafe was first released in 1994, so by my estimate they stopped using it in 1994.
  
  --
  Anons need not reply. Questions end with a question mark.
2. Re:VSS ? by Anonymous Coward · 2017-05-24 13:10 · Score: 0
  
  They have never used VSS for internal development or at least up until early 2005 or so. A friend ran into issues with VSS and MS Access and after the developers giving round about answers for things I'd asked what they used internally and they said it was a custom system.
3. Re:VSS ? by Jeremi · 2017-05-24 13:32 · Score: 1
  
  Microsoft Visual SourceSafe was first released in 1994, so by my estimate they stopped using it in 1994.
  Nonsense, they continue to use it to this day. It plays a prominent role in their initiation/hazing of new interns.
  
  --
  
  I don't care if it's 90,000 hectares. That lake was not my doing.
4. Re:VSS ? by Anonymous Coward · 2017-05-24 16:25 · Score: 0
  
  When did they stop using Visual Source Safe ?
  If they ever used it, it was for a very short time. VSS is very WIndows-centric, and it has been well known that the Windows Source Code was not even hosted on Windows using some kind of CVS variant. That didn't change until this move to Git.
5. Re:VSS ? by lucm · 2017-05-24 18:00 · Score: 1
  
  Truth be told, Microsoft didn't create SourceSafe. They bought it. In some cases, like SQL Server or Visio, their acquisitions have been a success, but more often than not (such as SourceSafe or Dynamics AX) they have gone downhill fast.
  
  --
  lucm, indeed.
6. Re:VSS ? by Xest · 2017-05-24 20:58 · Score: 1
  
  I don't think many people have been using VSS for a long time. It was replaced by TFVC (Team Foundation Version Control) back in I think about 2005 as part of TFS (Team Foundation Server).
  I don't think they ever used this for the Windows source code though. I think they were using Perforce or something.
7. Re:VSS ? by Junta · 2017-05-25 01:58 · Score: 1
  
  Note that while I am not going to defend VSS, while it is fun to poke at a company for not eating their own dog food, in this case it *could* make sense.
  What is appropriate for managing a project as complex as an entire operating system is not necessarily what is appropriate for 99% of their customers who want to manage code in a project.
  Just like the way MS runs Azure probably looks nothing like what they have customers run.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
8. Re:VSS ? by Honclfibr · 2017-05-25 04:27 · Score: 1
  
  Truth be told, Microsoft didn't create SourceSafe. They bought it. In some cases, like SQL Server or Visio, their acquisitions have been a success, but more often than not (such as SourceSafe or Dynamics AX) they have gone downhill fast.
  VSS started at the bottom of the hill. From there, it dug a hole and buried itself.
Re:But they're still allowing some of us... by DaHat · 2017-05-24 11:45 · Score: 1

Why are they allowing the use of Source Depot as a way to eventually check in to Git?
It would seem better to draw a line in the sand and say "beyond this point, we are all using Git... though for historical reasons the old repos will be kept around for reference and SE"?

--
Help Brendan pay off his student loans
Re: In Awe by Anonymous Coward · 2017-05-24 11:55 · Score: 0

Hey, alright! I've been cursed out by Linus Torvalds himself!
Re:But they're still allowing some of us... by Anonymous Coward · 2017-05-24 12:01 · Score: 0

Anything is better than ClearCase.
Something's wrong by Drunkulus · 2017-05-24 12:02 · Score: 5, Funny

I ran a git pull origin master, which seemed to work fine, but now I have a bunch of code that's copyright 1993 Digital Equipment Corporation?
1. Re:Something's wrong by Paul+Fernhout · 2017-05-24 14:26 · Score: 1
  
  That's funny. When I tried that, it said copyright 1980 Gary Kildall and Digital Research... The repo must be corrupt...
  https://en.wikipedia.org/wiki/...
  https://en.wikipedia.org/wiki/...
  "Kildall obtained a copy of PC DOS, examined it, and concluded that it infringed on CP/M. When he asked Gerry Davis what legal options were available, Davis told him that intellectual property law for software was not clear enough to sue.[12] "
  
  --
  A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
2. Re:Something's wrong by __aaclcg7560 · 2017-05-24 15:20 · Score: 1
  
  That story got covered in "Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" by G. Pascal Zachary. A great book that is out of print and not available in ebook format.
3. Re:Something's wrong by Anonymous Coward · 2017-05-24 22:59 · Score: 0
  
  I've got that book in print, sitting on my bookshelf. Other than the copious typos, it's a good read. Lots of Dave Cutler stories.
Re: And Microsoft still sucks by Anonymous Coward · 2017-05-24 12:08 · Score: 0

Cool. Subscription and advertising-based everything that ceases to exist when it's no longer profitable. Seems like a great reason to move away from a very effective operating system.
Re:But they're still allowing some of us... by Anonymous Coward · 2017-05-24 12:24 · Score: 0

Anything is better than ClearCase.
Visual SourceSafe? PVCS?
Cool stuff by swillden · 2017-05-24 12:38 · Score: 5, Interesting

The work they've done to make Git scale to fit their needs sounds great, and I see they've open-sourced the key components. That's awesome. At the moment it looks like GVFS is Windows-only (not a big surprise -- and not a complaint; they built what they needed). I'd like to see someone port it to Linux and make this infrastructure more broadly available. It sounds like it would be much nicer to work on than the "repo" tool that Android layers on top of Git to enable managing a whole bunch of smaller repositories.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
1. Re:Cool stuff by Billly+Gates · 2017-05-24 14:16 · Score: 1
  
  Microsoft released gitfs as opensource. It's there for anyone to patch.
  My guess is MS hatred is why in the opensource community
  
  --
  http://saveie6.com/
2. Re:Cool stuff by waveclaw · 2017-05-24 15:40 · Score: 2
  
  Jakub's Mastering Git book discusses briefly that git is less a version control system in itself and more a tool for building version control systems.
  Alternative user interfaces like Zit, Cogit and Yap show that there is some merit to this view.
  Git's content-addressable data store with locally computable global identifiers can form the basis of a generic storage engine. Microsoft has created what appears to be another file system out of git. There are many other filesystem implementations.
  The git wrapper and workflows used by the Linux project can be seen as just the demonstration of one implementation. Collaboration and hosting sites like GitHub and GitLab show that you can turn a git repository into a project management tool. People have even built code review tools out of git (Critic, git-issues, etc.)
  I wonder if Microsoft could implement something like etckeeper for the registry? (It would be nice to be able to run git blame after corruption by some vendor's installer.)
  I do find it odd that Microsoft is switching to git so the team can put Windows into a single, giant repository while trying to modularize the product. One would think that the prior Perforce based system would have suited the modularization goal. That was forcing multiple repositories on the developers to meet the scale of the codebase. Perhaps the intent is to centralize then reorganize and break out into logical modules again? (It could be a control freak VCS team that is jumping at the chance to become the gatekeepers.)
  The article does mention that "the company wanted to develop a single engineering system ('1ES'), spanning not just version control, but bug tracking, building, and more, that could span the entire company. " This makes the next version of Team Foundation Server sound a lot like GitHub Enterprise from Microsoft. Should Microsoft offer this 1ES environment for sale? It could certainly add a twist to the corporate on-premise or could-based git hosting market.
  
  --
  
  "You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
3. Re:Cool stuff by Anonymous Coward · 2017-05-24 16:31 · Score: 0
  
  The work they've done to make Git scale to fit their needs sounds great, and I see they've open-sourced the key components. That's awesome. At the moment it looks like GVFS is Windows-only (not a big surprise -- and not a complaint; they built what they needed). I'd like to see someone port it to Linux and make this infrastructure more broadly available. It sounds like it would be much nicer to work on than the "repo" tool that Android layers on top of Git to enable managing a whole bunch of smaller repositories.
  Why? The only reason to use their GVFS is to (a) work with VS and TFS - both of which are Windows-only (no, VS Code doesn't count, it doesn't have 95% of the features of VS), and (b) to use their broken development model of locking files when you're working on them. Neither of those is desirable to anyone using git or who understands proper VCS systems.
  SVN supported File Locking but they also heavily advocated against actually using such functionality saying your development model if using it was outright broken and should be fixed instead of using the File Locking.
4. Re:Cool stuff by swillden · 2017-05-24 23:42 · Score: 1
  
  The work they've done to make Git scale to fit their needs sounds great, and I see they've open-sourced the key components. That's awesome. At the moment it looks like GVFS is Windows-only (not a big surprise -- and not a complaint; they built what they needed). I'd like to see someone port it to Linux and make this infrastructure more broadly available. It sounds like it would be much nicer to work on than the "repo" tool that Android layers on top of Git to enable managing a whole bunch of smaller repositories.
  Why? The only reason to use their GVFS is to (a) work with VS and TFS - both of which are Windows-only (no, VS Code doesn't count, it doesn't have 95% of the features of VS), and (b) to use their broken development model of locking files when you're working on them. Neither of those is desirable to anyone using git or who understands proper VCS systems.
  Huh? I see absolutely nothing related to locking in GVFS. The GVFS protocol has no mechanisms for acquiring or releasing locks, and locking isn't mentioned anywhere else in the documentation. From everything I can see in the code, issues, documentation and TFA, GVFS just provides lazy fetching of git objects, which makes it possible to "check out" a large repository without having to wait for everything to download, and also optimizes the stat'ing of files that git does so much of.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
5. Re:Cool stuff by Actually,+I+do+RTFA · 2017-05-25 05:06 · Score: 1
  
  At the moment it looks like GVFS is Windows-only
  It's written in C#, which has virtual machines for Linux and OS X as well. So, if it does need to be ported, it will probably happen pretty quickly. Possibly even faster than if it was written in C/C++.
  
  --
  Your ad here. Ask me how!
Obligatory xkcd by Anonymous Coward · 2017-05-24 13:05 · Score: 0

https://xkcd.com/1597/
1. Re:Obligatory xkcd by Anonymous Coward · 2017-05-24 16:56 · Score: 0
  
  xkcd is not an more obligatory than UserFriendly. We're all fucking sick of people posting it.
2. Re:Obligatory xkcd by Anonymous Coward · 2017-05-24 20:38 · Score: 0
  
  Speak for yourself.
3. Re:Obligatory xkcd by Anonymous Coward · 2017-05-31 03:22 · Score: 0
  
  You must speak for the aspies that like repetitive and unfunny things.
Wait, what? by sqlrob · 2017-05-24 15:17 · Score: 1

The Windows repository now has about 4,400 active branches, with 8,500 code pushes made per day and 6,600 code reviews each day.
I really, really hope those 1900 unreviewed pushes are all developers just wanting to make sure their code is backed up and are pushes to private branches.
1. Re:Wait, what? by H0p313ss · 2017-05-24 16:29 · Score: 1
  
  Review system could easily cover multiple pushes per review, the git based one we use certainly can and it's not terribly sophisticated otherwise.
  
  --
  XML is a known as a key material required to create SMD: Software of Mass Destruction
Problem wif open source is... by Anonymous Coward · 2017-05-24 16:02 · Score: 0

you gotta let just about any ol git use it.
inaccurate by lucm · 2017-05-24 17:16 · Score: 5, Informative

You obviously didn't RTFA. They had to create this GVFS thing because their code base is huge and they don't want to sync hundreds of gigs between remote locations. Also they were not using VSS before switching to Git, they were using Perforce.
It's not a WTF. It's a great achievement and will probably become a standard component of large-scale git repos. If you ever had to deal with huge repos that are used by teams in many timezones you'd understand that.
For reference, the Linux kernel git repo is about 6GB all in. The Windows git repo is 300GB. We can all guess that in that 300GB there's a fair amount of dead wood but still, in an era where storage is dirt cheap, one shouldn't have to trim down a code source repo because the vcs can't keep up.

--
lucm, indeed.
1. Re:inaccurate by mysidia · 2017-05-24 20:26 · Score: 1
  
  in an era where storage is dirt cheap, one shouldn't have to trim down a code source repo because the vcs can't keep up.
  Cold storage is dirt cheap, not active/hot storage.
  If your codebase is somehow 300GB of code..... Imagine what kind of attack surface that represents. This kind of size is about insane.....
2. Re:inaccurate by Anonymous Coward · 2017-05-24 21:00 · Score: 1
  
  If your codebase is somehow 300GB of code..... Imagine what kind of attack surface that represents. This kind of size is about insane.....
  Quite a lot of that probably represents test cases, tools and test results for comparison. All of which you want to keep versioned with the code to which it corresponds. It gets messy if you start splitting the code up from the tests using things like submodules.
3. Re:inaccurate by swillden · 2017-05-24 23:56 · Score: 1
  
  If your codebase is somehow 300GB of code..... Imagine what kind of attack surface that represents. This kind of size is about insane.....
  Heh. Google's source repository was 86 PB (yes, that's 86,000,000 GB), in 2015. It's bigger now. Google uses Perforce, BTW, the thing that MS migrated away from because it ostensibly couldn't handle their puny 300 GB repo.
  It should be noted that Google's source repository contains more than just source code. In particular, it contains all of the build tools, compilers, libraries, etc. so when you check out a given revision of some project and build it, you build it with the tools used to build it originally. I'm sure there are lots of other sorts of non-code resources in there as well.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
4. Re: inaccurate by Anonymous Coward · 2017-05-25 00:25 · Score: 0
  
  Go fix an Android security hole swillden. There are plenty. You should be busier than you are.
5. Re:inaccurate by ausekilis · 2017-05-25 00:43 · Score: 1
  
  People are forgetting the most important part. Microsoft is actively trying to get some of these capabilities back into mainstream Git. They're actually, gasp!, giving back!
6. Re:inaccurate by Junta · 2017-05-25 01:40 · Score: 1
  
  Of course, if your repo is 300GB, you've done something wrong. That's not to say that there sholudn't be 300GB of resources going into a product, but having a *single* git repo encompass your entire product may be a bad call. It's not just whether the git software can keep up, I can guarantee you people struggle to keep up with the activity going on in the repo, when they really only care about more well defined subsets.
  It is a WTF in managing a product.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
7. Re: inaccurate by swillden · 2017-05-25 02:14 · Score: 1
  
  Go fix an Android security hole swillden. There are plenty. You should be busier than you are.
  I'm quite productive, thank you.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
8. Re:inaccurate by Anonymous Coward · 2017-05-25 02:29 · Score: 0
  
  That's not to say that there sholudn't be 300GB of resources going into a product, but having a *single* git repo encompass your entire product may be a bad call.
  Why? As far as I can tell splitting repositories of tightly coupled components and trimming them so that they don't contain large assets are largely a workaround over the fact that most VCS's can't handle it otherwise.
9. Re:inaccurate by Wdomburg · 2017-05-25 02:45 · Score: 1
  
  Google *used* Perforce. Past tense. Your own link details the custom system they built to replace it.
10. Re:inaccurate by Bite+The+Pillow · 2017-05-25 02:55 · Score: 3, Interesting
  
  I won't spend time searching for you, but there are blog posts from softies describing the various attempts over the years to segregate code, and this is the result of that failure.
  The evolution of windows from a DOS based illusion to a full client server model on a single computer resulted in a lot of bad decisions. Yes I'm aware of os2 and the parentage of XP via NT, but certain allowances were made so that Windows 98 and ME software would work on XP.
  There was no management and grand plan. Reading Charles Petzold and Raymond Chen make that clear. The effort continues. But this is a normal software company trying to ship product, not meet the ivory tower ideal. Hardly a defense, but the info is all out there, mostly documented in this switch to git. Mark Russinovich, SysInternals, Alex Ionescu have the unofficial story, in a sense. How we got here is clear if you know the history.
11. Re:inaccurate by lexman098 · 2017-05-25 03:04 · Score: 1
  
  Maybe I don't understand their problem exactly, but I'm not sure why they couldn't create separate git repos to be synced with the already available submodules or subtrees within git.
12. Re:inaccurate by gnasher719 · 2017-05-25 03:50 · Score: 1
  
  Of course, if your repo is 300GB, you've done something wrong.
  
  Maybe what you've done wrong is being one of the most successful software companies for the last forty years, and writing massive amounts of software. Well, maybe there has been one or the other video file check in at some point. That's actually a very good point for this: If some idiot checked a 2 Gigabyte video into your git repository, everyone doing a "git clone" has to download that video! And it can be really hard to remove it. With this file system, you wouldn't care (much).
13. Re: inaccurate by uM0p+ap!sdn+ · 2017-05-25 05:06 · Score: 1
  
  lol, and your using m$ or apple, lions & tigers & bears oh my
  android is the most used operating system in the world, with a linux kernel and the linux filesystem ext4
14. Re:inaccurate by swillden · 2017-05-25 06:14 · Score: 1
  
  Google *used* Perforce. Past tense. Your own link details the custom system they built to replace it.
  That's true now, and in 2015, but the commercial product was used until 2013 or so and when this paper was published in 2011, the Perforce metadata had exceeded 1TB. The paper doesn't give the total data size, but it certainly had to be in the region of tens of petabytes even then.
  The reason I didn't mention Piper (the in-house Perforce replacement) was because it seemed like unnecessarily complication. Google managed a Perforce repository approximately four orders of magnitude large than Microsoft before replacing it, so Piper isn't really relevant to the point.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
15. Re:inaccurate by Junta · 2017-05-25 06:37 · Score: 1
  
  So the point can be made that if it's something like a bunch of video files, it's weird, but could be a fair complaint about the VCS. Of course the VCS cannot meaningfully provide fine grained difference data about non-textual, so having the process have links to some more media appropriate storage would make sense.
  The other half is the implication that of the presumably massively far and wide code is in a single repository. A repository makes sense if people who access are *roughly* equally likely to access any part of it. If one portion of the repository is used by one team and they never touch the rest, and this is a common phenomenon, then it doesn't makes sense.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
16. Re:inaccurate by Junta · 2017-05-25 06:42 · Score: 1
  
  That success can *easily* be in spite of poor code management practices, or even if the code quality isn't that great.
  If they are having to spend a lot of time trying to change git to their use case, that means they are at *least* spending money on that. Given the sort of scenario that would drive these changes, I imagine the code workflow at microsoft is probably hideous. You can still get work done under those conditions, but probably in a really inefficient way.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
17. Re:inaccurate by lucm · 2017-05-25 12:49 · Score: 1
  
  Cold storage is dirt cheap, not active/hot storage.
  The cost for high-end enterprise storage is around $2,500 per TB according to Gartner. For commodity hardware it's around $30 per TB.
  This means that if Microsoft was to shrink their git repo by 1/3, they would save $275 for the gold copy stored on their SAN, and about $3 per developer cloning it.
  I don't know where you live but in my book, that's dirt cheap.
  
  --
  lucm, indeed.
18. Re:inaccurate by lucm · 2017-05-25 12:56 · Score: 1
  
  It is a WTF in managing a product.
  You don't like it, I get that, but that doesn't mean it's wrong. Every organization has different challenges and limitations, and whatever solution they find to solve their problems and sell their product is an achievement. This is not academia, this is real life with real dollars and real computers.
  
  --
  lucm, indeed.
19. Re:inaccurate by lucm · 2017-05-25 13:05 · Score: 1
  
  It's all in the article. Their previous system was split in 65 repos, but they wanted to have all Windows in the same repo to be in line with their new engineering strategy.
  They had 3 problems:
  1 - performance for cloning, which they fixed with that GVFS thing.
  2 - git processing files that were not modified (they changed the way it works to improve that)
  3 - slower and slower performance when many files are touched but not modified on the desktop (they also changed the way it works to improve that)
  
  --
  lucm, indeed.
20. Re:inaccurate by TemporalBeing · 2017-05-25 15:18 · Score: 1
  
  I won't spend time searching for you, but there are blog posts from softies describing the various attempts over the years to segregate code, and this is the result of that failure.
  Well...that's in all actuality a management failure. I'm familiar enough with a lot of stories about the codebase to say that it's a massive piece of junk. There is no reason why it couldn't be managed better and segregated - that'd actually help them in many many respects if they actually took to action and did it. But they're putting the priority in doing things other than making their life better. However, like with most companies they'll only actually do the hard work that's necessary when the shit hits the fan like with the XP -> Longhorn debacle that reset and create the XP -> Vista project - the only point in their history where they did a massive amount of work on the codebase itself without adding features because it was so borked.
  
  But then, their whole patch system is borked too - they have a long (long) history of one patch fixing something and then next unfixing it - sometimes delivered together. The WMF bug did that for years - originally fixed in the Win9x series it was still being fixed in Windows 8! Breaking apart the repository would help solve that. Treating your own projects as third-party tools helps solve that.
  
  And git has some nice utilities (f.e git submodule) that helps bring things together when you need to - projects become meta projects and you can track dependencies easily, do upgrades, etc. in very controlled ways.
  
  --
  Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
21. Re:inaccurate by TemporalBeing · 2017-05-25 15:21 · Score: 1
  
  You obviously didn't RTFA. They had to create this GVFS thing because their code base is huge and they don't want to sync hundreds of gigs between remote locations. Also they were not using VSS before switching to Git, they were using Perforce.
  I never said they actually *used* VSS. Actually, it's been well known that they have almost never used their own tool - VSS - nor hosted the source on Windows. No, I referenced functionality that is in VSS that is also in GVFS and nearly required for host VS works - which I'm pretty sure also exists in Perforce, Clear Case and a few others. SVN actually has the functionality too but their devs heavily advise against using it because if you need that kind of functionality your development process is actually broken.
  
  Oh - and I didn't need to RTFA this time because this whole move was discussed a long time ago. I already knew their reasoning - their reasoning just happens to be wrong. They need to fix their process and code management.
  
  --
  Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
22. Re:inaccurate by brantondaveperson · 2017-05-25 16:38 · Score: 1
  
  Of course, if your repo is 300GB, you've done something wrong.
  Another very typical response. Why? In what sense is it doing something wrong? Why does doing something that git can't deal with, necessarily doing something 'wrong'? I want to run my unit tests, they consume large amounts of data, I want that data on my machine. What's wrong with that?
23. Re:inaccurate by Wdomburg · 2017-05-30 02:45 · Score: 1
  
  Google made the switch in early 2012, but ultimately repository size is only one input into the performance of a revision control system. You're comparing two very different companies and a single produce repository to a global repository (which also includes things like documentation and build tools, which are presumably almost static content).
  If you look at something like code commits, presentations from Google show something on the order of 30-50k per week, which is in the same neighborhood as the 8500 per day that the Windows repository sees.
  And while it is laudable that Perforce could handle the repository at all, it is clear from the whitepaper that it took significant investment, ingenuity and vigilance in order to provide acceptable performance, including "monitoring with extreme prejudice". Many people would consider a revision control system that requires actively sniping long running commands unacceptable.
24. Re:inaccurate by swillden · 2017-05-30 03:09 · Score: 1
  
  Google made the switch in early 2012, but ultimately repository size is only one input into the performance of a revision control system. You're comparing two very different companies and a single produce repository to a global repository (which also includes things like documentation and build tools, which are presumably almost static content).
  Certainly; I never said otherwise.
  
  If you look at something like code commits, presentations from Google show something on the order of 30-50k per week, which is in the same neighborhood as the 8500 per day that the Windows repository sees.
  From the link above: "On a typical workday, they commit 16,000 changes to the codebase, and another 24,000 changes are committed by automated systems." So that's about 40K commits per day, quite a bit more than Microsoft.
  
  And while it is laudable that Perforce could handle the repository at all, it is clear from the whitepaper that it took significant investment, ingenuity and vigilance in order to provide acceptable performance
  Certainly. As did Microsoft's investment into Git. It's clear, though, that Microsoft's decision to switch wasn't made because Perforce couldn't handle the workload; it manifestly can given the right infrastructure. That trail had already been blazed by Google, so Microsoft clearly could have gone that route.
  Anyway, that wasn't really my point. My point was that 300 GB is not an insanely large repository. 90 PB is an insanely large repository :-)
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
25. Re:inaccurate by Wdomburg · 2017-05-30 03:48 · Score: 1
  
  You're quoting current numbers again. That shows what Piper can handle; not Perforce. They dramatically increased their commit rate (and in particular their automated commits) after the migration: ahref=https://youtu.be/W71BTkUbdqE?t=461rel=url2html-11078https://youtu.be/W71BTkUbdqE?t...>
  I suspect Google could have found a way to stay on Perforce as well, but ultimately there are good reasons to evaluate (and adopt) other options when you are running at unusual scale. It's interesting that the two companies went in opposite directions, and that it is Microsoft that decided to adapt and adopt an open source distributed solution while Google build a proprietary solution tailed to fit a more centralized system.
  Apparently Google did evaluate git, but it could not scale to larger repositories and they decided against breaking up into smaller repositories. In theory GVFS could make it a feasible option again.
  But yes, the broader point that 300GB is small by comparison stands. Scale is a funny thing. An elephant seems huge - and by all accounts *is* huge in most contexts - but is about the same size as just the tongue of a mature blue whale.
Re:But they're still allowing some of us... by Grishnakh · 2017-05-24 17:25 · Score: 2

Not using any revision control system, and instead just making copies of files before you change them and manually labeling them foo.v1.1.c and the like, is better than ClearCase.
Time to let go by lucm · 2017-05-24 17:32 · Score: 3, Insightful

If you try to make Git work like Subversion, you're doing it wrong. Stick with Subversion (or cvs for that matter) if that's what makes you comfortable and if you want to obsess about stuff like branches history. Otherwise read a good tutorial and pick a mainstream branching strategy such as Git flow.
Git branches are fantastic. They make life easier by allowing you to focus on the code without having to deal with side effects of Subversion-style branches, such as broken paths in config files. As for directory renames, if you use Git properly there's no problem.

--
lucm, indeed.
1. Re:Time to let go by brantondaveperson · 2017-05-25 09:59 · Score: 1
  
  I know exactly how git branches work thanks. Directory renames are not supported in merges, even if you use git 'properly', which I am doing as it happens. I also know how git flow works, and I think it's highly overcomplicated and best avoided. Branches increase development time, since every commit to any branch has a cost associated with it that multiplies by the square of the number of other branches, if those branches are eventually to be merged together. That's just the reality of coding with large teams. Technically automated and unit tests can save you here, but not everything is so easily tested.
  I've got no idea what broken paths in config files in SVN might be about, but I wasn't trying to defend SVN, I was pointing out that git leaves important metadata unrecorded, allows commits to be irrevocably lost, and doesn't merge anywhere near as well as advertised. Possibly the merging thing is almost an unsolvable problem, since what we really need is a language-aware merge that can deal with conflicts in a single line, by doing per-token merges, or something. But the other complaints stand.
2. Re:Time to let go by brantondaveperson · 2017-05-25 10:38 · Score: 1
  
  Wait. It's not the square, it's n(log(n)), but still. It's an overhead that's best avoided if at all possible. Which, it turns out, it is perfectly possible to do.
3. Re:Time to let go by ConceptJunkie · 2017-05-26 06:41 · Score: 1
  
  I was a bit overwhelmed by Git at first, but the more I learn about it, the more I'm impressed with it. Yes, it's still confusing at times, but I get the distinct impression that they (Linus and whoever else are the developers) have literally thought of everything. There are so many ways to do things, you can always find an approach that does what you need and makes sense.
  
  --
  You are in a maze of twisty little passages, all alike.
Re:But they're still allowing some of us... by lucm · 2017-05-24 17:37 · Score: 2

"SourceSafe" is even funnier than "Microsoft Works"

--
lucm, indeed.
LOL by Anonymous Coward · 2017-05-24 19:53 · Score: 0

Larry McVoy, eat you hat! :)
1760 builds each day? by Anonymous Coward · 2017-05-24 20:12 · Score: 0

It's like running Gentoo!
Where's the link to the repo? by sproketboy · 2017-05-24 23:38 · Score: 1

nt
Linus is the public face of a huge # of people by Anonymous Coward · 2017-05-25 01:10 · Score: 0

The Dear Leader always gets the glory, but the real work is done by everyone else.
1900 unreviewed commits per day? by MouseR · 2017-05-25 01:53 · Score: 1

with 8,500 code pushes made per day and 6,600 code reviews each day
Dang. We can't get away with that where I work.
why not... by Anonymous Coward · 2017-05-25 01:56 · Score: 0

Let microsoft windows customers compile their own windows with just the items they need or want.
Cool stuff: WinFS. by Anonymous Coward · 2017-05-25 02:53 · Score: 0

Unfortunately "generic storage engine"s don't do well under Windows as demonstrated by the lack of WinFS.
1. Re:Cool stuff: WinFS. by Anonymous Coward · 2017-05-25 03:59 · Score: 0
  
  It's been a decade. Let it go.
A little history by FingerPicknGood · 2017-05-25 04:05 · Score: 1

A long long time ago (like late 90s) Microsoft bought, whole hog, the source to Perforce and created "Source Depot". Something they never released to the public. I believe this is what the Windows team used. While I do think they might have been able to sell Source Depot as a product, I'm not sure they could have open sourced it.
The fact that GVFS can even be open sourced is also probably another reason for making the move.
Comment removed by account_deleted · 2017-05-25 06:26 · Score: 1

Comment removed based on user account deletion
Re:But they're still allowing some of us... by Anonymous Coward · 2017-05-25 08:15 · Score: 0

I'm not sure that answers the question.
Re:But they're still allowing some of us... by Grishnakh · 2017-05-25 12:12 · Score: 1

It does. The original statement was that "anything is better than ClearCase". Someone named two other really crappy VCSs, implying that these two were even worse than, or at least no better than ClearCase, hoping to disprove the OP's statement. I didn't address those specifically, but I went for the most extreme example I could think of which was no real version control at all except doing it manually with version numbers in the file names, and claiming that even that (which surely is clearly worse than VSS or PVCS, as bad as those may be) is better than ClearCase. And honestly, I do believe this to be the case, after having significant work experience with ClearCase. I'd rather use no revision control at all than ClearCase; it's really that bad.
Re:But they're still allowing some of us... by Anonymous Coward · 2017-05-25 16:55 · Score: 0

You'd think doing it like a band-aid, in other words just ripping it off, would be the better solution, but in a meeting I had today with a group of eight very experienced devs, they said they would not move to Git ever, so that isn't going to happen. I'm just a contractor so I'm like an AC with no karma (hey, like here!), so they didn't listen to me or your suggestion.