Client-side commit hooks (Revisited)

[Peter Davis <pe...@pdavis.cx>]

This issue has come up before, but in a different context.  Skip to the end to 
read my real issue if you don't want to read the long and boring context.

For those who don't know, I'm starting a project called Subissue 
(subissue.tigris.org) that aims to implement issue tracking directly in a 
subversion repository.  All was well until I talked to Sergey Lipnevich.

He suggested analyzing log messages from all commits and updating issues based 
on commands embedded in the log messages.  For example, you could have a 
message like:

  Subissue: /issues/assigned/your-username/issue-314159
  Subissue-Status: Resolved
  Subissue-Resolution: Fixed
  Fixed the fubar in baz.c; the whatzit was messing up the hoozer.

Subissue would provide some kind of commit hook to look at the message and 
update the issues accordingly.  This works fine in Sergey's original 
idea/project, which is a commit hook that updates a Bugzilla database.

My project needs to update files in the same repository as what is being 
committed (since the issues are stored in the repository).  This means I 
can't just write a pre-commit hook, since Subversion's hooks cannot modify 
the transaction (which is a Good Thing).

The alternative is to design this part of Subissue as a wrapper around the svn 
binary, but the wrapper would have to basically understand the semantics of 
each command, and other clients (RapidSVN) couldn't benefit from the wrapper.  
Hairy.


** Begin reading here **

Another thread back on May 25 talked about adding client-side commit hooks, 
and it was brushed off as being a security hazard (since the hooks were 
configured and stored in the repository).  Well, what if the hooks were 
simply specified by command line options, or in the user's ~/.subversion/ 
configuration?

$ svn ci -m "Log" --pre-commit-hook=/path/to/subissue-pch

(The --pre-commit-hook option could be remembered with 'alias svn=svn 
--pre-commit-hook...' or in ~/.subversion/.)

Now, hooks as we have known them have so far have mostly been geared towards 
performing passive actions w.r.t. the repository.  To properly do what I want 
to do, the transaction needs to be ammended with additional files and 
modifications.  So, does anyone have any ideas on how this could be done?

Is this type of hook the right answer?  Would it be better/easier to add hooks 
directly to the client library?

-- 
Peter Davis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Client-side commit hooks (Revisited)

[Peter Davis <pe...@pdavis.cx>]

On Friday 02 August 2002 14:14, you wrote:
> There are various ways to work around that, it sounds like you're
> already thinking about them...

I'm thinking the script will have a config with a simple map from the 
usernames used to commit to the user/pass pairs for the remote repo.  Yes 
they would have to be plaintext, but then it's all stored plaintext in the 
WCs anyway :)

begin-user-map http://server/remote-repos
  map localuser = remoteuser, pass
  map localuser2 = pass  # localuser2 is the same for both repos
end-user-map

... something like that.

But this is getting off topic.  Thanks for you're help, I'll come back if I 
have more questions.  Probably I'll need help using the Python bindings at 
some point.

-- 
Peter Davis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Client-side commit hooks (Revisited)

[Karl Fogel <kf...@newton.ch.collab.net>]

Peter Davis <pe...@pdavis.cx> writes:
> Where can I get the committer's password?  Or would that have to be
> stored in some config?

Well, you can't get it from the repository nor the txn, that's for
sure.  We're not *that* insecure :-).

There are various ways to work around that, it sounds like you're
already thinking about them...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Client-side commit hooks (Revisited)

[Peter Davis <pe...@pdavis.cx>]

On Friday 02 August 2002 13:53, you wrote:
> The two repositories could share the same user/password db, though.
>
> Oh, and you can get the committers' name from the txn property (it
> becomes a revision property after commit, that's how the commit emails
> work).

Where can I get the committer's password?  Or would that have to be stored in 
some config?

Thanks again,

-- 
Peter Davis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Client-side commit hooks (Revisited)

[Karl Fogel <kf...@newton.ch.collab.net>]

Peter Davis <pe...@pdavis.cx> writes:
> The question then is, how does a hook figure out the user/pass in order to 
> connect to a separate repository?  Maybe some magic will be required in the 
> hook's configuration (ie., don't support arbitrary URLs, only ones that have 
> been pre-configured and their passwords stored in the config).

The two repositories could share the same user/password db, though.

Oh, and you can get the committers' name from the txn property (it
becomes a revision property after commit, that's how the commit emails
work).

Not that you need two separate repositories, of course; just separate
txn commits, which might or might not be in different repositories.

> Thanks for your help.  Things are a lot clearer in my head now, even
> though it won't be quite as slick as I had hoped.

You're welcome -- good luck!

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Client-side commit hooks (Revisited)

[Peter Davis <pe...@pdavis.cx>]

On Friday 02 August 2002 13:10, Karl Fogel wrote:
> No.  But you could refer to the code-change revision in the log
> message of your bug-tracker-change revision.

Okay, I guess I'll just have to create separate revisions.

> (Not all projects will want to store their bug db in the same
> repository as their code, anyway, I would guess).

The question then is, how does a hook figure out the user/pass in order to 
connect to a separate repository?  Maybe some magic will be required in the 
hook's configuration (ie., don't support arbitrary URLs, only ones that have 
been pre-configured and their passwords stored in the config).

Thanks for your help.  Things are a lot clearer in my head now, even though it 
won't be quite as slick as I had hoped.

-- 
Peter Davis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Client-side commit hooks (Revisited)

[Karl Fogel <kf...@newton.ch.collab.net>]

[CC'd back to dev, hope that's okay Peter]

Peter Davis <pe...@pdavis.cx> writes:
> > But your hook can create and commit its own transaction, which solves
> > your problem, I think.
> 
> Can two transactions be committed as the same revision?

No.  But you could refer to the code-change revision in the log
message of your bug-tracker-change revision.

(Not all projects will want to store their bug db in the same
repository as their code, anyway, I would guess).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Client-side commit hooks (Revisited)

[Karl Fogel <kf...@newton.ch.collab.net>]

Peter Davis <pe...@pdavis.cx> writes:
> My project needs to update files in the same repository as what is being 
> committed (since the issues are stored in the repository).  This means I 
> can't just write a pre-commit hook, since Subversion's hooks cannot modify 
> the transaction (which is a Good Thing).

But your hook can create and commit its own transaction, which solves
your problem, I think.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org