On Tuesday, August 12, 2014 08:33:06 AM Branko Čibej wrote: > On 12.08.2014 08:17, Alexey Neyman wrote: > > On Tuesday, August 12, 2014 07:44:03 AM Branko Čibej wrote: > > > I'm still not sure what you're trying to achieve, though. "Communication > > > > > > between pre- and post-commit hooks" doesn't describe the problem, it > > > > > > describes a solution, and there are of course other ways for hooks to > > > > > > communicate that do not involve the repository. > > > > I've mentioned this in the other thread where you also responded. > > There are two problems that are currently (we're using 1.6) solved by > > modifying the transaction in the pre-commit hook: > > > > > > > > 1. We have a <version.h> header that needs to reflect the last > > modification date of *any* file in the project. Currently, pre-commit > > script modifies a property in each commit which touches any file in > > /project/trunk. > > So why do you need the last-changed revision of the project directory > stored in the header file? Are you distributing sources directly from > the repository, or are you using that number to identify builds? In > either case, there are better ways to do that.
Sometimes, yes. Not directly from a repository but engineers sometimes release semi- official builds to customers. I understand that is less than ideal way (not dealing with mixed-revision WCs, etc.). So, I am curious what are those better ways you mention? > > 2. We have a few checks in pre-commit that are performed on text but > > not on binary files, and (unless it the type is set explicitly), the > > text is distinguished from binaries using simple heuristics. To avoid > > running this heuristics over and over, the result is saved into a > > property on that file. > > I'd just like to point out that Subversion already has heuristics to > identify binary files. If you add a binary file to the working copy, it > will automagically get the svn:mime-type set to > application/octet-stream. There are only a few MIME types that > Subversion does not consider binary. Of course, your heuristics might be > different from Subversion's, but have you considered just looking at the > mime-type property? Yes, I've considered it, there are a few drawbacks: - First, the repository was imported from CVS and many binary files were not marked with the svn:mime-type properly set at the conversion time (most likely, because the oridinal CVS file didn't have -kb keyword expansion set - but that's now history). This could be solved by going over all the project files once and setting svn:mime-type explicitly, though. - Second, some of the MIME types are text even though the MIME type does not start with 'text/*'. "image/svg", "application/x-sh" and "application/xml" are a few most obvious examples that come to mind. I don't know how to come up with an exhaustive list of such "text-despite-MIME-type" types. Because of these I decided to use a separate property. > > So, to avoid modifying the transaction by pre-commit (that no longer > > reliably works in 1.7 and 1.8), > > Correction: that never reliably worked, because we never promised it > would work. We haven't noticed any issues with 1.4, 1.5 and 1.6 :) > > I am changing the pre-commit to list the 'tasks' to be performed by > > the post-commit - which will check in a new revision. I don't want to > > involve an out-of-repository storage for that list of tasks unless > > absolutely necessary - hence, revision property looks like the perfect > > place to store the "follow-up tasks" for a particular revision. > > > > > Also I find your approach less than robust: > > > > > > > > > > > > * There's no guarantee that the post-commit hook will ever run, so > > > > > > it's a bad idea to rely on it for anything that's critical to your > > > > > > workflow. > > > > Can you please elaborate on this? I thought that if a transaction was > > promoted to a revision, the post-commit hook is always run. I > > understand that post-commit may fail and this failure will not roll > > back a revision. But when is it not run at all? > > It's entirely possible that the commit succeeds, but for any number of > reasons -- power failure, full disk, simple misconfiguration -- the > post-commit hook doesn't run. Subversion does not make any guarantees > there other than making a best effort to run it. Well, these are force majeure sort of issues. For the uses I described, not running the post- commit is definitely not a deal-breaker for use case [2] (it will only result in non-caching the result of heuristics). For [1], I think I'll just add a monitoring cron job that will re-run post-commit hook if it detects a revision with the "actions" property from the pre-commit hook still set (which would mean that post-commit didn't run to completion). By the way, does SVN guarantee that such kinds of issues (full disk, power failure) do not result in repository ending up in an inconsistent state? If SVN does not offer such guarantees, it is pointless to require them from a post-commit script anyway. > > PS. I know that there's an interface, svn_fs_commit_txn, than can > > bypass both pre- and post-commit hook. But it is not used in regular > > commits from the command line, is it? > > Nope. > > > > * There's no guarantee that other commits won't happen before your > > > post-commit hook is run; so whatever you do with the repository in > > > post-commit may have to deal with conflicts, which is not fun to > > > automate. > > > > I understand that, but I don't expect conflicts: the actions by the > > post-commit will only touch certain properties that are not set > > manually. After all, I can reject an attempt to set those properties > > in the pre-commit. > > You mean like this? > > $ svnadmin create repo > $ svn co file://$(pwd)/repo wc1 > Checked out revision 0. > $ echo a > wc1/foo > $ svn add wc1/foo > A wc1/foo > $ svn ci -mm wc1 > Adding wc1/foo > Transmitting file data . > Committed revision 1.
