[Gnu-arch-users] Re: Re: Having two precommit hooks

[Anand Kumria]

On Sun, 10 Oct 2004 15:46:00 -0700, Thomas Lord wrote:


>     > From: Anand Kumria <address@hidden>
>     > >     > Like others, I thought "precommit" suggests the tree may
>     > >     > be modified. If we are going to have two precommit hooks,
>     > >     > then I suggest to use intuitive names this time, i.e.
>     > >     > prepare-commit and confirm-commit hooks.
> 
>     > > A "hook" is the opportunity to invoke a user-specified
>     > > computation at a point during another computation when,
>     > > otherwise, such invocation would be impossible.
> 
>     > > A pre-commit hook that allowed tree modifications would have to
>     > > be run, in effect, before the commit did anything else at all.
> 
>     > No, I would expect such a hook to run after a 'tla tree-lint'; no
>     > point doing any reformatting work if tla will bitch and moan later
>     > on.
> 
> I can't imagine not wanting to re-run tree-lint after a tree-modifying
> hook ran.  What's wrong with (in essense):
> 
> 
>       #!/bin/sh
> 
>         tla tree-lint
>         run-hook
>         tla commit
> 
> ?

nothing, but what is wrong with:

$ cat /usr/local/bin/tla-commit
#!/bin/sh
tla commands to get ARCH_ARCHIVE, ARCH_REVISION, ARCH_TREEROOT run-hook
tla commit

I not understanding why a post-commit hook is valuable but this one isn't
since you can also post-commit replace with a shell script.

>From a very brief glance at the commit logic, I see:

tla commit flow
 - <<< pre-commit-changeset hook here >>> 
 - prepare_commit_changeset
 - <<< post-commit-changeset hook here >>> 
 - pre-commit <= existing hook
 - generate txn id
 - lock revision
 - put log
 - put changeset
 - copy changeset to archive
 {{ mid commit }}
 - finish_revision?
 - other stuff
 - post-commit <= existing hook

What I, and others, are suggesting is that 
'<<< pre|post-commit-changeset hook here >>>' 
are needed precisely so that code reformators, things which extract .sxw
into directories/files, etc. can be run.

The specific, somewhat contrived, use case I'm thinking off is a
pre-precommit hook (pre-changeset-generation?) which searchs for .sxw's,
creates a directory based upon the filename, extracts the file into that
directory and, if necessary, tla add's the new files.

For me that would mean that sxw, and other OpenOffice files, could be
revision controlled.  Apply similiar, if somewhat contorted, logic to
storing .tar.gz's 'unpacked'.

Basically I think you need four hooks for commit:
        - pre-commit-changeset (tree modifications allowed, reformat code) 
        - post-commit-changeset (no modifications allowed, ?) 
        - pre-commit (no modifications allowed, run test suites) 
        - post-commit (send notifications)

In some sense you could combine post-commit-changeset and pre-commit
together; my thought is that post-commit-changeset could be used to clean
up after pre-commit-changeset.  In most cases it would not be necessary
but you never know.

Regards,
Anand