You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Chia-liang Kao <cl...@clkao.org> on 2008/07/15 17:38:31 UTC
unlock hook completeness?
Hi,
I just noticed that the unlock hook is not taking everything the api
does, notably lacking the lock token and the break-lock flag. Is
there any reason for that? I'd be happy to provide a patch passing
them along to the hook.
I am also wondering if we have any policies on hook interface
versioning? luckily this change should be backward-compatible as we
are just adding more arguments in this case.
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: unlock hook completeness?
Posted by David Glasser <gl...@davidglasser.net>.
On Tue, Jul 15, 2008 at 10:39 PM, Norbert Unterberg
<nu...@gmail.com> wrote:
> 2008/7/15 Karl Fogel <kf...@red-bean.com>:
>
>> The COMMENT can potentially be a multiline value. That's okay, the hook
>> is fine receiving a multiline value in one of its args, right?
>
> Well, not on windows, and for values with blank characters you need to
> ensure proper quoting.
Well, there's nothing to "ensure" coming from svn since it's not
running a shell, and it's easy enough to use "$@" to get the arguments
to whatever other program you run in bash on Unix.
And on Windows... well. There are already so many other hook
arguments that can contain whitespace; it really strikes me as a lost
cause.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: unlock hook completeness?
Posted by Norbert Unterberg <nu...@gmail.com>.
2008/7/15 Karl Fogel <kf...@red-bean.com>:
> The COMMENT can potentially be a multiline value. That's okay, the hook
> is fine receiving a multiline value in one of its args, right?
Well, not on windows, and for values with blank characters you need to
ensure proper quoting.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: unlock hook completeness?
Posted by Karl Fogel <kf...@red-bean.com>.
Chia-liang Kao <cl...@clkao.org> writes:
> Here's my proposed change (as in the hook templates). I was a bit
> unsure about having comment passed in as argument or stdin though. If
> this looks reasonable then I will put a patch together.
Looks good to me. For STEAL-LOCK and BREAK-UNLOCK, you'll need to
specify what exactly the argument looks like -- that is, how you're
going to represent a boolean value in someone's char **argv :-).
The COMMENT can potentially be a multiline value. That's okay, the hook
is fine receiving a multiline value in one of its args, right?
-Karl
> --- subversion/libsvn_repos/repos.c (revision 32132)
> +++ subversion/libsvn_repos/repos.c (local)
> @@ -537,6 +537,8 @@ PREWRITTEN_HOOKS_TEXT
> "# [1] REPOS-PATH (the path to this repository)" NL
> "# [2] PATH (the path in the repository about to be locked)" NL
> "# [3] USER (the user creating the lock)" NL
> +"# [4] COMMENT (the comment of the lock)" NL
> +"# [5] STEAL-LOCK (if the user is trying to steal the lock)" NL
> "#" NL
>
> "# The default working directory for the invocation is undefined, so" NL
> "# the program should set one explicitly if it cares." NL
> @@ -618,6 +620,8 @@ PREWRITTEN_HOOKS_TEXT
> "# [1] REPOS-PATH (the path to this repository)" NL
> "# [2] PATH (the path in the repository about to be unlocked)" NL
> "# [3] USER (the user destroying the lock)" NL
> +"# [4] TOKEN (the lock token to be destoryed)" NL
> +"# [5] BREAK-UNLOCK (if the user is breaking the lock)" NL
> "#" NL
> "# The default working directory for the invocation is undefined, so" NL
> "# the program should set one explicitly if it cares." NL
>
> Cheers,
> CLK
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: unlock hook completeness?
Posted by Chia-liang Kao <cl...@clkao.org>.
Karl Fogel <kfogel <at> red-bean.com> writes:
> > I just noticed that the unlock hook is not taking everything the api
> > does, notably lacking the lock token and the break-lock flag. Is
> > there any reason for that? I'd be happy to provide a patch passing
> > them along to the hook.
>
> Hunh. I don't know. Oversight? If you have a use case, a patch makes
> sense...
yes i do have a use case. ;) to get locks synchronized less painfully.
> > I am also wondering if we have any policies on hook interface
> > versioning? luckily this change should be backward-compatible as we
> > are just adding more arguments in this case.
>
> I think that's our policy -- you can add args, just don't lose or change
> existing args.
Here's my proposed change (as in the hook templates). I was a bit unsure about
having comment passed in as argument or stdin though. If this looks reasonable
then I will put a patch together.
--- subversion/libsvn_repos/repos.c (revision 32132)
+++ subversion/libsvn_repos/repos.c (local)
@@ -537,6 +537,8 @@ PREWRITTEN_HOOKS_TEXT
"# [1] REPOS-PATH (the path to this repository)" NL
"# [2] PATH (the path in the repository about to be locked)" NL
"# [3] USER (the user creating the lock)" NL
+"# [4] COMMENT (the comment of the lock)" NL
+"# [5] STEAL-LOCK (if the user is trying to steal the lock)" NL
"#" NL
"# The default working directory for the invocation is undefined, so" NL
"# the program should set one explicitly if it cares." NL
@@ -618,6 +620,8 @@ PREWRITTEN_HOOKS_TEXT
"# [1] REPOS-PATH (the path to this repository)" NL
"# [2] PATH (the path in the repository about to be unlocked)" NL
"# [3] USER (the user destroying the lock)" NL
+"# [4] TOKEN (the lock token to be destoryed)" NL
+"# [5] BREAK-UNLOCK (if the user is breaking the lock)" NL
"#" NL
"# The default working directory for the invocation is undefined, so" NL
"# the program should set one explicitly if it cares." NL
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: unlock hook completeness?
Posted by Karl Fogel <kf...@red-bean.com>.
"Chia-liang Kao" <cl...@clkao.org> writes:
> I just noticed that the unlock hook is not taking everything the api
> does, notably lacking the lock token and the break-lock flag. Is
> there any reason for that? I'd be happy to provide a patch passing
> them along to the hook.
Hunh. I don't know. Oversight? If you have a use case, a patch makes
sense...
> I am also wondering if we have any policies on hook interface
> versioning? luckily this change should be backward-compatible as we
> are just adding more arguments in this case.
I think that's our policy -- you can add args, just don't lose or change
existing args.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org