[PATCH] treemanifest: allow setting flag to 't'

Martin von Zweigbergk martinvonz at google.com
Sun Feb 21 11:13:11 EST 2016


Yep, was working on it yesterday. Can probably send it out tonight. I'll
explain that the 't' flag appears in the on-disk format and that it means
that that entry exists in a subdirectory log. I'll also elaborate on my
plans for the narrow extension. Let me know if there was anything else
(I've lost your comments past the scroll-back buffer).

On Sun, Feb 21, 2016, 02:46 Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

> After an irc discussion with Martin, I think I now understand this and
> I'm okay with it. Can we get a V2 with an updated description?
>
> On 02/12/2016 10:48 PM, Martin von Zweigbergk wrote:
> > On Fri, Feb 12, 2016, 07:20 Pierre-Yves David
> > <pierre-yves.david at ens-lyon.org> wrote:
> >>
> >>
> >>
> >> On 02/10/2016 07:12 PM, Martin von Zweigbergk wrote:
> >>> # HG changeset patch
> >>> # User Martin von Zweigbergk <martinvonz at google.com>
> >>> # Date 1455078153 28800
> >>> #      Tue Feb 09 20:22:33 2016 -0800
> >>> # Node ID 219279ba5749b893225284f6d5b486f5a1bfabb1
> >>> # Parent  a036e1ae1fbe88ab99cb861ebfc2e4da7a3912ca
> >>> treemanifest: allow setting flag to 't'
> >>>
> >>> The narrowhg extension allows cloning only a given set of files and
> >>> directories. Filelogs and dirlogs that don't match that set will not
> >>> be included in the clone. The extension currently doesn't work with
> >>> treemanifests. I plan on changing it so directories outside the narrow
> >>> clone appear in the manifest. I will therefore need to set the flag to
> >>> 't' on these nodes. I could of course directly update the _flags
> >>> field, but there's also call from manifest._slowreaddelta() that's
> >>> going to be problematic. Instead, let's just drop the assertion.
> >>
> >> I've read this description a couple of time and I'm fairly confused
> >> about this patch.
> >>
> >> Are you saying that there is no way to distinct a file from a directory
> >> without actually looking at it's file/directory log? And therefor narrow
> >> get confused?
> >
> > With my unsubmitted patches to narrowhg, manifest.read() replaces
> > directories (instances of the treemanifest class) that are outside the
> > narrow clone by placeholders. When these placeholders are iterated
> > over, they report something like ("dir/outside/clone/", "deadbeef", "
> > t"). I think that's a simple and good approach for handling these
> > exclude directories, so they are not silently dropped from e.g.
> > manifestmerge() and diff() and such. Instead, they will either just
> > work, or it will be obvious what the problem was (for example, "hg
> > manifest" will try to show the mode and flags for the unknown 't'-type
> > file). However, one problem it runs into is when _slowreaddelta()
> > tries to diff two manifests and create a new (partial) manifest. It
> > does so by iterating over m1.diff(m2) and inserts added or modified
> > entries into the partial manifest. That involves calling setflag() if
> > the added/modified entry has a flag.
> >
> > I hope that makes it clearer. Which parts do you think belong in an
> > updated commit message? I don't mind putting all of it in if you think
> > that's not too much.
> >
> > An alternative solution I was thinking of is to make _slowreaddelta()
> > to return a manifestdict. I don't think the tree-ness of the resulting
> > partial manifest ever matters. While that might work, and might be a
> > little faster (because manifestdict is faster than treemanifest), it
> > only happens to fix the problem because manifestdict.setflag() doesn't
> > have the assertion.
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
> >
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160221/8333d18e/attachment.html>


More information about the Mercurial-devel mailing list