[00:48] <stuartpb> What's the easiest way to install Bazaar on Ubuntu with feature parity to the default Windows installer (shell integration, bzr-svn)?
[00:53] <Meths> aptitude install bzr-svn bzrtools  <-- You probably want something like that to pull in all you want.  Not sure about how you define shell integration and how it meets your expectations though.
[00:53] <Meths> Do  'aptitude search bzr' and see what you need from the descriptions.
[00:54] <stuartpb> bzr-gtk
[00:54] <stuartpb> and that'll put stuff on the application menu and all?
[00:55] <mzz> I do use ubuntu but I have no clue about "shell integration", sorry.
[00:55] <Meths> Only if you install a gui for bzr otherwise you run bzr commands from a command line - pick a term of choice
[00:56] <stuartpb> see, I installed Bazaar with Ubuntu Software manager so I have bzr and bzrtols
[00:56] <mzz> bzrtools is in Recommends, so just installing bzr should pull it in by default. Might want to install bzr-svn and/or bzr-gtk too, yes (they're in Suggests)
[00:56] <mzz> I'm not much of a gui person, so I don't know how software center represents Suggests)
[00:56] <Meths> recommends is not depends, does not get pulled in
[00:57] <mzz> recommends is not depends, but *does* get pulled in by default since, erm, checking relnotes...
[00:57] <mzz> ubuntu 8.10
[00:57] <stuartpb> is there a way to get bazaar integrated with thunar?
[00:58] <Meths> oh, weird. Ta for info though.
[00:58] <stuartpb> and does bzr-gtk come with bazaar explorer
[00:58] <mzz> the most convenient way to find out may be to just install it.
[00:58] <mzz> (if you don't like it you can always uninstall it again)
[00:58] <stuartpb> yeah, it's doing it now
[00:59] <stuartpb> but will it go under the applications menu if it gets installed?
[00:59] <mzz> I have no idea, I haven't used bzr-gtk and an Applications menu at the same time.
[01:00] <mzz> I get the feeling if one of the people currently active knew they would've told you already. It's probably faster to install it and find out.
[01:00] <mzz> it's possible it integrates into the file manager without showing up as a standalone app in the applications menu.
[01:01] <mzz> (do you actually mean "I already installed it and it's not showing up on my applications menu. Should it?")
[01:01] <stuartpb> "bazaar notification" has been added to the programming submenu
[01:25] <stuartpb> how do I get Bazaar stuff on my context menu?
[01:25] <bob2> stuartpb: in what? nautilus?
[01:26] <stuartpb> yeah
[02:02] <arjenAU> ello bzr gurus
[02:02] <elroboto> helo
[02:02] <arjenAU> how do I upgrade the repo/branch format on a lp branch.
[02:03] <mzz> stuartpb: /usr/share/doc/bzr-gtk/README.Debian claims it is currently broken
[02:03] <mzz> stuartpb: (although that makes me wonder why the package still Recommends python-nautilus, bah)
[02:04] <mzz> arjenAU: I don't know if it's actually the best way but there's http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html#migrating-branches-on-launchpad
[02:04] <arjenAU> mzz: cheers
[02:43] <arjenAU> mzz: seems to have worked. groovy.
[02:44] <arjenAU> also observing the filesystem where lp holds the branches is about 8 minutes behind real time. probably borked ntp
[10:46] <bialix> fullermd: thanks for you mails in that thread
[10:58] <fullermd> bialix: I do go on, don't I   :)
[10:58] <bialix> я не понимаю
[10:59] <bialix> fullermd: now I feel like a mindless tree. I don;t understand your joke
[11:00]  * bialix hides away
[11:01] <fullermd> It's not really a joke, so much as a rueful reflection.
[11:01] <fullermd> Someday, I hope to learn how to write a SHORT email.
[11:01] <bialix> no, your e-mail was just right in size and content
[11:01] <bialix> right for me
[11:02] <bialix> you talk my thoughts
[11:02] <bialix> I was sad to hear from luks couple of years ago almost the same: it's almost impossible to get patches in
[11:03] <fullermd> I hate bringing it up, 'cuz what can you do?
[11:04] <fullermd> I mean, the answer can only be "We're doing the best we can, but there are only so many hours in the day", which doesn't solve the problem but is perfectly true.
[11:04] <fullermd> It's just a recipe for frustration on BOTH sides   :(
[11:04] <bialix> right
[11:04] <bialix> qbzr is more appealing for me therefore
[11:05] <bialix> we don't need to write zillion tests for 5-lines fix
[11:06] <bialix> thanks anyway
[11:06] <fullermd> I'll take any excuse to write a 10,000 word essay   8-}
[11:07] <bialix> :-)\
[11:07] <bialix> :-)
[13:41] <sjamaan> Is there an easy way to quickly go to a particular revision? (like "svn up -r xyz" in subversion)
[13:43] <LarstiQ> go in what sense? `bzr revert -r revspec` most likely
[13:44] <LarstiQ> or `bzr cat` for a single file at a revision, or `bzr export` for subtrees
[13:44] <sjamaan> bzr revert won't commit anything, will it?
[13:44] <LarstiQ> correct
[13:44] <sjamaan> alright, thanks
[13:45] <LarstiQ> (but if you run `bzr commit` directly after, you'll commit a new revision with the same state as the one you reverted to)
[13:45] <sjamaan> Understood
[13:45] <LarstiQ> which is different from svn, svn won't allow you to commit in that position
[13:45] <sjamaan> Exactly
[13:46] <LarstiQ> which I find bloody annoying :)
[13:46] <sjamaan> You could do a reverse merge and commit that with svn, but you can't update to an old revision and commit that
[13:46]  * LarstiQ nods at sjamaan 
[13:46] <sjamaan> svn merge -r HEAD:oldrev .
[13:46] <sjamaan> That's about the same as bzr revert -r oldrev, as I understand it
[13:46] <LarstiQ> does svn merge do treeshapes?
[13:47] <sjamaan> Excuse my ignorance, but what are treeshapes?
[13:47] <LarstiQ> sjamaan: move, add, delete
[13:47] <sjamaan> It does
[13:47] <LarstiQ> ok
[13:47] <LarstiQ> then yeah, pretty similar
[13:47] <Kinnison> presumably you could do something like bzr checkout --lightweight -r blahfoo . ../here-at-blahfoo
[13:48] <sjamaan> Ah, I suppose that would work too
[13:48] <sjamaan> But it's easier to revert, since I just wanted to look at something in the old state
[13:48] <sjamaan> Making a full new checkout is a bit too heavyweight for that
[13:49] <Kinnison> if you just want a given file, then bzr cat may be easier
[13:49] <sjamaan> mebbe
[13:49]  * LarstiQ frequently uses revert for that purpose though
[13:50] <SamB_XP> does qlog give you that? I forget...
[13:50] <sjamaan> I was wondering about something: If you do bzr unbind, then make some changes and commit those, then bind again and run bzr update, is it supposed to clobber all your local revisions without any warning?
[13:51] <sjamaan> (note I didn't first push the changes)
[13:51] <SamB_XP> sjamaan: it is undesirable for it to do so
[13:51] <SamB_XP> why, did it?
[13:51] <sjamaan> SamB_XP: When I tried, it did so
[13:51] <SamB_XP> oh :-(
[13:51] <SamB_XP> well, I believe they are still in there somewhere
[13:51] <LarstiQ> sjamaan: afaik it pivots them to be merged
[13:51] <sjamaan> How can I find them?
[13:52] <SamB_XP> LarstiQ: what do you mean "to be merged"?
[13:52] <LarstiQ> SamB_XP: pending merges
[13:52] <LarstiQ> sjamaan: doesn't `bzr st` list them?
[13:52] <sjamaan> nope
[13:53] <SamB_XP> what's that command to find loose heads in the repository ?
[13:53] <SamB_XP> or, well, any heads I guess
[13:53] <sjamaan> I don't know, I'm a newbie :)
[13:53] <LarstiQ> SamB_XP: `bzr heads`
[13:53] <LarstiQ> from bzrtools
[13:54]  * SamB_XP wonders how to get Windows' file copy progress dialog to give details like transfer size, size transferred so far, and kB/s for the last few seconds ...
[13:55] <SamB_XP> sjamaan: there you go
[13:55] <SamB_XP> run "bzr heads"
[13:55] <sjamaan> thanks
[13:55] <sjamaan> I guess I need to install those tools then
[13:55] <SamB_XP> you don't have bzrtools installed ?
[13:55] <sjamaan> Not yet
[13:56]  * SamB_XP is still confused about why those aren't part of bzr
[15:42] <maxb> I've just filed a merge proposal for qbzr - is that sufficient or do I need to email someone?
[15:48] <nyu> hi folks
[15:48] <Kamping_Kaiser> allo
[15:52] <phcoder> Hello, all. Can old bzr+ssh daemon together with new clients some of them maybe comitting by sftp lead to data corruption on server?
[15:53] <nyu> and if it can, can we prevent it from bothering us by using 2a repo format?
[15:53] <Kamping_Kaiser> I've not heard of that, but I'll stand by and wait for the bzr-hackers to comment
[15:54] <phcoder> Second question: on server repo we have different kinds of corruption. I managed to fix most of them with bzr reconcile and some hacks in bzr code to correct corruption but 4 commits still have incorrect SHA-1. Any way to write their new digest or delete them altogether?
[15:57] <Kamping_Kaiser> phcoder: perhaps `bzr push --force` (assuming you know your only overwriting 'corrupt' files)
[15:58] <phcoder> Kamping_Kaiser: I'm trying to recover server copy locally. Moreover corruption in repo may stay even if all corrupted branches are deleted
[15:59] <Kamping_Kaiser> phcoder: I'm going to retreat to the sideline and hope lifeless or some other bzr hacker wakes up and helps you out
[15:59] <Kamping_Kaiser> hm... lifeless sorry about the ping... 3am is a bad momentfor it ...
[16:03] <fullermd> If they've got incorrect SHA-1, you probably don't WANT to rewrite it.  It's way more likely that the data is corrupt than that the hash is....
[16:06] <phcoder> fullermd: If repo was already damaged when it was comitted hash could be miscalculated. I will check these commits manually afterwards. Alternative is to delete them but simply deleting refering directories didn't help
[16:07] <nyu> phcoder: checking corrupt commits manually isn't very reassuring wrt preventing the problem from happening again :-/
[16:08] <fullermd> I'm not sure that follows at all.  The hash calculated at commit time should always match the data committed at commit time.
[16:09] <phcoder> perhaps savannah is running out of free space or has HD failure
[16:09] <phcoder> are svn and bzr on same server?
[16:09] <nyu> phcoder: they have free space
[16:10] <nyu> can be retrieved with sshfs and df
[16:10] <nyu> doesn't seem to be the same server
[16:10] <nyu> different IPs at least
[16:13] <phcoder> bzr check reveals more potential problems. Looks like our repo is in serious trouble
[16:13] <nyu> what sort of problems?
[16:14] <phcoder> If I can at least fast-export in would be perhaps enough. Missing keys. I'll redecompress the backup and retry
[16:15] <Kamping_Kaiser> phcoder: at the risk of (re)sticking my nose in - can you give a bit more background for the problem your experiancing?
[16:17] <phcoder> We're trying to migrate to bzr. Currently we use it as a mirror of svn and to hold people and experimental branches. Every time we import all branches everything seems fine but breaks after about one week
[16:19] <Kamping_Kaiser> hm. I can't bzr svn-import today sadly. I can tomorrow, but that probably won't help your testing
[16:20] <nyu> svn-import?
[16:20] <nyu> we were using bzr-svn
[16:20] <phcoder> nyu: bzr svn-import I suppose imports all branches whereas bzr branch only one
[16:21] <Kamping_Kaiser> nyu: 'bzr help svn-import
[16:21] <Kamping_Kaiser> Purpose: Convert a Subversion repository to a Bazaar repository.
[16:21] <phcoder> but both are part of bzr-svn
[16:21] <Kamping_Kaiser> '
[16:21] <nyu> ah I see
[16:21] <phcoder> nyu: how do you update our bzr-svn mirror?
[16:21] <Kamping_Kaiser> I don't have a bzr-svn command
[16:22] <phcoder> Kamping_Kaiser: bzr-svn is a plugin, not a command
[16:22] <Kamping_Kaiser> phcoder: ah right. yes, we're on the sam epage then
[16:23] <phcoder> it provides bzr branch and bzr svn-import
[16:23] <Kamping_Kaiser> i should really backport bzr{-svn,-git} from sid atsome point
[16:24] <phcoder> Kamping_Kaiser++
[16:25] <nyu> phcoder: I bzr pull; bzr push
[16:25] <Kamping_Kaiser> I've been putting it off since it looks like it'll involve dependancies, but bzr-git would be helpful to me
[16:30] <phcoder> Kamping_Kaiser: KeyError: ('2063@d0de0278-0dc1-4c01-8a07-af38b3205e46:trunk%2Fgrub2:commands%2Fmemrw.c', 'svn-v3-single1-dHJ1bmsvZ3J1YjI.:d0de0278-0dc1-4c01-8a07-af38b3205e46:trunk%2Fgrub2:2172')
[16:31] <Kamping_Kaiser> phcoder: can you link me to the repo? I'll start to track it too
[16:31] <Kamping_Kaiser> {bzr,svn} info -v
[16:31] <Kamping_Kaiser> ftr
[16:32] <phcoder> Kamping_Kaiser: svn.sv.gnu.org/grub/trunk/grub2
[16:32] <Kamping_Kaiser> and shuld i branch or co?
[16:32] <phcoder> Corrupted one is here: http://people.debian.org/~rmh/grub/bzr-backup2/
[16:33] <phcoder> Kamping_Kaiser: branch
[16:34] <phcoder> nyu: what if we import through git avoiding svn but still getting the same IDs this way?
[16:35] <nyu> phcoder: what are those IDs for?
[16:35] <phcoder> nyu: merging
[16:36] <nyu> phcoder: it feels much safer to discard them
[16:36] <phcoder> ok. What about using stock git-svn then and get different IDs?
[16:36] <nyu> I mean, it feels much safer to operate on the higher layer above the tools that grok their own formats
[16:37] <phcoder> nyu: what do you mean?
[16:37] <nyu> have you read my script?
[16:38] <nyu> it's very small and simple
[16:38] <nyu> and from bzr POV it's like the svn never existed
[16:38] <phcoder> nyu: not yet. As you know I work in another direction of possible recovery. What about fast-import/fast-export?
[16:39] <nyu> what do you want to archieve?
[16:40] <nyu> if this is an issue on safety, I trust my code a lot more than any other approach
[16:40] <phcoder> nyu: fast-export creates a text file which is actually just a chain of patches
[16:41] <nyu> how does bzr import that?
[16:41] <phcoder> bzr fast-import <file>
[16:42] <nyu> uhm doesn't have this option, is that a plugin?
[16:42] <phcoder> it's in bzr-fastimport package
[16:43] <nyu> ok let me play a bit with that
[16:47] <lizard_r> Hi, I made a little program/lib with a local reposity[18 rev.] which I would like to upload to Sourceforge. I just enabled the bazaar feature. I'm on windows and I'm not sure what I made wrong, output: http://lizard.pastebin.com/m6e4430a5 - does someone know what is wrong?
[16:47] <wade> Hi all, Any idea how I can troubleshoot a hang when issuing bzr pull via sftp?  I successfully pushed this branch, but when I try to pull it back down as a test, bzr just hangs after I successfully enter my password
[16:49] <wade> using the latest stable versions, btw
[16:49] <Kamping_Kaiser> wade: tried running with -v to get extra info?
[16:49] <wade> yep..hangs too - no extra info
[16:49] <Kamping_Kaiser> lizard_r: perhaps you should look on the bzr site abougt the rich formats, sf.net may be using an older veersion
[16:57] <fullermd> Last I vaguely checked, SF was using something like 1.10.
[16:57] <fullermd> So it's RR capable (though not 2a capable), but their scripts probably don't make a RR repo.  So you'd probably have to make the repo manually (I think you can do that on SF)
[17:00] <lizard_r> yes, they use 1.10 I just checked - but what you just said is far over my head :-)
[17:00] <wade> if anyone has any other ideas on how to troubleshoot this bzr pull hang, I'm all ears
[17:16] <wade> oh crap...never mind....I'm an idiot - I should be running bzr branch, not bzr pull, since I'm trying to pull a new copy - however, bzr should probably give an error message, not just hang - I'll file a bug
[17:17] <wade> er, branch a new copy I should say
[17:17] <fullermd> It certainly shouldn't; it should exit right away with 'Not a branch'
[17:18] <fullermd> (by 'should' I mean "certainly does now, pretty sure always has)
[17:18] <wade> right...I've seen that before...hmm..let me try something
[17:18] <fullermd> So I suspect you WERE in a branch...
[17:20] <wade> hmm...you might be right - when I made sure I was in the non-branch dir I wanted to be in, I did get the "not a branch" error message
[17:20] <wade> so the question is - why did it just hang when I was in a branch, and shouldn't it have given some error?
[17:21] <fullermd> I doubt it was really hung.
[17:22] <fullermd> It seems more likely it was doing something that took a long-arse time.
[17:23] <wade> hmmm...I'll play with it and see if I can replicate - the branch in question was 3 test files with 1 line each so I'd be surprised about a long-arse operation :)
[20:38] <thumper> an item for the sprint next week
[20:38] <thumper> can we plz add a command to push to not stack?
[20:38] <thumper> also
[20:39] <thumper> if it does try to stack but fails due to different format types
[20:39] <thumper> can we retry without stacking?
[20:39] <thumper> stacking is decided by the client, but the server suggests
[20:39] <thumper> right now we don't have a way to tell the client "no, plz don't stack"
[20:53] <lifeless> thumper: file bugs please
[20:53] <thumper> lifeless: I think there is at least one
[20:53] <lifeless> thumper: the sprint is about prep for the next cycle, not doing individual bugs, they are easily done solo, not a good use of face-time.
[20:54] <thumper> lifeless: remind me during the open spaces time
[20:54] <lifeless> thumper: I'm leaving before then.
[20:54] <thumper> lifeless: yeah, fair enough
[20:54] <thumper> lifeless: ok
[20:54] <lifeless> thumper: I will try to remind you, can't promise anything.
[20:57] <sjohannes> quick question, is there a way to set bzr's executable bit for a file in win32?
[21:05] <lifeless> you can using python
[21:05] <lifeless> but I don't think we have a command to do it
[21:09] <sjohannes> lifeless: any pointers for doing this? i've never worked with bzrlib before, so any help is appreciated
[21:12] <lifeless> sjohannes: the test suite does it a few times, in the exec bit support
[21:12] <lifeless> I'll dig up a reference in ~ 20 minutes for you
[21:12] <sjohannes> lifeless: ok, thanks a lot
[21:27] <bialix> maxb: ping
[21:29] <bialix> sjohannes: pluing x-bit
[21:30] <sjohannes> bialix: pardon?
[21:30] <bialix> you need plugin x-bit
[21:31] <bialix> to change x-bit on win32
[21:31] <bialix> you wrote: "sjohannes	quick question, is there a way to set bzr's executable bit for a file in win32?" right?
[21:31] <bialix> sjohannes: ^
[21:32] <sjohannes> bialix: ah i see. just didn't understand the "pluing" bit :)
[21:32] <bialix> sory, typo
[21:32] <sjohannes> bialix: i'll have a look, thanks
[21:42] <sjohannes> bialix, lifeless: the x-bit plugin works nicely. thanks for your help
[21:42] <bialix> glad to hear
[21:43] <maxb> bialix: hi
[21:43] <bialix> maxb: hello
[21:43] <bialix> maxb: I'm working on inclusion of your patch for &nbsp; in qlog
[21:44] <bialix> I've changed news entry as following: "Preserving leading whitespace in the lines of the log message."
[21:44] <bialix> maxb: is it ok for you?
[21:44] <bialix> is it correct English?
[21:46] <maxb> Nearly - s/Preserving/Preserve/
[21:46] <bialix> ok
[21:48] <bialix> maxb: thank you for the fix, merged now
[21:49] <maxb> thanks very much for the quick response :-)
[21:50] <bialix> :-/
[21:50] <bialix> today there was said too much about speed of response
[21:51] <bialix> pushed to trunk
[21:53] <nyu> I have a /trunk/{grub,grub2} SVN repository layout.  I'm trying to convert it to Bazaar using "bzr fast-export-from-svn",
[21:53] <nyu> I have a /trunk/{grub,grub2} SVN repository layout.  I'm trying to convert it to Bazaar using "bzr fast-export-from-svn", but in the output /trunk is a single branch
[21:53] <nyu> and I'd rather make two branches out of it
[21:54] <bialix> nyu: does svn-import does not work for you?
[21:55] <nyu> bialix: is that bzr-svn?
[21:55] <bialix> yep
[21:55] <phcoder> bialix: we have repo corruption in bzr and bzr-svn is a possible reason
[21:55] <nyu> bialix: sorry, no.  we've been trying that for 2 weeks and it corrupted out repository twice
[21:55] <bialix> oh, sorry
[21:56] <nyu> I want an approach that is as little intrusive as possible, and fast-import patchsets seem like a good way
[21:56] <nyu> except I don't know how to split the branches
[21:56] <nyu> can it be done in bzr afterwards?
[21:57] <nyu> d'oh, there's a split command
[21:57] <bialix> nyu: there is fast-import-filter
[21:57] <bialix> split is not exactly what you want
[21:58] <bialix> nyu: did you try --trunk-path option?
[21:58] <bialix> see help for fast-export-from-svn
[21:59] <nyu> bialix: it didn't work
[21:59] <bialix> :-/
[21:59] <bialix> file a bug please
[21:59] <nyu> I think it doesn't like that the new "trunk" doesn't exist throughrough all repository life
[21:59] <bialix> and try fast-import-filter
[21:59] <nyu> is that still a bug?
[22:00] <bialix> I dunno, I was unable to run fast-export-from-svn on windows
[22:08] <nyu> bialix: does fast-import-filter require a SOURCE argument?  the examples in help page don't have it, but it refuses to run without it
[22:08] <nyu> (bug filed)
[22:09] <bialix> yes, require
[22:10] <bialix> there is typo with help
[22:11] <bialix> example should be: front-end | bzr fast-import-filter -i lib/xxx/ - > xxx.fi
[22:11] <nyu> and I take it that SOURCE is the fast-svn-export dump?
[22:11] <bialix> yes
[22:11] <nyu> strange.  then I don't understand why do I get this:
[22:11] <nyu> bzr: ERROR: exceptions.TypeError: cannot concatenate 'str' and 'NoneType' objects
[22:12] <bialix> do you have latest version from trunk?
[22:12] <bialix> pastebin full traceback
[22:12] <bialix> I recall this bug was fixed recently
[22:13] <nyu> bialix: no, 2.0.1
[22:13] <bialix> version of fastimport plugin I mean
[22:13] <nyu> http://pastebin.com/m42df5aa8
[22:14] <nyu> bialix: 0.9.0~bzr243
[22:15] <nyu> not sure if that 243 is meaningful or debian-made
[22:15] <bialix> looks like revno
[22:15] <bialix> the latest revno of fastimport trunk is 260
[22:17] <bialix> can you just do: cd ~/.bazaar/plugins; bzr get lp:bzr-fastimport fastimport
[22:17] <bialix> and then try fi-filter again
[22:19] <nyu> sure
[22:20] <nyu> bzr fast-export-from-svn svn-repo - | bzr fast-import-filter -i /trunk/grub2 - | bzr fast-import - bzr-repo
[22:20] <nyu> does this look sane?
[22:21] <nyu> uhm still same error
[22:21] <nyu> maybe I should use bzr split?
[22:21] <bialix> bzr split won't filter out the history of other branch
[22:21] <bialix> if you can live with that than use
[22:22] <bialix> and file bug please
[22:22] <bialix> about NoneType
[22:23] <nyu> bialix: maybe I can debug this, but I would need some direction
[22:23] <bialix> ok, set env variable BZR_PDB=1
[22:23] <bialix> and run again
[22:23] <nyu> ok
[22:23] <lifeless> sjohannes: if bialix's plugin works for you it will be _much_ simpler than the code wI was digging up
[22:24] <bialix> nyu: wait, why you're using -i /trunk/grub2 ?
[22:24] <sjohannes> lifeless: well, thank goodness it works :-P
[22:24] <bialix> nyu: why not just grub2?
[22:24] <nyu> bialix: I don't know
[22:24] <nyu> I want /trunk/grub2 to become a branch
[22:25] <bialix> if you don't use  filter and do fast-import what you have?
[22:25] <nyu> I have a shared-repo with only one branch in it, called "trunk"
[22:25] <nyu> which has two directories, grub and grub2
[22:25] <bialix> and what's inside?
[22:25] <nyu> the source trees
[22:25] <bialix> ok, filter operates in the terms of these paths
[22:26] <bialix> you should run filter with -i grub2
[22:26] <nyu> oh, ok
[22:26] <nyu> same problem.  actually, filter is supposed to work without -i or -x too, right?
[22:26] <nyu> I mean, as a no-op
[22:28] <bialix> I'm not sure, I'm not author, but used it successfully in the past
[22:28] <bialix> try to run fast-import-info instead of filter just to check if strea is correct
[22:28] <bialix> try to run fast-import-info instead of filter just to check if stream is correct
[22:30] <bialix> if you know the format of git-fastimport stream you can save it to disk as export-from-svn output and check if there all ":" marks are correct
[22:30] <nyu> it looks sane
[22:30] <nyu> what's a parent?
[22:30] <nyu> as in, parent branch?
[22:30] <bialix> nyu: btw, you can try to fast-export of imported bzr trunk and try to filter it instead of svn output
[22:31] <nyu> oh, but wouldn't I get the same thing?
[22:31] <bialix> sometimes -- no
[22:31] <bialix> parents -- it seems revision parents
[22:32] <bialix> merged revisions etc
[22:33] <nyu> self.parents[":" + cmd.mark] = parents
[22:33] <nyu> is ":" + cmd.mark an array index?
[22:33] <bialix> yes
[22:33] <bialix> and error talk about cmd.mark is None
[22:33] <bialix> but it supposed to be a string
[22:33] <bialix> you can try to change this line this way:
[22:34] <bialix> self.parents[":" + (cmd.mark or "")] = parents
[22:34] <nyu> cmd is some sort of struct passed from commit_handler() right?
[22:34] <bialix> passed to IMO
[22:34] <nyu> I thought of that, but it seems to be hiding the real bug?
[22:34] <bialix> can you print cmd
[22:34] <bialix> ?
[22:34] <nyu> I mean, is it acceptable that cmd.mark is empty?
[22:35] <bialix> I can't say for sure
[22:35] <nyu> 1 min
[22:36] <nyu> bialix: http://pastebin.com/mf82ea86
[22:36] <nyu> uhm... there's an empty line
[22:38] <bialix> you really can compare the output of fast-export from big bzr branch with grub1 and grub2
[22:39] <nyu> ok, I'll try that
[22:41] <bialix> nyu: I'm looking at parser.py: ImportParser
[22:41] <bialix> there is method _get_mark_if_any
[22:42] <bialix> result of this method then passed as cmd.mark
[22:42] <bialix> sometimes this method returns None
[22:42] <nyu> oh, interesting
[22:42] <nyu> what does it mean when it returns None?
[22:42] <nyu> is that supposed to be tollerable?
[22:43] <bialix> does your project is open-source?
[22:43] <nyu> bialix: the raw repo is public, rsync -avzHS rsync://svn.savannah.gnu.org/svn/grub/ /tmp/grub.repo/
[22:44] <bialix> how's big fi stream after export-from-svn?
[22:44] <bialix> after gzip/zip?
[22:44] <bialix> I can't rsync right now
[22:44] <bialix> and I can't run fast-export-from-svn either
[22:45] <nyu> hold on, compressing
[22:46] <bialix> ok, looking at the code if get_mark_any returns None it push the processed line back to stream
[22:47] <bialix> IMO it means it want to process it later or somehow different
[22:49] <nyu> bialix: what code portion are you looking at?
[22:49] <bialix> parser.py
[22:49] <nyu> btw, gzip'ed repo is 237 MiB
[22:49] <bialix> ImportParser
[22:49] <bialix> it's a bit big :-/
[22:50] <bialix> I can download it only tomorrow from work
[22:51] <nyu> I guess you meant _get_mark_if_any() ?
[22:51] <bialix> yep
[22:51] <bialix> but strange thing is in command.py
[22:51] <bialix> but strange thing is in commands.py
[22:52] <bialix> CommitCommand
[22:52] <bialix> there is code that checks cmd.mark for None
[22:53] <nyu> oh, maybe filter_processor.py should do a similar check?
[22:54] <bialix> wait
[22:54] <bialix> in your patse http://pastebin.com/mf82ea86 there is line commit, after which should be a line with mark
[22:55] <bialix> if I do fast-export for my testing repo I see line with mark
[22:55] <bialix> you have nothing
[22:56] <bialix> I really think that fast-export command over bzr branch will produce more "correct" stream
[22:56] <nyu> ah yes, I was going to test that
[23:00] <nyu> bialix: btw, lzma file is only 17 MiB
[23:00] <bialix> this size is much better
[23:00] <nyu> (tarball from svn repo)
[23:01] <nyu> ah wait, you said you don't have fast-export-svn handy?
[23:01] <bialix> no
[23:07] <bialix> nyu: just FYI: there is 2 forms of git-fastimport streams
[23:07] <bialix> one form has inline blobs
[23:07] <bialix> second one is not
[23:08] <bialix> fast-import plugin prefer to work with inline
[23:08] <nyu> bialix: it seems that export from bzr works
[23:08] <bialix> looking at your paste it seems you have the latter form
[23:08] <nyu> at least, fast-import-filter won't complain
[23:08] <bialix> good
[23:09] <nyu> I think I can work this way.  I'll add the missing information to the bug report
[23:10] <bialix> nyu: there is also fast-import-info command
[23:10] <bialix> according to help this command can be used as elper
[23:10] <bialix> according to help this command can be used as helper
[23:11] <bialix> but it seems filter does not use this additional info
[23:12] <bialix> glad you managed it to finish
[23:12] <nyu> excellent, fast-import-filter worked
[23:12] <nyu> bialix: I put the info in https://bugs.launchpad.net/bzr/+bug/477886
[23:12] <nyu> thanks for your assistance
[23:12] <bialix> thanks for filing a bug
[23:49] <jam> lifeless: I have a question about subunit. Namely, is there a way to get a nice progress bar out of "bzr selftest --subunit" ?
[23:49] <jam> As far as I can tell, pqm must have been running a custom filter on it
[23:50] <jam> ah, maybe "subunit2pyunit --progress" ?
[23:51] <jam> that is almost spooky to see the output :)
[23:58] <lifeless> jam: :)
[23:58] <lifeless> -> plane
[23:58] <jam> lifeless: of course, it would  be nicer if it could retain the log when run_bzr fails ... :)
[23:58] <jam> lifeless: I'll be joining you in..... 6 hours
[23:59] <jam> and then see you in about 30
[23:59] <jam> I figured I might try to get more of the test suite passing on Windows during my copious free time now.