firebird-docs

[Firebird-docs] Zips in the CVS tree

[Paul V. <pa...@vi...>]

Hello all - but especially Tilo this time,

We still have those two zips in the CVS tree, and lots of obsolete
files and subdirs that should be replaced by the zip contents. One of
the zips also unpacks awkwardly, creating a subdir that shouldn't be
there at all. We can fix this in two ways:

1. Unpack both zips, moving the contents to the right place where
   necessary, and commit to CVS. Obsolete files not overwritten by
   content from the zips can be sent to the attic; obsolete subdirs
   can either stay in place empty or we must have an admin ask SF to
   remove them.

2. Repack the troublemaking archive in such a way that it unzips into
   the right subdir, and leave the two zips in CVS. Move obsolete
   stuff to attic and/or... same as above.

Personally I have a strong preference for solution 1, because a) CVS
is a "text thing", and b) unzipping into CVS minimizes the extra steps
a body has to take after checking out the manual module. An additional
benefit is that if we upgrade the DocBook archives and we have things
unzipped in CVS, we can easily use cvs diff if problems arise, to see
what has changed, and how, and where. We can't do that with binaries.

However, I can live with solution 2 as well. But the present situation
makes things unnecessarily complicated.

Tilo, what do you think is best? Whichever solution we choose, I
volunteer to do the work (or part of it); in fact it'll be a good
opportunity to see if my setup works, including committing.


Another, smaller thing: Olivier Mascia's path fix should be applied,
for those who have Java in a path containing whitespace. I can do that
too if you like.

After that, all we have to do is write those docs and we're done! :-)


Greetings,
Paul Vinkenoog


PS:
"A body" is how Huckleberry Finn says "somebody" or "a person". It
just came naturally with the flow of the sentence so I decided to let
it stay there. Actually, I think it's really good English!

Re: [Firebird-docs] Zips in the CVS tree

[Tilo M. <tm...@al...>]

Hi,

"Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag
news:Pin...@so......
> Hello all - but especially Tilo this time,
>
> We still have those two zips in the CVS tree, and lots of obsolete
> files and subdirs that should be replaced by the zip contents. One of
> the zips also unpacks awkwardly, creating a subdir that shouldn't be
> there at all. We can fix this in two ways:
>
> 1. Unpack both zips, moving the contents to the right place where
>    necessary, and commit to CVS. Obsolete files not overwritten by
>    content from the zips can be sent to the attic; obsolete subdirs
>    can either stay in place empty or we must have an admin ask SF to
>    remove them.
>
> 2. Repack the troublemaking archive in such a way that it unzips into
>    the right subdir, and leave the two zips in CVS. Move obsolete
>    stuff to attic and/or... same as above.

1. costs more time for us but it's easier for writers. Anyway I'm still not
convinced that unzipping make things that much complicated.

> Personally I have a strong preference for solution 1, because a) CVS
> is a "text thing", and b) unzipping into CVS minimizes the extra steps
> a body has to take after checking out the manual module. An additional
> benefit is that if we upgrade the DocBook archives and we have things
> unzipped in CVS, we can easily use cvs diff if problems arise, to see
> what has changed, and how, and where. We can't do that with binaries.

The most problems that arise while using a new Docbook and Java releases are
related to the libraries (.jar).

> However, I can live with solution 2 as well. But the present situation
> makes things unnecessarily complicated.

Agreed, at least the zip paths should be correct.

> Tilo, what do you think is best? Whichever solution we choose, I
> volunteer to do the work (or part of it); in fact it'll be a good
> opportunity to see if my setup works, including committing.

I still would go with 2., but you can decide because I don't have time
before mid Oct..

> Another, smaller thing: Olivier Mascia's path fix should be applied,
> for those who have Java in a path containing whitespace. I can do that
> too if you like.

Yes feel free to commit it.

> After that, all we have to do is write those docs and we're done! :-)

Easy one ;)

> Greetings,
> Paul Vinkenoog

--
Regards,
Tilo Muetze
--
Marathon - The SQL Tool for Firebird & InterBase
http://gmarathon.sourceforge.net

Re: [Firebird-docs] Zips in the CVS tree

[Paul V. <pa...@vi...>]

Hello Tilo,

>> 1. Unpack both zips, moving the contents to the right place...
>> 2. Repack the troublemaking archive in such a way that...

> 1. costs more time for us but it's easier for writers. Anyway I'm
> still not convinced that unzipping make things that much complicated.

Maybe not much, but it is an additional two steps to take. And you
have to watch the target dirs while unpacking. I'd rather take those
steps on our end once, than oblige each and every docwriter to take
them on their end.

> I still would go with 2., but you can decide because I don't have
> time before mid Oct..

If you leave it up to me, I'll go for 1 in the next couple of days,
unless there is some additional benefit (other than saving my own
time) in leaving the zips in CVS.


Greetings,
Paul Vinkenoog

Re: [Firebird-docs] Zips in the CVS tree

[Tilo M. <tm...@al...>]

Sorry if this message appears twice, but seems my first one didn't make it
to the newsgroup...

Hi,

