On Fri, May 16, 2014 at 2:42 AM, David Turner wrote:
>> I assume you won't change your mind about this. Which is fine to me. I
>> will still try out my approach with your libwatchman though. Just
>> curious about its performance and complexity, compared to your
>> approach.
>
> I am open-minded he
On Wed, 2014-05-14 at 17:36 +0700, Duy Nguyen wrote:
> >> With that in
> >> mind, I think you don't need to keep a fs cache on disk at all. All
> >> you need to store (in the index) is the clock value from watchman.
> >> After we parse the index, we perform a "since" query to get path names
> >> (
One more thing I think we can solve with watchman is the racy
timestamp issue (see 29e4d36 and 407c8eb). Basically if a file is
updated within a second (and the system only supports timestamp
granuarity down to a second) then git can't know if a file is changed
by comparing stat data, so it compare
On Wed, May 14, 2014 at 6:44 AM, David Turner wrote:
>> I'm not so happy that git now needs to link to libjansson.so and
>> libwatchman.so. I would load libwatchman.so at runtime only when
>> core.usewatchman is on, but this is more of personal taste.
>
> I assume you mean something with dlopen? I
On Sat, 2014-05-10 at 15:16 +0700, Duy Nguyen wrote:
> On Sat, May 3, 2014 at 6:14 AM, wrote:
> > The most sigificant patch uses Facebook's watchman daemon[1] to monitor
> > the repository work tree for changes. This makes allows git status
> > to avoid traversing the entire work tree to find ch
On Wed, 2014-05-14 at 05:54 +0700, Duy Nguyen wrote:
> On Wed, May 14, 2014 at 5:38 AM, David Turner
> wrote:
> > On Mon, 2014-05-12 at 17:45 +0700, Duy Nguyen wrote:
> >> This is your quote from above, moved down a bit:
> >>
> >> > update_fs_cache should only have to update based on what it has
On Wed, May 14, 2014 at 5:38 AM, David Turner wrote:
> On Mon, 2014-05-12 at 17:45 +0700, Duy Nguyen wrote:
>> This is your quote from above, moved down a bit:
>>
>> > update_fs_cache should only have to update based on what it has learned
>> > from watchman. So if no .gitignore has been changed,
On Mon, 2014-05-12 at 17:45 +0700, Duy Nguyen wrote:
> This is your quote from above, moved down a bit:
>
> > update_fs_cache should only have to update based on what it has learned
> > from watchman. So if no .gitignore has been changed, it should not have
> > to do very much work.
> >
> > I cou
On Mon, May 12, 2014 at 5:56 AM, David Turner wrote:
>> So without watchman I got
>>
>>299.871ms read_index_from:1538 if (verify_hdr(hdr, mmap_size) < 0) go
>>498.205ms cmd_status:1300 refresh_index(&the_index, REFRESH_QUIE
>>796.050ms wt_status_collect:622 wt_status_collect_untracked(
On Sun, 2014-05-11 at 07:21 +0700, Duy Nguyen wrote:
> On Sun, May 11, 2014 at 1:38 AM, David Turner
> wrote:
> >> I got "warning: Watchman watch error: Got bad JSON from watchman
> >> get-sockname: '[' or '{' expected near end of file". Any ideas what I
> >> did wrong? I'm using watchman.git and
On Sun, May 11, 2014 at 1:38 AM, David Turner wrote:
>> I got "warning: Watchman watch error: Got bad JSON from watchman
>> get-sockname: '[' or '{' expected near end of file". Any ideas what I
>> did wrong? I'm using watchman.git and libwatchman.git. check-0.9.11
>> and jansson-2.4 were installed
On Sat, 2014-05-10 at 12:26 +0700, Duy Nguyen wrote:
> On Sat, May 3, 2014 at 6:14 AM, wrote:
> > The most sigificant patch uses Facebook's watchman daemon[1] to monitor
> > the repository work tree for changes. This makes allows git status
> > to avoid traversing the entire work tree to find ch
On Sat, May 3, 2014 at 6:14 AM, wrote:
> The most sigificant patch uses Facebook's watchman daemon[1] to monitor
> the repository work tree for changes. This makes allows git status
> to avoid traversing the entire work tree to find changes.
Some comments on this series. I still haven't been ab
On Sat, May 3, 2014 at 6:14 AM, wrote:
> The most sigificant patch uses Facebook's watchman daemon[1] to monitor
> the repository work tree for changes. This makes allows git status
> to avoid traversing the entire work tree to find changes.
I got "warning: Watchman watch error: Got bad JSON fr
On Fri, 2014-05-09 at 11:27 -0700, David Lang wrote:
> >
> > That's not my understanding from Durham Goode's talk in January. Yes,
> > operations involving history go to the server. But the client also
> > maintains a copy of the working tree, and it is for this that watchman
> > is used. Otherw
On Fri, 9 May 2014, David Turner wrote:
On Fri, 2014-05-09 at 11:08 -0700, David Lang wrote:
On Fri, 9 May 2014, David Turner wrote:
On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:
On Thu, 8 May 2014, Sebastian Schuberth wrote:
On 03.05.2014 05:40, Felipe Contreras wrote:
That's ver
On Fri, 2014-05-09 at 11:08 -0700, David Lang wrote:
> On Fri, 9 May 2014, David Turner wrote:
>
> > On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:
> >> On Thu, 8 May 2014, Sebastian Schuberth wrote:
> >>
> >>> On 03.05.2014 05:40, Felipe Contreras wrote:
> >>>
> >> That's very interesti
On Fri, 9 May 2014, David Turner wrote:
On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:
On Thu, 8 May 2014, Sebastian Schuberth wrote:
On 03.05.2014 05:40, Felipe Contreras wrote:
That's very interesting. Do you get similar improvements when doing
something similar in Merurial (watchma
On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:
> On Thu, 8 May 2014, Sebastian Schuberth wrote:
>
> > On 03.05.2014 05:40, Felipe Contreras wrote:
> >
> That's very interesting. Do you get similar improvements when doing
> something similar in Merurial (watchman vs . no watchman).
On Thu, 8 May 2014, Sebastian Schuberth wrote:
On 03.05.2014 05:40, Felipe Contreras wrote:
That's very interesting. Do you get similar improvements when doing
something similar in Merurial (watchman vs . no watchman).
I have not tried it. My understanding is that this is why Facebook
wrote
On 03.05.2014 05:40, Felipe Contreras wrote:
>>> That's very interesting. Do you get similar improvements when doing
>>> something similar in Merurial (watchman vs . no watchman).
>>
>> I have not tried it. My understanding is that this is why Facebook
>> wrote Watchman and added support for it t
On Sun, 2014-05-04 at 07:15 +0700, Duy Nguyen wrote:
> > I would like to merge the feature into master. It works well for me,
> > and some of my colleagues who have tried it out.
>
> Have you tried to turn watchman on by default, then run it with git
> test suite? That usually helps.
I have. Th
On Tue, May 6, 2014 at 7:26 AM, Duy Nguyen wrote:
> This discard_index() code was added
> recently in e28f764 (unpack-trees: plug a memory leak - 2013-08-13).
> As a workaround, perhaps we only do so when the sequencer is running.
Hmm.. as o->result does not carry cache-tree anyway, the next
assi
On Sat, May 3, 2014 at 7:52 AM, Duy Nguyen wrote:
> wt_status_collect_changes_index() depends on how damaged cache-tree is
> (in this case, totally scraped). watchman does not help this either.
> We need to try to "heal" cache-tree as much as possible to reduce the
> number.
On the topic of cache
David Turner wrote:
> On Fri, 2014-05-02 at 22:40 -0500, Felipe Contreras wrote:
> > David Turner wrote:
> > > On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
> > > > dturner@ wrote:
> > > > > Test repository 1: Linux
> > > > >
> > > > > Linux is about 45k files in 3k directories. The
On Fri, 2014-05-02 at 22:40 -0500, Felipe Contreras wrote:
> David Turner wrote:
> > On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
> > > dturner@ wrote:
> > > > Test repository 1: Linux
> > > >
> > > > Linux is about 45k files in 3k directories. The average length of a
> > > > filena
On Sun, May 4, 2014 at 3:49 AM, David Turner wrote:
> On Sat, 2014-05-03 at 15:49 +0700, Duy Nguyen wrote:
>> On Sat, May 3, 2014 at 11:39 AM, David Turner
>> wrote:
>> >> Index v4 and split index (and the following read-cache daemon,
>> >> hopefully)
>> >
>> > Looking at some of the archives fo
On Sat, 2014-05-03 at 15:49 +0700, Duy Nguyen wrote:
> On Sat, May 3, 2014 at 11:39 AM, David Turner
> wrote:
> >> Index v4 and split index (and the following read-cache daemon,
> >> hopefully)
> >
> > Looking at some of the archives for read-cache daemon, it seems to be
> > somewhat similar to w
On Sat, May 3, 2014 at 11:39 AM, David Turner wrote:
>> Index v4 and split index (and the following read-cache daemon,
>> hopefully)
>
> Looking at some of the archives for read-cache daemon, it seems to be
> somewhat similar to watchman, right? But I only saw inotify code; what
> about Mac OS?
On Sat, 2014-05-03 at 07:52 +0700, Duy Nguyen wrote:
> On Sat, May 3, 2014 at 6:14 AM, wrote:
> > The index format change might be less important with the split index;
> > I haven't investigated that since at the time I wrote these patches,
> > it didn't exist.
>
> This is the worst case scenari
David Turner wrote:
> On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
> > dturner@ wrote:
> > > Test repository 1: Linux
> > >
> > > Linux is about 45k files in 3k directories. The average length of a
> > > filename is about 32 bytes.
> > >
> > > Git status timing:
> > > no watchman:
On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
> dturner@ wrote:
> > Test repository 1: Linux
> >
> > Linux is about 45k files in 3k directories. The average length of a
> > filename is about 32 bytes.
> >
> > Git status timing:
> > no watchman: 125ms
> > watchman: 90ms
>
> That's v
On Sat, May 3, 2014 at 6:14 AM, wrote:
> The index format change might be less important with the split index;
> I haven't investigated that since at the time I wrote these patches,
> it didn't exist.
This is the worst case scenario of "git status" on webkit.git (182k
files, path name 74 byte lo
dturner@ wrote:
> Test repository 1: Linux
>
> Linux is about 45k files in 3k directories. The average length of a
> filename is about 32 bytes.
>
> Git status timing:
> no watchman: 125ms
> watchman: 90ms
That's very interesting. Do you get similar improvements when doing
something similar in
34 matches
Mail list logo
