El dom, 26-11-2006 a las 20:34 +0000, Peter Clifton escribió: > 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.... [snip] > 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 have no experience with merging branches, so I'll let someone else answer this. > 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? Ales said the merge will be done when more people tested the branch. Ales, what about this? > 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). sounds good. Regards, Carlos _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