"Paul Vinkenoog" <pa...@vi...> schrieb im Newsbeitrag
news:Pin...@so......
> Hello all - but especially Tilo this time,
>
> We still have those two zips in the CVS tree, and lots of obsolete
> files and subdirs that should be replaced by the zip contents. One of
> the zips also unpacks awkwardly, creating a subdir that shouldn't be
> there at all. We can fix this in two ways:
>
> 1. Unpack both zips, moving the contents to the right place where
>    necessary, and commit to CVS. Obsolete files not overwritten by
>    content from the zips can be sent to the attic; obsolete subdirs
>    can either stay in place empty or we must have an admin ask SF to
>    remove them.
>
> 2. Repack the troublemaking archive in such a way that it unzips into
>    the right subdir, and leave the two zips in CVS. Move obsolete
>    stuff to attic and/or... same as above.

1. costs more time for us but it's easier for writers. Anyway I'm still not
convinced that unzipping make things that much complicated.

> Personally I have a strong preference for solution 1, because a) CVS
> is a "text thing", and b) unzipping into CVS minimizes the extra steps
> a body has to take after checking out the manual module. An additional
> benefit is that if we upgrade the DocBook archives and we have things
> unzipped in CVS, we can easily use cvs diff if problems arise, to see
> what has changed, and how, and where. We can't do that with binaries.

The most problems that arise while using a new Docbook and Java releases are
related to the libraries (.jar).

> However, I can live with solution 2 as well. But the present situation
> makes things unnecessarily complicated.

Agreed, at least the zip paths should be correct.

> Tilo, what do you think is best? Whichever solution we choose, I
> volunteer to do the work (or part of it); in fact it'll be a good
> opportunity to see if my setup works, including committing.

I still would go with 2., but you can decide because I don't have time
before mid Oct..

> Another, smaller thing: Olivier Mascia's path fix should be applied,
> for those who have Java in a path containing whitespace. I can do that
> too if you like.

Yes feel free to commit it.

> After that, all we have to do is write those docs and we're done! :-)

Easy one ;)

> Greetings,
> Paul Vinkenoog

--
Regards,
Tilo Muetze
--
Marathon - The SQL Tool for Firebird & InterBase
http://gmarathon.sourceforge.net

Re: [Firebird-docs] Zips in the CVS tree

[Paul V. <pa...@vi...>]

Hi Tilo,

> Sorry if this message appears twice, but seems my first one didn't
> make it to the newsgroup...

I received it via the mailing list yesterday. The newsgroup has a long
delay sometimes, and it also seems to happen that messages don't make
it there at all. I do use it, because it's great to browse with Agent,
but I only post through the mailing list, to make sure my messages
arrive - and arrive reasonably quickly.

> I still would go with 2., but you can decide because I don't have
> time before mid Oct..

In the meantime I went for 1 and unzipped both archives to the right
folders, adapted the ReadMe and comitted the changes. Provided Java
and JAVA_HOME are set up, everything works out of the box now after a
checkout or update. At least for project members. An anonymous
connection still gives you the old tree; same with ViewCVS at SF. I
committed yesterday late afternoon but it seems the delay can be
several days for anon access :-(

BTW: A build under Linux failed because bash choked on the newline
escapes followed by comment lines. Evidently it escaped the #'s too
and saw the subsequent '-----' as commands! When I removed the
in-between comment lines from my local copy, everything worked.

Maybe it's just my system (SuSE 7.1, more than 2 yrs old by now - I
still have the receipt, shall I go complain at Karstadt Trier? ;-))

Anyway I'll try it on another Linux too. If this happens on more
systems we'll have to change build.sh (but it's an easy one, almost
as easy as writing docs :-))

I've also applied Olivier's fix.


Greetings,
Paul Vinkenoog

[Firebird-docs] build.sh broken (was: Zips in the CVS tree)

[Paul V. <pa...@vi...>]

Hi all,

> BTW: A build under Linux failed because bash choked on the newline
> escapes followed by comment lines. Evidently it escaped the #'s too
> and saw the subsequent '-----' as commands! When I removed the
> in-between comment lines from my local copy, everything worked.

Well, it turns out to be a documented bash thing: if a # is glued to
the previous word, it is not considered to be a comment character, so
e.g.

  echo hihihi # hahaha

echoes "hihihi", but

  echo hihihi# hahaha

echoes "hihihi# hahaha"

The same principle is at work in build.sh. It can be fixed in several
ways, but my proposition is to do it like this, because this makes
build.sh and build.bat look more alike, and therefore more easily
maintainable as a pair (I think):

--- BEGIN build.sh ---

#! /bin/sh

if [ "$JAVA_HOME" == "" ] ; then
  echo "    Error: The JAVA_HOME environment variable is not set."
  echo "    You must set it to point at your JDK or JRE distribution,"
  echo "    e.g. JAVA_HOME=/usr/java/j2sdk"
  exit 1
fi


# set up the classpath _CP_ :

# ----- ant libraries: ------
_CP_=../../lib/ant.jar
_CP_=$_CP_:../../lib/optional.jar

# ----- saxon libraries: ------
_CP_=$_CP_:../../lib/saxon.jar

# ----- FOP libraries: ------
_CP_=$_CP_:../../lib/fop.jar
_CP_=$_CP_:../../lib/batik.jar
_CP_=$_CP_:../../lib/avalon-framework-cvs-20020315.jar

_CP_=$_CP_:../../lib

_CP_=$_CP_:$JAVA_HOME/lib/tools.jar

java -Xmx100000000 -showversion -classpath $_CP_ org.apache.tools.ant.Main $*

--- END build.sh


I have this in a working copy of my working copy now, and it does the
job (also tested with JAVA_HOME empty of course).


Greetings,
Paul Vinkenoog