On Thu, May 14, 2009 at 8:39 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Alexander Gavrilov <angavrilov@xxxxxxxxx> writes: > >> We are considering using Git to manage a large set of mostly binary >> files (large images, pdf files, open-office documents, etc). The >> amount of data is such that it is infeasible to force every user >> to download all of it, so it is necessary to implement a partial >> retrieval scheme. >> >> In particular, we need to decide whether it is better to invest >> effort into implementing Narrow Clone, or partitioning and >> reorganizing the data set into submodules (the latter may prove >> to be almost impossible for this data set). We will most likely >> develop a new, very simplified GUI for non-technical users, >> so the details of both possible approaches will be hidden >> under the hood. > > First, there were quite complete, although as far as I know newer > accepted into git, work on narrow / sparse / subtree / partial > *checkout*. IIRC the general idea about extening or (ab)using > assume-unchanged mechanism was accepted, but the problem was in the > user interface details (I think that porcelain part was quite well > accepted, except hesitation whether to use/extend existing flag, or > create new for the purpose of narrow checkout). You can search > archive for that > http://article.gmane.org/gmane.comp.version-control.git/89900 > http://article.gmane.org/gmane.comp.version-control.git/90016 > http://article.gmane.org/gmane.comp.version-control.git/77046 > http://article.gmane.org/gmane.comp.version-control.git/50256 > ... > should give you some idea what to search for. This is of course > only part of solution. FWIW I still maintain the patch series as a merged branch "tp/sco" under my branch "inst" here http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=refs/heads/inst -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html