si wrote:
>>>>> What I'd like to be able to do is use the script to copy the
>>>>> state of the transaction out to a directory and run the build
>>>>> script. If it builds then I want the transaction committed.
>>>>> If not I want it to abort and the user to be notified.
>>>>
>>>> If you really want to, and your developers will tolerate the
>>>> delay, then sure, it's possible. You can use "svnlook changed"
>>>> in the pre-commit hook to figure out what files the transaction
>>>> wants to change. You could have an up-to-date working copy
>>>> waiting, and you could then "svnlook cat" the changed files into
>>>> the working copy and do the build. You'll have to devise a
>>>> mechanism to clean up after the build when you're done, and to
>>>> remove the effects of the "cat" commands, for example by doing
>>>> "svn revert" on the working copy, then using the output of "svn
>>>> statuts" to see what unversioned files remain, and deleting them.
>>>
>>> Oh, I should add that there's also "svnlook diff"; it would
>>> probably be much easier to get the diff and apply it to the
>>> working copy than to script something that works with "svnlook
>>> changed" and "svnlook cat". I must admit though that I'm not
>>> entirely sure how to use "svnlook diff" to do this, since usually
>>> you get a diff between two paths, or between two revisions of one
>>> path, but in this case you'd need the difference between HEAD and
>>> the transaction. But I think "svnlook diff" is still where I'd
>>> look first.
>>
>> What would be ideal is if you could checkout a transaction, but
>> that doesn't seem to be possible.
>
> What about an svn checkout of HEAD into a new working copy
> (or an svn update of existing working copy to keep things fast),
> pipe svnlook diff for the transaction into a patch program against
> working copy, trigger your build, report success/failure of build
> through pre-commit hook.
That's what I meant.
> Doing it in post-commit and then reverting on failure seems fraught
> with danger...what happens if 2 developers commit 5 seconds apart,
> with the first failing but the second succeeding?
AFAIK,it shouldn't be a problem because the 2nd developer's commit
will not be processed until the 1st developer's commit is accepted or
rejected, by which time one would have cleaned up the working copy
back to its pristine state. One should test that to assure oneself
that that's really what happens.
Mark Shead wrote:
> Thanks for your help. Here is what I've come up with so far:
>
> #!/bin/sh
> REPOS="$1"
> TXN="$2"
> SVNLOOK=/usr/bin/svnlook
> PATCH=/usr/bin/patch
> svn export file:///$REPOS /tmp/$TXN
> cd /tmp/$TXN
> $SVNLOOK diff --transaction $TXN $REPOS | $PATCH
>
> This seems to work if files are modified, but it doesn't seem to
> work if
> a file has been deleted or moved. If a file is moved or deleted it
> will
> just remove the contents of the old file, but not the file itself. If
> the file is moved it removes the contents of the old file, but doesn't
> create a new file. It seems to work ok when a file is added for the
> first time.
>
> Any suggestions? Is there a better way to go about getting a copy of
> what the repository will look like once the transaction has committed?
I think that's probably how you're going to have to go about doing
it. You're right that the diff will only correctly handle changes in
existing files; I forgot. You'll have to find another method to
handle file deletions, property changes, probably directory additions
or deletions, and so forth. I'm not certain whether any output of
svnlook will give you all the info you need to do that, but I'd try
out all the available commands (changed, dirs-changed, log, etc.) and
see if anything helpful gets produced.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 11 18:31:52 2005