[PATCH] largefiles: cache new largefiles for new heads when pulling

[Matt Mackall]

On Tue, 2012-01-17 at 17:06 -0600, Matt Mackall wrote:
> On Tue, 2012-01-17 at 22:10 +0100, Na'Tosha Bard wrote:
> > On Tue, Jan 17, 2012 at 9:56 PM, Matt Mackall <mpm at selenic.com> wrote:
> > 
> > > On Tue, 2012-01-17 at 16:36 +0100, Na'Tosha Bard wrote:
> > > > # HG changeset patch
> > > > # User Na'Tosha Bard <natosha at unity3d.com>
> > > > # Date 1326814529 -3600
> > > > # Node ID 453c8e098d89d29c725ef0c3bc609aa977c2f7c0
> > > > # Parent  d25169284e9883bfff74faf4fdafdd74a6a5ba27
> > > > largefiles: cache new largefiles for new heads when pulling
> > >
> > > I guess. Queued for default.
> > 
> > 
> > Do you think it would be a good idea to have an option to turn off this
> > behavior?
> > 
> > On one hand, the promise we make with largefiles is, "You'll only download
> > the largefiles you need."  In order to do pretty much anything meaningful
> > with another head (merge, rebase, or update to it), you will need to
> > download these largefiles.  So this doesn't really break that promise and
> > it fixes a workflow problem.
> > 
> > But I can imagine a situation, where you might not want this behavior -- if
> > you have a huge number of named branches, for example, with several large,
> > unique largefiles, and you are not sure when or if you will merge with any
> > of them.
> > 
> > If we think it would be a good idea to add an option for "don't cache
> > largefiles for new heads on pull", I'll be happy to do it.
> 
> "I guess" was basically shorthand for "there's apparently no perfect
> answer". The same problem exists with subrepos, but we can't do much
> about it there because we don't have a free-standing subrepo cache:
> everything lives in the working directory.
> 
> If the other largefiles folks think this is the best answer here, I'm
> fine with it. 

Looks like this fails a couple tests, check-code plus this in
test-largefiles-cache.t

@@ -37,6 +37,8 @@
   adding file changes
   added 1 changesets with 1 changes to 1 files
   (run 'hg update' to get a working copy)
+  caching new largefiles
+  0 largefiles cached

Not sure if that's a correct result, so dropping for now.

-- 
Mathematics is the supreme nostalgia of our time.