On Mon, Mar 10, 2014 at 6:28 PM, demerphq wrote:
> I had the impression, and I would not be surprised if they had the
> impression that the git development community is relatively
> unconcerned about performance issues on larger repositories.
>
> There have been other reports, which are difficult
On Mon, Mar 10, 2014 at 10:56:51AM -0700, David Lang wrote:
> On Mon, 10 Mar 2014, Ondřej Bílka wrote:
>
> >On Mon, Mar 10, 2014 at 03:13:45AM -0700, David Lang wrote:
> >>On Mon, 10 Mar 2014, Dennis Luehring wrote:
> >>
> >>>according to these blog posts
> >>>
> >>>http://www.infoq.com/news/2014/
On Mon, Mar 10, 2014 at 1:56 PM, David Lang wrote:
> there's also the issue of managed vs generated files, if you update the
> mtime all the way up the tree because a source file was compiled and a
> binary created, that will quickly defeat the value of the recursive mime.
I think this points us
On Mon, Mar 10, 2014 at 03:13:45AM -0700, David Lang wrote:
> On Mon, 10 Mar 2014, Dennis Luehring wrote:
>
> >according to these blog posts
> >
> >http://www.infoq.com/news/2014/01/facebook-scaling-hg
> >https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
> >
> >mercuri
On Mon, 10 Mar 2014, Ondřej Bílka wrote:
On Mon, Mar 10, 2014 at 03:13:45AM -0700, David Lang wrote:
On Mon, 10 Mar 2014, Dennis Luehring wrote:
according to these blog posts
http://www.infoq.com/news/2014/01/facebook-scaling-hg
https://code.facebook.com/posts/218678814984400/scaling-mercuri
On 03/10/2014 01:10 PM, Johan Herland wrote:
> It should be possible to teach Git to do similar things, and IINM
> there are (and have previously been) several attempts to do similar
> things in Git, e.g.:
>
> - http://thread.gmane.org/gmane.comp.version-control.git/240339
>
> - http://thread.g
Am 10.03.2014 12:42, schrieb Dennis Luehring:
> Am 10.03.2014 12:28, schrieb demerphq:
>> I had the impression, and I would not be surprised if they had the
>> impression that the git development community is relatively
>> unconcerned about performance issues on larger repositories.
>
> so the que
On Mon, Mar 10, 2014 at 12:42 PM, Dennis Luehring wrote:
> Am 10.03.2014 12:28, schrieb demerphq:
>
>> I had the impression, and I would not be surprised if they had the
>> impression that the git development community is relatively
>> unconcerned about performance issues on larger repositories.
>
Am 10.03.2014 12:28, schrieb demerphq:
I had the impression, and I would not be surprised if they had the
impression that the git development community is relatively
unconcerned about performance issues on larger repositories.
so the question is if the git community is interested in beeing
com
On 10 March 2014 11:07, Dennis Luehring wrote:
> according to these blog posts
>
> http://www.infoq.com/news/2014/01/facebook-scaling-hg
> https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
>
> mercurial "can" be faster then git
>
> but i don't found any reply from the
On Mon, 10 Mar 2014, Dennis Luehring wrote:
according to these blog posts
http://www.infoq.com/news/2014/01/facebook-scaling-hg
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
mercurial "can" be faster then git
but i don't found any reply from the git community
according to these blog posts
http://www.infoq.com/news/2014/01/facebook-scaling-hg
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
mercurial "can" be faster then git
but i don't found any reply from the git community if it is a real problem
or if there a ongoing
12 matches
Mail list logo
