Comment 1 for bug 380202

2009/5/25 Ian Clatworthy <email address hidden>:
> It appears that we deserialise and reserialise every dirstate line,
> whether it changed or not, as the "is modified" marker is dirstate-wide.
> Perhaps we should remember what lines changed and only
> deserialise/serialise those? Or something like that.

There are a few things we could do.

If there are no changes, we shouldn't even think about writing the
file. Do we get this right at the moment?

If there's very few changes, even just opening the file for writing
may be more work than is worthwhile. Updating it in place should be
possible, and it might be faster to seek to the write place and just
write that one line or section.

The other thing to consider is that the hash cache function is
generally only useful to tell if the contents of the file are
different to the basis tree. There are other cases like a file that's
changed from the parent but the same as some other tree the user's
diffing against, but I think they're uncommon. I think, further, it's
reasonable to assume that files will rarely be made the same as in the
parent except by bzr operations like commit, merge, and revert. So if
you accept this, we should probably never write the tree from bzr st,
but only when we've just updated the tree eg from building it, revert,
or commit.

There are three possible snags here: first, that reasoning may be
wrong. Second, because of the granularity of file timestamps, we may
not safely be able to record the timestamp when we first build the
tree. Third, I'm not sure that we always do update the hash cache
when we update the tree, and updating it on read operations will give
us some safety net against that. (But it's kind of hiding the real
problem, maybe we should rip off the bandaid.)

Doing this would have the advantage that we'd no longer be doing
physical writes from logical read operations which would be nice.

[Also, this bug may be a dupe.]

--
Martin <http://launchpad.net/~mbp/>