Subversion update problems
Hi all, I realise this isn't a FOP question but when I try to update my trunk sandbox with subversion I get svn: Delta source ended unexpectedly. Does anyone else experiencing this problem? svn up -N (non-recursive update works fine) and so does a fresh checkout of svn co http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk but plain old svn up doesn't work for me anymore. This has never happened before so I was wondering if some of the branching work may have affected things. Adrian.
Re: Subversion update problems
Hi Adrian, Adrian Cumiskey a écrit : Hi all, I realise this isn't a FOP question but when I try to update my trunk sandbox with subversion I get svn: Delta source ended unexpectedly. Does anyone else experiencing this problem? svn up -N (non-recursive update works fine) and so does a fresh checkout of svn co http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk but plain old svn up doesn't work for me anymore. This has never happened before so I was wondering if some of the branching work may have affected things. I don't know what is going on, but by searching on Google it seems you're not alone to have encountered the problem. Maybe you will find an answer on one of the links. Otherwise I'm afraid you will have to go with a new checkout. Sorry, no other clue :-\ Vincent
Re: Bounty for auto table layout?
Hi Jens, Jens Bannmann a écrit : Vincent Hennebert wrote: Question is, also, how to advertise the thing. Would the fop-user mailing list be enough to attract donators? From a quick search, it doesn't seem that the topic was brought up previously on that list. Can anyone think of another place where we can reach users? I think [EMAIL PROTECTED] might help, too - although it's not fop-specific, the DocBook user community is surely interested in improving their open source toolchain. Yes, probably. Given the mostly professional audience there they should be ok with such an action; all the more if a simple user makes the proposal and not a FOP developer. Andreas L Demelle wrote: I do wonder whether the motivation (with or without the bounty) is enough by itself to make it happen. (...) I'm under the impression that certain other things need to happen first before a decent auto-layout implementation becomes a feasible project... Could you elaborate on that a bit? Without knowing any implementation details, I think that all related work would be (implicitly or explicitly) included in the funded task and as such done by the developer. Well I would be curious too ;-) Right now I can't think of anything that would prevent or impede the development of this feature? Although there are probably some (many) other missing preliminary things. snip/ Vincent, you also indicated interest. What's the required time/bounty for you? Frankly, I can't tell it right now. I would first have to spend some time studying this part of the code. I'll try and find some time to do that ASAP. I'm pretty convinced that handling this via fundable.org is the way to go. The service has been around since 2005 and looks trustworthy. They accept payments via PayPal, but only actually charge when the pre-set funding goal of a group action is met. Well, this seems ok. What we need to decide on is a) What is the funding goal (fixed dollar amount)? If it's not met, no money is collected, so polls are really needed to get an idea of the support base. (Note: fundable.org charges 7% of the goal on success, but I think that's fair enough for their service) Ideally it would cover the whole needed time, to guarantee that the feature will be available on time. However, if only a few days of development are missing that would still make it I guess. The rest could be done in the free time. That should be at the discretion of the chosen developer of course ;-) b) What will be the group action's deadline? I propose two months from the day the group action starts. That increases the chance to be noticed; if the goal is met before, the group action immediately ends anyway. Well, if companies want to participate they would probably need some time to prepare a budget for that. That said, I don't think more than 3 months is reasonable, otherwise the interest will vanish. c) Who will be group leader of this over at fundable? This person gets the money, so it should be someone people trust, i.e. has a background with the project etc. (e.g. not me ;-) Ideally, it would be the developer, but it could be someone else who passes on the money. (btw: the latter would also allow several developers - working parallel or in sequence - among which the group leader distributes the money in some fair way.) I'd say someone from the project who is not the developer himself. Regards, Vincent
DO NOT REPLY [Bug 42956] - [PATCH] AFP Renderer - No Operation Extension
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42956. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42956 --- Additional Comments From [EMAIL PROTECTED] 2007-07-23 08:36 --- Created an attachment (id=20534) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=20534action=view) patch file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Bounty for auto table layout?
On Jul 23, 2007, at 16:13, Vincent Hennebert wrote: Could you elaborate on that a bit? Without knowing any implementation details, I think that all related work would be (implicitly or explicitly) included in the funded task and as such done by the developer. Well I would be curious too ;-) Right now I can't think of anything that would prevent or impede the development of this feature? Although there are probably some (many) other missing preliminary things. Prevent? No, indeed not. Impede... Well, have either of you actually /read/ the entire story in the Bugzilla 40271? :) It's not so much impediment, as an increase in the work involved. Note that, for instance, solving the issue of varying page-ipd (or even merely separating the concern of the initial generation of the element lists), would already get us an awful lot closer. Right now, it is almost impossible to get to the content-widths of the FOs in the table, without already going through the whole line-breaking loop... Cheers Andreas
Re: Subversion update problems
On Jul 23, 2007, at 15:37, Vincent Hennebert wrote: Adrian Cumiskey a écrit : Hi all, I realise this isn't a FOP question but when I try to update my trunk sandbox with subversion I get svn: Delta source ended unexpectedly. Does anyone else experiencing this problem? svn up -N (non-recursive update works fine) and so does a fresh checkout of svn co http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk but plain old svn up doesn't work for me anymore. This has never happened before so I was wondering if some of the branching work may have affected things. I don't know what is going on, but by searching on Google it seems you're not alone to have encountered the problem. Maybe you will find an answer on one of the links. Otherwise I'm afraid you will have to go with a new checkout. Same as Vincent, I didn't exactly know where the trouble lies... although I did find this nice explanation in a response to someone with a similar problem: The reason has *always* been because of a messed up wcprop cache. It's becoming a FAQ at this point. How it works: when you checkout a file, ra_dav stores a url cache which uniquely identifies the created-rev/path pair. Later, when you update the file, ra_dav asks mod_dav_svn for a binary diff against that specific cached url. And as one of the possible solutions, other than checking out anew: 1. the immediate solution is to just cd into .svn/wcprops in the offending directory, and delete everything. The caches will be rebuilt as necessary. Cheers Andreas
Re: Subversion update problems
Thanks for the the info, Yes I found the same tip by googling around also. Didn´t quite work for me though, I deleted the .svn/wcprops file and then tried updating and it didn´t rebuild the cache file. I isolated the problem to one subversion directory so ended up just checking out that one folder again and copying my files across to get it working again, was pretty annoying though.. it seems subversion is far from perfect :-[ Adrian. On 23/07/07, Andreas L Delmelle [EMAIL PROTECTED] wrote: On Jul 23, 2007, at 15:37, Vincent Hennebert wrote: Adrian Cumiskey a écrit : Hi all, I realise this isn't a FOP question but when I try to update my trunk sandbox with subversion I get svn: Delta source ended unexpectedly. Does anyone else experiencing this problem? svn up -N (non-recursive update works fine) and so does a fresh checkout of svn co http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk but plain old svn up doesn't work for me anymore. This has never happened before so I was wondering if some of the branching work may have affected things. I don't know what is going on, but by searching on Google it seems you're not alone to have encountered the problem. Maybe you will find an answer on one of the links. Otherwise I'm afraid you will have to go with a new checkout. Same as Vincent, I didn't exactly know where the trouble lies... although I did find this nice explanation in a response to someone with a similar problem: The reason has *always* been because of a messed up wcprop cache. It's becoming a FAQ at this point. How it works: when you checkout a file, ra_dav stores a url cache which uniquely identifies the created-rev/path pair. Later, when you update the file, ra_dav asks mod_dav_svn for a binary diff against that specific cached url. And as one of the possible solutions, other than checking out anew: 1. the immediate solution is to just cd into .svn/wcprops in the offending directory, and delete everything. The caches will be rebuilt as necessary. Cheers Andreas
