pre-commit hooks and $Id$ banners?
mbp at sourcefrog.net
Mon Apr 24 05:44:32 BST 2006
On 24/04/2006, at 1:24 AM, John Arbash Meinel wrote:
> First, we would need to change how we detect what files have been
> modified. Since now we have a sha1 mismatch between what is on
> disk, and
> what is committed to the inventory. I can think of 2 ways to do this:
> 1) Change line 175 in hashcache.py, which reads in the files, and
> computes their sha1 sum. This needs to change so that instead of just
> plain reading a file, we actually filter the file, to unexpand the
> Doing it this way means that the working inventory looks like the
> final inventory, but we have to unescape every file we come across.
> the value in .bzr/stat-cache doesn't match a simple 'sha1sum file/
> 2) Add a field to the working inventory. So that we have sha1, and we
> have expanded_sha1. Then when doing something like 'bzr status' we
> compare against the expanded sha1. Now the hashcache doesn't have to
> change. If we want to allow per-file decisions about what is expanded
> and what isn't (like svn), we probably need a new inventory field
I too would prefer #2, keeping hashcache as just a simple object that
accelerates operations on a directory, without making it know about
any higher level operations.
> Second, we would obviously need to change how we read the actual text
> contents when we are committing a new snapshot. This seems as
> simple as
> modifying 'work_tree.get_file_by_name()' so that it returns a
> instead of a regular python file. And that ProxyFile would unescape
I think we'd want Tree methods which let you get either the actual on-
disk text, or the expanded or unexpanded text, as desired; these
would just pass through for non-expanded files.
This may be a good place to also add conversion of newlines or
character sets -- the "expanded" version will convert to the working
copy's preferred conventions.
It's not totally clear to me that we'd want to commit the unexpanded
text though. Doing so would make storage more compact, and only hide
information that would never normally be accessible. On the other
hand perhaps it is better to commit precisely what the user had on
disk - perhaps you would want to extract it later without doing the
expansion. That's probably not by itself a good enough reason to
spend the time & space.
More information about the bazaar