On Mon, 28 Dec 2009 12:47:59 -0400 bulia byak <buliabyak@...400...> wrote:
On Mon, Dec 28, 2009 at 12:28 PM, bulia byak <buliabyak@...400...> wrote:
On Sun, Dec 27, 2009 at 9:22 PM, Jon Cruz <jon@...18...> wrote:
And after I pulled, all of my recent changes seem intact. So we are good.
Actually we're not good at all. For example
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/8859#src/w...
lumps together my latest change to this file with a lot of other changes, all under rev 8859 ascribed to Arcadie Cracan.
Now, the basic purpose of any revision control system is exactly this: to record/show who changed what and in what order. If it fails in this basic purpose - if it is SO easy to break it - I seriously doubt it is fit for serious use.
Your change is still in there in it's original state:
revno: 8857.1.55 revision-id: buliabyak-20091226175618-l2dis72b19tb0035 parent: maximilian.albert@...2303... committer: buliabyak branch nick: trunk timestamp: Sat 2009-12-26 13:56:18 -0400 message: alignment change accompanied by compensating move, so the text stays put i modified: src/widgets/toolbox.cpp toolbox.cpp-20091128124040-aej0x7yhxng1m6ly
Arcadie just inadvertently moved a bunch of revisions to sub-revisions of his commit, but the actual revisions (as defined by the revision-id) reamain atomic and attributable.
bzr annotate src/widgets/toolbox.cpp shows what you did:
8857.1.55 buliaby | | // move the x of all texts to preserve the same bbox | Inkscape::Selection *selection = sp_desktop_selection(de 8857.1.56 jon@...2304... | for (GSList const *items = selection->itemList(); items 8857.1.55 buliaby | if (SP_IS_TEXT((SPItem *) items->data)) { | SPItem *item = SP_ITEM(items->data); | | unsigned writing_mode = SP_OBJECT_STYLE(item)->w | // below, variable names suggest horizontal move | // and move in the corresponding axis | int axis; 8857.1.56 jon@...2304... | if (writing_mode == SP_CSS_WRITING_MODE_LR_TB || 8857.1.55 buliaby | axis = NR::X; 8857.1.56 jon@...2304... | } else { 8857.1.55 buliaby | axis = NR::Y; 8857.1.56 jon@...2304... | } 8857.1.55 buliaby |
Arcadie's workflow changed the revision numbers in a way that's not familiar to SVN users, and lp's interface tends to hide sub-revisions, which doesn't help. I think it's relatively difficult to actually lose revisions.
Cheers -Terry
Missing revisions are a really, really bad thing. The black hole Ted created in our SVN was felt for months - even though no files were lost, only records of revisions. Now we have a very similar thing happen, perhaps even exactly the same (Ted was using a bzr client for svn, as far as I remember), just weeks after we switched to a new system. I request that those in charge please investigate some ways to AUTOMATICALLY prevent this thing from happening (e.g. by banning branches unless approved by moderator). A wiki page is not enough.