Thoughts on narrow checkouts

[Didly Bom]

On Wed, Aug 18, 2010 at 10:08 AM, Patrick Mézard <pmezard at gmail.com> wrote:

> Le 18/08/10 09:42, Didly Bom a écrit :
> > On Wed, Aug 18, 2010 at 2:49 AM, Matt Mackall <mpm at selenic.com <mailto:
> mpm at selenic.com>> wrote:
> >
> >     On Mon, 2010-08-16 at 14:30 +0200, Martin Geisler wrote:
> >     > Patrick Mézard <pmezard at gmail.com <mailto:pmezard at gmail.com>>
> writes:
> >     >
> >     > Hi Patrick,
> >     >
> >     > > I am trying to measure the feasability and amount of work to
> support
> >     > > read-only narrow checkouts as Mercurial subrepositories.
> >     >
> >     > I think this sounds like an interesting and useful feature.
> >
> >     Agreed. Though if we're going to be read-only, we might as well think
> >     ahead to narrow pulls as well.
> >
> >
> > I also think that this could be a very useful feature!
> >
> > Is there a technical reason (other than the additional development
> effort) to make these narrow checkouts read only? Or could this be a first
> step towards full narrow checkout support?
>
> Actually it depends whether we want narrow checkouts or narrow clones. If
> the approach I described is valid, read-only narrow checkouts could probably
> be extended to writable ones: once your are able to trick the
> dirstate/fs-operations to think they operate on the whole checkout instead
> of a subset of it, all operations should work accordingly, except for stuff
> depending and repo wide paths like .hgignore, matcher objects and the likes.
> Read-only narrow clones are probably harder to implement than read-only
> checkouts, and much harder to make writable, but I could be wrong.
>
> So my current plan was to go for narrow checkouts because the read-only
> case seems doable, because I don't have real issues with cloning full
> repositories even if I checkout only part of them and because I believe they
> can be made writable later with the same approach.
>
> --
> Patrick Mézard
>

Patrick, thanks for the explanation.

So if I understood you correctly, the difference between a narrow checkout
and a narrow clone is that in the former case you still get the whole
repository history (i.e. your .hg folder is basically the same as the .hg
folder of a regular repository), but you only get some files in your working
copy. On the other hand, if a narrow clone feature was implemented, the .hg
folder would only contain the information regarding the files that would be
included in the working copy (thus potentially reducing the size of a narrow
clone). Is that it?

If so, I feel that while it would be nice to have at some point real "narrow
clones", this would mostly be an optimization feature. It seems to me that
functionality-wise narrow check-outs would cover all possible use cases of
narrow clones (except those in which you wanted to use them to reduce the
size of your repositories or the time or bandwidth used to clone, push and
pull).

So, as a user, I would find it much more useful to have writable narrow
checkouts than read-only narrow clones (although writable narrow clones
would be even nicer :-) )

Cheers,

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20100818/6386a594/attachment.html>