{"thread":{"id":"23781","subject":"Advice on choosing git","startedAt":"2010-05-12T06:31:34Z","lastAt":"2010-05-19T01:12:50Z","messageCount":13,"participants":["Noah Silverman","Dmitry Potapov","Ramkumar Ramachandra","Jonathan Nieder","Joe Brenner","Avery Pennarun","Matthieu Moy","Jeff King","Martin Langhoff","Anthony W. Youngman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"141507","messageId":"4BEA4B46.6010009@smartmediacorp.com","threadId":"23781","inReplyTo":null,"subject":"Advice on choosing git","fromName":"Noah Silverman","fromEmail":"noah@smartmediacorp.com","sentAt":"2010-05-12T06:31:34Z","receivedAt":"2010-05-12T06:31:34Z","isPatch":false,"sender":{"key":"noah@smartmediacorp.com","avatar":null},"body":"Hi,\n\nI'm looking for both a version control system and backup system.\n\n\nUp for consideration are Git, Bazaar, and generic Rsync.\n\nIn the past, I've just use Rsync to sync up the directories I care\nabout. I just sync all the machines with the remote server. Often,\nI'll start working on a file or two at the office, rsync my work to the\nserver, then rsync them back down to my home machine to keep working at\nnight. This works, but doesn't give me any nice VCS features, history,\ncollaboration, etc. So clearly it is time to upgrade the system.\n\nI work on both a laptop, and office machine and a home machine.\n\n1) I'd like to keep my documents directory synced between the office and\nhome machines.\n2) I'd like to keep two or three sub directories of this synced with my\nlaptop\n3) We have a server in \"the cloud\" where I like to keep backups of my\ndocuments. Just in case.\n3) I have a few project where I am the only developer, but want a VCS to\nmanage my changes.\n4) I have 3-4 projects where there are a team of 3 of us and I want to\nuse a VCS.\n\nIn general, I might work on a given project/file on any of my machines\nin a given day. Not everything is a full \"branch\", but just some\nongoing work. I've always followed the practice of backup up any\nchanged files remotely, just in case. So with a VCS, I don't want a new\nversion number for everytime I change a file. As I do incremental work\nacross three machines, it could quickly turn versioning nightmare.\n\nI guess, that I need just keep some files backed up (and/or synced) as\nthey're not \"working projects\". I will add new documents and\noccasionally edit others, but no real need for versioning. Other files\nare working projects (possible with collaboration) and need active VCS. \n\nI've heard amazing things about Git, but have a few concerns. Hopefully\nsomeone here can offer some suggestions.\n\n1) Size. THIS IS MY MAIN CONCERN - If I want to sync my home, office,\nand server Document directories. From what I have read, I will\neffectively have multiple copies of each item on my hard drive, thus\neating up a lot of space (One of the \"working file\"and several in the\n.git directory.) If I have multiple changes to a file, then I have\nseveral full versions of it on my machine. This could be a problem for\na directory with 100GB or more, especially on a laptop with limited hard\ndrive space. I know Subversion is a dirty word around here, but it\nseemed to only annotate and send the changes\n\n2) Sub-directory selection. On my laptop, I only want a few\nsub-directories to be synced up. I don't need my whole document tree,\nbut just a few directories of things I work on.\n\nBazaar also looks like a possible option, but I'm not sure it handles\ndrive usage better. Their website has a lengthy manifesto about how\nthey're better than Git, but I don't have enough experience with either\nto make an informed decision.\n\nAny and all suggestions are welcome and appreciated.\n\nThank You,\n\n--\nNoah\n"},{"id":"141517","messageId":"20100512090418.GM14069@dpotapov.dyndns.org","threadId":"23781","inReplyTo":"4BEA4B46.6010009@smartmediacorp.com","subject":"Re: Advice on choosing git","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-12T09:04:19Z","receivedAt":"2010-05-12T09:04:19Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, May 11, 2010 at 11:31:34PM -0700, Noah Silverman wrote:\n> \n> 1) Size. THIS IS MY MAIN CONCERN - If I want to sync my home, office,\n> and server Document directories. From what I have read, I will\n> effectively have multiple copies of each item on my hard drive, thus\n> eating up a lot of space (One of the \"working file\"and several in the\n> .git directory.)\n\nUsually, Git is more efficient in disk space than other DVCS, because\nit uses packages to store files. In each package contains deltified\nand then gzip data, and this deltification is done not only relatively\nto direct ancestor but potentially any suitable candidate (there is some\nheuristic to find best). But when you add a new file to the repository\nthen it is stored just gzip compressed inside .gzip/objects. Such files\nare often referred as \"loose\" in Git documentation. When you have a lot\nof loose objects then the garbage collector is activated and packs them\ntogether. Obviously, you can run \"git gc\" that manually, or to configure\nthe condition what means too many loose objects.\n\nEven those files that are stored as loose objects is never transfered\nseparately over network. When you pull or push, all required objects are\npacked together in a single package, and this package is sent to the\nother side. So, on the other side they will never stored as separate\nfiles. But each push/pull can create a new package, if you have too many\nsmall packages, git-gc will combine them into a single package.\n\nHowever, if you have huge multi-media files, I am not sure how Git is\ngood at handling them. There were some improvements to Git recently,\nand there is a clone of git that specifically focuses on this problem:\nhttp://caca.zoy.org/wiki/git-bigfile\nbut I don't know much about it.\n\n> several full versions of it on my machine. This could be a problem for\n> a directory with 100GB or more, especially on a laptop with limited hard\n> drive space. I know Subversion is a dirty word around here, but it\n> seemed to only annotate and send the changes\n\nActually, Subversion is very inefficient in space usage (at least,\nwhen I used it last time). I had a repository where subversion checkout\ntook much more space than git working tree and the whole repository with\nall history combine! Obviously, a centralized VCS do not have to store\nthe whole history on each client, which saves space, but having the\nwhole history with you is very handy, and also it avoids the situation\nwhere you have a single point of failure.\n\nBTW, git allows to do a shallow clone to save space by not storying the\nwhole history (only the specified number of revisions), but I have never\nused this feature, and it has some limitations.\n\n> \n> 2) Sub-directory selection. On my laptop, I only want a few\n> sub-directories to be synced up. I don't need my whole document tree,\n> but just a few directories of things I work on.\n\nSynchronization works on what you committed in your repository. At\nthis level, directories are completely irrelevant. Probably, you\nwant to have a separate repository for each sub-directory that you\nwant to synchronize separately, and then you can bundle them together\nusing git-submodules mechanism or trivial shell script that will\nsynchronize all of them.\n\nIn fact, the basic concept of Git is to treat a single repository\nas whole. So, if you have some pieces that are irrelevant, it is\nbetter to store them in separate repositories. It will improve\nspeed and possible disk usage, because deltifying will have easy\ntime to find related files, so compression will be better.\n\n> \n> Bazaar also looks like a possible option, but I'm not sure it handles\n> drive usage better. Their website has a lengthy manifesto about how\n> they're better than Git, but I don't have enough experience with either\n> to make an informed decision.\n\nWell, this manifesto sounds like written by a marketing guy, and it\ncompares Bazaar to rather old version of Git... So I am not going to\ncomment on it.\n\nIn fact, any meaningful comparison has to consider your workflow. Git\ntargets fully distributed workflow, which may even have hierarchy of\nrepositories, while Bazaar focus around more centralized solution and\nclose to what you have with Subversion. So, people who got used to a\ncentralized VCS may find Bazaar easier at the beginning, but IMHO,\nGit is more flexible and when you learn basic principles everything\nfeels very natural.\n\nIn any case, your main concern was the size of the repository, and\neven this marketing piece from Bazaar admits that Git is better at\nsaving disk space.\n\nHere you can see some comparison of a repository size for Git,\nMercurial, Bazaar:\nhttp://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html\n\n\n\nDmitry\n"},{"id":"141518","messageId":"AANLkTimIfAZp0ywpwMyllp3QtmO2Js6H1HhkP4l47bGl@mail.gmail.com","threadId":"23781","inReplyTo":"4BEA4B46.6010009@smartmediacorp.com","subject":"Re: Advice on choosing git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-05-12T09:15:30Z","receivedAt":"2010-05-12T09:15:30Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nOn Wed, May 12, 2010 at 8:31 AM, Noah Silverman wrote:\n> I'm looking for both a version control system and backup system.\n\nI recommend git for versioning and bup [1] for backup.\n\n> Bazaar also looks like a possible option, but I'm not sure it handles\n> drive usage better.  Their website has a lengthy manifesto about how\n> they're better than Git, but I don't have enough experience with either\n> to make an informed decision.\n\nScott Chacon maintains this page [2] that compares Git with other\nversioning systems. From my personal experience, I find Bazaar to be\nquite horrible and slow. Mercurial is user-friendly, but nowhere near\nGit in terms of speed, power, and size.\n\n-- Ram\n\n[1] http://github.com/apenwarr/bup\n[2] http://whygitisbetterthanx.com/\n"},{"id":"141519","messageId":"20100512092446.GA17520@progeny.tock","threadId":"23781","inReplyTo":"4BEA4B46.6010009@smartmediacorp.com","subject":"Re: Advice on choosing git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-05-12T09:24:46Z","receivedAt":"2010-05-12T09:24:46Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nNoah Silverman wrote:\n\n> I'm looking for both a version control system and backup system.\n\nI am fond of this question. :)\n\n> I guess, that I need just keep some files backed up (and/or synced) as\n> they're not \"working projects\". I will add new documents and\n> occasionally edit others, but no real need for versioning.\n\nI suggest rsync or unison[1], and to use btrfs locally if you want\nsnapshots. I don’t know a good tool for shared snapshots, but that is\nprobably my ignorance.\n\nIn my humble opinion, tools designed for tracking source code, like\ngit and bzr, are not appropriate for this task. To illustrate this, I\nhave put some thoughts about how to cheat git into doing an okay job\nin a footnote[4].\n\n> Other files\n> are working projects (possible with collaboration) and need active VCS. \n\nIn very small projects, I believe any free DVCS will do.\n\nWhat tools are you and your collaborators already comfortable with?\nI hear it can be hard to unlearn habits from using Subversion when\ngetting started with Git. Some other version control systems cater to\nthat transition better.\n\nAs projects scale in size, the speed differences between version\ncontrol systems start to matter. I find myself making larger commits,\nlooking through history less, and checking email more often when using\ncertain systems.\n\n> From what I have read, I will\n> effectively have multiple copies of each item on my hard drive, thus\n> eating up a lot of space (One of the \"working file\"and several in the\n> .git directory.) If I have multiple changes to a file, then I have\n> several full versions of it on my machine.\n\nIf your files are relatively compressible (or at least rsyncable) and\nyou pack your the repository occasionally, this should not be a\nproblem. The relevant page[2] of the Pro Git book tells probably more\nthan you wanted to know about this.\n\nShort summary: each file is initially stored in the .git directory as\na compressed file named after its content. When asked to pack with\nthe \"git gc\"[3] command (or automatically if there are too many\nunpacked objects around), git puts the data into a larger \"pack file\",\nthis time as a delta against some suitable similar blob.\n\nFor source code (which is already rather compressible), this tends to\nwork well. My local git/.git object repository is about 2½ times the\nsize of the working copy.\n\n> This could be a problem for\n> a directory with 100GB or more, especially on a laptop with limited hard\n> drive space.\n\nYes. Actually, this point is why I replied. Using a source code\nmanagement system as a backup system generally implies this weird\nassumption that even the oldest revisions are always worth keeping.\n\nWith big, machine-generated files, that doesn’t make sense to me ---\nit is better to be able to throw away some snapshots when you are\nrunning low on space.\n\n> 2) Sub-directory selection. On my laptop, I only want a few\n> sub-directories to be synced up. I don't need my whole document tree,\n> but just a few directories of things I work on.\n\nIt requires foresight, but you could use a separate filesystem for\nthis (possibly loop-mounted) if you want to keep snapshots. With\nsome symlinks, this would not require changing the directory\nstructure.\n\n> Any and all suggestions are welcome and appreciated.\n\nThanks for the food for thought.\nJonathan\n\n[1] http://www.cis.upenn.edu/~bcpierce/unison/\n[2] http://progit.org/book/ch9-4.html\n[3] http://www.kernel.org/pub/software/scm/git/docs/git-gc.html\n[4]\nSo, you want to use git as a general backup tool?\n\n . Files should be compressible. Set appropriate attributes. Use\n clean and smudge filters[5] to replace the weird working-copy\n representation with a simpler tracked form. Use !delta[6] where\n appropriate so git knows not to waste its time.\n\n . Files should be conducive to de-duplication. Cut large files\n into slices using rsync’s rolling checksum algorithm[7].\n\n . Backups should be fault-tolerant. Use par2[8] or zfec[9] to\n protect pack files, maybe.\n\n . Sometimes metadata (file owners and modes) is important. Track a\n \"restore\" script that sets the appropriate metadata, and update it\n before each commit[10].\n\n . Files should not change as git reads them (or it will error\n out). Wait for a quiescent state to backup, or make a\n snapshot some other way and ask git to back up that.\n\n . Old revisions are not precious. It would be nice to be able to\n decide when each backed-up tree can expire. My best suggestion is\n to rely on reflogs[11] instead of the revision graph to represent\n your history so old versions can expire, but getting this to work\n nicely would take some work: there is no built-in mechanism to\n transfer reflogs and associated objects to another repository, for\n example.\n\n[5] http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_tt_filter_tt\n[6] http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_tt_delta_tt\n[7] http://github.com/apenwarr/bup\n[8] http://parchive.sourceforge.net/\n[9] http://allmydata.org/trac/zfec\n[10] http://kitenet.net/~joey/code/etckeeper/\n[11] http://www.kernel.org/pub/software/scm/git/docs/git-reflog.html\n"},{"id":"141554","messageId":"201005130018.o4D0I7iI079145@kzsu.stanford.edu","threadId":"23781","inReplyTo":"4BEA4B46.6010009@smartmediacorp.com","subject":"Re: Advice on choosing git","fromName":"Joe Brenner","fromEmail":"doom@kzsu.stanford.edu","sentAt":"2010-05-13T00:18:07Z","receivedAt":"2010-05-13T00:18:07Z","isPatch":false,"sender":{"key":"doom@kzsu.stanford.edu","avatar":null},"body":"\nNoah Silverman wrote:\n\n> I'm looking for both a version control system and backup system.\n\nI had a similar thought some time ago. I thought that putting my life\ninside of a distributed version control system (my first thought back\nthen was Monotone) would also be a convienient way to handle the\nlaptop-workstation sync problem.\n\nBut:\n\n> 1) Size. THIS IS MY MAIN CONCERN - If I want to sync my home, office,\n> and server Document directories. From what I have read, I will\n> effectively have multiple copies of each item on my hard drive, thus\n> eating up a lot of space\n\nPretty much any version control system is going to have this problem,\nand it gets really bad if you've got any files that aren't straight text.\n\nYou won't get any benefit out of things like \"git diff\" either. The\ndiffs we have (these days at least) don't work well on anything but plain\ntext.\n\nI suggest you stick to using git down on the project level, where a\nproject should be limited to things like code development (or writing\nprojects where you stick to text formats), and give up on any ideas like\nputting your entire home directory into a single repository.\n\nAs far as mirroring machines go, rsync based solutions actually aren't\nthat bad, though in addition to the annoying syntax gotchas, I've had\nproblems with an unreliable laptop clock. Lately I've been using the\n\"--size-only\" option of rsync, which assumes that if a file is bigger\nit must be newer.\n\nI tend to use a perl script something like this, which copies newer\nstuff from a given directory to an analogous directory on a remote\nmachine:\n\n use File::Basename qw( dirname );\n my $this = shift; # e.g. '/home/doom/dev/code\n my $there = shift; # e.g. 'doom@192.168.1.3'\n my $this_loc = dirname( $this );\n $cmd = \"rsync -avz --size-only -e ssh $this $there:$this_loc\";\n system( $cmd );\n"},{"id":"141555","messageId":"AANLkTikc6_jZoMzF1VhfJBSk1DRHCNNP3puPT0Z2Usk5@mail.gmail.com","threadId":"23781","inReplyTo":"201005130018.o4D0I7iI079145@kzsu.stanford.edu","subject":"Re: Advice on choosing git","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-13T00:31:32Z","receivedAt":"2010-05-13T00:31:32Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, May 12, 2010 at 8:18 PM, Joe Brenner wrote:\n> Noah Silverman wrote:\n>> 1) Size.  THIS IS MY MAIN CONCERN - If I want to sync my home, office,\n>> and server Document directories.  From what I have read, I will\n>> effectively have multiple copies of each item on my hard drive, thus\n>> eating up a lot of space\n>\n> Pretty much any version control system is going to have this problem,\n> and it gets really bad if you've got any files that aren't straight text.\n\nNote that most people probably don't need to worry about this\nnowadays. Disk $/gigabyte just keeps dropping and is now at\nabsolutely abysmally small levels. You can only fill up your disks if\nyou download tons of movies and/or create tons of VMs.\n\nIf you're struggling with a laptop drive that's too small, just buy a\nnew one for $100 and solve all your problems.\n\nSo you're fine with storing multiple copies. Just make sure your\nbackup/syncing software has an expiration algorithm so you don't end\nup storing *all* the historical copies.\n\nI'd like to adapt bup to support this usage model eventually.\nHowever, I haven't yet written the expiration algorithm and it doesn't\nyet support two-way syncing. The fundamental design allows for this,\nthough, so it's just a matter of having some free time. Meanwhile,\nyou might want to take a look at something like rdiff-backup.\n\nHave fun,\n\nAvery\n"},{"id":"141573","messageId":"vpqvdasgh8d.fsf@bauges.imag.fr","threadId":"23781","inReplyTo":"201005130018.o4D0I7iI079145@kzsu.stanford.edu","subject":"Re: Advice on choosing git","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-05-13T11:42:58Z","receivedAt":"2010-05-13T11:42:58Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Joe Brenner writes:\n\n> You won't get any benefit out of things like \"git diff\" either. The\n> diffs we have (these days at least) don't work well on anything but plain\n> text.\n\nNot totally true. textconv filter is just great when working when\nword-processors (with the filter being odt2txt or antiword).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"141576","messageId":"vpqr5lgggzt.fsf@bauges.imag.fr","threadId":"23781","inReplyTo":"AANLkTikc6_jZoMzF1VhfJBSk1DRHCNNP3puPT0Z2Usk5@mail.gmail.com","subject":"Re: Advice on choosing git","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-05-13T11:48:06Z","receivedAt":"2010-05-13T11:48:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Avery Pennarun writes:\n\n> You can only fill up your disks if\n> you download tons of movies and/or create tons of VMs.\n\nRight, but if you do so, managing your movies and VMs with Git would\nbe really bad idea. Typically, you don't want your backup system to\ntry to diff each movie with each other to save space.\n\n> Just make sure your backup/syncing software has an expiration\n> algorithm so you don't end up storing *all* the historical copies.\n\nAnd this is where Git will be really bad. Removing past revisions\nmeans editing history, and while Git knows how to edit history,\nsyncing after doing that will be terrible.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"141577","messageId":"20100513115158.GB10963@coredump.intra.peff.net","threadId":"23781","inReplyTo":"vpqvdasgh8d.fsf@bauges.imag.fr","subject":"Re: Advice on choosing git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-13T11:51:58Z","receivedAt":"2010-05-13T11:51:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 13, 2010 at 01:42:58PM +0200, Matthieu Moy wrote:\n\n> Joe Brenner writes:\n> \n> > You won't get any benefit out of things like \"git diff\" either. The\n> > diffs we have (these days at least) don't work well on anything but plain\n> > text.\n> \n> Not totally true. textconv filter is just great when working when\n> word-processors (with the filter being odt2txt or antiword).\n\nI agree. Whoever wrote the textconv code was a genius. ;)\n\nBut I did want to note that textconv is just _one_ way of seeing the\ndata. You can also have git invoke custom diff and merge handlers. I\nhaven't tried it, but I suspect you may be able to drive the interactive\ngraphical versioning found in many word processors. I thought somebody\nhad done some work on this, but I can't seem to dig up a link.\n\n-Peff\n"},{"id":"141601","messageId":"AANLkTikLph7SZsAt0aK2Axm7DyrsGta39LZ1vq7aW0c6@mail.gmail.com","threadId":"23781","inReplyTo":"vpqr5lgggzt.fsf@bauges.imag.fr","subject":"Re: Advice on choosing git","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-13T17:31:33Z","receivedAt":"2010-05-13T17:31:33Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, May 13, 2010 at 7:48 AM, Matthieu Moy\n wrote:\n> Avery Pennarun writes:\n>> You can only fill up your disks if\n>> you download tons of movies and/or create tons of VMs.\n>\n> Right, but if you do so, managing your movies and VMs with Git would\n> be really bad idea. Typically, you don't want your backup system to\n> try to diff each movie with each other to save space.\n\nThis problem is supposedly solved by the git-bigfiles project. bup\ndoes things a bit differently, but works well when deduplicating\nthings like VMs and movies, even though it uses the git repository\nformat.\n\n>> Just make sure your backup/syncing software has an expiration\n>> algorithm so you don't end up storing *all* the historical copies.\n>\n> And this is where Git will be really bad. Removing past revisions\n> means editing history, and while Git knows how to edit history,\n> syncing after doing that will be terrible.\n\nYeah, obviously an SCM doesn't really need history expiration\nfeatures, and git's transport protocols are optimized with the\nassumption that expiration will never happen. bup uses a different\nprotocol so it won't have this problem (but bup doesn't have any\nexpiration features at all, right now). rdiff-backup, which I also\nmentioned, is efficient in the face of expiration.\n\nHave fun,\n\nAvery\n"},{"id":"141602","messageId":"AANLkTinIsXGxPhC8aICUTODIy2CVI9YRyeR7464h0Tbc@mail.gmail.com","threadId":"23781","inReplyTo":"4BEA4B46.6010009@smartmediacorp.com","subject":"Re: Advice on choosing git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2010-05-13T18:20:55Z","receivedAt":"2010-05-13T18:20:55Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Wed, May 12, 2010 at 2:31 AM, Noah Silverman wrote:\n> 1) I'd like to keep my documents directory synced between the office and\n> home machines.\n> 2) I'd like to keep two or three sub directories of this synced with my\n> laptop\n> 3) We have a server in \"the cloud\" where I like to keep backups of my\n> documents.  Just in case.\n\nUnison is a perfect fit for items 1 & 2. Works well over large files,\ndoes not keep history.\n\nThe DSCMs tend to fall over with very large (often binary) files. A\nfew videos included in your presentation, high res TIFF images,\nhorrendously fat PDFs coming from a third party, even an openoffice\npresentation with many imagees, all make the DSCMs choke, because\ninternally the DSCM wants to load it into RAM to store deltas.\n\nThe DSCM assumption is that a source file will fit in ram with ample\nspace to spare, to be delta'd (for storage) and diff'd.\n\n> 3) I have a few project where I am the only developer, but want a VCS to\n> manage my changes.\n> 4) I have 3-4 projects where there are a team of 3 of us and I want to\n> use a VCS.\n\ngit is a perfect fit for 3 & 4. Mercurial is a close competitor.\n\ncheers,\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"141894","messageId":"aCSPCSKYLz8LFwlq@thewolery.demon.co.uk","threadId":"23781","inReplyTo":"AANLkTikc6_jZoMzF1VhfJBSk1DRHCNNP3puPT0Z2Usk5@mail.gmail.com","subject":"Re: Advice on choosing git","fromName":"Anthony W. Youngman","fromEmail":"wol@thewolery.demon.co.uk","sentAt":"2010-05-19T00:37:44Z","receivedAt":"2010-05-19T00:37:44Z","isPatch":false,"sender":{"key":"wol@thewolery.demon.co.uk","avatar":null},"body":"In message \n, Avery \nPennarun writes\n>On Wed, May 12, 2010 at 8:18 PM, Joe Brenner wrote:\n>> Noah Silverman wrote:\n>>> 1) Size.  THIS IS MY MAIN CONCERN - If I want to sync my home, office,\n>>> and server Document directories.  From what I have read, I will\n>>> effectively have multiple copies of each item on my hard drive, thus\n>>> eating up a lot of space\n>>\n>> Pretty much any version control system is going to have this problem,\n>> and it gets really bad if you've got any files that aren't straight text.\n>\n>Note that most people probably don't need to worry about this\n>nowadays. Disk $/gigabyte just keeps dropping and is now at\n>absolutely abysmally small levels. You can only fill up your disks if\n>you download tons of movies and/or create tons of VMs.\n>\n>If you're struggling with a laptop drive that's too small, just buy a\n>new one for $100 and solve all your problems.\n\nAnd create a bunch of new ones. I think you mean \"buy yourself a new \nlaptop\"!\n\nJust because YOUR computer is modern and is happy being fed a new bigger \nhard drive doesn't mean they all are. This computer here has 3/4gig ram. \nTiny by modern standards but I can't put any more in - it only has three \nslots at 256Mb maximum each. And it's got a 250Gb drive but it can only \nuse the first 128Gb (I'm being economical with the truth here, but \nhey...)\n\nAnyways. Why should hundreds of people have to throw out thousands of \nserviceable machines just because a few programmers can't be assed to at \nleast TRY to be economical with their usage of resources?\n\nCheers,\nWol\n-- \nAnthony W. Youngman - anthony@thewolery.demon.co.uk\n"},{"id":"141895","messageId":"AANLkTimymNnHHXnN3dsFfis30FBsuboXc0ILXExB5IkU@mail.gmail.com","threadId":"23781","inReplyTo":"aCSPCSKYLz8LFwlq@thewolery.demon.co.uk","subject":"Re: Advice on choosing git","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-05-19T01:12:50Z","receivedAt":"2010-05-19T01:12:50Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, May 18, 2010 at 8:37 PM, Anthony W. Youngman\n wrote:\n> Just because YOUR computer is modern and is happy being fed a new bigger\n> hard drive doesn't mean they all are. This computer here has 3/4gig ram.\n> Tiny by modern standards but I can't put any more in - it only has three\n> slots at 256Mb maximum each. And it's got a 250Gb drive but it can only use\n> the first 128Gb (I'm being economical with the truth here, but hey...)\n>\n> Anyways. Why should hundreds of people have to throw out thousands of\n> serviceable machines just because a few programmers can't be assed to at\n> least TRY to be economical with their usage of resources?\n\nIt's a tradeoff. There are a bunch of programs that can sync files\nback and forth *without* keeping a history - and those tools are\nmostly not used. IMHO that's because they're too complicated and\ndangerous; if something goes wrong with your sync, the\nmistakenly-deleted-or-modified files are gone for good. If I care\nenough about my files to want to replicate them for safety, then I\ncare too much about them to trust them to an unpredictable sync\nalgorithm.\n\nA version control system like git, on the other hand, makes a\ndifferent tradeoff: you can be reasonably sure that it'll *never*\npermanently lose data, but to get that assurance, you're going to pay\nfor it in disk space.\n\nIf you want to use yesterday's computers, you're probably going to\nhave to be satisfied with yesterday's solutions. AFAIK, home\ndirectory replication has never been adequately solved. Of course,\nsomeone could still come along and invent an elegant, fast, reliable,\nspace-efficient, trustworthy solution to this problem. But I don't\nthink that person has been along yet.\n\nHave fun,\n\nAvery\n"}]}