On 09/27/2012 11:22 AM, Rob Stryker wrote: 1. Ensure your change is backward compatible (no removal, no move...). If it's not, explain your need on the mailing-list. 2. Commit your change (Don't add binaries, but add scripts to get binaries instead) 3. Run job to get your change published https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... 4. If you want to push binaries to this folder, ask the mailing-list for the most appropriate process. "Someone else" is only download.jboss.org. It should never be not-synchable. If it becomes not-synchable, then it's a bug, describe the issue in a Jira. You don't do the rsync by yourself. You must use this Jenkins job to sync: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... So there is only a single user (jenkins) doing rsync on a single folder (download.jboss.org/jbosstools) and there should not be conflict. Yes. But ensure your change won't break older stuff! Prefer adding files than modifying them. HTH -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>

if we still have automatic sync from trunk into release project examples we should stop that ASAP. Changes to those files should only be done when actually tested and cleared - not when an svn commit occurs. /max On 27 Sep 2012, at 11:22, Rob Stryker <rstryker(a)redhat.com&gt; wrote: