| Paavo Helde <myfirstname@osa.pri.ee>: Feb 04 12:37AM +0200 On 3.02.2016 23:56, Jerry Stuckle wrote: >> central repository, so it cannot be lost. > And what happens when there is a major failure at your repository? How > long is it going to take to get them to restore it for you? This has never happened (during 17 years), so I have no actual data. If the repair would involve finding a replacement server and setting it up then I guess it might take a day or two. The developers could continue to work meanwhile, later commits might just be more coarse-grained than ideal (even this could be avoided by using a multi-stage VCS like git or mercurial). The worst case scenario is a plane crash into the building (it is situated near a landing corridor of a major airport). In that case we should set up our own server, using the copy of the repository which is mirrored to our site every night. But I guess there would be no hurry in such a situation. |
| David Brown <david.brown@hesbynett.no>: Feb 03 11:40PM +0100 On 03/02/16 22:46, Jerry Stuckle wrote: >>> Even our "slow" WAN link to the DR site sustains 100MB/second throughput. > Yes, I know what a snapshot is. Do you know how to recover a repo from > snapshots? Yes. I have never had to do it, but I use snapshots and backups in a what that makes it simple to find previous versions of files or directories, or to roll back the virtual machines, or to make temporary duplicates of the entire virtual machines. Pick the right technology, and it's not hard or time-consuming. |
| Ian Collins <ian-news@hotmail.com>: Feb 04 11:59AM +1300 Jerry Stuckle wrote: >> I don't think he knows what a snapshot is either. >> I am guessing that you do it using ZFS snapshots, which is probably an >> idea he has never heard of. Got it in one. >>> Even our "slow" WAN link to the DR site sustains 100MB/second throughput. > Yes, I know what a snapshot is. Do you know how to recover a repo from > snapshots? cp <filesystem>/.zfs/snapshot/<pick a snapshot>/<path to file> . Next? -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Feb 04 12:07AM +0100 On 03/02/16 22:55, Jerry Stuckle wrote: >>> whatever they use. >> Then maybe you don't know how to use the systems? > Oh, I know how to use them. No problem. You have given every indication that you have no idea what version control systems are for, how to use them, or what they can do. > And what happens if your repository was bad? It does happen! First - no, repositories don't go bad except if you are /really/ unlucky (such as too many disks in your raid dying at once). Or they go bad if you use crap like MS Source Safe, which corrupts repositories. And second, if it happens, then you have an IT problem, and the IT department fixes it by restoring from backups. But that is not part of the development process. And of course, if you are using a distributed version control system like git (as you would in bigger groups), you don't need to worry at all - you just use one of the other repositories until your central server (if you even have one) is in place again, copied over from one of the other repositories. That is one of the points of having a distributed version control system. >> development (or testing, for that matter). > You don't show that you know how. But then you admit you're a small > company. My main customers are large (Fortune 500) companies. I don't need to show you how I do backups. I say we have automated nightly backups, which we use for backup purposes rather than as part of our development process. While I don't post so often to c.l.c++, I believe I have a good enough reputation here that people will take my word for it without having to spell out the details or provide proof (that applies to almost all posters here - you are one of the very few whose claims are regularly so unbelievable and absurd that we cannot accept you at your word). But if you don't believe me, then that's fine - I care not. >> Okay? > It is much easier to restore a repo from your own backup than it is to > wait for IT to do it. That makes no sense. If you are using any sort of centralised version control system, then individual developers don't have the access to restore a repository (just as they don't have the access required to destroy one). That requires the IT folk. If you are using a distributed version control system and this is your local copy on your own system that you have broken, you just clone it anew from one of the other copies. If developers are making their own backups and restoring the repositories from them, then your system is more screwed than I had previously imagined. >> tracking them, and merging them is all standard practice. > Yes, you should get it and read it. Then you *might* understand that > things happen. Just backing out a change does *not* work 100% of the time! Yes it does, if you know how to use your tools. >> Day 2: Test department tries the code, finds it doesn't work. Developer >> picks his nose. > Day 2. Developer is working on different code. While leaving half-done code outside of the version control system, and with no idea whether it works at all? Welcome to chaos. >> Day 7: The developer doesn't have a copy of the first version any more, >> so asks IT for the backups. > Developer has copy of all versions. No requirement to ask IT for backup. Okay, so on day 7 the developer spends the morning finding the right file from his multitude of folder copies named "old", "test version 1.21.3" and "ready to test 3b". He then spends the afternoon begging the department head to let them get a proper version control system, and to let them use it. > But then you've obviously never worked on a large project - or one that > is properly managed. Big companies know how to do it *right*. It's too > expensive for them to get it wrong. I find it very hard to believe your claims. The only thing that makes any of it plausible is the summer job interview I once had at IBM, some 25 years ago. The interviewer concluded the interview by saying that I was obviously a talented young programmer, highly motivated for designing software, writing code, and making things work - he would not offer me a job because I would be frustrated, annoyed, and depressed at the extraordinary inefficiency and time-wasting that happened in companies like IBM, where I could expect to spend most of my time in meetings, writing documents that no one would read, reading documents that didn't make sense and didn't matter anyway, and generally fighting the idiotic systems that meant it took 30 programmers to do the real work of 2 people. Perhaps your problem is that you have only worked for companies like that. |
| Ian Collins <ian-news@hotmail.com>: Feb 04 12:08PM +1300 Jerry Stuckle wrote: >> special server room which is maintained, backed up and sent to a bank >> vault regularly by the IT people. None of this is of any concern for any >> team of developers using this repository. Me neither. If your infrastructure is sound, you never will. If your infrastructure isn't sound, get one that is. >> central repository, so it cannot be lost. > And what happens when there is a major failure at your repository? How > long is it going to take to get them to restore it for you? Let me say it slowly for you: if you have the sense to use a distributed VCS there isn't a single repository There, is that clear? -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 04 12:32PM +1300 Jerry Stuckle wrote: > Sure I know what the word "replicate" means. And unless you're running > fiber, you won't get 100MB/s throughput on a lan - especially one shared > with other users. Your disk won't even provide that speed. Weren't the capitals *WAN* bold enough for you? Besides, all my systems (home and on client site) use 10GE (something you may not have encountered in your 80s world) and the storage can happily manage 4-500MB/s machine to machine. > Not to mention needing several terabytes per day for all of the > replications. Google "incremental". -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 04 08:01AM +1300 Mr Flibble wrote: > have disastrous consequences if incorrect assumptions are made based on > them. > The best form of documentation is the code itself! Aren't you going to offer up your critique of Uncle Bob's TDD sausages? -- Ian Collins |
| Vir Campestris <vir.campestris@invalid.invalid>: Feb 03 09:46PM On 03/02/2016 17:35, Mr Flibble wrote: > them. > The best form of documentation is the code itself! > /Flibble I'll bite. It can't make things wurst. A good comment tells you what the code is supposed to do, and tells you why it doesn't do something else that seems obvious. The code tells you what it does. Nothing more. Andy |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 04 12:41AM +0200 On 3.02.2016 23:46, Vir Campestris wrote: > A good comment tells you what the code is supposed to do, and tells you > why it doesn't do something else that seems obvious. I have written several comments for missing or deleted code, explaining why something is not done or why some function is not called at this point. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 03 11:04PM On 03/02/2016 21:46, Vir Campestris wrote: > A good comment tells you what the code is supposed to do, and tells you > why it doesn't do something else that seems obvious. > The code tells you what it does. Nothing more. Well written and designed code with sensible, descriptive variable, function and class names is virtually self-documenting. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Feb 04 12:09PM +1300 Mr Flibble wrote: > Well written and designed code with sensible, descriptive variable, > function and class names is virtually self-documenting. Especially if it was written with TDD where you have a lovely set of tests that tell you exactly what the code does :) Aren't you going to offer up your critique of Uncle Bob's TDD sausages? -- Ian Collins |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 03 11:19PM On 03/02/2016 23:09, Ian Collins wrote: > Especially if it was written with TDD where you have a lovely set of > tests that tell you exactly what the code does :) > Aren't you going to offer up your critique of Uncle Bob's TDD sausages? Perhaps your problem is that you are confusing TDD with unit testing? Unit tests are great, TDD isn't. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Feb 04 12:24PM +1300 Mr Flibble wrote: >> Aren't you going to offer up your critique of Uncle Bob's TDD sausages? > Perhaps your problem is that you are confusing TDD with unit testing? > Unit tests are great, TDD isn't. Nope. Aren't you going to offer up your critique of Uncle Bob's TDD sausages? -- Ian Collins |
| Geoff <geoff@invalid.invalid>: Feb 02 05:35PM -0800 On Tue, 2 Feb 2016 21:16:12 +0000, Vir Campestris >"foolish") for the group. The kindred but enemy Navajo to the north >called both, the Tonto Apache and their allies, the Yavapai, Dilzh?í? >diné?i? - "People with high-pitched voices")." ... which pretty well proves racism is not the sole purview of the whites. In the original radio series Tonto was Potawatomi nation. Ke-mo sa-be was what he called the Lone Ranger. This was repeated in the television series starring Clayton Moore and Jay Silverheals. Since Tonto was a complete fiction and a product of writers who may or may not have been cognizant of native American culture it's not surprising that the name translates badly into other languages. The name was probably selected to be short and to sound better than "Fred". Another name that translated badly into Spanish was Chevy Nova. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment