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

Matt Harbison matt_harbison at yahoo.com
Wed Aug 8 21:09:28 CDT 2012


Na'Tosha Bard wrote:
> 2012/8/7 Matt Harbison <matt_harbison at yahoo.com
> <mailto:matt_harbison at yahoo.com>>
>
>     # HG changeset patch
>     # User Matt Harbison <matt_harbison at yahoo.com
>     <mailto:matt_harbison at yahoo.com>>
>     # Date 1343696201 14400
>     # Node ID e45f7b1b766e67c56c40a92c86dd823b903eaf96
>     # Parent  40fc3ecfffc7727537a11f5a26064e97f1dd0e7b
>     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?

> 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.)

--Matt


More information about the Mercurial-devel mailing list