[02:35] <mwhudson> jelmer: ERROR: test_push (bzrlib.plugins.git.tests.test_blackbox.TestGitBlackBox) seems to fail with on bzr-git tip
[02:36] <mwhudson> http://pastebin.ubuntu.com/189938/
[02:36] <mwhudson> (with dulwich tip, but somehow i don't think that matters)
[03:29] <pattern> when i do a "bzr version-info" in /home/foo/xyz i get an error: "Format <RepositoryFormatKnit1> for file:///home/foo/bzr/.bzr is deprecated - please use 'bzr upgrade' to get better performance"
[03:30] <pattern> but when i do a "bzr upgrade" in that directory i get:  "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
[03:31] <mwhudson> yeah, that sucjs
[03:31] <mwhudson> pattern: are you using a shared repo?
[03:31] <pattern> no
[03:31] <mwhudson> oh
[03:31] <pattern> just a local one
[03:31] <mwhudson> pattern: pastebin what bzr info -v says?
[03:31] <mwhudson> e.g. here http://pastebin.ubuntu.com/
[03:33] <pattern> http://pastie.org/503222
[03:34] <mwhudson> pattern: oh
[03:35] <mwhudson> pattern: try running bzr upgrade :this
[03:35] <mwhudson> um, maybe not that
[03:35] <mwhudson> pattern: you have a bound branch, it seems?
[03:35] <mwhudson> pattern: the format of the bound and master branch are different, i guess
[03:35] <pattern> not really sure what i have, in bzr terminology
[03:36] <mwhudson> try bzr upgrade :bound
[03:37] <pattern> Format <RepositoryFormatKnit1> for file:///home/foo/bzr/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
[03:37] <pattern> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
[03:38] <mwhudson> hmm
[04:37] <mwhudson> mm
[04:37] <mwhudson> does merge (maybe with --lca) losing executable bits sound familiar to anyone?
[04:47] <Peng_> mwhudson: I lost the xbit on a file once. I assumed it was because I did something like "mv foo.OTHER foo".
[04:47] <Peng_> I never actually tracked it down, though...
[04:47] <mwhudson> Peng_: hmm
[04:48] <mwhudson> Peng_: there's basically no chance that the files that lost x bits conflicted, though there may have been a conflict in the merge
[04:48] <mwhudson> actually, i think what i did was either 'merge; revert; merge --lca; commit' or 'merge; remerge --lca; commit'
[04:48] <Peng_> mwhudson: Oh, huh. I have no clue, then.
[04:48] <Peng_> ...Ugh, what's wrong with my connection this time?
[04:49] <mwhudson> ah well, i'll look again, on monday :)
[04:50] <mwhudson> i think both files that lost the x bit moved in the merge, too
[04:50] <mwhudson> which seems unlikely to be a coincidence
[04:50] <Peng_> 800-900 ms ping to hop #2?! WTF?!
[04:50] <Peng_> WTF is with me and Internet problems this week?
[04:51] <mwhudson> Peng_: obviously you're getting subconsciously ready to move to .au or .nz
[04:52] <Peng_> I've had problems with 2-3 different ISPs in different states in 1 week. :D
[04:52] <Kamping_Kaiser> harsh, but fair
[04:54] <treeform> hey guys my commit is taking for ever, can some one help diagnose the problem?
[04:55] <Peng_> treeform: Local? Internet? Checkout? Branch? Is it really gigantic? Define "forever"? RAM usage? CPU?
[04:55] <Peng_> Oddly, this barely feels worse than my 300 ms pings last time.
[04:59] <Peng_> Darn, it's confusing ntpd too.
[05:00] <treeform> Peng_: its my own remote server
[05:00] <treeform> i dont think its high on ram or cpu
[05:00] <treeform> its just taking for ever network wise
[05:00] <treeform> packing flowing for 2 hours to change 12 files
[05:00] <treeform> 12 python small files
[05:01] <treeform> i estimate it could have uploaded over gig now
[05:01] <treeform> on the server same thing
[05:01] <treeform> no ram or cpu problems
[05:01] <treeform> just open network connection
[05:02] <Peng_> treeform: How large is the repo?
[05:02] <treeform> 1.8Gb
[05:03] <Peng_> treeform: It's possible it's doing an autopack, which in old versions (or any version over a dumb protocol) means downloading a nd re-uploading a potentially significant amount of data.
[05:03] <Peng_> treeform: Check .bzr.log
[05:04] <treeform> where would bzr log be
[05:04] <Peng_> treeform: "bzr version" gives the location. Probably ~/.bzr.log.
[05:04] <treeform> oh the client is on windows and server is on linux
[05:04] <treeform> could that matter?
[05:04] <lifeless> no
[05:05] <treeform> server 1.8 , client 1.2
[05:05] <treeform> i just downloaded the client
[05:05] <treeform> maybe i got wrong one
[05:06] <Peng_> Those are both rather old.
[05:06] <lifeless> very
[05:06] <lifeless> I'll leave it with you Peng_ :)
[05:06] <Peng_> Wait, I was about to say that!
[05:07] <Peng> Ugh, typing over that SSH connection was driving me nuts.
[05:08] <treeform> i dont get the version numbers on the site
[05:08] <Peng_> treeform: Huh?
[05:08] <treeform> every thing from 1.15 to 1.6 is up for grabs
[05:08] <Peng> treeform: 15 > 6
[05:08] <treeform> The current stable version is 1.15final
[05:08] <treeform> but server say i have 1.8?
[05:09] <treeform> oh its 15 as in
[05:09] <treeform> ok got it
[05:09] <Peng> treeform: Check what's going on in .bzr.log on the client. If it says "Auto-packing repository", that's what's going on. If both the client and server were recent, auto-packing would occur server-side (if you're using the smart server).
[05:10] <treeform> where would .bzr.log be on windows?
[05:10] <Peng> treeform: I told you, ask "bzr version".
[05:10] <Peng> Seriously, how do people SSH over a satellite connection without just hanging themselves? It's awful!
[05:10] <Peng_> Anyway, whining about that is off-topic.
[05:13] <treeform> http://dpaste.com/52384/
[05:13] <treeform> the log is very very large
[05:14] <Peng_> treeform: Scroll up to the last push.
[05:14] <Peng_> treeform: Or commit, or whatever you were doing. :P
[05:14] <treeform> commit
[05:14] <treeform> i am not sure where it starts
[05:15] <Peng_> The file includes both dates (in recent versions, anyway) and the command line.
[05:15] <treeform> oh found it
[05:15] <Peng_> lifeless! I was about to leave! :(
[05:15] <treeform> there is tons of errors about locks
[05:16] <treeform> it has "Auto-packing repository"
[05:16] <treeform> so its autopacking 2GB of data?
[05:16] <treeform> and resending it?
[05:16] <Peng_> treeform: Some portion of it. Probably not all of it.
[05:17] <treeform> i probably need to update bzr's
[05:17] <treeform> and figure out smart server
[05:18] <Peng_> treeform: What type of connection are you using to the server? SFTP? bzr+ssh?
[05:18] <Peng_> God forbid, FTP?
[05:18] <treeform> sftp
[05:18] <treeform> bzr+ssh gives locking problems
[05:18] <Peng_> Oh, huh.
[05:19] <treeform> maybe its due to version being old
[05:19] <Peng_> Could be.
[05:19] <treeform> bzr+ssh is still not a smart protocol?
[05:19] <treeform> only the bzr one is?
[05:19] <treeform> but the server it runs does not support authintication?
[05:19] <Peng_> treeform: All of the schemes that start with "bzr" are smart.
[05:20] <treeform> so if i do get bzr+ssh working? it would give me smartness and authintication?
[05:20] <Peng_> bzr+ssh simply uses SSH for auth.
[05:20] <Peng_> ...As does SFTP.... :P
[05:21] <treeform> yes
[05:21] <treeform> i have all of the ssh setup
[05:21] <Peng_> So switching to bzr+ssh should be easy.
[05:22] <Peng_> I have no idea what your locking problems could be caused by, or if a newer version improves things. You should upgrade anyway, though.
[05:22] <treeform> could i cancel this commit and try bzr+ssh
[05:22] <treeform> should*
[05:22] <Peng_> treeform: I wouldn't. It would waste all of the bandwidth you've already used.
[05:23] <treeform> hmm
[05:23] <treeform> but its been going for 2+ hours
[05:24] <treeform> basically i was voiping with people
[05:24] <treeform> and said ok ill commit this
[05:24] <treeform> and ...
[05:24] <Peng_> Well, I don't know, it's your choice.
[05:25] <treeform> ok got the 1.15 on server
[05:26] <Peng_> You could kill the commit, log into the server and run "bzr pack" on the repo.
[05:26] <treeform> oh
[05:26] <Peng_> Then you wouldn't have to do a significant autopack for a long time.
[05:26] <Peng_> (Note: That would temporarily double the amount of disk space used. And it would probably use a lot of RAM, I dunno.)
[05:28] <treeform> hmm only took 14 sec to do bzr pack on server
[05:28] <treeform> with 1.15
[05:29] <Peng_> Yes, well, local disks are a lot faster than the Internet. :P
[05:29] <treeform> was there a new better knit format since 1.8 ?
[05:29] <Peng_> treeform: The --1.9 format has new, smaller and faster indexes.
[05:29] <Peng_> treeform: (As its name suggests, it was intorudced in 1.9.)
[05:29] <treeform> ok
[05:30] <Peng_> (And if I wasn't typing over this slow SSH connection, I'd fix that typo. :P )
[05:30] <treeform> is it worth to switch and how would i switch to it?
[05:30] <Peng_> treeform: You'd use "bzr upgrade --1.9". Obviously, all of your clients would have to be 1.9 or newer.
[05:31] <Peng_> treeform: If the clients are new enough, there's not really any reason not to upgrade. It does improve performance, especially over dumb servers.
[05:31] <treeform> lets see if it can upgrade 2GB worth of data
[05:31] <Peng_> treeform: BTW, you should run bzr check and (if necessary) bzr reconcile as well.
[05:31] <Peng_> treeform: before upgrading
[05:31] <treeform> oh man
[05:31] <treeform> allready started
[05:31] <treeform> cancel?
[05:32] <Peng_> treeform: Nah.
[05:32] <Peng_> treeform: Well, it would still be a good idea to run check and reconcile after upgrading. And it'll be faster, to boot! :D
[05:33] <treeform> because i am using new shiny format
[05:33] <treeform> its done switching, checking now
[05:34] <treeform> is there a big performance difference between bzr+ssh and bzr straight?
[05:36] <Peng_> treeform: Nah. And anyway, regular bzr:// is unencrypted and doesn't support any form of auth. Use each where it's more appropriate, not out of performance concerns.
[05:36] <treeform> using bzr+ssh gives this error on windows
[05:37] <treeform> "the procedure entry point ___lc_collate_cp_func could not be located in the dynamic link library msvcrt.dll"
[05:37] <treeform> this is in 1.15 just freshly downloaded
[05:38] <treeform> on the windows client
[05:38] <treeform> https://bugs.launchpad.net/bzr/+bug/341465
[05:38] <Peng_> Oh, there we go.
[05:39] <treeform> this is probalby i did not use bzr+ssh :)
[05:39] <treeform> probably why*
[05:40] <treeform> any advice?
[05:41] <Peng_> I haven't touched Windows in like 5 years. :P
[05:41] <Peng_> So, I don't know, sorry.
[05:41] <treeform> yeah i whish i did not have to live with it either
[05:41] <Peng_> You might be able to run bzr from source, but I don't know how easy that is on Windows. Plus performance would be worse.
[05:42] <Peng_> I think it's worth adding a comment on that bug, that it still affects you in 1.15.
[05:45] <treeform> random dll from the net does not have ___lc_collate_cp_func either
[05:46] <Peng_> Try the mailing list or something.
[05:46] <Peng_> I really don't know anything about Windows, and it's the weekend, so not many people are around.
[05:46] <treeform> crap now sftp does not work too!!!!
[05:47] <treeform> ill try restart
[05:47] <treeform>  :)
[05:57] <treeform> same dam thing
[05:59] <treeform> oh i fixed it
[05:59] <treeform> yey
[06:06] <Peng_> You fixed it? How?
[06:07] <treeform> i removed the svn plugin ( https://bugs.launchpad.net/bzr/+bug/341465/comments/2 )
[06:07] <treeform> the trace lead to that
[06:07] <treeform> too bad i dont have the trace any more
[06:08] <treeform> other wise i would post it
[06:08] <Peng_> Oh
[06:10] <lifeless> treeform: its probably in your bzr log
[06:10] <treeform> yes
[06:10] <treeform> got it updateing
[06:11] <Peng_> lifeless: Hi. :)
[06:11] <lifeless> bzr --version will give you the path to the log
[06:11] <lifeless> hi Peng_
[06:11] <treeform> yeah i added it to commets
[06:12] <treeform> maybe it could help some poor sole in the future
[06:12] <Peng_> Ooh, subvertpy.
[06:13] <treeform> its the svn2bzr stuff right?
[06:13] <treeform> i dont know, i just hack folder, stuff works
[06:14] <treeform> bzr+ssh feels faster
[06:14] <Peng_> treeform: subvertpy provides Subversion bindings for Python. It's used by bzr-svn (and was, in fact, created by the author of bzr-svn for bzr-svn).
[06:14] <treeform> but its just an physiology thing
[06:14] <Peng_> treeform: bzr+ssh is faster than sftp.
[06:14] <treeform> cool
[06:14] <treeform> just commit some binary files
[06:15] <treeform> 12megs
[06:15] <treeform> it went in fine
[06:15] <treeform> after the small 12 file commit that took 3 hours  1 minute and 9 second with sftp ...
[06:15] <treeform> and faild
[06:15] <Peng_> treeform: Well, that was thanks to the auto-pack.
[06:16] <treeform> yeah
[06:16] <treeform> what are some of the largest bzr repos people have?
[06:16] <treeform> do they have Terabyte repos?
[06:16] <Peng_> lifeless: Think that bug should be linked against subvertpy?
[06:17] <lifeless> Peng_: bzr installer probably
[06:18] <Peng_> lifeless: yeah.
[06:18] <lifeless> Peng_: not sure what part should be responsible for doing the suckin of the dll
[06:19] <Peng_> treeform: MySQL is probably the largest public project at the moment.
[06:19]  * Peng_ shrugs
[06:19] <Peng_> I'm sure Launchpad has statistics.
[06:20] <lifeless> treeform: Theres nothing in our dataformats preventing scaling to terabytes of history
[06:20] <lifeless> but there are limitations on individual file size
[06:20] <Peng_> lifeless: What about hte inventory?
[06:21] <treeform> my stuff is mostly 3d data
[06:21] <treeform> like huge images and huge files of 3d model
[06:27] <lifeless> treeform: bzr currently wants to hold up to 5 times the size of a single file in memory while committing or diffing it
[06:27] <lifeless> treeform: we have some plans about how we might fix this
[06:28] <lifeless> probably post 2.0
[06:28] <lifeless> Peng_: inventory scales to 100K files+ in a single tree today
[06:29] <Peng_> lifeless: Isn't dev7 down to 3 times for commit?
[06:29] <lifeless> Peng_: once jams's patches land, and only dev7 which treeform won't be using yet.
[06:30] <Peng_> Ah. Well, it's still progress in the right direction, right?
[06:30] <lifeless> right
[06:31] <lifeless> but better to be capped at (say) 5MB
[14:12] <garyvdm> igc: ping
[14:18] <RockyRoad> hi :)
[14:18] <garyvdm> Hi RockyRoad
[14:19] <RockyRoad> maybe you could help me ?
[14:19] <garyvdm> Go ahead and ask. If I can't I'm sure someone else might be able to.
[14:19] <RockyRoad> I was here friday, with a problem a bit complicated
[14:20] <RockyRoad> I explained it here http://www.rocky-shore.net/misc/bzr-rebuild.html
[14:22] <RockyRoad> I wondered if bzr rebase could help ?
[14:22] <garyvdm> I'm reading you page
[14:23] <garyvdm> There is a command half way down: bzr -r0..1 lp:branch_Bx
[14:23] <garyvdm> should that be bzr *merge* -r0..1 lp:branch_Bx
[14:24] <RockyRoad> right !
[14:25] <RockyRoad> corrected
[14:27] <garyvdm> RockyRoad - So the problem is that you can't push from A to B?
[14:27] <RockyRoad> I tried to push to a subdir of Bx, that fails
[14:28] <RockyRoad> because the parent branch is different
[14:29] <garyvdm> Is these branches publicly accessible? - I think It will be much easier for me to look at the branches.
[14:29] <RockyRoad> (i suppose)
[14:29] <RockyRoad> sure
[14:30] <RockyRoad> https://edge.launchpad.net/planet-drupal
[14:31] <garyvdm> so which is A and which is B?
[14:31] <RockyRoad> A is drupal-planet and B is planet-drupal
[14:35] <RockyRoad> FYI http://drupal.org/node/476042
[14:36] <RockyRoad> (so it's not  a fork !)
[14:37] <garyvdm> RockyRoad: do you have qbzr installed?
[14:37] <RockyRoad> bzr gtk and qbzr
[14:38] <RockyRoad> I like bzr viz
[14:38] <garyvdm> you can run "bzr qlog lp:drupal-planet lp:planet-drupal" to see a visualization between the two branches.
[14:39] <RockyRoad> one project after the other, not together ?
[14:39] <RockyRoad> bzr: ERROR: extra argument to command qlog: lp:planet-drupal
[14:40] <garyvdm> Ah - what version of qbzr?
[14:40] <RockyRoad> I have a lot of errors with qlog
[14:41] <RockyRoad> qbzr 0.9.2-0ubuntu1
[14:42] <garyvdm> Yes - It did not have that feature back then.
[14:42] <garyvdm> I'll upload a screen shot for you
[14:43] <RockyRoad> thx :)
[14:43] <garyvdm> Now what command are you using to push from A to B?
[14:44] <RockyRoad> bzr push lp:~m-baert/planet-drupal/planet-6-x
[14:45] <RockyRoad> I'll pastebin all, one moment
[14:45] <RockyRoad> http://pastebin.com/m30a5ff1c
[14:47] <garyvdm> http://garyvdm.googlepages.com/log-planet-drupal.png
[14:47] <garyvdm> You can get the latest qbzr from https://launchpad.net/~qbzr-dev/+archive/ppa
[14:48] <RockyRoad> It's much nicer that what I have ! I will :)
[14:54] <garyvdm> ok - so I think what you want merge A into B
[14:55] <garyvdm> so go to your directory that contains B (lp:~m-baert/planet-drupal/planet-6-x ?) do bzr merge
[14:56] <garyvdm> and do bzr merge lp:drupal-planet
[14:57] <garyvdm> Check that it gets you what you want.
[14:57] <garyvdm> And then push
[14:59] <RockyRoad> but there's no common ancestor ...
[14:59] <RockyRoad> oh yep
[14:59] <garyvdm> brb
[15:00] <RockyRoad> k
[15:08] <RockyRoad> planet-6x$ bzr merge lp:drupal-planet
[15:08] <RockyRoad> Nothing to do.
[15:08] <RockyRoad> revno = 25
[15:13] <RockyRoad> Is there a way to bring my branch from drupal-planet to planet-drupal history ?
[15:13] <garyvdm> sorry - bzr merge *lp:planet-drupal*
[15:13] <garyvdm> These names are very confusing
[15:14] <RockyRoad> I've no rights on drupal-planet, I have on planet-drupal
[15:15] <garyvdm> But you don't have to create a whole new project.
[15:15] <RockyRoad> ?
[15:16] <garyvdm> You can just create a new branch lp:~rockyroad/planet-drupal/trunk (or dev or fork :-P)
[15:16] <RockyRoad> I couldn't agree with the person who "administrates" drupal-planet and related projects
[15:17] <garyvdm> if you push to  lp:~rockyroad/planet-drupal/trunk - then it will show up in the branches list for planet-drupal
[15:18] <RockyRoad> but the "old history" I added ?
[15:19] <RockyRoad> drupal planet starts from my trunk rev 3
[15:19] <garyvdm> You can bring that in with bzr merge *lp:planet-drupal*
[15:20] <garyvdm> Earlier I said bzr merge lp:drupal-planet - that give you "Nothing to do. " because it an older branch of lp:~m-baert/planet-drupal/planet-6-x
[15:21] <RockyRoad> from planet-drupal checkout directory ...
[15:21] <RockyRoad> sorry I need time to figure it out
[15:22] <garyvdm> brb
[15:22] <RockyRoad> k
[15:24] <RockyRoad> what may be a trick is that I built a newer project (planet-drupal) to store older history (CVS) before a clone of drupal-planet
[15:29] <igc> hi garyvdm
[15:31] <RockyRoad> s/trick/pitfall/
[15:32] <RockyRoad> hi igc
[15:34] <garyvdm> Hi igc
[15:36] <garyvdm> RockyRoad - I think you need to try figure what you merge into what. qlog branchA branchB branchC can help you alot with that.
[15:38] <garyvdm> igc: Bazaar Explorer overlaps alot with qmain.
[15:38] <igc> hi guys
[15:38] <RockyRoad> I can't see it very clearly yet ... what kind of connection does qlog do between branches ?
[15:38] <igc> garyvdm: I certainly took a lot of its design from qmain
[15:39] <garyvdm> It shows how their revision histories relate
[15:39] <igc> well, the discussion around qmain at least
[15:40] <garyvdm> igc - I not against a split effort. I would just like to discuss it.
[15:40] <igc> garyvdm: sure. Apologies for not discussing it more before I threw it together
[15:41] <igc> garyvdm: the orginal focus was prototyping the menu I wanted in bzr-eclipse
[15:41] <garyvdm> And would still like to do qmain - because there are things that we will be able to do with qmain that will be more difficult.
[15:42] <igc> garyvdm: by all means
[15:42] <garyvdm> Like integrate log into qmain.
[15:42] <igc> garyvdm: right, I was looking for a lightwieght wrapper/shell because that best simulates the experience ...
[15:43] <igc> that users of qbzr-eclipse and TortoiseBzr will get
[15:43] <garyvdm> So, If I understand you correctly, bazaar-explorer is really experimental?
[15:43] <igc> garyvdm: at this stage, yes
[15:43] <igc> garyvdm: but I'm using it for development and dogfooding it
[15:43] <igc> so I expect it to rapidly improve
[15:44] <igc> garyvdm: in fact, it's almost finished in one sense ...
[15:44] <igc> I really do want it to be lightweight ...
[15:44] <garyvdm> Ok - cool.
[15:44] <igc> and for most of the energy to go into the q* commands themselves
[15:45] <garyvdm> So I've been thinking alot about the idea that I posted as a response to one of your mails.
[15:45] <igc> garyvdm: going further, I'd be interested in pushing any smarts in explorer down into q* commands even
[15:46] <garyvdm> Thats great.
[15:47] <igc> garyvdm: tell me more about your idea
[15:48] <garyvdm> So my idea is now something like this. I create a "api" in qbzr where you can say wrap this bzr command, and show fields x, y, z on the dialog.
[15:49] <igc> garyvdm: yes!!
[15:49] <igc> garyvdm: I was thinking of code generating creating Qt forms
[15:49] <igc> but your idea - dynasmic lookup of the Command objects - is better
[15:50] <garyvdm> It will try and what type of field it, so for say a revision spec field, it will show a revision selector, but will may have to provide it some extra information.
[15:50] <igc> right
[15:51] <garyvdm> e.g. for push, it must show revisions from the current directory (or what was provided by -d), but for pull, it must show the location you entered.
[15:52] <garyvdm> That will make adding a new command only a couple of lines of code.
[15:52] <igc> excellent
[15:53] <garyvdm> Right now though - I'm batteling to decide what to work on :-)
[15:53] <igc> garyvdm: here's some simple ideas if they help
[15:54] <igc> as I said, I've been dogfooding, trying to go command line cold turkey ...
[15:54] <igc> some limits of our q* GUIs ...
[15:54] <garyvdm> Ha ha - I've tried that a couple of time ...
[15:54] <igc> in qadd, I can do the equivalent of add foo/bar when foo is unversioned
[15:54] <igc> s/can/can't/
[15:55] <igc> I can only add all of foo
[15:55] <igc> so qadd needs a button like ...
[15:55] <igc> Expand Directories
[15:55] <igc> a second example ...
[15:55] <igc> I can't use qmerge to merge a merge directive easily
[15:56] <igc> as the 'branch selector' insists on a directory
[15:56] <garyvdm> That should be easy to fix.
[15:57] <igc> garyvdm: there's lots of little stuff too ...
[15:57] <igc> qbind and qunbind are essential
[15:57] <igc> and both probably really simple (a few hours each I hope)
[15:58] <garyvdm> qbind/qunbind/qswitch are the type of commands that my api would make realy easy to do.
[15:58] <igc> garyvdm: exactly
[15:59] <igc> garyvdm: but the bind ones at least arguably need to be slightly nicer than generic, e.g.
[16:00] <garyvdm> re qadd: what I would like is for directories to have twisties so you can expand them.
[16:00] <igc> bind takes an optional location now
[16:00] <igc> qbind ought to say something like ...
[16:00] <igc> [X} Bind to existing location: ...
[16:01] <igc> [ ] Select a new location
[16:01] <igc> and picking the seconf radio button ought to enable an entry field
[16:02] <igc> qunbind ought to be a simple yes/no dialog even
[16:04] <igc> garyvdm: quncommit is another one that ought to be easy ...
[16:04] <igc> [X] Uncommit last revision
[16:04] <igc> [ ] Select an earlier revision...
[16:04] <garyvdm> qunbind could be just when you select revert from the qcommit dialog.
[16:05] <igc> garyvdm: probably, though it also needs to be separate I think
[16:06] <igc> garyvdm: qunbind will turn something from a bound branch into an unbound branch in Explorer
[16:07] <igc> so it probably needs to be a button on the Bound Branches tab of a repo
[16:07] <garyvdm> I meant - the qbind dialog should look like revert dialog initiated from qcommit.
[16:08] <igc> garyvdm: ah - sorry, I'm yet to see that one :-)
[16:08] <garyvdm> and the code for that is implement is a very reusable fashion.
[16:08] <igc> nice to hear
[16:08] <garyvdm> brb
[16:09] <garyvdm> About qadd
[16:09] <garyvdm> what I would like is for directories to have twisties so you can expand them.
[16:09] <garyvdm> To do that
[16:10] <igc> +1 to that
[16:11] <garyvdm> currently we have 3 directory/tree browsers. The working tree widget used in qcommit/qadd/qrevert. The qbrowse widget, and the qbzr (aka qmain) widget.
[16:12] <garyvdm> I would like to see them refactored into one.
[16:12] <igc> garyvdm: I'm not across enough of the qbzr code but ...
[16:13] <igc> sound good to me
[16:13] <garyvdm> igc: can I ask for some none-tech advice?
[16:13] <igc> garyvdm: fwiw, I'd like to see ...
[16:13] <igc> qbzr have a widgets directory as well as a lib one
[16:13] <igc> so the widgets are more easily discoverable
[16:13] <garyvdm> Ok
[16:14] <igc> I've started doing that in bzr-explorer
[16:14] <garyvdm> Currently there are only 2 that are designed to be reuseabe.
[16:14] <garyvdm> log and working tree
[16:15] <igc> garyvdm: non-tech advice?
[16:15] <igc> fire away
[16:15] <garyvdm> And the currently unmerged into trunk revision selector
[16:15] <igc> yes please
[16:15] <garyvdm> I can't decide what to work on.
[16:15] <RockyRoad> I wouldn't like to disturb in your busy developers chat (qbzr rocks :), but I still need some help. Somebody else maybe ? jelmer what about rebase ? My problem is exposed here: http://www.rocky-shore.net/misc/bzr-rebuild.html
[16:16] <garyvdm> I started working on tests for log at uds
[16:16] <garyvdm> There is alot more test that should be written for qlog
[16:16] <garyvdm> Fix bugs?
[16:17] <garyvdm> Work on api for creating command?
[16:17] <garyvdm> Work on refactoring directory/tree widgets into one.
[16:17] <garyvdm> I cant decide.
[16:18] <igc> garyvdm: there's no right answer :-)
[16:18] <igc> but here's my view ...
[16:18] <igc> pick whatever gives end users most value
[16:18] <igc> if the bugs are stopping users from working, they become #1
[16:19] <garyvdm> ok
[16:19] <igc> garyvdm: fwiw, what helps me most is the sort of stuff above ...
[16:20] <igc> because each one of them means "back to command line"
[16:20] <igc> garyvdm: I feel that once we get those sort of rough edges smoothed out ...
[16:21] <igc> then more people will start using our GUIs and they'll gain more momentum
[16:21] <igc> and more developers to help us improve them
[16:21] <garyvdm> Yes
[16:22] <igc> garyvdm: so, stepping back a second ...
[16:22] <garyvdm> If I work on the api - it may save other developers, and increase the momentum.
[16:22] <igc> my vision is for each IDE and shell to have the same Bazaar menu ...
[16:22] <igc> and for the menu options to be very lightweight code calling out to q* (and optionally g*)
[16:23] <igc> putting together menus in most environments is easy
[16:23] <igc> writing code behind them is hard
[16:23] <garyvdm> Yes - I agree that is the way to go.
[16:24] <igc> garyvdm: so my preferred order for things is ...
[16:24] <igc> 1) get coverage so menu options do something
[16:24] <igc> 2) look at streamlining the commonly used dialogs
[16:24] <igc> 3) the rest
[16:25] <garyvdm> Ok - so for me -
[16:25] <igc> garyvdm: I think your API idea is excellent
[16:25] <garyvdm> 1) fix bugs
[16:25] <garyvdm> 2) command api
[16:25] <garyvdm> 3) tree/dialog refactoring
[16:25] <garyvdm> Cool - thanks for the advice
[16:25] <igc> sounds good
[16:26] <igc> 1 makes users happy and 2+3 will help build momentum
[16:26] <garyvdm> I was looking forward to meeting you at uds, and disappointed when I found out that you weren't going to be there. But I understand why.
[16:26] <igc> garyvdm: :-(
[16:26] <igc> I hear the sprint was great
[16:26] <igc> and would have *loved* to be there
[16:26] <garyvdm> Did you see I signed your book. On one of the back pages :-)
[16:27] <igc> I'm yet to receive that stuff
[16:27] <garyvdm> :-(
[16:27] <igc> but I'll look for your name when I do :-)
[16:28] <garyvdm> Ok - thanks for the chat - I'm going to work on a bug, and then go visit my Dad.
[16:29] <igc> garyvdm: my pleasure. I should get some sleep :-)
[16:30] <RockyRoad> thanks garyvdm, good luck
[16:30] <garyvdm> RockyRoad: I also want to help you still if you have some time
[16:31] <RockyRoad> you probably need to keep all these good ideas fresh in mind and go on with qbzr. I can understand that
[16:32] <garyvdm> I do want to help you
[16:32] <RockyRoad> k
[16:32] <RockyRoad> to refer back to my drawing http://www.rocky-shore.net/misc/bzr-rebuild.html (A/B less confusing names ?)  what I understand of merging lp:planet-drupal into lp:planet-drupal/planet-6-x/ is merging B rev5 into By rev25, which looks like reverting to Bx rev 9.
[16:33] <RockyRoad> I don't want to revert to that state !
[16:33] <RockyRoad> although I'm ok to rebuild all from the start if needed
[16:34] <RockyRoad> also, I have no problem pushing lp:~m-baert/drupal-planet/6.x (Az) into lp:~m-baert/planet-drupal/6x-mich (Bz), but the problem I could have is to merge it into Bx or Bxy.
[16:34] <garyvdm> can you run bzr qlog lp:~m-baert/planet-drupal/planet-6-x lp:drupal-planet lp:planet-drupal
[16:34] <garyvdm> and tell me when It has loaded.
[16:35] <RockyRoad> loaded
[16:35] <garyvdm> rev 5 from lp:drupal-planet != rev9 from lp:planet-drupal
[16:36] <garyvdm> It has rev9 merged into it
[16:36] <garyvdm> rev 5 from the yellow line
[16:37] <RockyRoad> drupal-planet rev5 is nothing special
[16:37] <RockyRoad> planet-drupal rev5 reflect drupal-planet/6x/ rev 9
[16:39] <garyvdm> If i understand correctly, the yellow line (lp:drupal-planet) has changes that you want to merge into the black line (lp:planet-drupal / lp:~m-baert/planet-drupal/planet-6-x)
[16:39] <RockyRoad> not really
[16:39] <garyvdm> Oh
[16:40] <RockyRoad> the black line is a copy of lp:~sweetdave/drupal-planet/6.x
[16:41] <RockyRoad> th yellow line is what I added
[16:41] <RockyRoad> (old history + tags)
[16:41] <garyvdm> I see that
[16:42] <garyvdm> You want to merge the black line into the yellow line?
[16:43] <RockyRoad> I pushed lp:~m-baert/drupal-planet/6.x as lp:~m-baert/planet-drupal/6x-mich , but it's not connected
[16:44] <garyvdm> Ok - let me have a look at thems
[16:44] <garyvdm> *them
[16:44] <RockyRoad> I need to build a common ancestor
[16:44] <RockyRoad> not reverting to previous development stage
[16:46] <RockyRoad> those 0.x revisions in yellow are added recently to describe older project steps
[16:47] <RockyRoad> so logically, I would prefer to see them _below_ rev 1 in black
[16:47] <RockyRoad> but the connection line is fine
[16:48] <garyvdm> Ah - so you want to change them into one history?
[16:48] <garyvdm> Yes - you can do that with bzr-rebase
[16:48] <RockyRoad> this part is ok, but I'd like to connect
[16:49] <RockyRoad> lp:~m-baert/planet-drupal/6x-mich to the same history
[16:50] <RockyRoad> because I will need to merge its rev 24 after black rev 25
[16:51] <RockyRoad> there's not much difference in code, but i'd like to keep its revision logs
[16:52] <RockyRoad> on my graph, I showed a lot a "manual merges" , which can't appear in qlog, because they didn't use bzr merge, and were often partial
[16:53] <RockyRoad> it's explained in rev logs
[16:53] <garyvdm> So you've got 3 options 1. Merge black in to yellow an push that your dev focus (yellow then becomes your main line).
[16:53] <RockyRoad> yellow is the main line
[16:54] <garyvdm> 2. Merge yellow into black  - and push - black stays you main line
[16:54] <garyvdm> or
[16:54] <RockyRoad> yellow and black are fine as is
[16:55] <garyvdm> use rebase so that the black line follows on from rev 3 of the yellow line.
[16:55] <RockyRoad> I just miss a third color
[16:56] <RockyRoad> I thought about rebase, but I couldn't understand well if it was the thing I needed
[16:56] <RockyRoad> and how to use
[16:56] <RockyRoad> it
[16:57] <RockyRoad> rebase 6x-mich to planet-6x
[16:58] <RockyRoad> If I didn't merge black25 in yellow trunk, it's just because it's not ready yet, from a dev point of view
[16:59] <RockyRoad> I could merge easily its rev 9, so I guess there's no problem to merge rev 25
[17:00] <RockyRoad> that because I used from planet-trunk$ bzr merge -r0..1 lp:planet-drupal/planet-6x
[17:01] <garyvdm> Yes
[17:01] <garyvdm> How come you created the .moved files?
[17:01] <RockyRoad> with this exact step
[17:01] <RockyRoad> merge -r0..1
[17:02] <RockyRoad> a matter of file-id that vila explained me in detail friday
[17:02] <garyvdm> Ok
[17:03] <garyvdm> I wonder if it is possible to specify when you do a cvs import to specify that it must use the file ids from an existing branch?
[17:03] <RockyRoad> it's not a big issue, humans could quickly see the files are identical
[17:04] <garyvdm> but if you do bzr log file, or bzr annotate file, the history will stop at that merge.
[17:04] <RockyRoad> As I understood, it's intentional to forbid that
[17:04] <RockyRoad> (file-id trick)
[17:05] <RockyRoad> it's not a big problem
[17:05] <garyvdm> So I think what I would want to do is redo the cvs import, and get it to use the bzr file-id's
[17:05] <garyvdm> Then you can rebase the start of the black line on the the end of the new cvs import.
[17:05] <RockyRoad> My problem is not here
[17:06] <RockyRoad> I need to link a _third_ branch
[17:06] <garyvdm> Oh - which is?
[17:06] <RockyRoad> lp:~m-baert/planet-drupal/6x-mich
[17:07] <garyvdm> but that is exactly the same as lp:~m-baert/drupal-planet/6.x
[17:07] <RockyRoad> yep
[17:08] <RockyRoad> just copied in the new project
[17:08] <garyvdm> What do you mean by link?
[17:08] <RockyRoad> something like merge -r0..1
[17:10] <garyvdm> But they are the same - so you don't have to do any thing.
[17:10] <RockyRoad> I need a common ancestor between planet-drupal/planet-6x and planet-drupal/6x-mich
[17:11] <RockyRoad> to be able to do future merges
[17:11] <garyvdm> You don't need to do any thing.
[17:11] <garyvdm> You will be able to merge.
[17:12] <RockyRoad> ok I retry
[17:22] <RockyRoad> It sounds like it could do it but but renames+add again
[17:22] <RockyRoad> that's more an issue at this stage
[17:26] <garyvdm> RockyRoad: No - if you make a change to lp:~m-baert/planet-drupal/6x-mich, and one to lp:~m-baert/drupal-planet/6.x, you should be able to merge one into the other with out any problems.
[17:27] <RockyRoad> http://pastebin.com/d711d6fd7
[17:27] <RockyRoad> I don't need to merge 2 copies of the same branch that I own
[17:28] <RockyRoad> I don't think so ...
[17:29] <RockyRoad> oh no the moves don't concern the program files, it's ok
[17:29] <RockyRoad> doc subdir is all my own
[17:30] <RockyRoad> these are "ordinary" conflicts
[17:33] <RockyRoad> but I find it mysterious why I can do it here what I couldn't on other branches ...
[17:34] <RockyRoad> old command: bzr merge -r 1 lp:~m-baert/planet-drupal/planet-6x
[17:34] <RockyRoad>  # bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[17:35] <garyvdm> Ok - I said lp:~m-baert/planet-drupal/6x-mich was the same as lp:~m-baert/drupal-planet/6.x
[17:35] <RockyRoad> from  planet-trunk
[17:35] <garyvdm> lp:planet-drupal/planet-6x and lp:~m-baert/planet-drupal/6x-mich are differnet - although they do have a common ancestor.
[17:36] <garyvdm> Let me look further at the errors
[17:38] <garyvdm> So David Giard manualy added doc.
[17:39] <garyvdm> Had he done a merge (or a cherry pick merge) from your branch, then there would not be a conflict.
[17:40] <RockyRoad> No
[17:40] <RockyRoad> oops
[17:40] <garyvdm> Because he did it manually, the file id's of the doc folder are differnent
[17:40] <RockyRoad> no problem
[17:40] <RockyRoad> That's interesting
[17:42] <garyvdm> Ok - I must go
[17:42] <garyvdm> I hope I was a help
[17:42] <RockyRoad> ok thanks a lot for your patience and help :)
[17:43] <RockyRoad> I'll force a commit right now to check ..
[17:43] <garyvdm> It's a pleasure.
[18:11] <Glenjamin> hey guys, is there any way to set the default external diff options?
[18:25] <ddaa> use an alias
[18:32] <Glenjamin> can i alias diff to di --diff-options=whatever ?
[18:54] <LarstiQ> Glenjamin: yes
[18:54] <LarstiQ> Glenjamin: see `bzr help alias`
[18:54] <Glenjamin> excellent, thanks
[18:54] <Glenjamin> i read the help, it doesnt mention replacing default commands
[18:56] <cody-somerville> Glenjamin, I just tried it, like you could have, and it lets you set aliases that override default commands
[18:58] <LarstiQ> cody-somerville: I suppose an example could be included that does that
[19:00]  * cody-somerville nods.
[19:05] <LarstiQ> cody-somerville, Glenjamin: either of you interested in submitting a patch that does that?
[19:18] <FryGuy-> is it normal for bzr resolve to need to specify the full file name for each file to resolve?
[19:20] <LarstiQ> FryGuy-: instead of what?
[19:20] <FryGuy-> just doing bzr resolve
[19:21] <FryGuy-> maybe it's just a windows problem
[19:21] <FryGuy-> i think i recall that there are a few places where wildcards don't work properly
[19:22] <LarstiQ> FryGuy-: if you want to resolve a specific file, `bzr resolve path/to/file`, if you want to autoresolve what you can, just `bzr resolve`, if you want to force everything, `bzr resolve --all`
[19:22] <FryGuy-> hmm
[19:22] <LarstiQ> FryGuy-: if you're expecting that `bzr resolve` clears all conflicts, maybe the detection thinks it can't resolve yet
[19:22] <LarstiQ> that, or you might indeed have found a bug
[19:23] <FryGuy-> well in this case, i don't know how i can resolve it
[19:23] <LarstiQ> FryGuy-: could you pastebin `bzr conflicts` output?
[19:23] <FryGuy-> this happened at work, i'm trying to reproduce it
[19:25] <FryGuy-> k i got it
[19:26] <FryGuy-> http://pastebin.com/m4efe2a77
[19:27] <FryGuy-> on my work computer i've also gotten into cases where the conflict on switch happens, and it completely breaks the locks
[19:27]  * LarstiQ blinks
[19:27] <LarstiQ> FryGuy-: and what is someproject
[19:27] <LarstiQ> ?
[19:28] <FryGuy-> http://pastebin.com/m27652c7c
[19:28] <FryGuy-> there's how I reproduced it
[19:30] <FryGuy-> er, excluding ilne 5
[19:41]  * LarstiQ can reproduce that on Debian too
[19:45] <LarstiQ> FryGuy-: so yeah, you certainly found a bug there
[19:46] <LarstiQ> FryGuy-: however, if you explicitly `bzr resolve someproject`, that should get you out of the immediate situation
[20:36] <asabil> hi all
[20:49] <LarstiQ> FryGuy-: I'm trying to make the case for reproducing it somewhat smaller
[20:50]  * LarstiQ tries an alternative approach
[20:55] <LarstiQ> FryGuy-: http://pastebin.com/d6453183c
[20:58] <LarstiQ> FryGuy-: there is a chance that the switch mechanics are different, but I believe the bug is in shared code
[20:59] <LarstiQ> ah, there are some differences
[22:40] <mwhudson> jelmer: thanks for the bzr-git test fix :)
[23:28] <mwhudson> are any bazaar developers working today? :)
[23:45] <pygi> mwhudson: its sunday :p
[23:46] <mwhudson> pygi: nonsense!
[23:46] <pygi> mwhudson: uh, actually, I just lied
[23:46] <pygi> its monday
[23:49] <mwhudson> pygi: and has been for nearly 11 hours now!
[23:49] <mwhudson> anyway, i figured things out myself
[23:50] <pygi> mwhudson: no, only 47 minutes
[23:51] <pygi> mwhudson: that's cool, share the findings :p
[23:51] <mwhudson> pygi: bzr tests fail with an old subunit around
[23:51] <mwhudson> (not very exciting)
[23:52] <pygi> indeed :p