feature request: "svn checkout" a transaction ID

[James Ralston <qr...@andrew.cmu.edu>]

We use Subversion to maintain a repository that consists of various
configuration files in various directories.

The repository has a post-commit hook script.  When the post-commit
hook script fires, it checks out the latest version of the repository
and scans the structure and the configuration files for syntax errors.
If it finds errors, it sends a mail message to the person who
committed the revision; if no errors are found, it pushes out the
configuration files to other systems as appropriate.

It would be highly desirable to be able to perform the syntax-checking
in the pre-commit hook script, for the following reasons:

    1.  The commits made to the repository are often time-sensitive;
        having to wait until a mail message shows up to tell if
        something went wrong is often highly undesirable.

    2.  Since success is the norm, the people performing the commits
        often don't bother to check their email to see if they
        received a notification of a syntax error.

If the syntax checking occurred in the pre-commit hook script, I could
abort the commit if an error were found, and return a useful message
to the person attempting to make the commit.

The problem, however, is that in order to perform the syntax checking
in the pre-commit hook script, I need to obtain a copy of what the
repository would look like if the commit were to occur successfully.
In other words, I need to be able to run "svn checkout" on the
transaction ID of the commit.

Unfortunately, the "checkout" command doesn't have this ability.  And
although it would be theoretically possible to emulate "svn checkout"
on a transaction ID by using svnlook tree/cat, that would be
incredibly inefficient, and extremely difficult to code correctly.

Therefore, my feature request is this: it would be *incredibly* useful
to have some equivalent to "svn checkout" that could be run on a
transaction ID within a pre-commit hook script, that would
*efficiently* give you a copy of what will become the latest revision
of the repository should the commit transaction succeed.  It doesn't
have to be a working copy in the "svn checkout" sense; it just needs
to have the structure (the directories/files) there.

Thoughts?


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

Re: feature request: "svn checkout" a transaction ID

["Colleen R. Dick" <pl...@peak.org>]

I am going along using subversion just fine for a long time.  My client 
is Ubuntu 8.04  and I am just using the naked command line "svn commit 
bla"   I'm going along just fine,   all of a sudden I get

svn: Commit failed (details follow):
svn: Connection closed unexpectedly
svn: Your commit message was left in a temporary file:
svn:    '/xxxxxxxxxxxx/svn-commit.3.tmp'

I thought the file might be corrupt so I tried making a bogus change to 
a different file I had just successfully committed moments earlier and I 
got the same thing.   Please advise.

>
>


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

Re: feature request: "svn checkout" a transaction ID

[Kevin Grover <ke...@kevingrover.net>]

On Fri, May 16, 2008 at 9:45 AM, James Ralston <
qralston+ml.svn-users@andrew.cmu.edu<qr...@andrew.cmu.edu>>
wrote:

> We use Subversion to maintain a repository that consists of various
> configuration files in various directories.
>
> The repository has a post-commit hook script.  When the post-commit
> hook script fires, it checks out the latest version of the repository
> and scans the structure and the configuration files for syntax errors.
> If it finds errors, it sends a mail message to the person who
> committed the revision; if no errors are found, it pushes out the
> configuration files to other systems as appropriate.
>
> It would be highly desirable to be able to perform the syntax-checking
> in the pre-commit hook script, for the following reasons:
>
>    1.  The commits made to the repository are often time-sensitive;
>        having to wait until a mail message shows up to tell if
>        something went wrong is often highly undesirable.
>
>    2.  Since success is the norm, the people performing the commits
>        often don't bother to check their email to see if they
>        received a notification of a syntax error.
>
> If the syntax checking occurred in the pre-commit hook script, I could
> abort the commit if an error were found, and return a useful message
> to the person attempting to make the commit.
>
> The problem, however, is that in order to perform the syntax checking
> in the pre-commit hook script, I need to obtain a copy of what the
> repository would look like if the commit were to occur successfully.
> In other words, I need to be able to run "svn checkout" on the
> transaction ID of the commit.
>
> Unfortunately, the "checkout" command doesn't have this ability.  And
> although it would be theoretically possible to emulate "svn checkout"
> on a transaction ID by using svnlook tree/cat, that would be
> incredibly inefficient, and extremely difficult to code correctly.
>
> Therefore, my feature request is this: it would be *incredibly* useful
> to have some equivalent to "svn checkout" that could be run on a
> transaction ID within a pre-commit hook script, that would
> *efficiently* give you a copy of what will become the latest revision
> of the repository should the commit transaction succeed.  It doesn't
> have to be a working copy in the "svn checkout" sense; it just needs
> to have the structure (the directories/files) there.
>
> Thoughts?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

I'm just thinking, but the pre-commit hooks have access (to at least) the
new version of the changed files.  Why couldn't you svn co (or svn export)
the base revision, write the new file contents, then run your checks?

If you keep the temp area a working copy, you can 'svn update' to the target
path/revision and use svn revert to revert it to it's original state when
done.