Peter B. West wrote:
Branches generally don't occur with subset of files. The usual
procedure is to tag a working set of files, then checkout the tag. If
there are files you don't want in the new working set, delete and 'cvs
remove' them. Until you 'cvs remove', the comments I made above
Jeremias Maerki wrote:
1.0 as soon as possible. I'm grateful for Victor's work and I hope it
won't be a distraction. Because distractions may leave the focus of
potential co-developers on the maintenance branch even though the
redesign is already quite advanced.
I'm aware that this is a
Hi All,
Not sure where to start with all this...
On Mon, 2002-11-04 at 08:34, Jeremias Maerki wrote:
Yes, for peripheral components (PDF lib, fonts etc.).
That is one of the main problems with the old code, these components are
all linked together in bad ways, making it hard to improve and
On Mon, 2002-11-04 at 09:35, Victor Mote wrote:
I'll take your word for how it is used in real life, and this perhaps
explains how we got to the status quo. I just wonder why? It seems like
tagging only the subset of files that need to be different is a much more
elegant way to handle the
On Mon, 2002-11-04 at 09:57, Victor Mote wrote:
Jeremias Maerki wrote:
1.0 as soon as possible. I'm grateful for Victor's work and I hope it
won't be a distraction. Because distractions may leave the focus of
potential co-developers on the maintenance branch even though the
redesign is
On 04 Nov 2002 10:05:06 +0100 Keiron Liddle wrote:
Hi All,
Not sure where to start with all this...
On Mon, 2002-11-04 at 08:34, Jeremias Maerki wrote:
Yes, for peripheral components (PDF lib, fonts etc.).
That is one of the main problems with the old code, these components are
all
On Sat, 2002-11-02 at 21:31, Victor Mote wrote:
I agree that maintenance branches are not obliged to be merged eventually,
but you still have not shown any benefit to keeping them in the same tree if
they are not.
Usual development pattern would also be that someone makes sure that new
keiron 2002/11/04 03:50:11
Modified:src/org/apache/fop/layoutmgr PageLayoutManager.java
src/org/apache/fop/fo/pagination PageSequence.java
Log:
page numbering across sequences and number formatting
Revision ChangesPath
1.22 +20 -7
Jeremias Maerki wrote:
Comments on your thoughts about branches: It sounds like the CVS
manipulation gets to be a project of its own. If it's too complicated,
some won't follow the rules, more work is generated for maintaining the
codebase. That's the impression I get.
It's definitely 1) more
Here is one other point to consider: if you expect the redesign when
complete to perform at at least the same level, i.e. with the same coverage
of the specification and as many or fewer defects, when it comes online
and replaces the current maintenance release, then I imho the project
should
pbwest 2002/11/04 06:46:03
Modified:src/org/apache/fop/fo/pagination Tag: FOP_0-20-0_Alt-Design
FoLayoutMasterSet.java FoPageSequenceMaster.java
FoRegionAfter.java FoRegionBeforeAfter.java
FoRegionBefore.java
pbwest 2002/11/04 06:54:56
Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design FONode.java
FoRoot.java
Log:
Node and TreeException extracted from Tree.
Revision ChangesPath
No revision
No revision
jeremias2002/11/04 07:14:33
Modified:src/org/apache/fop/viewer Tag: fop-0_20_2-maintain
GoToPageDialog.java PreviewDialog.java
src/org/apache/fop/viewer/resources Tag: fop-0_20_2-maintain
resources.cs resources.de
Log:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14161.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
pbwest 2002/11/04 07:17:10
Modified:src/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design
Tree.java
Added: src/org/apache/fop/datastructs Tag: FOP_0-20-0_Alt-Design
Node.java TreeException.java
Log:
Node and TreeException
Keiron Liddle wrote:
That is one of the main problems with the old code, these components are
all linked together in bad ways, making it hard to improve and deal with
improvements to any particular part.
So work on the old code really means using the new code if these are to
be considered
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13919.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14057.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
jeremias2002/11/04 08:05:09
Modified:.Tag: fop-0_20_2-maintain build.sh
Log:
Bugzilla Entry 13310
Improved classpath construction
Submitted by: Victor Mote [EMAIL PROTECTED]
Revision ChangesPath
No revision
No
Where would be a good place to put some patches.
I have current cvs working with cocoon+forrest and have a patch to work
with the fop-block and a patch to make bookmarks in the pdf output.
Really basic stuff but it might be useful to someone.
On Mon, 2002-11-04 at 17:38, Oleg Tkachenko wrote:
Keiron Liddle wrote:
The major areas of neglect would have to be:
- font handling
- api classes
- awt viewer
Please, reserve last one for me, I'm almost finishing with it.
Sorry, should have mentioned you are working on it.
Hi all,
I m new bie in this Fop project. I just want to know what is the start point in
Fop project and how it goes. can any body help me to start with? thanks in advance.
SriGet faster connections -- switch to MSN Internet Access! Click Here
Sridhar Velagapudi wrote:
I m new bie in this Fop project. I just want to know what is the start
point in
Fop project and how it goes. can any body help me to start with? thanks
in advance.
There is a directory docs/html-docs in your FOP distribution.
Start there.
J.Pietschmann
I've been following this list for a few weeks now, but I'm still unclear as
to the current status of the re-design efforts. The FOP Web site's status
page hasn't been updated since June, apparently, when the estimate of being
35% done was issued.
Anyone want to take a stab at
Victor
If it's ok with you, go with font support. I guess you already read
yourself halfway in and you know my ideas. That would really be great.
Anything else you might want to take is ok, though, and of course,
highly appreciated. What are your ideas?
On 04.11.2002 17:33:55 Keiron Liddle
Jeremias Maerki wrote:
If it's ok with you, go with font support. I guess you already read
yourself halfway in and you know my ideas. That would really be great.
Anything else you might want to take is ok, though, and of course,
highly appreciated. What are your ideas?
That sounds fine. I'm
On Monday 04 November 2002 23:53, Peter B. West wrote:
. . .I don't know the
mechanism for handling line-end differences on entry into a CVS
repository on a unix box.
. . .
AFAIK as long as the binary file flag is not set, CVS takes care of line
endings by itself when a file is checked out
On Monday 04 November 2002 17:02, Jeremias Maerki wrote:
. . .Does anyone have a good idea how to...
2. enforce correct line endings?
Using the commitinfo administrative file, scripts can be configured in CVS to
run when a file is committed, at which point you could detect the problem.
I'm
Thanks, Peter and Betrand, for your answers.
On Tue, 5 Nov 2002 07:21:54 +0100 Bertrand Delacretaz wrote:
On Monday 04 November 2002 17:02, Jeremias Maerki wrote:
. . .Does anyone have a good idea how to...
2. enforce correct line endings?
Using the commitinfo administrative file, scripts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13310.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
30 matches
Mail list logo
