PDFTranscoder configuration and CVS branches
I have downloaded the FOP's main branch and I have built it successfully. After playing with the PDFTranscoder (only, no FOP) for several days I wanted to take the next step and try to add some custom fonts. I traced through the code and I think I need to provide a configuration class which implements Avalon's Configuration interface and at the same time can parse FOP's configuration file (for font metrics). I was not able to find such class. I noticed that there is src/java/org/apache/fop/configuration package in Alt-Design and src/org/apache/fop/configuration in fop-0_20_5 but I could not find anything in the main trunk. Previously mentioned classes do not implement Configuration interface but could at least be a start for one. In addition, I was not able to find any configuration related classes in the trunk. How can I configure the latest PDFTranscoder code? Am I looking in wrong places? Thank you very much, Petar Obradovic
PDFTranscoder configuration and CVS branches
My apology for posting the question below to the dev list. It was meant to go to the user list. Petar -Original Message- From: OBRADOVIC,PETAR (HP-Vancouver,ex1) [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 7:29 PM To: FOP ([EMAIL PROTECTED]) Subject: PDFTranscoder configuration and CVS branches I have downloaded the FOP's main branch and I have built it successfully. After playing with the PDFTranscoder (only, no FOP) for several days I wanted to take the next step and try to add some custom fonts. I traced through the code and I think I need to provide a configuration class which implements Avalon's Configuration interface and at the same time can parse FOP's configuration file (for font metrics). I was not able to find such class. I noticed that there is src/java/org/apache/fop/configuration package in Alt-Design and src/org/apache/fop/configuration in fop-0_20_5 but I could not find anything in the main trunk. Previously mentioned classes do not implement Configuration interface but could at least be a start for one. In addition, I was not able to find any configuration related classes in the trunk. How can I configure the latest PDFTranscoder code? Am I looking in wrong places? Thank you very much, Petar Obradovic
RE: Common code in CVS branches
At 02:09 AM 11/6/02, you wrote: I just went looking in the archives for this discussion thought I saw pieces of it, but could not find what I was looking for -- namely, what theories you guys had proposed / agreed upon. This is related to the font work that I have started, i.e. I assume that the problem is a difference between metrics reported/used by the awt Font and those reported from our parsed metrics files. If it is not too much trouble, do you mind recapping a brief summary of where the issue stands now? Thanks. Victor (and Oleg, Keiron) I agree this should get summarized (and documented.) Presently, I am trying to systematically reproduce it here -- it may take another day or two, since the new JRE versions appear to behave differently (and still wrongly, it appears). -- And, frankly, I'm totally confused by what I'm seeing today. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
font issues (was RE: Common code in CVS branches)
On Wed, 2002-11-06 at 08:09, Victor Mote wrote: I just went looking in the archives for this discussion thought I saw pieces of it, but could not find what I was looking for -- namely, what theories you guys had proposed / agreed upon. This is related to the font work that I have started, i.e. I assume that the problem is a difference between metrics reported/used by the awt Font and those reported from our parsed metrics files. If it is not too much trouble, do you mind recapping a brief summary of where the issue stands now? Thanks. It would be great if this information could be put somewhere for better issue tracking, bugzilla for example. Hopefully this could make it easier to locate and use when it is needed. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
Ralph LaChance wrote (to Oleg): Some months ago, we exchanged some notes regarding a problem in java that leads to a discrepancy in glyph measuring and rendering between printing and on-screen viewing. Does your work by any chance avoid or resolve those problems ? (For that matter, does your awt viewer handle printing?) I just went looking in the archives for this discussion thought I saw pieces of it, but could not find what I was looking for -- namely, what theories you guys had proposed / agreed upon. This is related to the font work that I have started, i.e. I assume that the problem is a difference between metrics reported/used by the awt Font and those reported from our parsed metrics files. If it is not too much trouble, do you mind recapping a brief summary of where the issue stands now? Thanks. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Ralph LaChance wrote: Your comment about progress on the awt viewer is good news - I'm looking forward to trying it out ! Well, I'm afraid I have to disappoint you, but we have talked about 1.0dev stuff. The viewer's reworking at the moment primary consists of cleaning the code, removing unnecessary complexity + moving to standard Locale-aware l10n. And that component is only about viewing, not rendering. Some months ago, we exchanged some notes regarding a problem in java that leads to a discrepancy in glyph measuring and rendering between printing and on-screen viewing. Does your work by any chance avoid or resolve those problems ? Nope, but I hope AWTRenderer is the next on our task list, so we'll see wht acan be done. (For that matter, does your awt viewer handle printing?) Ahem, in the same way 0.20.4 viewer does. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
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 would apply, I think. That's the way I would envisage a new subset branch being created. But see Jeremias' comments on the difficulties of educating committers. 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 problem. It 1) greatly simplifies the commit process (it really eliminates the educating committers problem that Jeremias mentioned), 2) defers branching individual files until they must be branched, 3) provides a moderately easy way of knowing which files are actually different. It requires only that when a file needs to be added to the branch that someone run a cvs tag command on that file, and that if you are working on the branch you use cvs checkout -f to make sure you get the trunk version of the common files. If you fail to do the latter, the compiler will no doubt remind you. Although I'm pretty green with CVS, I have used RCS pretty heavily, and have used the above concept successfully with it. We used scripts to accomplish the same sort of things that CVS handles so nicely, but the concepts are pretty much the same. Since the success of maintaining any re-merged work depends on this concept, I'll do some testing on that first to make sure that I'm not missing anything. BTW, it is this viewpoint that makes me think that we have the branches reversed. If the working / maintenance code is the core code that you start with, then the new design code is the stuff that is branching off. Go back to the point in time immediately before the first file was changed in the redesign work. You modify file foo.java and want to commit it to the repository as the first piece of the redesign. You have decided that the redesign will live in the trunk and that the old code will be pushed onto a branch (exactly as we have done). The only way that you can accomplish this is to force a checkin of the code that **did not** change onto the branch. Other have pointed out that it really doesn't matter where the branches are, and in a strict sense they are correct (and we can use the admin -b to change the default branch if we want to). However, it seems extremely awkward and counter-intuitive to create a branch on code that didn't change. I don't feel strongly about the position of the two branches. However, there seems to be general agreement that this is a complex project. Since complexities tend to be exponential in nature, every one of them that can be eliminated tends to have a large benefit. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
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 concern. However, consider the following: 1. The layout redesign is not the only work that is needed before a 1.0 release. If people can work on the other features in parallel with those who are working on redesign, then we get to 1.0 faster. 2. As I understand it, there is maintenance code work that needs to be merged into the trunk anyway. This should accomplish that, again in parallel with the redesign. We don't want to have features in 0.20.4 that aren't in 1.0. 3. If we can get the code that should be common merged, then anyone who works on common code for the benefit of the maintenance branch must make sure that they haven't broken anything in the redesign along the way. This *might* expose them more to the redesign work. 4. If the old layout is as dead-end as I have been told (and I have no reason to doubt it), then *no one* will want to spend any time on the code that is specific to the maintenance branch only. People working on layout will do so in the redesign code, people working on anything else will do so in the common code. We can still quibble about whether people should be working on this or that, but at least everyone will be working on 1.0. That is the theory anyway. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
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 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 separate components. I fully agree with you. That's why I mentioned my employer who actually understands the reasons for the redesign and looks forwards to FOP 1.0, but thinks that there are certain issues that have to be dealt with right now. That's why I'm going to look at multithreading issues in the maintenance branch this week. If we had enough resources (like in Jakarta Tomcat, XML Xerces and XML Xalan, where they maintain/maintained two or more dev tracks at once) I wouldn't mind a two-track-approach. But in our situation I tend to force the redesign so we can deliver FOP 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 wondering how advanced it really needs to be before anyone wants to work on it. It is almost suitable to be used with the docs that forrest creates. I understand your particular situation and the required things for production. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
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 problem. It 1) greatly simplifies the commit process (it really eliminates the educating committers problem that Jeremias mentioned), 2) defers branching individual files until they must be branched, 3) provides a moderately easy way of knowing which files are actually different. It requires only that when a file needs to be added to the branch that someone run a cvs tag command on that file, and that if you are working on the branch you use cvs checkout -f to make sure you get the trunk version of the common files. If you fail to do the latter, the compiler will no doubt remind you. The selection of the branch really was simple: - the old code had a number of problems - we were getting nowhere trying to improve on that code due to the poor design creep - the code was branched only for bug fix updates with the intention of abandoning it - branch for old code simply as reference and for bug fixing - new code on trunk as the main development focus - work on new code to address design problems Redesign, rewrite call it what you want. The design of some fundamental parts is different (area tree, renderers, xml handling, image handling, layout), a number of things where rewritten to accomodate the different design approach. I really don't think that you can say, even with the benefit of hindsight, that working from the original code would have got us towards a better design in the same time. Quite simply the code was a mess. BTW, it is this viewpoint that makes me think that we have the branches reversed. If the working / maintenance code is the core code that you start with, then the new design code is the stuff that is branching off. Go back to the point in time immediately before the first file was changed in the redesign work. You modify file foo.java and want to commit it to the repository as the first piece of the redesign. You have decided that the redesign will live in the trunk and that the old code will be pushed onto a branch (exactly as we have done). The only way that you can accomplish this is to force a checkin of the code that **did not** change onto the branch. Other have pointed out that it really doesn't matter where the branches are, and in a strict sense they are correct (and we can use the admin -b to change the default branch if we want to). However, it seems extremely awkward and counter-intuitive to create a branch on code that didn't change. I don't feel strongly about the position of the two branches. However, there seems to be general agreement that this is a complex project. Since complexities tend to be exponential in nature, every one of them that can be eliminated tends to have a large benefit. As I have said a number of times and will continue to say. The old code was linked all over the place making it unecessarily complex, a suitable design was not forming and there was essentially no hope of implementing certain important features. We needed to start from scratch in some areas and attack it from a different perspective. There didn't seem to be a need to waste a lot of time bringing across the old code in gradual steps. Even now it seems like it would take far longer to bring across in small steps than it would to simply focus on what we have now. Should we then focus on a simpler cleaner design to get rid of these exponential complexities. How good does it need to be working before you will consider it suitable to work on. Keiron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
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 already quite advanced. I'm aware that this is a concern. However, consider the following: 1. The layout redesign is not the only work that is needed before a 1.0 release. If people can work on the other features in parallel with those who are working on redesign, then we get to 1.0 faster. Wouldn't that work better under the same design prinicples and support code. The branch does not have this. 2. As I understand it, there is maintenance code work that needs to be merged into the trunk anyway. This should accomplish that, again in parallel with the redesign. We don't want to have features in 0.20.4 that aren't in 1.0. Only about 1 or 2 minor things that I know, is there a list of them anywhere. We are working on a 1.0 final, in the meantime we could do a developers release that has less. 3. If we can get the code that should be common merged, then anyone who works on common code for the benefit of the maintenance branch must make sure that they haven't broken anything in the redesign along the way. This *might* expose them more to the redesign work. 4. If the old layout is as dead-end as I have been told (and I have no reason to doubt it), then *no one* will want to spend any time on the code that is specific to the maintenance branch only. People working on layout will do so in the redesign code, people working on anything else will do so in the common code. We can still quibble about whether people should be working on this or that, but at least everyone will be working on 1.0. It comes down to resources, who will do all this. That is the theory anyway. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
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 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 separate components. Thanks for filling the white spots I left with my answer. I fully agree with you. That's why I mentioned my employer who actually understands the reasons for the redesign and looks forwards to FOP 1.0, but thinks that there are certain issues that have to be dealt with right now. That's why I'm going to look at multithreading issues in the maintenance branch this week. If we had enough resources (like in Jakarta Tomcat, XML Xerces and XML Xalan, where they maintain/maintained two or more dev tracks at once) I wouldn't mind a two-track-approach. But in our situation I tend to force the redesign so we can deliver FOP 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 wondering how advanced it really needs to be before anyone wants to work on it. It is almost suitable to be used with the docs that forrest creates. The fact that we started to get a few patches for the redesign after our discussions in August is already a good sign. I understand your particular situation and the required things for production. Yeah, I'd be grateful if the situation was different. At least, it looks like I will be able to work on the redesign soon. For how long and if I'm going to get paid for it I'm still trying to check out. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
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 complicated, though not massively more so, and 2) requires closer liaison between committers on common code commits. 1) bad 2) good? I can't follow you on 2). Do you mean between maintenance-oriented committers and redesign-oriented committers? If that gets a problem then we have a split in the project and that wouldn't be good. Between all committers. I meant that closer liaison between committers is a good thing. All committers then have a more lively appreciation of what the others are up to. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
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 separate components. I understand, and I will interpret these comments and other related ones together to be a veto on my proposal to try to merge the two branches. I totally understand and respect that, and will comply. I do think that I got the wrong impression somewhere along the way. To the extent that I am able to demand anything, I really think we must at the very least make it very clear in our web site/doc that the maintenance branch is not open for business except for bug fixes, and with perhaps a two-sentence explanation of why. That may prevent you from getting to have this discussion again. I'm wondering how advanced it really needs to be before anyone wants to work on it. It is almost suitable to be used with the docs that forrest creates. I'll start in on it right away. If you have a specific task that a greenhorn can chew on, please let me know. Otherwise, I'm sure I'll be able to find something interesting. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
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 wrote: On Mon, 2002-11-04 at 16:19, Victor Mote wrote: I'll start in on it right away. If you have a specific task that a greenhorn can chew on, please let me know. Otherwise, I'm sure I'll be able to find something interesting. Hi Victor, The major areas of neglect would have to be: - font handling - api classes - awt viewer Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
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 installing a new workstation today, but hope to be started on this work tomorrow. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Common code in CVS branches
Re some recent questions on this topic. As I understand it, creating a branch in the tree off an existing file set simply involves tagging the set of files with the new branch tag. From that point on, as long as a particular file remains unchanged, a checkout on either branch will retrieve a identical *revision* of the file. As soon as a change is made to a file in either branch, the retrieved files will differ by that delta, and the unchanged file will retain the original revision number. Maintaining common code across different branches is another question. Here's an approach which *may* work. Interested parties might like to create a dummy CVS tree and try it. As well as the two full development branches, create a branch (or branches) specifically for common code sets. From that branch, cvs remove all of the non-common files. Proceed with parallel development. When one wants to make changes to the common code, notify everyone of the intention. Negotiate any conflicts of intention. (This may be a good reason to split the common code into a number of modules, each with its own reference branch.) Make the changes, test and perform a normal commit. Now merge from your branch into the common code branch or branches. This is the tricky part. CVS may spit the dummy here, but I hope not. I hope that it will simply report on all of the unknown files that you are throwing its way, while going ahead with a merge of the files it knows about. Tag your branch and tag the common branch according to some agreed scheme. Notify completion. Now someone working on another branch or branches can merge from the common branch into his branch. He then tags his branch according to the same scheme. Note that future merges to and fro will be relative to these tag points. It's kinda messy, but it might just be feasible. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Peter This is an idea I was also playing with. Avalon does that, too. But having multiple subprojects (that's what they are, not modules) brings it own difficulties. There are several pros and cons to this: + Encourages loose coupling and good design + Components that could in theory be used independently of FOP would get a better visibility. + Reduces redundancy/code duplication + It is easier for newbies to start working on FOP because they don't see a big bundle of code at once. - dependencies get more difficult to handle - encourages the development on the old FOP (which I don't think is a good thing) I've found more pros than cons but I'm not sure I like it. 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. FOP has lost a lot of its maintainers last year. New ones have been elected into the project but we're still in a resource shortage. I'm glad we have a few new candidates coming up. As we've discussed in August, I think it's VERY important to focus our work so we can get that redesign/rewrite phase behind us as fast as possible. Having to watch dependencies in this process is braking these efforts. If changes are being performed in the maintenance path that can later be ported to the redesigned FOP then I have nothing against it. Examples can be those given by Keiron. IMO font support is also pretty separate. Also, bugs should also be fixed if they are easy to fix. But please, let's put our efforts together to bring FOP to a version 1.0 as soon as possible. A lot is already there. We can build on that. On 03.11.2002 15:12:24 Peter B. West wrote: (This may be a good reason to split the common code into a number of modules, each with its own reference branch.) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Jeremias Maerki wrote: But please, let's put our efforts together to bring FOP to a version 1.0 as soon as possible. A lot is already there. We can build on that. That's what I wanted to say all the thread, +1. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
Peter B. West wrote: Re some recent questions on this topic. As I understand it, creating a branch in the tree off an existing file set simply involves tagging the set of files with the new branch tag. From that point on, as long as a particular file remains unchanged, a checkout on either branch will retrieve a identical *revision* of the file. As soon as a change is made to a file in either branch, the retrieved files will differ by that delta, and the unchanged file will retain the original revision number. The first part of this is correct, I think. If you have 100 files, and 30 of them need to be branched, those 30 files are tagged with a branch ID. To get a complete set of code on that branch, I think you would have to use checkout -f, so that your CVS client knows how to find the other 70 files on the default branch. I am almost sure that if changes are made to any of those 70 files, they will be seen in this scheme by both those working on the trunk and those working on the branch. This is where we wish we were right now, but I think what happened is that basically **all** of the files got tagged with a branch ID, effectively forking a bunch of them that would have been better to leave unified. It may be possible to restore this state even now. More on this in my response to Jeremias to follow. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Victor Mote wrote: Peter B. West wrote: Re some recent questions on this topic. As I understand it, creating a branch in the tree off an existing file set simply involves tagging the set of files with the new branch tag. From that point on, as long as a particular file remains unchanged, a checkout on either branch will retrieve a identical *revision* of the file. As soon as a change is made to a file in either branch, the retrieved files will differ by that delta, and the unchanged file will retain the original revision number. The first part of this is correct, I think. If you have 100 files, and 30 of them need to be branched, those 30 files are tagged with a branch ID. To get a complete set of code on that branch, I think you would have to use checkout -f, so that your CVS client knows how to find the other 70 files on the default branch. I am almost sure that if changes are made to any of those 70 files, they will be seen in this scheme by both those working on the trunk and those working on the branch. This is where we wish we were right now, but I think what happened is that basically **all** of the files got tagged with a branch ID, effectively forking a bunch of them that would have been better to leave unified. It may be possible to restore this state even now. More on this in my response to Jeremias to follow. Victor, 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 would apply, I think. That's the way I would envisage a new subset branch being created. But see Jeremias' comments on the difficulties of educating committers. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Jeremias Maerki wrote: Peter This is an idea I was also playing with. Avalon does that, too. But having multiple subprojects (that's what they are, not modules) brings My sloppy use of the term module. it own difficulties. There are several pros and cons to this: + Encourages loose coupling and good design + Components that could in theory be used independently of FOP would get a better visibility. + Reduces redundancy/code duplication + It is easier for newbies to start working on FOP because they don't see a big bundle of code at once. - dependencies get more difficult to handle - encourages the development on the old FOP (which I don't think is a good thing) In the case of common code, work on the old FOP would also be work on the new FOP, wouldn't it? I've found more pros than cons but I'm not sure I like it. 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 complicated, though not massively more so, and 2) requires closer liaison between committers on common code commits. 1) bad 2) good? FOP has lost a lot of its maintainers last year. New ones have been elected into the project but we're still in a resource shortage. I'm glad we have a few new candidates coming up. As we've discussed in August, I think it's VERY important to focus our work so we can get that redesign/rewrite phase behind us as fast as possible. Having to watch dependencies in this process is braking these efforts. If changes are being performed in the maintenance path that can later be ported to the redesigned FOP then I have nothing against it. Examples can be those given by Keiron. IMO font support is also pretty separate. Also, bugs should also be fixed if they are easy to fix. But please, let's put our efforts together to bring FOP to a version 1.0 as soon as possible. A lot is already there. We can build on that. I concur with Oleg here. (Yes, really.) However, there are people who, as Victor has said, who find the all-or-nothing approach extremely difficult. If they can come up with practical ways of easing such difficulties, their suggestions should be carefully considered. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
On Mon, 04 Nov 2002 10:22:14 +1000 Peter B. West wrote: Jeremias Maerki wrote: Peter This is an idea I was also playing with. Avalon does that, too. But having multiple subprojects (that's what they are, not modules) brings My sloppy use of the term module. it own difficulties. There are several pros and cons to this: + Encourages loose coupling and good design + Components that could in theory be used independently of FOP would get a better visibility. + Reduces redundancy/code duplication + It is easier for newbies to start working on FOP because they don't see a big bundle of code at once. - dependencies get more difficult to handle - encourages the development on the old FOP (which I don't think is a good thing) In the case of common code, work on the old FOP would also be work on the new FOP, wouldn't it? Yes, for peripheral components (PDF lib, fonts etc.). I've found more pros than cons but I'm not sure I like it. 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 complicated, though not massively more so, and 2) requires closer liaison between committers on common code commits. 1) bad 2) good? I can't follow you on 2). Do you mean between maintenance-oriented committers and redesign-oriented committers? If that gets a problem then we have a split in the project and that wouldn't be good. FOP has lost a lot of its maintainers last year. New ones have been elected into the project but we're still in a resource shortage. I'm glad we have a few new candidates coming up. As we've discussed in August, I think it's VERY important to focus our work so we can get that redesign/rewrite phase behind us as fast as possible. Having to watch dependencies in this process is braking these efforts. If changes are being performed in the maintenance path that can later be ported to the redesigned FOP then I have nothing against it. Examples can be those given by Keiron. IMO font support is also pretty separate. Also, bugs should also be fixed if they are easy to fix. But please, let's put our efforts together to bring FOP to a version 1.0 as soon as possible. A lot is already there. We can build on that. I concur with Oleg here. (Yes, really.) However, there are people who, as Victor has said, who find the all-or-nothing approach extremely difficult. If they can come up with practical ways of easing such difficulties, their suggestions should be carefully considered. I fully agree with you. That's why I mentioned my employer who actually understands the reasons for the redesign and looks forwards to FOP 1.0, but thinks that there are certain issues that have to be dealt with right now. That's why I'm going to look at multithreading issues in the maintenance branch this week. If we had enough resources (like in Jakarta Tomcat, XML Xerces and XML Xalan, where they maintain/maintained two or more dev tracks at once) I wouldn't mind a two-track-approach. But in our situation I tend to force the redesign so we can deliver FOP 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. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Wondering about CVS branches
On Fri, 2002-10-25 at 18:08, Patrick Dean Rusk wrote: I've recently started working with FOP, and I gather from this list that there are multiple CVS branches of code, in particular for the new design and for the upcoming 0.20.5. I gather from the fop-cvs messages that at least one of these is called FOP_0-20-0_Alt-Design. How can I find out about all of the branch names? Which branch is the default trunk? The upcoming 0.20.5 maintenance release? One way with cvs is to do a cvs log on a file. It will list the symbolic names where the branches and tags on branches have the version form of 1.x.x.x You will then find the names of the branches that Peter mentioned. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Wondering about CVS branches
I've recently started working with FOP, and I gather from this list that there are multiple CVS branches of code, in particular for the new design and for the upcoming 0.20.5. I gather from the fop-cvs messages that at least one of these is called FOP_0-20-0_Alt-Design. How can I find out about all of the branch names? Which branch is the default trunk? The upcoming 0.20.5 maintenance release? Thank you. Patrick Rusk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Wondering about CVS branches
Patrick, There are three: HEAD is the top of the trunk, of course, and is the mainline redesign. fop-0_20_2-maintain is the line of development of the current working version. All of the releases since, let's say, 0.20.2, have been off this branch. If you want to do any work on the current version, you need to checkout this tag. cvs status -v in one of the directories should expose the tags that have been applied as the various releases have been made. FOP_0-20-0_Alt-Design is an Alt(ernative new)-Design. That's what I've been working on. It is focussed on a re-working of properties handling, so far. Peter Patrick Dean Rusk wrote: I've recently started working with FOP, and I gather from this list that there are multiple CVS branches of code, in particular for the new design and for the upcoming 0.20.5. I gather from the fop-cvs messages that at least one of these is called FOP_0-20-0_Alt-Design. How can I find out about all of the branch names? Which branch is the default trunk? The upcoming 0.20.5 maintenance release? -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: CVS branches
Keiron Liddle wrote: Confusion abounds! It does indeed. 8) The trunk is also known as: HEAD, MAIN, main, development, redesign or even cvs update -A or cvs update -rHEAD Okay, thanks for clearing that up. My confusion arose from the fact that ViewCVS (which is used by cvs.apache.org) lists MAIN as a FOP branch. I looked at another ViewCVS installation, and that also lists MAIN as a branch. So I guess it's just a facet of ViewCVS. Apologies for the static. Michael. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
Re: CVS branches
Confusion abounds! There are only two (2) FOP cvs things. THe is the trunk and the maintanence branch. The maintanence branch has the name fop-0_20_2-maintain. This is for maintanence releases. The trunk is also known as: HEAD, MAIN, main, development, redesign or even cvs update -A or cvs update -rHEAD Those still confused should read up on cvs. On 2002.03.26 00:05 Michael Gratton wrote: Christian Geisert wrote: I assumend MAIN and HEAD are equivalent ... (Maybe someone can explain this to me ;-) Not in FOP.. 8) If you checkout FOP without a given branch you get the main development branch (aka redesign). Yeah, that's the case. This is usually called the trunk, and is a special case branch. It has the symbolic name HEAD, although you don't want to use that when checking it out. FOP actually has a branch called MAIN, separate to the trunk (HEAD). Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: CVS branches
Christian Geisert wrote: I assumend MAIN and HEAD are equivalent ... (Maybe someone can explain this to me ;-) Not in FOP.. 8) If you checkout FOP without a given branch you get the main development branch (aka redesign). Yeah, that's the case. This is usually called the trunk, and is a special case branch. It has the symbolic name HEAD, although you don't want to use that when checking it out. FOP actually has a branch called MAIN, separate to the trunk (HEAD). Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
CVS branches
Guys, Sorry to reshash what is probably an old and tired subject, but I've gotten some conflicting advice as to what CVS branch is used for what. If anyone could help fill in the blanks and correct the errors, I'd appreciate it. 8) MAIN - FOP redesign / new-design branch. This is where dev for for the next main iteration of FOP is done. HEAD - I assume v0.21 and latter versions will stem from this branch at some stage, up until the work on the MAIN branch lands on the trunk. fop-0_20_2-maintain - the v0.20.x maintanence branch. Further releases in the v0.20.x series (and others?) are made from this branch. Thanks, Mike. -- Michael Gratton [EMAIL PROTECTED] Recall Design http://www.recalldesign.com/ s: 53 Gilbert Street Adelaide SA 5000 Australia t: +61 8 8217 0500 f: +61 8 8217 0555 smime.p7s Description: S/MIME Cryptographic Signature
