{"thread":{"id":"23071","subject":"About single user setup for lightweights","startedAt":"2010-03-19T01:53:28Z","lastAt":"2010-03-19T17:14:11Z","messageCount":6,"participants":["Harry Putnam","Avery Pennarun","Ben Finney","Martin Geisler","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"137174","messageId":"87r5nht6uf.fsf@newsguy.com","threadId":"23071","inReplyTo":null,"subject":"About single user setup for lightweights","fromName":"Harry Putnam","fromEmail":"reader@newsguy.com","sentAt":"2010-03-19T01:53:28Z","receivedAt":"2010-03-19T01:53:28Z","isPatch":false,"sender":{"key":"reader@newsguy.com","avatar":null},"body":"Hold your fire on this one if possible. I'm not just a lazy slug who\ncan't think and study for himself.\n\nI'm a little confused about the different way of using rcs that git,\nmercurial bazaar and probably several others offer.\n\nI've not used anything but cvs. I use it at least every couple of\ndays but really only a limited set of commands, and no deep knowledge\neven of that style.\n\nMy usage is basically to keep up with rc files for the several OSs' I\ntinker with on my home lan and a fair bit of scripting and\nexperimenting with shell, perl, c, etc. that I've built up over the\nyears and find reason to change a bit every so often.\n\nI keep a central cvs repo and on each host I do a check out of the\nentire thing from the base up. Mostly to have copies of various style\nof rc files the OSs need but also to keep the scripts I've written\nover the years and learned to rely on, available and in sync.\n\nTo me, keeping up with cvs is always a PITA. I've never hit on a\nhandy and efficient way to do it. Even for a just my light usage.\n\nAnd I do mean lignt. For example, even after yrs of using cvs my\n$CVROOT is still tiny:\n\n du -sh /usr/local/cvsroot\n 12M\t/usr/local/cvsroot\n\nSo, I'm wondering if one of the newer systems would be less of a PITA.\n\nHow would a workflow actually go:\nI'd create and populate a repo, then what?. Create clones on each\nmachine I guess and if I found a need to change or add files, I'd then\npush back to the original repo? Its sounding a whole lot like cvs so far.\n\nSo, am I likely to see some improvement in the chore of keeping up an\nrcs system with git, mercurial or bazaar?\n\nAnther thing I'm really curious about concerns binary rcs. I'm thinking\nof photo editing and things like flash where I might be changing a\nproject over time and want access to past versions.\n\nI'm told cvs is not good for that... consequently I've never tried\nit. Am I likely to find that one of git, mercurial or bazaar is far\nbetter for that?\n"},{"id":"137177","messageId":"32541b131003181913v7319d6a1ydd72c0177729dbf4@mail.gmail.com","threadId":"23071","inReplyTo":"87r5nht6uf.fsf@newsguy.com","subject":"Re: About single user setup for lightweights","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-19T02:13:53Z","receivedAt":"2010-03-19T02:13:53Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Mar 18, 2010 at 9:53 PM, Harry Putnam wrote:\n> I keep a central cvs repo and on each host I do a check out of the\n> entire thing from the base up.  Mostly to have copies of various style\n> of rc files the  OSs need but also to keep the scripts I've written\n> over the years and learned to rely on, available and in sync.\n>\n> To me, keeping up with cvs is always a PITA.  I've never hit on a\n> handy and efficient way to do it. Even for a just my light usage.\n[...]\n> How would a workflow actually go:\n> I'd create and populate a repo, then what?.  Create clones on each\n> machine I guess and if I found a need to change or add files, I'd then\n> push back to the original repo?  Its sounding a whole lot like cvs so far.\n\nYes. Or you could skip the central repo and pull directly from one\nmachine's working tree to another. If that has any value to you, then\nit's the only likely reason a DVCS would do you any good for this\ntrivial case.\n\nThe real question is: what makes your current setup a PITA? If you\ncan't answer that concisely, then you don't know what to look for in a\nsupposedly better solution.\n\n> Anther thing I'm really curious about concerns binary rcs.  I'm thinking\n> of photo editing and things like flash where I might be changing a\n> project over time and want access to past versions.\n>\n> I'm told cvs is not good for that... consequently I've never tried\n> it.  Am I likely to find that one of git, mercurial or bazaar is far\n> better for that?\n\ngit sucks at handling large binary files (>50 megs or so) unless you\nhave boatloads of RAM. If your binary files are moderately sized (a\nfew megs) then it'll probably be reasonably efficient. I don't know\nabout hg and bzr for memory usage.\n\nIt's better to store uncompressed binary files (eg *.tar) instead of\ncompressed ones (*.tar.gz) in order to allow useful delta compression.\n That means raw images instead of png/gif/jpg. And probably completed\nflash files are compressed. The best thing to do is actually try it\nand see if your repository size and memory usage is reasonable.\n\nHave fun,\n\nAvery\n"},{"id":"137181","messageId":"87y6hpufi3.fsf@benfinney.id.au","threadId":"23071","inReplyTo":"87r5nht6uf.fsf@newsguy.com","subject":"Re: About single user setup for lightweights","fromName":"Ben Finney","fromEmail":"ben+bazaar@benfinney.id.au","sentAt":"2010-03-19T04:01:08Z","receivedAt":"2010-03-19T04:01:08Z","isPatch":false,"sender":{"key":"ben+bazaar@benfinney.id.au","avatar":null},"body":"Harry Putnam writes:\n\n> Hold your fire on this one if possible. I'm not just a lazy slug who\n> can't think and study for himself.\n\nHopefully you're in for a smooth ride; I'd be disappointed if any of\nthese communities are hostile to an honest and specific enquiry like\nyours.\n\nWelcome, and thanks for learning about modern VCS options!\n\n> I'm a little confused about the different way of using rcs that git,\n> mercurial bazaar and probably several others offer.\n\nI got a bit confised by that sentence. You would do well to use “VCS”\n(Version Control System) to refer to the class of program. “RCS” refers\nto a particular VCS, one that is still in current use for some purposes.\n\n> I've not used anything but cvs. I use it at least every couple of\n> days but really only a limited set of commands, and no deep knowledge\n> even of that style.\n\nGood news; you'll have little un-learning to do :-)\n\n> My usage is basically to keep up with rc files for the several OSs' I\n> tinker with\n[…]\n> To me, keeping up with cvs is always a PITA. I've never hit on a\n> handy and efficient way to do it. Even for a just my light usage.\n\nI don't know what “keep up with CVS” means. Can you explain what part of\nyour workflow is a PITA?\n\n> How would a workflow actually go:\n> I'd create and populate a repo, then what?.\n\nYou could choose which files should be common between different\nmachines, add those to the repository and choose not to track the rest\nin the VCS. Other ways of doing it are also feasible.\n\n> Create clones on each machine I guess and if I found a need to change\n> or add files, I'd then push back to the original repo? Its sounding a\n> whole lot like cvs so far.\n\n> So, am I likely to see some improvement in the chore of keeping up an\n> [VCS] system with git, mercurial or bazaar?\n\nPending an explanation of what “keeping up” means, I think one of the\nbig benefits you'll get is that the modern VCS designs:\n\n* treat the whole working tree as the thing to be represented in each\n revision; and\n\n* have significantly better merging capability compared with CVS.\n\n> Anther thing I'm really curious about concerns binary rcs. I'm\n> thinking of photo editing and things like flash where I might be\n> changing a project over time and want access to past versions.\n\nYou can do this with any VCS, but binary files don't have a good generic\nway to represent differences efficiently, whereas text files do. So\ntracking binary files will work, but will be rather inefficient in terms\nof memory usage and repository data.\n\n-- \n \\ “If you can do no good, at least do no harm.” —_Slapstick_, |\n `\\ Kurt Vonnegut |\n_o__) |\nBen Finney\n"},{"id":"137195","messageId":"87k4t81vt8.fsf@hbox.dyndns.org","threadId":"23071","inReplyTo":"32541b131003181913v7319d6a1ydd72c0177729dbf4@mail.gmail.com","subject":"Re: About single user setup for lightweights","fromName":"Martin Geisler","fromEmail":"mg@lazybytes.net","sentAt":"2010-03-19T09:53:55Z","receivedAt":"2010-03-19T09:53:55Z","isPatch":false,"sender":{"key":"mg@lazybytes.net","avatar":"https://gravatar.com/avatar/0abee533a2a6717b6a685550529569023bdfde2c16d763f7a255aa1562ed62ec?d=mp&s=160"},"body":"Avery Pennarun writes:\n\n> git sucks at handling large binary files (>50 megs or so) unless you\n> have boatloads of RAM. If your binary files are moderately sized (a\n> few megs) then it'll probably be reasonably efficient. I don't know\n> about hg and bzr for memory usage.\n\nMercurial also uses lots of RAM, way more than I had hoped. I did some\ntests with this recently:\n\n http://markmail.org/message/uxqtmmnkyimxse5b\n\nThey show a factor 3-6 blowup when working with a 256 MB file.\n\nWe don't really recommend storing such large files in Mercurial. Instead\nwe recommend storing the files outside of the tree, e.g., on a server\nwith a huge disk. The bfiles extension can do this:\n\n http://mercurial.selenic.com/wiki/BfilesExtension\n\n-- \nMartin Geisler\n\nFast and powerful revision control: http://mercurial.selenic.com/\n"},{"id":"137218","messageId":"2e24e5b91003190708y162f0ecfkeb00346aaa14d1e3@mail.gmail.com","threadId":"23071","inReplyTo":"87r5nht6uf.fsf@newsguy.com","subject":"Re: About single user setup for lightweights","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2010-03-19T14:08:11Z","receivedAt":"2010-03-19T14:08:11Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Fri, Mar 19, 2010 at 7:23 AM, Harry Putnam wrote:\n\n> I keep a central cvs repo and on each host I do a check out of the\n> entire thing from the base up.  Mostly to have copies of various style\n> of rc files the  OSs need but also to keep the scripts I've written\n> over the years and learned to rely on, available and in sync.\n\nabout the most important thing, you ought to notice is that you don't\nneed to stay connected to your \"server\" to commit. I do this too, and\nhaving a DVCS (in my case, git) helps a lot.\n\nI didn't, on a quick read, see that mentioned in any of the replies so far.\n"},{"id":"137242","messageId":"32541b131003191014u6439f0dhe90eca77f42e24dd@mail.gmail.com","threadId":"23071","inReplyTo":"87k4t81vt8.fsf@hbox.dyndns.org","subject":"Re: About single user setup for lightweights","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-19T17:14:11Z","receivedAt":"2010-03-19T17:14:11Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Mar 19, 2010 at 5:53 AM, Martin Geisler wrote:\n> Avery Pennarun writes:\n>> git sucks at handling large binary files (>50 megs or so) unless you\n>> have boatloads of RAM. If your binary files are moderately sized (a\n>> few megs) then it'll probably be reasonably efficient. I don't know\n>> about hg and bzr for memory usage.\n>\n> Mercurial also uses lots of RAM, way more than I had hoped. I did some\n> tests with this recently:\n>\n>  http://markmail.org/message/uxqtmmnkyimxse5b\n>\n> They show a factor 3-6 blowup when working with a 256 MB file.\n>\n> We don't really recommend storing such large files in Mercurial. Instead\n> we recommend storing the files outside of the tree, e.g., on a server\n> with a huge disk. The bfiles extension can do this:\n>\n>  http://mercurial.selenic.com/wiki/BfilesExtension\n\nYou might find my \"bup\" program entertaining:\n\n http://github.com/apenwarr/bup/\n\nIt happens to use the git file format, but the hashsplitting algorithm\nwould work with any repo and the code is written mostly in python.\nBecause it breaks larges files into chunks, it tends to avoid the\nmemory growth problems (at the cost of somewhat worse compression and\ndeltas). At least you can then store them in your repository.\n\nbup is intended for use as a full-system backup tool, but it would be\ninteresting to take the same techniques and use them to solve the\ngeneral case of large files in git/hg.\n\nHave fun,\n\nAvery\n"}]}