I'm including Mayank's reply which doesn't seem to have made it to the list.
Hi,
The reason is following:
When I run the build, it takes around 30 minutes. In the
build process I first do the checkout of source code, and
then perform the build operations in sequence. My last build
operation is a checkin in which I checkin some of the files
created by the build process.
My understanding is that it's not a good practice to put build products
under source control, although there are some good exceptions to that. If
the files created by the build were not under SVN control, might this make
the situation easier to handle?
To explain it further:
Before starting the build, subversion head number is 800.
Now I run the build and finally checkin few files and head
number becomes 801. We consider 801 as the build release number.
But if somebody else comes in between and checks in his
source code, he will occupy 801 and I will get 802 (802 will
be the release) and thus he will corrupt the whole build
process because 802 does not have the exact release files.
I have not found a way to lock a repository, but perhaps others know more
than I do. I chose Subversion specifically because I didn't want to have to
manage locks. Perhaps others can offer more help now that the whole picture
is here.
You might be able to provide this capability in a pre-commit hook script.
You would need to have some method for the build process to signal the start
of a build. This might be writing a specific file or setting an environment
variable. The pre-commit script could check for the existence of the signal
and prevent checkins until the signal is cleared by the build process.
So I want to solve this problem by locking the repository for
the build time. I can add repository lock/unlock steps in my
build process.
With Regards,
Mayank
To unsubscribe, e-mail: users-unsubscribe (AT) subversion (DOT) tigris.org
For additional commands, e-mail: users-help (AT) subversion (DOT) tigris.org