Quoting Wolf Josef <josef.wolf@siemens.com>:
> Branko Cibej wrote:
> > Tom Eastman wrote:
> >
> > >What I'll do instead is just move the pdf's to another
> > >directory shared by apache, so it's no real problem.
> > That's the best plan.
>
> Well, this is one solution, but then you need something like wget
> if you need to access those files.
Why'd you need wget to access files that are served by Apache? All you need is a
Web browser. Or are you worried about those files not appearing in your working
copy at checkout?
>
> > Imagine the potential for disaster if we had a version control
> > system that allowed you to avoid doing version control. Ouch.
>
> While I too can't see any point in storing generated PDFs in the
> repos,
> there might be other use-cases for this feature. Here are two
> examples:
>
> - IT-infrastructure changes sometimes. So we want to have a file which
> contains the current information where "make dist" should put
> released
> tarballs and such things. I think that there is no doubt that such a
> file should always contain the _current_ information.
Sure the information should be current. What does that have to do with the file
not being versioned? The chances are that your current dist.sh won't work with
your older sources/build scripts/whatever. And you often do want to know what
your build environment used to look like, and why or how it changed.
> - If you want to maintain one changes-file that contains all the
> changes
> made in all branches, then this file should be unversioned, too.
Nonsense. Why should it be unversioned? Every project I know of -- including
Subversion -- has a versioned CHANGES file, and so they should be. The one
possible exception is GNU ChangeLog files that are nothing but a collection of
log messages; In Subversion, you can get rid of them completely and generate
them during tarball creation using "svn log".
> I admit that such use-cases are very rare and that it does not make
> much
> sense to implement it before-1.0. But you can not say that there are
> _no_
> such cases.
What I'm saying is that a version control tool should be just that -- a version
control tool. Not a repository for unversioned files.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 31 13:36:21 2003