brane@xbc.nu 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.
First, how do you share those files if you do not have a
web server? What about the svnserve-installations?
Second, I do not want to grab the files by drag-n-drop. This is very
time-consuming and error-prone if you have many clients and a
lot of such files. An automated build need to either find the files
already in place or grab them automatically.
> 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.
I am not sure whether you got my point. So let me explain it.
For example let us assume your dist.sh contains something
like:
scp foo-$VERSION.tar.gz bigserver:/releases
Then you will need to change every branch/tag if the destination
is replaced by newserver:/dists. Changing the tags is especially
picant, because they should (theoretically) be write-once.
This situation would not come up at all if you would put
. build/variables.sh
scp foo-$VERSION.tar.gz $RELEASEDIR
into your dist.sh and get the value for $RELEASEDIR from
an unversioned file which is automatically kept up-to-date.
Since our IT-infrastructure has changed several times, I have learned
the following from the past:
1. never put any hostname into a versioned file
2. never put any paths that are not relative and withhin the WC
into a versioned file.
3. never try to keep those hostnames/paths syncronized across
a lot of clients without rsync.
Integrating unversioned files into the SCM system would make it
pretty easy to avoid those three bullets in the above use-case.
OTOH, a setup like the example above has security drawbacks,
so I am not sure whether such a feature is really desireble...
I just tried to show a use case.
> And you often do want to know what
> your build environment used to look like, and why or how it changed.
Why? In the above example, the build has not changed. Only future
builds should be affected (if a bug is fixed on a branch, for example)
> > - 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.
As I wrote above: this file should contain _every_ change that was
made to every branch of the project. If this file is versioned, you end
up merging the changes to this file over and over again and it still do
not contain all the changes of all the branches. BTDT.
> 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".
That depends. Theoretically, "svn log" would do exactly what I want
in this case. But in practice it does _not_, because the above-mentioned
changes-file is for testers/endusers and should not go in _that_ detail
as "svn log" goes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 4 12:11:55 2003