| Ian Collins <ian-news@hotmail.com>: Feb 04 07:55AM +1300 Jerry Stuckle wrote: > cycle. What happens, for instance, if you get a disk crash? Or if a > disgruntled employee wipes the entire server (as has happened in at > least one instance I know of)? Lots of things can happen. Such as the disaster part of DR. > Backing up should be an automated process and is generally done after > hours. If you back up nightly, you lose at most one days work. Definitely 80s. I snapshot and replicate development systems every 15 minutes and push to the DR site hourly... > any of the above was not possible. But then you've obviously not worked > on a project with dozens of programmers. In fact, from your comments, I > highly suspect you've never worked on a project with even two programmers. Blah, blah, blah. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 04 08:00AM +1300 Mr Flibble wrote: >>> programmers. >> Blah, blah, blah. > May I suggest sausages? Well it is time for my breakfast :) -- Ian Collins |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 03 07:22PM On 03/02/2016 19:18, Geoff wrote: >> You didn't answer my question. What happens if you delete a file from >> the repo? You no longer have that file since you don't have a backup. > Hello Jerry! The 21st century is calling! He is probably using Microsoft Delta. /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 03:01PM -0500 On 2/3/2016 11:58 AM, Paavo Helde wrote: > Revert the last commit? >> Who said anything about a .zip file? These are repos. > svn or git? And I should add - the development team backing up the repository on its own (separate from host backups) makes recovery much faster - they don't have to depend on IT operations doing the restore - which may be delayed if they have "more important" work to do. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Gareth Owen <gwowen@gmail.com>: Feb 03 08:28PM >> I'm fine with my choices. > Ah, yes. Here comes the Libs favorite word then they're losing an > argument - "Racist". Led by your Emperor. Donald Trump is a racist. |
| Ian Collins <ian-news@hotmail.com>: Feb 04 09:13AM +1300 Jerry Stuckle wrote: > Snapshots are one thing. Full backups of the repo are something > completely different. You aren't going to back up hundreds of mbs every > 15 minutes. Or hourly, even. I assume you didn't understand the term "replicate"? Even our "slow" WAN link to the DR site sustains 100MB/second throughput. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 04 09:16AM +1300 Jerry Stuckle wrote: >> Revert the last commit? > And what if that last commit was six months ago, and hundreds of files > had been changed since then? Or if it was the only copy of that file? Check out from the data or commit before the file was lost and copy the file. >>> Who said anything about a .zip file? These are repos. >> svn or git? > It makes no difference. Things can happen to *any* repository. Oh but it does! -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 04:06PM -0500 On 2/3/2016 3:16 PM, Ian Collins wrote: >> had been changed since then? Or if it was the only copy of that file? > Check out from the data or commit before the file was lost and copy the > file. And what if it was the only copy of the file? >>> svn or git? >> It makes no difference. Things can happen to *any* repository. > Oh but it does! You've obviously never lost a repository. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 04:07PM -0500 On 2/3/2016 3:28 PM, Gareth Owen wrote: >> Ah, yes. Here comes the Libs favorite word then they're losing an >> argument - "Racist". Led by your Emperor. > Donald Trump is a racist. Yup, Libs favorite word, for sure! -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 04:56PM -0500 On 2/3/2016 4:31 PM, Paavo Helde wrote: > If you lose central repository in a regular basis, you should consider > using a distributed VCS like git or mercurial. There is technically no > 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? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 03 11:31PM +0200 On 3.02.2016 23:06, Jerry Stuckle wrote: > You've obviously never lost a repository. No, I haven't. Our central repository resides in another country in a 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. If you lose central repository in a regular basis, you should consider using a distributed VCS like git or mercurial. There is technically no central repository, so it cannot be lost. |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 04:55PM -0500 On 2/3/2016 4:40 PM, David Brown wrote: >> Nope, I've used several over the years, with different clients. I use >> whatever they use. > Then maybe you don't know how to use the systems? Oh, I know how to use them. No problem. >> least one instance I know of)? Lots of things can happen. > Well, if you were the project manager - as you have claimed - I'm not > surprised the employees are disgruntled. Having nothing to do with me. It occurred before I arrived. In fact, that was one of the reasons I was hired. > check-in that change. Five minutes later, we rolled back that change > and carried on. That is because we use a version control system, and > know how to use it. And what happens if your repository was bad? It does happen! > departments, precisely because they don't use version control systems. > And I wear a different hat when doing that - it is not part of > 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. > We all know that backups are important. > But backups are not part of a development process. > Okay? It is much easier to restore a repo from your own backup than it is to wait for IT to do it. > version control? Everyone else uses version control systems that log > changes - what changed, who did it, and why. Backing out of changes, > 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! > testing. > Day 2: Test department tries the code, finds it doesn't work. Developer > picks his nose. Day 2. Developer is working on different code. > tries again. > Day 4: Test department tests it again. Developer spends the day at > casualty, after banging his head off the wall too often. Day 4. Developer is working on different code. > Day 6: Test department finds they prefer something from the first version. > 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. > Day 10: Test department agrees that the code works. > Day 11: The developer is now allowed to check in his code to the version > control system, which immediately crashes and needs restored from backups. Test department checks code into production system where everyone else can read it. > tells upper management that he needs another 30 programmers to > multi-task the workflow, or the new version of minesweeper will not be > finished in time for Christmas. Project Manager Jerry reports to management project is continuing on time and within budget. You don't seen to understand how proper project management works. Just because a developer turns code over to the test department does NOT mean he's sitting on his arse. He's doing other things. And just because he's turned one version over to the test department does NOT mean he doesn't have other copies. That's why there are multiple version control systems. 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Feb 03 10:45PM +0100 On 03/02/16 21:13, Ian Collins wrote: >> completely different. You aren't going to back up hundreds of mbs every >> 15 minutes. Or hourly, even. > I assume you didn't understand the term "replicate"? 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. |
| 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. |
| 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 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 |
| 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 |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 07:42PM -0500 On 2/3/2016 4:49 PM, David Brown wrote: >> with other users. Your disk won't even provide that speed. > Jerry, have you ever heard the phrase "when you are in a hole, stop > digging" ? You are truly making a fool of yourself. Yup, and you should have stopped several posts ago. > re-copying all the data? You copy the /changes/. Unless you are > producing a movie or running a particle accelerator, you don't make > terabytes of /new/ data every day. Backing up 100MB every 15 minutes comes out to about 9.6Tb per day. Copying the changes means you have to restore starting with the last full backup. That may have been weeks ago. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 04 01:49PM +1300 Jerry Stuckle wrote: > Backing up 100MB every 15 minutes comes out to about 9.6Tb per day. > Copying the changes means you have to restore starting with the last > full backup. That may have been weeks ago. Bong! Wrong again. I restore from the appropriate snapshot. Each snapshot represents the state of the filesystem when it was taken. If you are replicating from a busy build server (or a VM image) you may get many megabytes of data every 15 minutes, but nearly all of that will be changes to the same files, the the aggregate isn't much bigger the the individual replications. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 04 02:12PM +1300 Jerry Stuckle wrote: > On 2/3/2016 6:07 PM, David Brown wrote: > Once again you show your extreme ignorance. git is far from the best, > and is never used in bigger development groups. Er the Linux kernel? The Illumos kernel? The... and so on. Seeing as you like them so much, read: http://www.ibm.com/developerworks/library/wa-git/ -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 04 02:02PM +1300 Jerry Stuckle wrote: > You haven't? I have. In fact, I've been using incremental backups > since the mid 1980's with DB2. A database, but the concept is identical. You are still living there aren't you? > idea what you're talking about. To restore from snapshots, you need to > go back to the last full backup, then restore each snapshot - *in > order*. Nope. On modern filesystems, a snapshot is a full representation of the filesystem at the time it was taken. To restore, you just copy the files from the snapshot. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Feb 04 01:59PM +1300 Jerry Stuckle wrote: >>> with other users. Your disk won't even provide that speed. >> Weren't the capitals *WAN* bold enough for you? > Yep. And I stand by my statement. WAN != LAN. 10GBASE-T 10 Gbit/s Ethernet over cat-6A will give you many times that. >> happily manage 4-500MB/s machine to machine. > For hundreds of megabytes? I doubt it. What disks are you using that > are that fast? Yep. Stripes of mirrors of Seagate Constellation ES.3 drives. >>> replications. >> Google "incremental". > Google "restore from incremental backup" Old hat, we restore from snapshots. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 08:09PM -0500 On 2/3/2016 6:08 PM, Ian Collins wrote: >>> 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. Just because you've never lost one doesn't mean it can't happen. > single > repository > There, is that clear? Yes. But that still doesn't mean the repository itself cannot be corrupted - even if it is distributed. You obviously have no idea what can happen, and has happened, in the real world. Big companies know the potential problems, and take steps to prevent them. This includes backups of the repositories, separate from system backups. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 08:06PM -0500 On 2/3/2016 5:37 PM, Paavo Helde wrote: > 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). Never does not mean can't. In 38 years of being employed in the computer field, I've seen similar things happen several times. The worst case was 9/11/2001, when the World Trade Center was destroyed. None of my customers were directly involved, but I know those of some consultant friends of mine who were. Some companies had off-site backups and were back running in a couple of days. Others had off-site backups of their data, but no backup systems and were out for weeks. None of them had offsite backups more than 36 hours old (the night before the attack), AFAIK > 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. For a project with dozens of developers, every hour down can cost tens of thousands of dollars. Backups like you're taking are quite important, and keeping those backups at a different physical location critical. However, if you wait for IT to restore your repos, you might be down for days. If you have your own backups of the repos, you can rent a server and be back up in a few hours. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 08:00PM -0500 On 2/3/2016 6:07 PM, David Brown wrote: >> 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. You have given every indication that you have no idea how to manage systems to limit failures. Something that is critical when dealing with more than one or two programmers. > 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. Repositories *can* and *do* go bad. Whether you're lucky or not, it happens. Not a problem for a one or two person development group. A major problem for 100+ developers. > 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. The IT department is only responsible for restoring to the latest backup. Nothing more, nothing less. And you don't know for sure when that backup was. > (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. Once again you show your extreme ignorance. git is far from the best, and is never used in bigger development groups. They use commercial systems which are much more reliable. But any version control system, no matter how distributed, can be corrupted. > 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. I don't care how you do backups. You just showed you have no idea what you're doing. And your reputation means nothing. You have shown zero knowledge of how large projects work. But then I have yet to see anyone with any experience in large projects posting here. Everyone seems to be be one or two person development groups. So you're not unique. > 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. No, developers don't. But the project manager and assistants do. That's true whether it's local or distributed. >> 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. Not when the repository is corrupted, for instance. >> 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. Nope. He's done with that code and working on something entirely different. No chaos involved - the system's design shows what he needs to do. But you probably don't do designs, either. > 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. No more than trying to find the right file from any other repo. > 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. Yes, perhaps my problem is that I've only worked for companies who know what they are doing - including IBM. You had a summer job interview. I had 13 years as an employee. And I hate to tell you - but the interviewer was being kind. They tell something like that to every one they turn down. They aren't going to tell you you aren't qualified. And 8 of those years was in software - where we worked on code most of the week. We had maybe two hours of meetings a week; most weeks we had less. But from your posts here, I would have told you exactly the same thing - either as an IBMer or a project manager. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 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