Re: unversioned properties: size limitations?

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.

> 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?

> 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.

> 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.

> 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.
$ svn co file://$(pwd)/repo wc2
A wc2/foo
Checked out revision 1.
$ echo b > wc1/foo
$ svn ci -mm wc1
Sending wc1/foo
Transmitting file data .
Committed revision 2.
$ svn propset x y wc2/foo
property 'x' set on 'wc2/foo'
$ svn ci -mm wc2
Sending wc2/foo
svn: E155011: Commit failed (details follow):
svn: E155011: File '/Users/brane/src/test/wc2/foo' is out of date
svn: E160028: File '/foo' is out of date

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com