Largefiles broken?
Na'Tosha Bard
natosha at unity3d.com
Thu Jan 3 10:49:49 UTC 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://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20130103/3136b2be/attachment-0002.html>
More information about the Mercurial-devel
mailing list