Largefiles broken?

[dukeofgaming]

It would just be to make largefiles more intuitive.

The config parameter looks like the way to go, and I agree that it should
be deactivated by default.

I would also sugges .hglarge an file with the ability to add glob/regex
rules. The current way is too crammed (all rules in a single line).

Regards,

David


On Mon, Nov 19, 2012 at 11:29 AM, Na'Tosha Bard <natosha at unity3d.com> wrote:

> 2012/11/17 Matt Harbison <matt_harbison at yahoo.com>
>
>> Arne Babenhauserheide wrote:
>>
>>> Am Donnerstag, 15. November 2012, 22:12:26 schrieb Matt Harbison:
>>>
>>>> dukeofgaming wrote:
>>>>
>>>>> I think adding a "largefiles" option to these two commands could be
>>>>> more
>>>>> intuitive:
>>>>>
>>>>> hg add --largefiles
>>>>> hg addremove --largefiles
>>>>>
>>>>> Would this be possible?
>>>>>
>>>> I agree that having to explicitly add one of the files first is a bit
>>>> surprising and inconvenient, and even init --large doesn't completely
>>>> fix this because what if you want to opt in later?  But I don't think
>>>> this proposal will gain acceptance for a couple of reasons:
>>>>
>>>
>>> Why not just as a config option to largefiles?
>>>
>>> [largefiles]
>>> assume_tracked_largefile = True
>>>
>>> All the calls would then change to
>>>
>>> hg --config largefiles.assume_tracked_**largefile=True
>>> add/addremove/commit/…
>>>
>>> It would then also be possible to opt in for all repos by setting the
>>> config
>>> in the ~/.hgrc.
>>>
>>
>> I could be wrong, but I was under the impression that the reason an
>> explicit opt in was required was to prevent somebody from simply enabling
>> the extension in the user level or global hgrc, along with a pattern or
>> size, and unwittingly commit largefiles in a repo they didn't mean to.  So
>> adding another option that could be put in the global or user config and
>> cause the exact same problem undermines that safeguard.
>>
>> Given a choice between that and just honoring the pattern as long as the
>> extension is enabled, I would opt for the latter.  But I'm not sure that
>> would be permitted, given that largefiles somewhat changes a DVCS to a CVCS
>> (i.e. largefiles don't come along for the ride by default when pulling or
>> cloning).
>
>
> This is indeed the reason why enabling the largefiles extension still
> means you have to explicitly add a file as a largefile the first time.
>  Largefiles significantly change how Mercurial works and it's quite easy to
> accidentally turn a non-largefiles repo into a largefiles repo accidentally
> if the behavior didn't require this.
>
> It could be a reasonable solution to add a "assume_largefile_repos" or
> similar setting, as long as the default is "False", but I'm not convinced
> this is actually much of a real-world problem.
>
> Cheers,
> Na'Tosha
> --
> *Na'Tosha Bard*
> Software Developer | Unity Technologies - Copenhagen
>
> *E-Mail:* natosha at unity3d.com
> *Skype:* natosha.bard
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121231/44629b68/attachment.html>