Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Usually you only want to keep binary files that have been explicitly released, i.e. official releases or binaries that are used by the Testing department. So it really doesn't make sense to commit every newly built binary.</p> <p>So the real solution to your problem is a redesign of your SVN repository. The directories where the files are built shouldn't be under source control AND should be ignored using svn:ignore properties. This prevents newly built binaries from being noticed by SVN. Secondly you might create a separate directory where you store the binaries you do want to keep. This directory, ofcourse, needs to be under version control.</p> <p>Now you can develop, without having troubles with changing binaries. When you finally get to the stage where you do want to keep those binaries, you just copy those binaries to that separate directory created above, thereby overwriting the old ones. SVN will now notice the files have changed and you can commit them.</p> <p>Another approach that I have seen used in the past is to first create a TAG from your source tree. The build server (or yourself) then checks out this TAG and builds the binaries from that checked out TAG. Afterwards the built binaries are committed on top of that TAG. Many people think you should never ever commit on top of a TAG, but it might work for you. The only think you should remember is that when you export/check out that TAG you have to take the HEAD revision and not the TAG's own revision (which would be HEAD-1).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload