Largefiles broken?
dukeofgaming
dukeofgaming at gmail.com
Thu Jan 3 17:14:58 CST 2013
If the .hglarge file I'm suggesting behaves just the way .hgignore does, I
think nobody would have a problem. That way people have a more intuitive
option and current functionality/behavior doesn't need to be modified.
It would be just adding a new way of doing things.
Regards,
David
On Thu, Jan 3, 2013 at 4:49 AM, Na'Tosha Bard <natosha at unity3d.com> wrote:
>
>
> 2013/1/2 Matt Harbison <matt_harbison at yahoo.com>
>
>> dukeofgaming wrote:
>>
>>> 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
>>>
>>
>> I think there are two issues identified in this thread:
>>
>> 1) users are unaware/forget that an extra explicit optin is required when
>> adding large files the first time.
>>
>> 2) the explicit optin is inconvenient when wanting to immediately rely on
>> the configured patterns (e.g. addremove).
>>
>>
>> I think 1 is the bigger issue because largefiles are more likely to be
>> added to an existing repo that already has largefiles, than to a fresh one
>> without. Once in the habit of the pattern being used automatically, it is
>> very easy to expect the files to be added as large, and commit a bunch of
>> stuff before realizing there's an issue. This then becomes a permanent
>> part of the history. A config option doesn't help this without defeating
>> the original safeguard for other repos on the system.
>>
>> A better option for this may be to emit a warning if a file that matches
>> a configured large pattern is added as a normal file because the repo
>> hasn't locked in a largefile yet.
>
>
> But what happens then someone adds a largefile accidentally via a GUI tool
> that eats the warning and the user doesn't see it? Do we just say that's a
> bug in the GUI tool and argue that it isn't our problem?
>
> Cheers,
> Na'Tosha
>
>
>> (Similar to the bookmark warning when branching. I know there were
>> complaints about that, but I think they were mostly about content and the
>> frequency of the warning. Here, the warning doesn't occur once a largefile
>> is added, or the extension is disabled for that repo. The unfortunate part
>> would be that the add operation would have to be redone if the files really
>> should have been large.)
>>
>> The other choice here would be to prompt the user instead of just warning
>> and continuing, but that may not be possible due to backward compatibility
>> concerns.
>>
>> The config option would help #2, but I like the idea of the .hglarge
>> pattern file more for this case, simply because it doesn't defeat the
>> original safeguard when dealing with other repos on the system, and
>> provides a capability to (mostly) centralize the configuration.
>>
>> All that said, I'm not totally against the config option if you want to
>> try it- I just wanted to see if there are other/better options that should
>> be investigated first.
>>
>>
>> --Matt
>>
>>
>>
>>> On Mon, Nov 19, 2012 at 11:29 AM, Na'Tosha Bard <natosha at unity3d.com
>>> <mailto:natosha at unity3d.com>> wrote:
>>>
>>> 2012/11/17 Matt Harbison <matt_harbison at yahoo.com
>>> <mailto:matt_harbison at yahoo.**com <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 <mailto:natosha at unity3d.com>
>>> *Skype:* natosha.bard
>>>
>>>
>>> ______________________________**_________________
>>> Mercurial-devel mailing list
>>> Mercurial-devel at selenic.com <mailto:Mercurial-devel@**selenic.com<Mercurial-devel at selenic.com>
>>> >
>>> http://selenic.com/mailman/**listinfo/mercurial-devel<http://selenic.com/mailman/listinfo/mercurial-devel>
>>>
>>>
>>>
>>
>
>
> --
> *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://selenic.com/pipermail/mercurial-devel/attachments/20130103/77c05eb3/attachment.html>
More information about the Mercurial-devel
mailing list