[pretty please, stop mailing me personally, and keep the discussion on
the list! :-) ]
On Sun, 2004-07-18 at 09:15, Daniel Albuschat wrote:
> Ben Collins-Sussman wrote:
> > Using templates as part of the build system is the most common thing in
> > the world. Heck, check out a copy of subversion itself and notice that
> > even 'configure.in' is under version control, but 'configure' is not.
> > Count how many "*.in" files are versioned and are converted to
> > unversioned files by the build system.
>
> This is a totally different story. In this case, configure.in can be
> `compiled' to configure. So, of course, you shouldn't put it under
> version control, since it's redundant and sometimes inconsistent and
> error-prone (if the configure doesn't match the configure.in, for
> example).
I don't think it's a different story at all. People write build scripts
that run 'autoconf' on configure.in, which produces configure. Everyone
who checks out a working copy understands that the build system must
"convert" the template to an customized, unversioned file. It doesn't
matter whether the "conversion" involves running a fancy program like
autoconf, or if it's just a matter of running 'cp'. The point is that
the customized file is auto-generated in one way or another, so it's the
template that's put under version control, not the generated file.
>
> > So no, I don't think there's any planned feature to teach 'svn commit'
> > to ignore versioned files.
>
> Well, I was thinking about putting this template-trick into
> the subversion command, somehow. Something like this:
> "svn template <file>"
> will copy <file> to <file>.tmpl, putting <file>.tmpl under version
> control and put some info into the repos, that when doing a checkout,
> svn should copy <file>.tmpl to <file>.
> This way, you can compile right ahead, without knowing about template
> files and/or looking for them.
> And, if <file>.tmpl changes, svn can give a message like: "Compare your
> <file> to the <file>.tmpl file, because the template changed and you
> have to make changes to your local copy accordingly.".
Unlike SCM tools like clearcase (which come with their own 'make'
tools), Subversion is not a build system. Our philosophy is to avoid
adding features that a build system should take care of.
(I am not the Subversion project, but this has come up on dev@
discussions before, and I think this is the general consensus.)
>
> But this is just a thought. I know that subversion doesn't put it's
> `philosophy' into the command structure (like with branches, tagging,
> etc.). But then again, this template-trick should be described in the
> documentation (and/or the subversion book), too.
Hm, yeah, I guess almost all of the FAQ's should go into the book at
some point. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jul 18 21:04:16 2004