Largefiles broken?

Na'Tosha Bard natosha at unity3d.com
Thu Jan 3 04:49:49 CST 2013


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/3136b2be/attachment.html>


More information about the Mercurial-devel mailing list