On Mon, Mar 12, 2012 at 12:32 PM, David Weintraub <qazwart_at_gmail.com> wrote:
> Here's why I don't think this is a feature for the Subversion project:
>
> * This is a Subversion client function and not a function of
> Subversion itself. Subversion thoughtfully publishes a Subversion API
>
So far, yes. That doesn't mean it wouldn't be welcome.
>
> * Many continuous integration systems (like Jenkins) already have an
> option to remove non-versioned files before doing a build. The OP
> mentioned this as an issue.
>
Yes, and they're a real pain in the keister to manage, and often done
wrong.
> * It is traditional when you design your build system to make sure
> your built objects are stored in a temporary directory, so they don't
> pollute your source area. This way, it's easy to remove all of your
>
Except for, say, all the source code published by CPAN, the Free Software
Foundation, and everything I've seen that compiles code on Sourceforge or
Github. This practice is not uncommon for libraries and binaries (in
subdirectories such as ".lib", but it's almost uneard of for the compiled
object files. It's also incompatible with standard practices for autoconf,
GNU Makefile, Ant, and Maven.
I'd have to say that such separate subdirectory compilation is *not*
traditional.
> built objects by simply deleting the temporary folder. In Java, I tell
> developers to create a folder called "target" under their project
> root, and store all built files and logs over there. This also ensures
> that you don't accidentally add built files into your repository.
>
While it's a reasonable practice, it's by no means standard. I've not seen
it in *any* of the dozen or so Java projects I've helped wrap and integrate
in the last 2 years. And it's *precisely* the sort of case that would
benefit from such a cleanup. If the "target" directory is excluded by
an svn:ignore, no normal Subversion scripting will find it without great
awkwardness recursively extracting "svn:ignore" settings and parsing them.
That means the the build tools, such as Ant and GNU Make, would require
hand-manipulation to know to flush it. And they don't, it has to be added
manually.
> * It is traditional as part of your build system to have a "clean"
> target that does this.
>
And the Subversion system alrady knows what goes in the "clean" filesystem,
right?
> * It is easy enough to create a script to do this job for you. In
> Unix, if you don't have spaces in your file names, the one liner "svn
> status | awk '/^\?/ {print $2}' | xargs rm -rf" will do the job.
>
Nope It won't handle the svn:ignore contents, and it won't handle the
svn:externals
> * There are more serious features that Subversion is missing. The best
> known is a true "obliterate" command to remove obsolete revisions of
> files. For example, if someone commits a file that contains customer
> proprietary information, there's no easy way to completely remove that
> revision from Subversion. You have to take down the repository, and do
> a dump, filter, and load. I'd rather the Subversion team work on this
> issue, which involves the way the Subversion server acts, rather than
> this issue.
>
Yeah, and that one's clearly going nowhere. The increasing sophistication
and feature additions to the back end databases make it bloody scary.
> This maybe why this has never even been considered as a feature. It
> really doesn't affect Subversion itself. This is something that the
> build system should be handling. In many open source projects, the
> source and build files are tarred up and distributed. What happens
> when the source is distributed, and you can't depend upon the version
> control system to do this for you?
>
> Nico Kadel-Garcia commented that this is important because his build
> contains many war files. You really should never check in built
> objects into Subversion. Instead, these objects should be stored in
release system where they can be downloaded as needed. Maven does
>
You mean like a Subversion tag? Yes, that is certainly common practice in a
well managed environment. This can lead to interesting branching behavior,
and excess binary churn needs to be avoided. But I've seen plenty of 100
Meg Java directories in Subversion. It gets even more fun when the various
*build* and deployment tools are ..jar files.
> this, but you can easily do this with Ant and Ivy too. Storing wars
> and jars in version control is an easy way to start off a project, but
> will cause major issues later on. Most of the time, you lose track of
> what version of the war or jar you're build is depending upon. Plus,
> no matter what version control system you're using, checking in and
> out binary based files is slow and takes up a lot of space.
>
> Well, yes. That's yet another reason why it would be so handy to have a
local "revert me" command.
> It gets to the point where your project is fighting a constant battle
> with stability. We have a project with five copies of the same jar
> file. Even worse, there are three completely separate versions of this
> jar in our project with two different ones in the same ear file. Every
> time something changes, something goes wrong. It'll take us months to
> clean up this mess.
>
Heh. Been there, done that. But if you tell them to build the components on
the fly, especially the deployment tools, you're dead. Each developer will
often have their own special little build environment, especially with
different JDK's, and they *will not* produce identical objects.
Received on 2012-03-13 02:29:01 CET