[jblack: Re: [tools-discuss] Evaluation notes on bzr-0.7]

[Michael Ellerman]

On 3/6/06, Robey Pointer <robey at lag.net> wrote:
> On 1 Mar 2006, at 12:23, Aaron Bentley wrote:
> > Robey Pointer wrote:
> >>> One model that supports this is BitKeeper,  where
> >>> you have to run 'bk edit' to edit each file.
> >>
> >> Perforce uses the same model.  I've gotten used to it, but it's not
> >> very convenient.
> >
> > I think that we can make it convenient.  For example, we can have an
> > inotify daemon that runs 'bzr edit' on every file that we modify.
> > Fundamentally, it doesn't make sense to me that we have to tell the
> > tool
> > which files changed, because the OS must already know.
>
> It just occurred to me that one way we could make this optional is:
> Once a branch has a list of files "open for editing" (ie you or a
> daemon has run 'bzr edit' on them), then you're in explicit mode.  If
> you never 'bzr edit' a file, everything is implicit as it is currently.
>
> The idea of having a little daemon that uses inotify to mark files
> with 'bzr edit' is a very cool one.  That lets you edit a file and
> have bzr tag along after you.  With perforce, all checked-out files
> are mode u-w.  (On osx, they're also marked immutable!!)  So you have
> to ask *first* (via 'p4 edit'), *then* you can edit.  Irritating.
>
> I think if I could start up a little daemon at login that would
> automatically track 'bzr edit's for me, I'd probably do it.

I think that sounds reasonable, but I think we want to make sure it's
a useful optimisation first.

I did a quick test the other week and given a hot cache I can stat my
entire kernel tree (18,976 files) in somewhere around 0.65 seconds
(including python startup). A 'bzr st' takes 11 seconds, so I think
there's some fat we can work on before we worry too much about the
cost of stat'ing the whole tree.

cheers