| Paavo Helde <myfirstname@osa.pri.ee>: Feb 03 08:43PM +0200 On 3.02.2016 20:07, Scott Lurndal wrote: >>> Who said anything about a .zip file? These are repos. >> svn or git? > or cvs or rcs or sccs or clearcase or bitkeeper or perforce? You missed at least visual sourcesafe and mercurial. Anyway, I trust that all these are able to revert a deleted file, so Jerry's "repo" must be something else. Probably predating sccs (which was released in 1972). Cheers Paavo |
| 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 |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 03 06:57PM On 03/02/2016 18:55, Ian Collins wrote: >> highly suspect you've never worked on a project with even two >> programmers. > Blah, blah, blah. May I suggest sausages? /Flibble |
| Ian Collins <ian-news@hotmail.com>: Feb 04 07:59AM +1300 Jerry Stuckle wrote: >> an issue. > 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. Revert the change.... > necessarily mean server failure. It means you lost something that you > need. It could even be erasing a critical file - or even deleting a > file accidentally from the repo. Revert the change.... > As to local repos - now what do you do when you have five people making > five different (and incompatible) changes to a file? And if you lose a > file on the main repo, local repo do you use to restore it? Revert the change.... Read up on distributed version control, you might learn something. -- 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 |
| Geoff <geoff@invalid.invalid>: Feb 03 11:18AM -0800 On Wed, 3 Feb 2016 11:08:42 -0500, Jerry Stuckle >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! |
| 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 02:53PM -0500 On 2/3/2016 11:58 AM, Paavo Helde wrote: >> You didn't answer my question. What happens if you delete a file from >> the repo? > 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? >> Who said anything about a .zip file? These are repos. > svn or git? It makes no difference. Things can happen to *any* repository. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 02:55PM -0500 On 2/3/2016 12:54 PM, Gareth Owen wrote: >> character assassination than anything anyone with brains could invent. > A massively racist demagogue, who is also a successful business. > 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 02:57PM -0500 On 2/3/2016 1:55 PM, Ian Collins wrote: >> 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... 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. >> highly suspect you've never worked on a project with even two >> programmers. > Blah, blah, blah. Just hope you never lose a repository. Management would not look very happily on 50+ man-years of work going down the drain. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 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 ================== |
| 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 |
| 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. |
| 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:10PM -0500 On 2/3/2016 3:13 PM, Ian Collins wrote: >> 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. 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. Not to mention needing several terabytes per day for all of the replications. You're making it even more obvious you've never been on a team more than two or three people, and never been on a project that's been properly managed. -- ================== 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. |
| David Brown <david.brown@hesbynett.no>: Feb 03 10:40PM +0100 On 03/02/16 16:50, Jerry Stuckle wrote: >> medieval - perhaps it was MS "Source Safe" ? > 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? > 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. Well, if you were the project manager - as you have claimed - I'm not surprised the employees are disgruntled. But disk crashes, server stability, security, etc., are part of IT services, not development. They are as much part of your development cycle as the electricity and the coffee machine - they may be essential to making the project work, but they are not part of development. We once had an employee accidentally delete 500 MB of a project, and 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. > 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. You don't need to tell me how to do backups. We are a small company - as well as development, I handle the IT department. Backups run nightly - I've only ever had to use them for non-development files for other 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). >> If your version control system lets anyone screw up the repository, get >> a better version control system. > See above. Anything can happen at any time. Listen carefully - I say it slowly... We all know that backups are important. But backups are not part of a development process. Okay? > programmer changed? How are you going to easily back out all of those > fixes - especially when each one can affect multiple files. You > suddenly have a snowball effect. I'm sure there is a book somewhere called "Version Control for Dummies". Or perhaps you are mistaking the "undo" button on your editor for 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. > 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. Most of my projects have small teams - often just one, and only on a couple of occasions have a dozen been involved. But version control is scalable - I would not limit myself to the sort of botch job you describe even if I were just writing a "hello world" program as a hobby: Day 1: Developer writes a new function. It compiles. Pass it on to testing. Day 2: Test department tries the code, finds it doesn't work. Developer picks his nose. Day 3: Developer gets the damage report from the test department, and 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 5: Developer gets the new test report, and fixes another bug. 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. Day 8: The IT department finds the right tape, and restores file. Day 9: Developer finally gets the code right. 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. Day 12: Project manager Jerry "PHB" Stuckle reports on the progress, and 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. |
| 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. |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 03 04:46PM -0500 On 2/3/2016 4:45 PM, David Brown wrote: > I am guessing that you do it using ZFS snapshots, which is probably an > idea he has never heard of. >> 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? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Feb 03 10:49PM +0100 On 03/02/16 22:10, 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. Jerry, have you ever heard the phrase "when you are in a hole, stop digging" ? You are truly making a fool of yourself. > Not to mention needing several terabytes per day for all of the > replications. You haven't the faintest clue what you are talking about, do you? What kind of amateur IT person would transfer their data off-site by 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. |
| 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 ================== |
| 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 ================== |
| Geoff <geoff@invalid.invalid>: Feb 03 02:03PM -0800 On Wed, 3 Feb 2016 16:06:37 -0500, Jerry Stuckle >> 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? What you talkin' 'bout Willis? If the file is in an RCS it's not going to be the only copy and it's not going to be lost. The file is journaled and all the changes to it were recorded in the RCS and the entire history of the file, including it's deletion from the RCS, is recoverable. Backups of the state of the RCS, including local and off-site backups would always be recoverable for any scenario short of Global Thermonuclear War. What tools are you using in your work where you can even conceive of a scenario where a development team with a version control system could have a singular copy of a file? |
| 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