Re: [Monotone-devel] Re: netsync doesn't do anything

[Nathaniel Smith]

On Tue, Apr 05, 2005 at 01:58:24PM +0200, Peter Simons wrote:
> Nathaniel Smith writes:
>  > The workaround is to make sure that if you want to pull
>  > one revision, you're also pulling its complete ancestry
>  > at the same time.
> 
>  > Does this fix your problems?
> 
> No, unfortunately it does not. The setup I have is:

Ah, well, but just to be sure -- it does explain your problem, i.e., I
know you have at least one _more_ problem, but now we know that the
original problem isn't some hitherto unseen bug?

>  branch A  =  unfathomably large set of files
> 
>  branch B  =  mind-boggingly small subset of A
> 
> So for the sake of efficiency, I want users to be able to
> pull B _without_ pulling A -- which is precisely the case
> that doesn't work.
> 
> In other words, it would be really, really nice if this
> problem could be fixed, because it's essentially a
> show-stopper for me using monotone in this project. :-(

Yes, we do need to support some kind of "partial pull", for large
projects -- just because it's not at all reasonable to ask a casual
contributor to download however many megs (or gigs!) of history exist.
Matt's been working on this some, not sure how far he's gotten.  There
are a lot of very tricky cases, unfortunately, but hopefully we'll
eventually figure it out...

> P. S.: It's a show-stopper because doing a "monotone status"
> or "monotone commit" in branch A runs for several minutes on
> the fastest machine we have. The developers doing everyday
> work in this branch is out of question, unfortunately. We
> need to split A into smaller sub-branches, but we need to do
> so without losing the ability to propagate changes in B back
> into A.

...but this makes it sound like your problem is not the problem that
partial pulls can solve.  "status", "commit", etc. should be O(the
size of your current tree), and the amount of history in your
database, or the size of historical trees, should be irrelevant.  Am I
wrong?

As for "status" and "commit" taking that long, I assume it's because
we currently read the entire working copy off of disk scanning for
changes, and you're waiting on IO.  It's entirely possible, even
straightforward, to fix this, and let people use something more like
CVS's timestamps to detect differences; just someone needs to write
it...

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff