Largefiles broken?

Thu Jan 3 23:14:58 UTC 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://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20130103/77c05eb3/attachment-0002.html>