There are moments when I need to be sure that no one is committing to either a specific branch or to my trunk. Release builds and reintegration merges are an example.
SVN "locking" all the files is not realistic (very long since project is huge). I also don't believe that locking prevents someone from committing new files.
What would be a quick way to make sure no one commits anything to the folder until I'm done what I'm doing?
Thanks
The passwd file could be changed temporarily while work is being done. The downside is that this affects the entire repository, not just one folder.
If you're making a release build, the first thing you do is check out a particular revision.
It doesn't really matter if someone commits something else during that time - it won't affect your build.
We'll first, you might try performing those operations on specific revisions rather than the head.
If the revision isn't an option, I'd next suggest that you tag the revision you want to build or whatever and operate on that one. This obviously won't work for merges as it defeats the purpose.
But, to get to the crux of your question, the quickest way I can think of is to prevent incoming information is to halt the server itself. I am not an SVN expert however, I've admin'd a box for several years.
Interesting question. It sounds as though your development work-flow could do with some changes, since you're encountering this issue. In particular, on such a large project, you should consider a work-flow that is more controlled, so development changes aren't coming in at the same time, and on the same branch, as a release build that is in progress. You mentioned reintegration merges for example—surely you can coordinate the project so that reintegration merges aren't happening at the same time as a release build. And developers shouldn't be directly committing to the branch that a release build is being done on.
Possibilities:
trunk).
We faced this problem when compiling our projects for release builds, where a build server property (CruiseControl.NET project label) is used as part of the assembly and installer version.
The solution is easy where you are branching (or tagging) the working copy, e.g. for release builds.
Workflow:
If you want to commit your working copy without branching, then as you say this will fail (or at the least be unreliable) if someone has modified that path of the repository.
A way to solve this would be to use svn authorization control, adding a build server user to svn and have different authz files for the repository.
Workflow:
authz with file granting write access for build server user and read access for all other users.authz with file granting normal access for all users.Note that svn authorization allows path-based control, so you could restrict this just to trunk (or wherever) to reduce impact on users.
Another way using a similar approach (same workflow) would be replacing pre-commit hook and checking the user; rejecting the commit (with appropriate error message) if it wasn't your build server user performing the commit. Again, this could be path based (with a little extra regex work) if needed.
Depending on how much access you have to the server, send an announcement telling no one to commit until some time.
If you can't do that, then checkout/checkin using the file:// or file+ssh:// for release builds and during that time shutdown the SVN server process. (be it apache, or svnserver) then restart it as soon as the build is done.
Also, be sure to rework this so it doesn't require locking the repo as soon as possible. (I realize this is just a temporary thing that you inherited)