[prev in list] [next in list] [prev in thread] [next in thread]
List: mercurial-devel
Subject: Re: Largefiles broken?
From: dukeofgaming <dukeofgaming () gmail ! com>
Date: 2012-12-31 20:41:08
Message-ID: CAFt2z-mg9JDjH+8oC+z84DR+BtPBk-AcDu3BnUhPRWdAieJ5ag () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@unity3d.com> wrote:
> 2012/11/17 Matt Harbison <matt_harbison@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@unity3d.com
> *Skype:* natosha.bard
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>
[Attachment #5 (text/html)]
<div dir="ltr">It would just be to make largefiles more intuitive.<div><br></div><div \
style>The config parameter looks like the way to go, and I agree that it should be \
deactivated by default.</div><div style><br></div><div style>
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).</div><div \
style><br></div><div style>Regards,</div><div style><br></div><div style>
David</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, \
Nov 19, 2012 at 11:29 AM, Na'Tosha Bard <span dir="ltr"><<a \
href="mailto:natosha@unity3d.com" target="_blank">natosha@unity3d.com</a>></span> \
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">2012/11/17 Matt Harbison <span dir="ltr"><<a \
href="mailto:matt_harbison@yahoo.com" \
target="_blank">matt_harbison@yahoo.com</a>></span><br>
<div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>Arne \
Babenhauserheide wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Am Donnerstag, 15. November 2012, \
22:12:26 schrieb Matt Harbison:<br> <blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> dukeofgaming wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I think adding a "largefiles" option to these two \
commands could be more<br> intuitive:<br>
<br>
hg add --largefiles<br>
hg addremove --largefiles<br>
<br>
Would this be possible?<br>
</blockquote>
I agree that having to explicitly add one of the files first is a bit<br>
surprising and inconvenient, and even init --large doesn't completely<br>
fix this because what if you want to opt in later? But I don't think<br>
this proposal will gain acceptance for a couple of reasons:<br>
</blockquote>
<br>
Why not just as a config option to largefiles?<br>
<br>
[largefiles]<br>
assume_tracked_largefile = True<br>
<br>
All the calls would then change to<br>
<br>
hg --config largefiles.assume_tracked_<u></u>largefile=True \
add/addremove/commit/…<br> <br>
It would then also be possible to opt in for all repos by setting the config<br>
in the ~/.hgrc.<br>
</blockquote>
<br></div>
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.<br>
<br>
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).</blockquote>
<div><br></div></div></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Na'Tosha </div></div><span \
class="HOEnZb"><font color="#888888">-- <br><div><div><span \
style="color:rgb(153,153,153)"><b>Na'Tosha Bard</b></span></div><div><font \
color="#999999">Software Developer | Unity Technologies - Copenhagen<br>
</font></div><div><font color="#999999"><br></font></div><div><font \
color="#999999"><b>E-Mail:</b> <a href="mailto:natosha@unity3d.com" \
target="_blank">natosha@unity3d.com</a></font></div><div><font \
color="#999999"><b>Skype:</b> natosha.bard</font></div>
</div><br>
</font></span><br>_______________________________________________<br>
Mercurial-devel mailing list<br>
<a href="mailto:Mercurial-devel@selenic.com">Mercurial-devel@selenic.com</a><br>
<a href="http://selenic.com/mailman/listinfo/mercurial-devel" \
target="_blank">http://selenic.com/mailman/listinfo/mercurial-devel</a><br> \
<br></blockquote></div><br></div>
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic