On Sun, 2006-11-26 at 19:31 +0100, Carlos Nieves Ónega wrote: > El jue, 23-11-2006 a las 13:35 +0000, Peter Clifton escribió: > > Hi, > > > > In the few hours I have spare, I've been tinkering with removing cached > > screen coordinates again, this time against the glist-dev branch. > [snip] > > Maybe it's worth to make a branch for this... hope a branch of a branch > could be created... what do you think?
I think it could be useful... I'm not sure how it works in CVS, but I expect it is possible. It would be based off glist-dev I guess, however as the changes are quite major in many places, I expect merging it up-to date might require manual intervention at times. How smart is CVS when merging? Let me think though a few use-cases of the branch.... Keeping up to date with parent changes, which is good, whilst still being able to hack on the new testing code. How about pushing specific changes back into the parent branch, or head? Is it possible to take a particular set of changes from the branch, put it into head, (or the parent branch), then re-root those files to the updated parent? Does CVS care that the changes to the parent are now "already applied" in the parent.. how does it affect revision numbering for commits where those changes were made in the branch its self? I've been using glist-dev for a while now, and it seems stable. I've also been using the -noscreen version (which prints a few warnings I added), and otherwise doesn't seem too bad. Is there any time-table or coding roadmap for merging glist-dev back with HEAD? A few known issues with my -noscreen: there may be a slight miss-alignment in snapping to the grid, as that doesn't take place in an obvious way, and often happens as an unintended byproduct of converting coordinates. I intend to migrate grid-snapping to occur only in world coords, when specifically required. Since I didn't like the hard-coded +4 pixel "extra" bounds allowed in screen coords, it is slightly harder to grab objects in my -noscreen version. I expect this can nicely be customised with a scheme parameter to define how close you have to get to an object to select it. (If not a scheme parameter, at the least, a #define). Regards Peter C. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
