I have an SVN repository where huge files are checked in.
Is there a way to; firstly, track the size of the current commit and secondly track the overall commit size for that user. Maybe the second can run offline and mark the user as barred from further commits.
As far as preventing checking, you could have the tool nightly calculate a black list, and then set up a pre-checkin script to see if the user is in the black list and then disallow the checkin.
But a better solution might just be to post the statvn results of who is using up the most subversion space; that might be enough to cause the offending parties to be more careful.
Also, what is taking up all of the space? If your developers are loading JARs into subversion so that they will be available for their builds, then you might want to look into Maven and how it handles dependencies. JARs should never be in Subversion.
If your developers are loading JARs into subversion so that they will be available for their builds
This is the problem and I don't think we can prevent this. Pairs of developers work on a utility jar before they decide on the final utility jar and let Maven do the rest. My objective is to find a way to scratch out these temp jars within SVN.
Thanks for the help, I might just post the statvn results since most of the time, the users don't realize that they have so much temp information in there.
I recommend writing a pre-commit script that generates an error if an attempt is made to commit a JAR file. If you are using Maven for builds, there is no excuse whatsoever to place a JAR file in Subversion. The developer's should either just use the JARs available from Maven Central (or some other repository) or place them in their local repository. And if you have Nexus, you can create a hosted repository in Nexus specifically to hold such temporary JARs - it is trivial to remove JARs from Nexus.
In our shop, we have a private cloud what has a VM template that I created which contains all of our tools (Subversion, Nexus, Jenkins) so that developers can experiment before placing their source and build into the production build environment. After the experimentation is done, the VM is wiped.
Thanks Peter, this is a lot of useful information.
there is no excuse whatsoever to place a JAR file in Subversion
The developers(one team among many teams) have to share their version of the utility jar which provides interfaces. Once we have the utility jars working we have the final utility jar as a part of the bigger build process. Now that we discuss I think Nexus would have solved this problem in a cleaner way.
I don't think I need to track the size of the repository if I work on Nexus or the private cloud thingy. I like the private cloud option but the change is too big.
But I am kinda interested to know how you have designed this and the cloud provider that you have used. Do you have the details blogged somewhere ?
We created our own IaaS cloud using our in-house set of tools. We do market this cloud to various enterprise-level customers who need a cloud tightly integrated with their existing data center, so our cloud is not publicly available. We offer our cloud both as a hosted service (in one of our data centers) or as a private cloud (in the customer's data center).
As far as the work we have been doing with Maven and Nexus, I am actively looking at doing a presentation on that at one or more Java conferences this year (or next). I'm trying for qCon in SF in November amd OSCON Java in Portland in July.