[PATCH 3 of 3] largefiles: add --large to init command to immediately mark as a largefiles repo

[Na'Tosha Bard]

2012/8/9 Matt Harbison <matt_harbison at yahoo.com>

> Na'Tosha Bard wrote:
>
>> 2012/8/7 Matt Harbison <matt_harbison at yahoo.com
>> <mailto:matt_harbison at yahoo.**com <matt_harbison at yahoo.com>>>
>>
>>
>>     # HG changeset patch
>>     # User Matt Harbison <matt_harbison at yahoo.com
>>     <mailto:matt_harbison at yahoo.**com <matt_harbison at yahoo.com>>>
>>
>>     # Date 1343696201 14400
>>     # Node ID e45f7b1b766e67c56c40a92c86dd82**3b903eaf96
>>     # Parent  40fc3ecfffc7727537a11f5a26064e**97f1dd0e7b
>>     largefiles: add --large to init command to immediately mark as a
>>     largefiles repo
>>
>> How does this work out in the following use case:
>>
>> 1) User creates a normal repo, then adds and commits a file with
>> "-large", turning the repo into a largefiles repo.
>> 2) User strips this commit, so now the repo now has no largefiles.
>>
>> I think expected behavior would be that the repo is now no longer a
>> largefiles repo, and subsequent "hg add" calls will not possibly add
>> files as largefiles, but I don't think that would happen with this change.
>>
>>
> I hadn't thought about strip, but I agree that seems like reasonable
> behavior.  You're correct though- it gets added as large instead.  As an
> aside, why does the requirement stay when this occurs?  Is that file meant
> to be append only?


I just think it's never been the case that we've needed to *remove* a
requirement from the requires file, so there is no mechanism for doing it.


>
>  If the user had run "hg init -large", (instead of running plain "hg
>> init" and then adding a file with -large), then I believe expected
>> behavior would be that the repo would forever be a largefiles repo.
>> However I'm not sure how we can distinguish this.
>>
>>
> Agreed.  I'm not sure either, and I'm not sure if there are other places
> that could benefit from remembering user choices that don't have an
> immediate effect, meaning this should be solved generically (I can't think
> of any cases).
>
> The best I can think of is to add a file in .hg/largefiles that isn't
> tracked.  I don't think it necessarily has to have content for this. The
> benefit of it not being tracked is it doesn't have to be filtered out of
> all command output; the downside is cloning such a repo results in a normal
> repo with the current code.  Maybe overrideclone() can detect and transfer
> this file/setting somehow, like how bookmarks are transferred?  (I have no
> idea how bookmarks and clone actually works.)
>

This seems like a reasonable solution and should be possible to use a
similar mechanism to how we transfer bookmarks from remote to local
repositories.

Cheers,
Na'Tosha

-- 
*Na'Tosha Bard*
Software Developer | Unity Technologies - Copenhagen

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120809/4dce3d30/attachment-0002.html>