Re: [PATCH 0/6] inotify support

2014-02-19 Thread Duy Nguyen
On Thu, Feb 20, 2014 at 3:35 AM, Shawn Pearce  wrote:
> Why a new daemon? Why don't we reuse the stable
> https://github.com/facebook/watchman project Facebook built to make
> Hg's status system fast?

I did look briefly through its readme before but there were a few
off-factors like CLA, JSON.. that made me go away. I agree that
reusing the same daemon would save us maintenance code and buy the
stability (and maybe sharing some inotify handles for users that use
both git and hg). I'll need to have a closer look at it and compare
with what I've got, now that I have a better picture of how things
should work.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] inotify support

2014-02-19 Thread Shawn Pearce
On Sun, Jan 12, 2014 at 3:03 AM, Nguyễn Thái Ngọc Duy  wrote:
> It's been 37 weeks since Robert Zeh's attempt to bring inotify support
> to Git [1] and unless I missed some mails, no updates since. So here's
> another attempt with my preferred approach (can't help it, playing
> with your own ideas is more fun than improving other people's code)
>
> To compare to Robert's approach:
>
> - This one uses UNIX datagram socket. If I read its man page right,
>   unix socket respects the containing directory's permission. Which
>   means on normal repos, only the user process can access. On shared
>   repos, multiple users can access it. This should work on Mac.
>   Windows will need a different transport.
>
> - The daemon is dumb. It passes the paths around and that's it.
>   lstat() is done by git. If I design it right, there's should not be
>   any race conditions that make git miss file updates.
>
> - CE_VALID is reused to avoid mass changes (granted there's other
>   neat ways as well). I quite like the idea of machine-controlled
>   CE_VALID.
>
> inotify support has the potential of reducing syscalls in
> read_directory() as well. I wrote about using lstat() to reduce
> readdir() a while back, if that's implemented then inotify will fit in
> nicely.
>
> This is just a proof of concept. I'm sure I haven't handled all error
> cases very well. The first five patches show the protocol and git
> side's changes. The last one fills inotify in.
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=78

Why a new daemon? Why don't we reuse the stable
https://github.com/facebook/watchman project Facebook built to make
Hg's status system fast?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/6] inotify support

2014-01-12 Thread Nguyễn Thái Ngọc Duy
It's been 37 weeks since Robert Zeh's attempt to bring inotify support
to Git [1] and unless I missed some mails, no updates since. So here's
another attempt with my preferred approach (can't help it, playing
with your own ideas is more fun than improving other people's code)

To compare to Robert's approach:

- This one uses UNIX datagram socket. If I read its man page right,
  unix socket respects the containing directory's permission. Which
  means on normal repos, only the user process can access. On shared
  repos, multiple users can access it. This should work on Mac.
  Windows will need a different transport.

- The daemon is dumb. It passes the paths around and that's it.
  lstat() is done by git. If I design it right, there's should not be
  any race conditions that make git miss file updates.

- CE_VALID is reused to avoid mass changes (granted there's other
  neat ways as well). I quite like the idea of machine-controlled
  CE_VALID.

inotify support has the potential of reducing syscalls in
read_directory() as well. I wrote about using lstat() to reduce
readdir() a while back, if that's implemented then inotify will fit in
nicely.

This is just a proof of concept. I'm sure I haven't handled all error
cases very well. The first five patches show the protocol and git
side's changes. The last one fills inotify in.

[1] http://thread.gmane.org/gmane.comp.version-control.git/215820/focus=78

Nguyễn Thái Ngọc Duy (6):
  read-cache: save trailing sha-1
  read-cache: new extension to mark what file is watched
  read-cache: connect to file watcher
  read-cache: get "updated" path list from file watcher
  read-cache: ask file watcher to watch files
  file-watcher: support inotify

 .gitignore   |   1 +
 Makefile |   1 +
 cache.h  |   4 +
 config.mak.uname |   1 +
 file-watcher.c (new) | 329 +++
 git-compat-util.h|   5 +
 pkt-line.c   |   2 +-
 pkt-line.h   |   2 +
 read-cache.c | 280 ++-
 wrapper.c|  27 +
 10 files changed, 645 insertions(+), 7 deletions(-)
 create mode 100644 file-watcher.c

-- 
1.8.5.2.240.g8478abd

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html