Hello,
I don't really know how I've managed to do this (bzr still seems a bit complicated to me) but I think the current revision is an outdated one. Please revert my today (Dec 27) commits.
Thank you, Arcadie Cracan
On Sun, Dec 27, 2009 at 8:35 AM, Arcadie M. Cracan <acracan@...400...> wrote:
I don't really know how I've managed to do this (bzr still seems a bit complicated to me) but I think the current revision is an outdated one. Please revert my today (Dec 27) commits.
Judging by http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files, we also lost a lot of recent revisions :(
Ted, can you please help us out? I'm having a deja vu :)
What I like about SVN is that there, a revision is a revision. Once it's there, no one can delete it from history, accidentally or not. Isn't Bazaar operating on the same principle?
2009/12/27 bulia byak <buliabyak@...400...>:
On Sun, Dec 27, 2009 at 8:35 AM, Arcadie M. Cracan <acracan@...400...> wrote:
I don't really know how I've managed to do this (bzr still seems a bit complicated to me) but I think the current revision is an outdated one. Please revert my today (Dec 27) commits.
Judging by http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files, we also lost a lot of recent revisions :(
I think we didn't. The only thing that happened is that Arcadie apparently committed something that had a lot of obsolete files that somehow were regarded as locally changed. I am guessing that he didn't originally branch from lp:inkscape, because if he did, he would be warned about diverged branches; or that he went back to a previous revision by copying a different working tree over the branch.
Arcadie: to fix this, run "bzr uncommit", it should undo the changes from the fatal rev. 8859. If you want to undo more than the last commit, supply a revision to revert to with the -r parameter. Then describe what exactly did you do with your branch (I'm guessing that you started from an SVN working copy, so provide the details of how did you migrate to Bazaar).
Regards, Krzysztof
On 27/12/09 17:35, Krzysztof Kosiński wrote:
Judging by http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files, we also lost a lot of recent revisions :(
I think we didn't.
This morning I updated my checkout from lp:inkscape to r8918
from ~/.bzr.log:
| Sun 2009-12-27 10:06:56 +0100 | 0.031 bzr arguments: [u'update'] | (...) | 1.318 fetch up to rev {jon@...2301...} | (...) | [49682] 2009-12-27 10:07:05.348 INFO: Updated to revision 8918.
Now the website states that lp:inkscape is at revision 8859 and the launchpad site gives 'internal server error' if I try to access more recent revisions like the last commit by joncruz: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/8918
The previously committed revisions 8858 to 8918 seem to be gone from the shared repository, replaced by the two most recent commits 8858 and 8859 (apparently continuing the revision count from the commits that originally merged the GSoC connector branch).
~suv
On 27/12/09 18:24, ~suv wrote:
On 27/12/09 17:35, Krzysztof Kosiński wrote:
Judging by http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files, we also lost a lot of recent revisions :(
I think we didn't.
This morning I updated my checkout from lp:inkscape to r8918
from ~/.bzr.log:
| Sun 2009-12-27 10:06:56 +0100 | 0.031 bzr arguments: [u'update'] | (...) | 1.318 fetch up to rev {jon@...2301...} | (...) | [49682] 2009-12-27 10:07:05.348 INFO: Updated to revision 8918.
Now the website states that lp:inkscape is at revision 8859 and the launchpad site gives 'internal server error' if I try to access more recent revisions like the last commit by joncruz: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/8918
nm - it is still here - as sub-revision ;)
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/8857.1.61 "This revision was merged to the branch mainline in revision 8858"
~suv
~suv-2 wrote:
nm - it is still here - as sub-revision ;)
yes, for example, the file share\extensions\render_barcode_datamatrix.py was originally committed as a new file at bzr rev 8905. That file is still present, and reported now as rev 8857.1.48
În data de Duminică 27 Decembrie 2009 06:35:51 pm ați scris:
2009/12/27 bulia byak <buliabyak@...400...>:
On Sun, Dec 27, 2009 at 8:35 AM, Arcadie M. Cracan <acracan@...400...>
wrote:
I don't really know how I've managed to do this (bzr still seems a bit complicated to me) but I think the current revision is an outdated one. Please revert my today (Dec 27) commits.
Judging by http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files, we also lost a lot of recent revisions :(
I think we didn't. The only thing that happened is that Arcadie apparently committed something that had a lot of obsolete files that somehow were regarded as locally changed. I am guessing that he didn't originally branch from lp:inkscape, because if he did, he would be warned about diverged branches; or that he went back to a previous revision by copying a different working tree over the branch.
Arcadie: to fix this, run "bzr uncommit", it should undo the changes from the fatal rev. 8859. If you want to undo more than the last commit, supply a revision to revert to with the -r parameter. Then describe what exactly did you do with your branch (I'm guessing that you started from an SVN working copy, so provide the details of how did you migrate to Bazaar).
I started with a local branch of lp:inkscape and then merged locally my gsoc work, and then pushed it back. What I did today was: - change some files - bzr commit - bzr merge - bzr push
I think the order of the commands should have been: - bzr merge - bzr commit - bzr push
Anyways, it seems strange to me that the revision number has changed and that all those subsequent commits became subrevisions.
Regards, Arcadie
W dniu 27 grudnia 2009 19:52 użytkownik Arcadie M. Cracan <acracan@...400...> napisał:
I started with a local branch of lp:inkscape and then merged locally my gsoc work, and then pushed it back. What I did today was:
- change some files
- bzr commit
- bzr merge
- bzr push
I think the order of the commands should have been:
- bzr merge
- bzr commit
- bzr push
That's right, the changes that a merge introduces are stored as local changes. They need to be committed before pushing. SVN also behaves that way.
I think the best way to work for people more comfortable with the earlier SVN way of doing things is to have a folder with a trunk checkout rather than a branch (e.g. all commits go directly to the remote repository), and only use it to merge work from your branches, apply patches and do quick fixes (like build fixes).
Anyways, it seems strange to me that the revision number has changed and that all those subsequent commits became subrevisions.
This post and its reply might explain what happened. https://lists.ubuntu.com/archives/bazaar/2007q3/031160.html
Regards, Krzysztof.
2009/12/27 Krzysztof Kosiński <tweenk.pl@...400...>:
I think the best way to work for people more comfortable with the earlier SVN way of doing things is to have a folder with a trunk checkout rather than a branch (e.g. all commits go directly to the remote repository), and only use it to merge work from your branches, apply patches and do quick fixes (like build fixes).
I second that. Please use bzr bind, as I'm doing, unless you have really good reasons not to. I wonder if we can somehow force this requirement automatically, to prevent further accidents like this?
În data de Duminică 27 Decembrie 2009 09:41:02 pm ați scris:
2009/12/27 Krzysztof Kosiński <tweenk.pl@...400...>:
I think the best way to work for people more comfortable with the earlier SVN way of doing things is to have a folder with a trunk checkout rather than a branch (e.g. all commits go directly to the remote repository), and only use it to merge work from your branches, apply patches and do quick fixes (like build fixes).
I second that. Please use bzr bind, as I'm doing, unless you have really good reasons not to. I wonder if we can somehow force this requirement automatically, to prevent further accidents like this?
I'm sorry for the trouble created... I saw JazzyNico made a new commit. Could anyone confirm that everything is in place. I've talked to tbnorth on irc and he said that a revert might not even be needed.
I did a 'bzr diff -r8857.1.61..8859' and it shows only my changes, so I guess the trunk is in a correct state.
Also he told me about a more appropriate workflow, having two branches, one to work in and the other with a clean up-to-date trunk copy. I also got more familiar with bazaar now. ^suv suggested to write a wiki page on pitfalls switching to bazaar after svn, I'll try to sum up my today's findings on that page.
Thank you for all the responses, Arcadie
On Dec 27, 2009, at 4:19 PM, Arcadie M. Cracan wrote:
I'm sorry for the trouble created... I saw JazzyNico made a new commit. Could anyone confirm that everything is in place. I've talked to tbnorth on irc and he said that a revert might not even be needed.
I did a 'bzr diff -r8857.1.61..8859' and it shows only my changes, so I guess the trunk is in a correct state.
Thanks.
I too was a bit concerned, but I had not yet pulled any changes. I waited, and saw that there was a "fixup" commit. A lot of files were listed, however when I did "bzr missing -v" only a few files showed up as needing updating.
And after I pulled, all of my recent changes seem intact. So we are good.
Also he told me about a more appropriate workflow, having two branches, one to work in and the other with a clean up-to-date trunk copy. I also got more familiar with bazaar now. ^suv suggested to write a wiki page on pitfalls switching to bazaar after svn, I'll try to sum up my today's findings on that page.
Thanks. Updating the Wiki is probably the most beneficial thing to do. Checking on the mailing list and chat room helped us prevent much breakage on the trunk, which is great. In the long run, though, the little bit of pain you hit can be used to make life much easier for others by just that little wiki magic you mentioned.
Thanks very much.
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.
Not quite. http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/ still does not show many revisions. Can this ever be restored?
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.
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.
De : bulia byak <buliabyak@...400...>
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.
Would a gatekeeper help? http://wiki.bazaar.canonical.com/Workflows#Decentralized%20with%20human%20ga...
Regards, -- Nicolas
On 28/12/09 17:47, bulia byak 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.
that's a limitation of the bazaar web interface at launchpad (log view doesn't show subrevisions).
all revisions are still there (with the original Revision IDs), but as sub-revisions of 8859.
use $ bzr log --levels=0 --verbose --show-ids to see a complete log.
more info in yesterdays irc log: http://inkscape.gristle.org/2009-12-27.txt
tbnorth's explanation: http://pastebin.com/m1187380f
example:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/8918 Revision ID: jon@...2301...
is now at
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/8857.1.61 Revision ID: jon@...2301...
~suv
2009/12/28 ~suv <suv-sf@...58...>:
all revisions are still there (with the original Revision IDs), but as sub-revisions of 8859.
Does this mean that I should never refer to a specific revision by its revision number (e.g., in bug reports) but only using its revision ID because the revision number could accidentally be changed in the future? That's somewhat annoying and makes me wonder why bzr uses revision numbers at all. So what is the suggested policy when referring to revisions?
Max
On Mon, 2009-12-28 at 18:47 +0100, Maximilian Albert wrote:
2009/12/28 ~suv <suv-sf@...58...>:
all revisions are still there (with the original Revision IDs), but as sub-revisions of 8859.
Does this mean that I should never refer to a specific revision by its revision number (e.g., in bug reports) but only using its revision ID because the revision number could accidentally be changed in the future? That's somewhat annoying and makes me wonder why bzr uses revision numbers at all. So what is the suggested policy when referring to revisions?
I would recommend using the user-friendly version numbers because they're so much simpler and 99% of the time they're going to stay the same.
If you want to be 100%, the revision IDs will always be correct, but they're kinda a pain to use.
--Ted
On Mon, Dec 28, 2009 at 1:16 PM, ~suv <suv-sf@...58...> wrote:
that's a limitation of the bazaar web interface at launchpad (log view doesn't show subrevisions).
all revisions are still there (with the original Revision IDs), but as sub-revisions of 8859.
OK, thanks for clarification, but two points still stand:
- Obviously bazaar web interface is seriously broken. This is bad because I tend to use a web interface mostly when I browse revisions. Admittedly it does not mean bzr itself is broken, but it's a point to consider when evaluating it overall.
- Even if revisions are not lost, I'm sure it must not be so easy to accidentally move them around into branches. Can this operation be restricted in some way?
On 12/28/2009 06:48 PM, bulia byak wrote:
- Obviously bazaar web interface is seriously broken. This is bad
because I tend to use a web interface mostly when I browse revisions. Admittedly it does not mean bzr itself is broken, but it's a point to consider when evaluating it overall.
Olive Bazaar Branch Manager does a nice job for browsing revisions. See the screenshot I just made
http://i48.tinypic.com/vrc9dx.jpg
You can immediately see what is going on with our nested revisions. Nevertheless, a good web interface is still a must IMHO.
I did notice though that Olive doesn't use the short revision numbers, but the full revision Id instead, e.g. "diederik_van_lierop_mail_at-sign_diedenrezi_dot_nl-20091228123156-c65f20zricbearlz".
Diederik
On Mon, Dec 28, 2009 at 1:16 PM, ~suv <suv-sf@...58...> wrote:
use $ bzr log --levels=0 --verbose --show-ids to see a complete log.
I captured all of this log into a file and looked at the end.
The rev 1 is dated 2006-01-16. This is clearly wrong, our first commits were in 2003!
Does it mean all of the revisions between 2003 and 2006 are lost? Or are we supposed to go back to SourceForge SVN for them? Is it guaranteed to remain available?
If these revisions are indeed lost, this is a much more serious problem. Unless it can be fixed somehow, I think we should reconsider migrating to bzr.
If you keep forgetting your past you're headed into nowhere.
2009/12/28 bulia byak <buliabyak@...400...>:
The rev 1 is dated 2006-01-16. This is clearly wrong, our first commits were in 2003!
The log for the first commit says that the SVN trunk has been moved to a different directory in the SVN repo in 2006, this might be the cause. It might be a problem with Launchpad's SVN import. I'm trying an alternative way of migration (use bzr-svn to do "bzr branch" directly from the SVN repository, then push the result to LP) and I'll let you know what is the result.
For the subrevisions issue, the fix is to never push - only direct commit from a checkout. (I wonder whether it's possible to enforce this in Launchpad.) https://lists.ubuntu.com/archives/bazaar/2007q3/031163.html
Regards, Krzysztof.
bzr branch from Sourceforge SVN using bzr-svn still gives me only 9017 revisions, and it failed for some reason while it was nearing the end. It might have been a network issue though.
Regards, Krzysztof
On Mon, 2009-12-28 at 14:11 -0400, bulia byak wrote:
On Mon, Dec 28, 2009 at 1:16 PM, ~suv <suv-sf@...58...> wrote:
use $ bzr log --levels=0 --verbose --show-ids to see a complete log.
I captured all of this log into a file and looked at the end.
The rev 1 is dated 2006-01-16. This is clearly wrong, our first commits were in 2003!
Does it mean all of the revisions between 2003 and 2006 are lost? Or are we supposed to go back to SourceForge SVN for them? Is it guaranteed to remain available?
They're still in SVN. Basically uniting these repositories was one of the issues I was having with the whole migration thing. I also would like to connect with the hydra branch for Sodipodi. Basically it comes down to the tools for doing this aren't good, and new ones will have to be written. :(
For the record, those revisions didn't show up in SVN log either. It handled the reshuffling of the root directories poorly as well :( (which is probably why none of the tools work with it, as they're based on the SVN libs)
This is on my TODO list, but not with a hugely high priority as I doubt many lines of code go back that far. I do think that it's important to merge these together though.
--Ted
On Tue, Dec 29, 2009 at 4:36 PM, Ted Gould <ted@...11...> wrote:
This is on my TODO list, but not with a hugely high priority as I doubt many lines of code go back that far. I do think that it's important to merge these together though.
Ideally I would love to see them merged, but if it turns out too difficult, at least we must have them accessible as backup somewhere, and linked from our web site.
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.
Regarding the subrevision issue, can someone confirm whether I'm understanding this correctly?
1. It is not possible to sensibly assign sequential revision numbers to all commits that result from a merge. Instead of this, Bazaar leaves the history of the branch that is being merged into alone, and groups all commits from the branch being merged as one "merge commit". 2. Arcadie merged trunk into his local branch, then pushed it to the trunk. All trunk commits that were made since he created his own branch got grouped into one "merge commit" (8857).
Is this correct?
Regards, Krzysztof
On Tue, 29 Dec 2009 00:09:29 +0100 Krzysztof Kosiński <tweenk.pl@...400...> wrote:
Regarding the subrevision issue, can someone confirm whether I'm understanding this correctly?
- It is not possible to sensibly assign sequential revision numbers
to all commits that result from a merge. Instead of this, Bazaar leaves the history of the branch that is being merged into alone, and groups all commits from the branch being merged as one "merge commit". 2. Arcadie merged trunk into his local branch, then pushed it to the trunk. All trunk commits that were made since he created his own branch got grouped into one "merge commit" (8857).
Is this correct?
Mostly. The commits that became sub-commits of Arcadie's commit weren't merged together into one mass change, they still exist as separate commits attributed to their original authors with only the changes made by those authors. But you need to look at the sub-commits or sub-revisions attached to Arcadie's commit to see them. Launchpad doesn't show them, there are already three duplicate bugs posted against launchpad for this, but other bzr utilities do, for example `bzr log --level=0 --verbose --show-ids` from the command line.
I chatted about this on #bzr for some time today, and their first response was so what, that's how it's supposed to work, followed by a second response explaining how to avoid having that happen again. For some reason not all my posts to this list show up, or at least I don't see them all. For example this post:
http://article.gmane.org/gmane.comp.graphics.inkscape.devel/32676
I haven't seen arrive on the list myself, it describes how to enforce merging of local branches into the trunk, rather than the other way around.
Anyway, there is a workflow which ensures sensible revision numbers, and that workflow can be enforced (see the post or maybe you saw the email on this list already).
Cheers -Terry
Regards, Krzysztof
This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Dec 28, 2009 at 11:37 PM, Terry Brown <terry_n_brown@...36...> wrote:
http://article.gmane.org/gmane.comp.graphics.inkscape.devel/32676
I haven't seen arrive on the list myself, it describes how to enforce merging of local branches into the trunk, rather than the other way around.
Thanks! Dear bzr admins, could you please make the change as described there?
On Tue, 2009-12-29 at 00:09 +0100, Krzysztof Kosiński wrote:
Regarding the subrevision issue, can someone confirm whether I'm understanding this correctly?
- It is not possible to sensibly assign sequential revision numbers
to all commits that result from a merge. Instead of this, Bazaar leaves the history of the branch that is being merged into alone, and groups all commits from the branch being merged as one "merge commit".
Basically yes. But more completely, the revision numbers (like r2443) are calculated locally in the user facing code. In Bazaar's core they don't really exist.
- Arcadie merged trunk into his local branch, then pushed it to the
trunk. All trunk commits that were made since he created his own branch got grouped into one "merge commit" (8857).
Yes, I would guess that it went something like this.
$ cd trunk $ bzr push error: branches have diverged $ bzr merge ; bzr commit $ bzr push
So the merge parent for the commit in this listing was the old head for everyone else.
--Ted
On Dec 28, 2009, at 8:47 AM, bulia byak wrote:
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.
Actually, we and bzr are both good.
Those "subrevisions" are there, and all your independent changes are still listed individually.
The problem is that the web interface that Launchpad is running does not show the subrevisions on a "main" trunk. It only shows the last shared revision of two branches, and then the revision at which those two branches recombine.
I think this link finally shows the details that are now suppressed on the main view: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/8857.1.61
There are a few bugs recorded against Launchpad in regards to this. I sent Ted a list. I think they *really* need to bump up priority on those.
On Mon, Dec 28, 2009 at 7:28 PM, bulia byak 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.
Not quite. http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/ still does not show many revisions. Can this ever be restored?
I happen to have a clean 8912 revision checkout at home. Do you want it?
Alexandre
2009/12/28 Arcadie M. Cracan <acracan@...400...>:
^suv suggested to write a wiki page on pitfalls switching to bazaar after svn, I'll try to sum up my today's findings on that page.
See if you can integrate it with this existing page. http://wiki.inkscape.org/wiki/index.php/Working_with_Bazaar
Regards, Krzysztof
On Sun, 2009-12-27 at 11:43 -0400, bulia byak wrote:
On Sun, Dec 27, 2009 at 8:35 AM, Arcadie M. Cracan <acracan@...400...> wrote:
I don't really know how I've managed to do this (bzr still seems a bit complicated to me) but I think the current revision is an outdated one. Please revert my today (Dec 27) commits.
Judging by http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files, we also lost a lot of recent revisions :(
Ted, can you please help us out? I'm having a deja vu :)
Yup. Fixed. Actually a similar problem to before, but now it is fixable :) I replayed some revisions so that they'd all appear in series, but that means they're committed by me. The originals are still in the history. This was only 4 revisions, so I thought that was much better than the way things were :)
What I like about SVN is that there, a revision is a revision. Once it's there, no one can delete it from history, accidentally or not. Isn't Bazaar operating on the same principle?
Yes, but what is immutable is the UUID of the version number, not the user friendly one. I love the userfriendly version numbers in Bazaar, but they aren't as solid as I may like :-/
What Bazaar is checking when you push to the branch is that you have a revision that has the current head revision as a parent. What it doesn't check is where that version is located in the tree. It could be on a branch (as in this case) and it doesn't check for that. So you can't delete data, but you can effectively change the layout of the tree.
Sorry I wasn't up on my e-mail this weekend.
--Ted
On Tue, 29 Dec 2009 14:02:52 -0600 Ted Gould <ted@...11...> wrote:
What it doesn't check is where that version is located in the tree. It could be on a branch (as in this case) and it doesn't check for that. So you can't delete data, but you can effectively change the layout of the tree.
Hi Ted, what do you think of
python -c 'import bzrlib.branch as b; b.Branch.open("bzr+ssh://bazaar.launchpad.net/path/to/branch").set_append_revisions_only(True)'
which I got from the people in #bzr? Supposedly that would reject pushes which would result in changes to the log, other than extensions of the log, of course.
I tried it locally with `bzr init --append-revisions-only myTest` and it seemed to work as advertised, the above of course is the code to set it on an existing repo on launchpad. On an existing local repo. you could edit .bzr/branch/branch.conf, on launchpad that's harder, although sftp might work, the #bzr folks said.
I know what happened will happen again and again if this isn't set.
Cheers -Terry
On Tue, 2009-12-29 at 14:21 -0600, Terry Brown wrote:
On Tue, 29 Dec 2009 14:02:52 -0600 Ted Gould <ted@...11...> wrote:
What it doesn't check is where that version is located in the tree. It could be on a branch (as in this case) and it doesn't check for that. So you can't delete data, but you can effectively change the layout of the tree.
Hi Ted, what do you think of
python -c 'import bzrlib.branch as b; b.Branch.open("bzr+ssh://bazaar.launchpad.net/path/to/branch").set_append_revisions_only(True)'
which I got from the people in #bzr? Supposedly that would reject pushes which would result in changes to the log, other than extensions of the log, of course.
Seems good to me. Sorry, I'm catching up on all the e-mail for this and didn't get a chance to reply to your original yet :)
I ran the command (anyone with access to the repository can) and so now it should be set for lp:inkscape.
--Ted
participants (12)
-
Alexandre Prokoudine -
Alvin Penner -
Arcadie M. Cracan -
bulia byak -
Diederik van Lierop -
Jon Cruz -
Krzysztof Kosiński -
Maximilian Albert -
Nicolas Dufour -
Ted Gould -
Terry Brown -
~suv