pre-commit hooks and $Id$ banners?

[Martin Pool]

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  
> keywords.
>
>    Doing it this way means that the working inventory looks like the
> final inventory, but we have to unescape every file we come across.  
> And
> the value in .bzr/stat-cache doesn't match a simple 'sha1sum file/ 
> foo'.
>
> 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  
> anyway.

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  
> ProxyFile,
> instead of a regular python file. And that ProxyFile would unescape  
> the
> contents.

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.

-- 
Martin