[PATCH 2 of 2 RFC] extdiff: use -S to archive the full repo

Mathias De Maré mathias.demare at gmail.com
Tue Feb 10 13:36:42 CST 2015


On Tue, Feb 10, 2015 at 4:39 AM, Matt Harbison <mharbison72 at gmail.com>
wrote:

> On Mon, 09 Feb 2015 19:52:56 -0500, Matt Harbison <mharbison72 at gmail.com>
> wrote:
>
>  On Mon, 09 Feb 2015 18:02:25 -0500, Augie Fackler <raf at durin42.com>
>> wrote:
>>
>>  On Sun, Feb 08, 2015 at 11:01:37PM -0500, Matt Harbison wrote:
>>>
>>>> # HG changeset patch
>>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>>> # Date 1342370590 14400
>>>> #      Sun Jul 15 12:43:10 2012 -0400
>>>> # Node ID 9c4f27e5c804662d2d25581ad3856ef6da3729ec
>>>> # Parent  6abceaa1a49f82cebd3a4f141f69558e2bb3cec4
>>>> extdiff: use -S to archive the full repo
>>>>
>>>> The working copy snapshot into the subrepo(s) is still missing.
>>>>
>>>
>>> This sentence makes no sense to me. Can you reprhase it?
>>>
>>
>> Basically, archive -S can extract the necessary files into the snapshot
>> directory, from both the parent and the subrepo.  But archive doesn't work
>> on 'repo[None]', so I left the old code in there to (partially) handle that
>> case.  The old code doesn't recurse into subrepos though.  So this meant
>> "working copy snapshot *of* the subrepo(s) is still missing- only the
>> parent repo is in the snapshot of the working directory".
>>
>> I'm not sure what the right thing is here.  A revset symbol for the
>> working directory was recently mentioned on the ML.  Presumably archive
>> should support it.  But it doesn't look like the subrepo code supports
>> "give me a subrepo containing its working context".  It looks like the
>> state tuple can only contain a committed revision identifier?  So archive
>> -S wouldn't be able to support such a symbol without changes to subrepo.
>>
>> OTOH, Mathias pointed out util.copyfile(), which is probably easier, and
>> looks like it would work with largefiles without any issues.  But then we
>> lose the 'wfn not in ctx' check.
>>
>
> Scratch that.  Archive *does* support taking the working directory (the
> command line doesn't), and it looks like it even grabs the uncommitted
> files in hgsubrepo too.  But largefiles aborts when trying to archive the
> working copy, so I think that needs to be fixed first to avoid breaking
> something that works now.  I'm not sure why I special cased 'node is None'
> 2 years ago, and I didn't double check yesterday.
>
> Mathias- can you test with dirty files in git?  You just need pull the new
> archiving lines out of the 'if node is not None' check, and drop the opener
> and for loop left over in the else case.  I did a quick comparison against
> 'diff -S' output, and it looks sane.
>

Adding a single file in the working directory worked fine (since it only
does the snapshot for the old (non-working dir) context).
When I add a file and remove another, I get 'abort: no files match the
archive pattern' when the snapshot of the working directory is done. I had
a further look, and it seems (archive.py:307-310) like for the
subrepositories, the revision is always extracted by checking the substate.
As a result, the last revision is used (instead of the working directory).
Specifically for Git, I have the impression there's additionally the
problem that 'git archive' does not support archiving the working directory.

If I then commit the added and removed file and run extdiff on those, it
works fine.

So to get the working directory working, we'll also need to modify the
support for archiving subrepos in general and git subrepos in particular.

Greetings,
Mathias

>
> --Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150210/5a117684/attachment.html>


More information about the Mercurial-devel mailing list