ivazquez|laptopOkay, branch..revision_id_to_revno() worked for that one. But it fails for files like README.00:01
lifelessdotted revnos aren't handled by that api; I think there is another newer api00:01
lifelessthere has been some stuff on the list recently too, about this00:02
ivazquez|laptopI'll take a look there then, thanks.00:02
enigma42jelmer: Can I use the 0.6.0 release of subvertpy with bzr-svn 0.5-trunk?00:04
jelmerenigma42, yes00:04
enigma42jelmer: OK.00:04
enigma42jelmer: Where do I install subvertpy?00:05
jelmerenigma42, somewhere in your python path (./setup.py install usually does the right thing)00:05
enigma42jelmer: Is there a way to install it unprivileged?00:07
enigma42jelmer: LIke in "~/.python" or something like that?00:07
jelmerenigma42, yeah, you can specify a different directory using the --root option00:07
jelmerenigma42, but you'll have to set PYTHONPATH appropriately to use bzr-svn then00:07
enigma42Oh, OK.00:07
lifeless--homedir isn't it?00:09
enigma42jelmer: OK. I use "checkinstall" to create a deb and installed it that way.00:14
Jc2klifeless: bzr + ssh, more specifically its SSHSuprocess objects. do you know why os.read(stdin.fileno()...) was preferred over sdin.read(.. ?00:17
Jc2klifeless: i have some questions about hooks too when you have some spare cycles00:20
lifelessJc2k: just ask00:21
lifelessI'm at LCA, but will do my best00:21
lifelessdunno wh we use os.read there, annotate may help?00:21
ivazquez|laptopAha, branch.get_revision_id_to_revno_map()[inv.revision].00:22
Jc2kah ok. os.read seems to return something, but maybe not as much as you asked for. in that regard stdin.read is nicer.00:22
Jc2klifeless: my question was about a plugin i threw together as "bzr-hookless-email reloaded"00:23
Jc2klifeless: i replied to a post on bazaar ml about bzr-hookless-email with my thoughts, it might be easier to look at that00:24
Jc2klifeless: basically im reusing Branch.hooks in a different context, and thats slightly evil of me but means that i have a way to make something like bzr-cia "just work" with a bzr-hookless-email type arrangement00:25
Jc2k(out of process hooks)00:25
enigma42jelmer: Great! The latest 0.5-trunk pushed and pulled just fine.00:27
jelmerGreat :-)00:27
enigma42jelmer: Thanks for your help.00:27
ivazquez|laptopExcellent. 4 down, 1 to go.00:29
enigma42jelmer: OK. Same problem about branches diverging again.00:30
jelmerenigma42, what is the error there exactly?00:30
jelmerand what does e.g. "bzr missing" say?00:31
enigma42Here's the symptom. Before I clear the cache, I can do a "push" or "pull" and there will be not changes.00:31
enigma42Then I clear the cache.00:31
enigma42Then it says they diverge.00:31
enigma42It says I'm missing 40 revisions.00:32
enigma42Basically, everything that has been committed since I first pulled down the branch.00:32
enigma42So, SVN has all the revisions.00:32
enigma42And the bzr branch has all the same revisions.00:33
enigma42But the revision IDs don't match.00:33
enigma42The IDs I'm getting from SVN are now different than the IDs in bzr.00:33
jelmerenigma42: But it doesn't report that you have 40 *extra* revisions as well?00:33
enigma42I'm missing 40 and I have 40 extra.00:34
enigma42From bzr:00:34
enigma42revno: 7300:34
enigma42revision-id: bhatpr@pbhat1-20090122095933-d3cmuadsx8jepmna00:34
enigma42parent: bhatpr@pbhat1-20090122094625-kq5y49s9uqagx45900:34
enigma42And from SVN:00:34
enigma42revno: 7300:34
enigma42revision-id: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:967100:34
enigma42parent: svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:sys-data-analyzer/trunk:967000:34
enigma42So, somehow the ID got lost.00:35
enigma42The branch format is: Standalone branch (format: rich-root-pack)00:35
enigma42Does it need to be something like 1-9-rich-root?00:35
jelmerno, that shouldn't matter00:35
jelmerwhat subversion version is the server running?00:36
enigma42It's svn 1.4 via collabnet00:36
jelmernot recently downgraded or anything?00:36
enigma42It's about to be upgraded to 1.5 this weekend.00:37
jelmerso bzr-svn uses svn file properties?00:37
enigma42I'm thinking so.00:37
jelmerenigma42: The repository is not public I assume?00:38
enigma42Unfortunately, no.00:38
jelmerenigma42: If you run e.g. "svn diff -c <last-svn-revnum> <url>", do you see any bzr-svn properties?00:38
enigma42OK. Let me try.00:38
enigma42No, I don't see any bzr-svn properties.00:40
enigma42I'm going to try putting the old cache back in place real quick to see what happens.00:40
=== spiv is now known as hypatia
enigma42Yeah. With the restored cache, it's happy again.00:41
jelmerenigma42, if you run "svn log --xml --with-all-revprops" on the last revision, do you see any bzr properties?00:42
enigma42Let me try.00:42
enigma42They are showing up as revprops.00:43
enigma42But bzr-svn thinks it's a 1.4 server because it complains about needing to upgrade to 1.500:43
=== hypatia is now known as spiv
enigma42jelmer: I tried using the ubuntu pastbin, but it's complaining about the xml.00:45
enigma42jelmer: Want an email?00:46
jelmerenigma42: No, thanks - I'm pretty sure this is related to the 1.4/1.5 logic00:47
enigma42Oh, OK.00:47
enigma42Let me know if you want more information.00:47
jelmerenigma42, since when have you been using 0.5 ?00:48
enigma42Well...the version I was using previously was checked out Dec 27.00:48
enigma42But, I've used a variety of versions in the last several months.00:48
enigma42Basically, I've been using bzr-svn since April.00:49
enigma42I can't remember the first version I used.00:49
enigma42It may have been 0.3.x...but I can't remember.00:49
jelmerenigma42, and when was the first of these 20 revisions that are now out of sync?00:49
enigma42Every revision commited to the branch since I checked out the branch on Jan 900:50
enigma42Using the version from Dec 2700:51
jelmerenigma42, is there a bzr:see-revprops file property set on the branch root ?00:51
enigma42Let me check.00:52
enigma42There is a bzr:see-revprops file property there now.00:53
enigma42Is it possible to do a bzr log on a file property?00:53
enigma42I mean an "svn log" on a file property.00:53
jelmerenigma42: no, I don't think that's possible00:54
jelmerwhat are the contents of that property ? It should be a svn revno00:54
enigma42It is: 957600:54
enigma42The lastest rev in subversion is: 972500:55
enigma42Little more info..00:55
enigma42This project used to be in /trunk/backoffice/sys-data-analyzer00:55
enigma42Then, as part of our transition to using bzr as a team, I did an "svn copy /trunk/backoffice/sys-data-analyzer /sys-data-analyzer/trunk"00:56
enigma42Then, I did a branch on "/sys-data-analyzer/trunk" to build the bzr branch the rest of the team uses.00:56
enigma42And I run a script to push changes back into svn for corporate compliance. ;-)00:57
jelmerah :-)00:57
enigma42So, it's a branch has been moved in subversion. That branch had not previously been touched with bzr-svn until after I moved it.00:57
enigma42And it has only been touched wtih the bzr-svn version from Dec 2700:58
jelmerSo what it seems to come down to is that bzr-svn should be looking at that bzr:see-revprops property (since this is svn 1.4)00:58
jelmerand that property has the correct value00:58
jelmerbut it's not reading it for some reason00:58
enigma42Is there some logging I can turn on?00:59
enigma42Other than the transport stuff?00:59
jelmerno, but this patch should add some:01:01
enigma42OK. Let me apply it.01:02
enigma42It's patched....01:04
enigma42Do you want me to move the cache out of the way?01:04
enigma42Start with an empty cache?01:04
jelmeryeah, please01:05
enigma42OK....doing a bzr missing01:06
enigma42OK...where should I look for the log?01:08
enigma42It says I'm missing 43 revisions and I have 43 extra revisions.01:09
jelmercheck ~/.bzr.log01:09
jelmerthat should give some extra data01:09
enigma42Want me to pastbin it?01:09
jelmerplease do01:09
enigma42OK...just a minute....I'll post it....01:11
enigma42OK...I'm going to put my old svn-cache back for now.01:14
enigma42I've got to run....I'll be back on IRC tomorrow.01:14
jelmerah, I think I've got it01:14
enigma42I'll leave it logged in....01:15
enigma42If you post a fix, I'll pull it down and try it out in a couple of hours.01:15
jelmerenigma42, http://samba.org/~jelmer/tmp/fix-changes-root.diff01:16
enigma42OK....let me try.01:16
jelmeryou'll need to revert the patch I posted earlier01:16
enigma42I'll re-export from trunk.01:16
enigma42OK...here goes....01:17
enigma42REbuilding the cache....01:17
enigma42Branches are up to date!01:18
enigma42Woohoo! :-D01:18
jelmercool :-)01:18
enigma42Thank you so much!01:19
jelmerThanks for confirming, that was a pretty stupid bug01:19
enigma42No problem. I'm happy I could help out. :-D01:19
enigma42I'll do a full sync of all the different repos later and make sure all is well.01:19
enigma42Thanks again.01:19
enigma42I've been really pleased with 0.501:19
enigma42Following copies is great!01:20
enigma42Well...I'm off for now....bye....01:20
=== enigma42 is now known as enigma_afk
thumperis there a short cut to go to the bottom thread of a loom from the top thread?01:45
thumpernm, found it01:48
thumperdown-thread [thread-name]01:48
=== jfroy|work is now known as jfroy
=== jfroy is now known as jfroy|work
* thumper has found a weirdness03:36
thumperin locations.conf I have a default push location set with append path03:36
thumperfor one of my branches, I wanted this slightly different03:37
thumperso `bzr push --remember xyz`03:37
thumperhowever bzr tells me that value xyz is masked by locations.conf03:37
thumpersurely if I say --remember, it should override a default???03:37
mwhudsonthumper: --remember sets stuff in branch.conf and locations.conf wins over branch.conf03:39
mwhudsonthere was a thread about this on the mailing list a few months back03:39
mwhudson(i don't understand the reasoning)03:39
lifelessjelmer: ^ may interest you. Thats invoking git-cat-file per object04:15
lifelessmorning kiko04:18
lifelessjelmer: how are we meant to access the dulwich that is in bzr-git?04:24
lifelessjelmer: b.p.git.dulwich ?04:24
* igc out for a few hours04:30
j^why does the ppa repository for hardy remove bzrtools?05:16
rockstarj^, once the updated bzrtools gets installed, then it won't remove them.05:32
vilahi all06:54
mcfletchPPA for Intrepid seems to have been broken (bzrtools is 1.10, bzr is 1.11).08:30
AfCmcfletch: are you actively using something from bzrtools? If not, then you could un-install it [for now] and get around the problem\08:32
* AfC is using bzr 1.11 from PPA but didn't see your problem as I don't have bzrtools installed08:32
mcfletchHmm, interesting, aptitude was telling me it was "broken"... I actually switched back to 1.6 to commit the changes... will try again...08:37
mcfletchAh, I was reading the "recommended" as "required" and the second confirmation as a "you can't do that, choose something else"... guess I shouldn't updates software at 3am.08:41
mcfletchthanks for the clue-stick.08:41
wgrantjelmer: Using a fresh checkout with bzr-svn 0.5.0~rc1+bzr does work, unlike 0.4.16, and all that fails is a reconcile (check works fine, which is odd). I can then branch that existing local branch locally, and it will work fine. But then checking it out once it's pushed to LP fails with a 'No such file'. I'm very confused.09:26
=== kiko is now known as kiko-afk
=== asac_ is now known as asac
Lo-lan-doHi all12:44
james_whi Lo-lan-do12:45
Lo-lan-doWe're debating the ol' git-vs-bzr debate for starting a new project, and I wondered how functional the bzr-git plugin was (or was expected to get soonish)12:46
james_wLo-lan-do: guess who's working on it :-)12:46
Lo-lan-dojelmer?  Well, he'll be happy to get rid of me for bzr-svn, but maybe I'll switch to pester him on bzr-git :-)12:47
james_wLo-lan-do: it's kind-of functional now, and improving quickly12:50
james_wLo-lan-do: I'm not sure how differences in bzr and git limit it though12:50
Lo-lan-doDoes it work both ways?12:50
Lo-lan-doie, commit to git from bzr and vice-versa?12:50
james_wnot sure12:51
james_wI imagine it will work like bzr-svn does12:51
fullermdBut with less svn-induced wonkiness, I should think.12:58
fullermdThe bzr and git data models are fundamentally so similar that there should be a lot fewer impedance mismatches.12:58
Lo-lan-doI'll give it a try, I guess.  We've agreed to have both so far until we can test how interoperable they are.12:59
jonnydeeI've got a question regarding 'bzr join': after joining a tree, is the sub-tree fully contained in the parent branch? I mean can I remove the .bzr-directory of the joined tree?13:22
sjokkishi. i've made a branch of my project, and i want the branch to become the new trunk. what's the best way to do this?13:27
sjokkis(the branch was made to port the project from c++ to c, so i don't think merging is viable)13:27
luks'trunk' in really unrelevant in bzr13:28
sjokkisso just delete trunk and copy the branch so it's a new trunk?13:28
lukswhat trunk?13:29
luksit depends on your setup13:29
sjokkisthey're all just branches with different names, eh?13:29
fullermdMerging could still be viable.  Or you could mv away the old trunk and stick it in its place.  Or you could pull or push it over the existing trunk.  Or just advertise that the trunk is a different place now.  Or...13:29
sjokkisfullermd: well the files have new names now that they're in c and not cpp13:30
luksthat doesn't really matter to bzr13:30
fullermdWell, but you branched off that to start with, right?13:30
fullermdSo the only difference between merging and switching is that in one case, the bighugechange happens in one mainline rev, and in the other it's spread over N mainline revs.13:31
fullermd(which isn't to say that you necessary _want_ to do it via merge; but it's just as viable an option, depending on details, as the others)13:33
jelmerwgrant, you need the 0.5 branch, rather than the rc13:34
jonnydeeI tried to 'join' a tree but I get an error: "bzr:ERROR: Cannot join FooBar.  Trees have the same root". What am I doing wrong?13:34
pooliewe're chatting about the bzr home page; some notes are in gobby.ubuntu.com if anyone's interested13:45
sjokkiswhat's the common way of creating tags in bzr? i'm used to copying to project/tags from svn, but it seems bzr just gives the current (or a specified) revision a name. is this how it's supposed to be done?13:45
wgrantjelmer: I'm running r2355 at the moment; do I need later?13:46
jelmerwgrant, no, I think that should be sufficient13:47
jelmerwgrant, what's the error you're getting exactly13:47
=== Mario__ is now known as pygi
wgrantjelmer: On the checkout from LP:13:49
wgrantbzr: ERROR: No such file: ('1123@2b9c9e99-6f39-0410-b283-7f802c844ae2:trunk:ivle%2Futil.py', 'svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:branches%2Fstorm:1132')13:49
jelmerand the backtrace?13:49
wgrantThe checkout doesn't give one.13:49
wgrantThe reconcile on the original local copy does; do you want that?13:50
jelmerah, ok13:50
jelmerwgrant, I'll try that here locally13:50
wgrantjelmer: Thanks.13:50
bob2sjokkis: with the tags command13:51
jelmerwgrant, reconcile passes successfully here13:56
wgrantjelmer: Huh. I'll try checking out again on another box.13:56
bond`how can i export a revision with the original file dates?14:05
bob2bzr doesn't version ctime/atime/mtime14:07
bond`is this a planned feature?14:09
LeoNerdI doubt it, for the complexities of making it work cross-platform14:09
Jc2kit would probably confuse build systems, too14:10
bond`so i have no possibility to see the original file time?14:10
bob2what do you mean by 'original'?14:10
fullermdWell, the time of commit is known.  So theoretically, export could set file mtimes to the time of last change.14:11
bond`bob2: the time the file was changed14:11
fullermdOf course, in any but very carefully crafted cases, the time of commit would be different from the mtime of the file when it was committed, and I'm pretty sure that isn't stored.  But do you really care about the difference?14:11
bob2bond`: bzr log filename14:11
jamvila: ping14:12
vilajam: pong14:12
bond`bob2: thats ok, i'd like to see something which 'svn export' or 'hg archive' does14:13
* fullermd points at bug 26226114:16
ubottuLaunchpad bug 262261 in bzr "Should use the revision timestamp when exporting" [Unknown,Confirmed] https://launchpad.net/bugs/26226114:16
bond`fullermd: that's what i mean14:22
wgrantjelmer: http://pastebin.com/d3e21e522 is what I get when reconciling a fresh checkout from svn trunk. It really works fine for you?14:34
jelmerwgrant, a clean branch created from http://ivle.googlecode.com/svn/trunk/ using bzr-svn reconciles fine for me14:35
jelmerwgrant, can you perhaps try a clean import, after removing ~/.bazaar/svn-cache ?14:35
wgrantBut... but...14:35
wgrantjelmer: That's what I tried.14:35
jelmerwgrant, and if you try with a newer bzr-svn?14:35
jelmerI don't think there's actually any fixes recently that could affect this though..14:36
wgrantjelmer: I looked at stuff post-2355, and it doesn't look relevant...14:36
* wgrant removes stuff from subversion.conf.14:36
jelmerwgrant, I'm just trying to eliminate things that could cause it to work for me but not for you14:37
wgrantjelmer: You're running bzr 1.11, or bzr.dev?14:38
jelmerwgrant, bzr.dev14:38
wgrantjelmer: OK, removing all svn-related config didn't work; trying with latest bzr-svn trunk now...14:58
=== beaumonta is now known as abeaumont
sjokkishi, how do i go undo all changes i've done since the last commit?15:09
jelmersjokkis, "bzr revert"15:09
sjokkisoh. that was simple. thanks15:13
wgrantjelmer: It still doesn't work... Do we blame bzr 1.11?15:15
* wgrant should go to bed ~now.15:15
jelmerwgrant, not sure :-( Is there any chance you can try with bzr.dev ?15:15
wgrantjelmer: I'll hopefully try tomorrow (I'm gone for a week after that).15:16
wgrantThanks for your help!15:16
jdobrienI had some trouble with my bzr installation and I can't figure out how to fix it15:26
jdobriensudo apt-get install bzr .... seems to work15:27
jdobrienbut then:  bzr15:27
jdobrienbash: /home/john/bin/bzr: No such file or directory15:27
jelmerlooks like you have a dangling symlink there15:29
jdobrienyeah i removed it15:29
jelmerand you still get that error?15:29
jdobrienyeah...im hunting for the symlink...it has to be somewhere15:32
jdobrienfound it15:33
LarstiQhey jdobrien15:34
pooliehi guys15:34
jdobrienhi LarstiQ15:34
pooliejdobrien: you may need to type 'rehash'15:34
jdobrienhash -r?15:35
jelmerhi LarstiQ, poolie15:36
LarstiQhey jelmer :)15:36
jdobrienLarstiQ: thanks15:36
jdobrienThe following packages have unmet dependencies:15:37
jdobrien  bzrtools: Depends: bzr (< 1.11~) but 1.11-1~bazaar1~intrepid1 is to be installed15:37
jdobrienE: Broken packages15:37
jdobrienhi poolie15:38
jdobrienjohn@Monolith:/usr$ bzr version15:41
jdobrienBazaar (bzr) 1.1115:41
jelmerkfogel, hi15:49
kfogeljelmer: just responding to the web site summary mail15:50
=== Pieter_ is now known as Pieter
jelmerkfogel, Actually, I had a Subversion question16:00
jelmerkfogel, I've been pulling my hair out trying to use svn_wc_process_committed()16:01
jelmerkfogel, it seems to require that the files it's called on are already marked unchanged. Is that correct?16:01
kfogeljelmer: can you ask me in #svn?  (and rephrase -- I confess I didn't quite understand the question :-) )16:09
jelmerkfogel, yeah, np16:09
=== andreas__ is now known as ahasenack
jrwrenERROR: selected file commit of merges is not supported yet.16:41
jrwrenIs that true?16:41
jrwrenjust trying to bzr commit -x PathToExclude16:41
jelmerjrwren, yes, that's correct - cherrypick merges are not yet supported16:45
jrwrenthis is really hurting me now :(16:46
jrwrenplus its something my svn loving, bzr hating coworkers can hang over my head :(16:46
=== bac is now known as bac_lunch
kfogelhttps://savannah.gnu.org/support/index.php?106612  ("Preparation for switching Emacs from CVS to bzr on Savannah.")17:01
kfogelthought people here might be interested17:01
Kobazpeople still use cvs?17:04
Lo-lan-doThey could have switched to GNU Arch...17:05
jelmerkfogel: Nice!17:05
jelmerkfogel: I've been wondering about the bzr support on Savannah, e.g. it would be nice if they could run loggerhead17:06
kfogeljelmer: I think they do, but it's in beta17:07
kfogelthat's part of what I'm asking in that issue17:07
Lo-lan-doA new loggerhead release with some of the proposed patches merged in would help, in that regard *hint* *hint*17:09
Lo-lan-do(I'm probably going to become more and more annoying about loggerhead in the near future :-)17:11
* jelmer is eagerly waiting for the first non-start-loggerhead release..17:12
jelmerkfogel:  Are you still looking for an editor for the scenarios on the wiki ? (Sorry, just catching up with list email)17:32
jelmerkfogel, I'm happy to edit some of the scenarios about topics I'm familiar with17:33
kfogeljelmer: an aggressive editor -- that is, one who can not only edit scenarios, but take out / add scenarios based on list discussion.17:33
kfogelMy initial list of scenarios is *not* to be treated as gospel.  quite the opposite.17:33
kfogeljelmer: it sounds like when you say "edit" you mean what I think of as "write"17:34
jelmerkfogel: Yes, sorry17:35
kfogelplease do!17:37
kfogeljelmer: the reason is that the other purpose (perhaps the real purpose?) of the scenarios is to help us figure out what stories bzr doesn't know how to tell yet.17:37
kfogelFor example, just trying to write the one-off bugfix scenario has exposed that we don't, actually, *have* a recommended way to go about this that everyone agrees on.17:38
kfogelIt's important to find that out.17:38
jelmerkfogel: Ah, right17:38
kfogeljelmer: so, you write the scenarios you feel comfortable with.  Then we see if people say "Wait, that's not how I'd do it!"17:39
jelmerwill do :-) I actually already see two existing scenarios I would object to..17:40
jelmerI've added http://bazaar-vcs.org/Scenarios/ConvertFromSVN17:45
=== enigma1 is now known as enigma42
Peng_How does one fix conflicting tags? Delete it and pull again?18:03
enigma42Peng_: I just ran across that too.18:06
enigma42I got a "conflicting tag" message when using bzr-svn.18:06
enigma42I delete the tag from the repo, deleted it from svn, retagged the repo and then pushed.18:07
enigma42It seemed fine until the second push.18:07
enigma42When I got the message again.18:07
Peng_I went ahead and deleted them. Blah.18:09
enigma42jelmer: Any idea on how I could track down the "conflicting tag" error?18:09
* Peng_ does it to another copy of the branch too.18:09
enigma42jelmer: How do I see what rev svn thinks the tag is pointing to?18:09
jelmerenigma42, bzr tags --show-ids18:10
enigma42So, I get this: 0.11                 svn-v4:daff2dd8-1c3d-0410-9cd2-f6297dd8f964:frame-broker/trunk:942518:13
enigma42SVN thinks the tag is set to 9425?18:14
enigma42Is there a way to ask SVN to see revision project/tags/0.11 is pointing to?18:14
elmooh hai18:17
enigma42jelmer: Oh...I think my issues is related to the bad id problem we found yesterday.18:17
elmo# bzr ci -m "wut" alternatives/abort.7.gz18:17
elmobzr: ERROR: Not a branch: "/usr/share/postgresql/8.3/man/man7/abort.7.gz/".18:17
elmohas anyone seen that?  i can't reproduce it locally18:17
enigma42It looks like the revision id in svn is different than the revision ID in the bzr branch.18:18
jelmerelmo, I think I've seen that18:18
jelmerelmo, And caused by some plugin I had installed18:18
jelmerelmo, What plugins are installed on the host where you get that error?18:18
jelmerenigma42, Ah, that would explain it18:18
elmojelmer: just bzr tools18:19
elmoah, actually I can reproduce it locally18:19
elmolet me try with bzr 1.1118:19
enigma42jelmer: I'm re-branching off SVN...I'll see what happens...18:20
enigma42jelmer: OK...Now I have a new issue: bzr: ERROR: The branch svn+https://sequoia.csd200a.com/svn/sequoia/frame-broker/trunk has no revision None.18:22
enigma42So, it's refusing to make a branch.18:23
jelmerenigma42: That's most likely fallout from the problem we fixed yesterday (a tag referring to a nonexisting revision?)18:23
enigma42So, I should be able to fixup the svn reprop?18:24
jelmerenigma42, Any chance you can comment out the bit in bzrlib/builtins.py where it prints that message by catching NoSuchRevision?18:24
enigma42jelmer: OK...let me try.18:24
Peng_jelmer: I just hit bug 308353 again, with the latest trunk (more or less). :\18:25
ubottuLaunchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Medium,Fix released] https://launchpad.net/bugs/30835318:25
enigma42jelmer: Grabbing a source copy of bzr so I can comment it out.18:25
elmole sigh18:25
jelmerPeng, which URL?18:25
elmojelmer: it's https://bugs.launchpad.net/bzr/+bug/128562, FWIW18:25
ubottuLaunchpad bug 128562 in bzr "bzr commit FILE breaks when given symlink as argument" [Medium,Confirmed]18:25
elmo(and is still broken in bzr 1.11)18:25
jelmerelmo, ahh18:26
Peng_jelmer: Same URL (lighttpd-1.4.x)18:26
jelmerPeng_, just doing a clean branch?18:26
Peng_jelmer: No, "bzr pull".18:27
Peng_Err, wait a minute. I hit *something*, but I'm not sure it's the same something.18:28
enigma42jelmer: Do you want me to comment out the whole "except" block?18:28
enigma42jelmer: It looks like it deletes the tree, prints the message, and raises a different error.18:29
Peng_jelmer: Sorry, my mistake. It was just the bzr-search error I get. I forgot that it indexes the branch on "pull", and most of the traceback went off my screen.18:29
pooliehello all18:29
poolieabentley, if you're here -  http://bazaar-vcs.org/WritingPlugins used to advise people to merge their plugins into bzrtools18:30
pooliei removed it18:30
poolieit's an option but i don't think we want it to be a catch-all18:30
jelmerenigma42, yes, please18:30
jelmerenigma42, that should make it show the proper traceback18:30
jelmerPeng_, Ah, so this is the same problem you reported a bug for earlier?18:31
abentleypoolie: Okay18:31
Peng_jelmer: Yeah, it's nothing new. I just forgot that bzr-search kicks in on "pull".18:31
=== bac_lunch is now known as bac
abentleypoolie: The desire was for bzrtools to become a collection of utilities so that people didn't have to spend forever installing new plugins.18:33
enigma42jelmer: OK...I'll pastbin the traceback....18:33
abentleypoolie: shelf and heads have worked out that way, but few others.18:33
jelmerPeng_, which reminds me, do you have a link to that bug?18:33
enigma42jelmer: http://pastebin.ubuntu.com/108674/18:34
jelmerenigma42, that looks like a problem in what you changed in builtins.py18:34
Peng_jelmer: https://bugs.launchpad.net/bzr-search/+bug/31893518:34
ubottuLaunchpad bug 318935 in bzr-search ""Did not find ids" when indexing a bzr-svn-imported branch" [Undecided,New]18:34
enigma42jelmer: Oh..I see it...the exception was thrown before "branch" was assigned....18:39
jelmerPeng_, Thanks18:40
* enigma42 is commenting out more stuff...18:41
enigma42jelmer: Well that's strange...I cleared the cache and now I don't get an error.18:49
enigma42jelmer: Must have been one of those bad ids stuck in the cache.18:49
enigma42Oh wait...hold on...18:50
enigma42I must have commented out too much stuff.18:50
* apw wonders if there is a command to bzr command line to show both the summary message and the diff for a commit in one go18:51
* enigma42 is changing the commenting again...18:51
enigma42Ah ha! I figured it out....my python is a bit rusty... :-P18:56
enigma42jelmer: OK...let me get this backtrace into the pastebin....18:57
Peng_Oh, I just hit a bunch of conflicting tags in bzr-svn too.18:58
* mgedmin actually also wants what apw wants18:59
Peng_jelmer: With the very latest bzr.dev, there are warnings about your "determining changes" progress bar.18:59
Peng_One for every revision, in fact. :D18:59
mgedminso, can bzr do what 'git log -p' does, i.e. show the diff for every log revision?19:00
* Peng_ looks at apw and mgedmin.19:01
jelmerenigma42, thx19:01
pooliemgedmin: iirc there's a patch to add that up now19:02
jelmermgedmin, not yet, but there's a patch waiting for inclusion19:02
poolieyou can test it!19:02
jelmerpoolie, After pulling bzr.dev I'm now getting the following error:19:13
jelmer/home/jelmer/bzr/bzr.dev/bzrlib/ui/text.py:96: UserWarning: ProgressTask(1165/2000, msg='determining changes') is not the top progress task ProgressTask(1164/2372, msg='analyzing repository layout')19:13
jelmerwhat does this mean exactly ?19:13
enigma42jelmer: I'm looking at the revprops...in the svn repo.....It looks like the "base-revision" is not the same as the "rev-id" of the parent.19:14
jelmerenigma42, the uuid is different?19:14
* davidstrauss is waiting for one of the 500 people in #git to not ignore him so he can write a balanced blog post comparing a git workflow to bazaar's.19:14
jelmerenigma42, Did the svn repository recently change its UUID ?19:14
enigma42So, the revision ID isn't using the svn UUID at all.19:15
enigma42Since the revision was pushed into SVN from bzr, I presume...19:16
jelmerenigma42, yeah, but it refers to its parent revision19:16
=== enigma1 is now known as enigma42
enigma42jelmer: How much of that log did you get? I tried to /msg it to you.19:17
jelmerI saw some of it19:17
enigma42Let me try little chunks....19:18
jelmerenigma42: But the problem appears to be that the Subversion repository UUID has changed since that bzr-svn revision was committed19:18
jelmerCould that be correct?19:18
jelmerare you perhaps working on a svnsynced copy of the repo?19:18
jelmer'morning Ian19:19
jelmerenigma1, did you see my messages here?19:20
enigma1jelmer: The only thing that has changed is that I delete my svn-cache....and you fixed that bug around the ids.19:20
=== enigma1 is now known as enigma42
enigma42jelmer: How do I find the SVN UUID?19:21
jelmerenigma42: "svn info <repos-url>"19:21
enigma42jelmer: No...it looks like the subversion ID is the same.19:22
enigma42jelmer: This is my guess...19:22
enigma42What I saw yesterday before the bugfix was that bzr-svn was inventing rev-ids instead of using the ones that were stored in the revision properties.19:23
enigma42So, somehow, when I tagged, the rev-id that had been invented was used instead of the rev-id that was stored in the SVN revision property.19:23
jelmerenigma42, see privmsg19:23
pooliejelmer:  the warnings mean there is probably a missing pb.finish() on the progress bar with those messages19:25
poolieor, as in one other case, the finally is wrapped around an iterator, so it's firing asynchronously to the operation actually finishing19:25
pooliei'm open to either fixing them up or silencing the warning19:25
pooliewe should do one or another before releasing19:26
=== jfroy|work is now known as jfroy
=== jfroy is now known as jfroy|work
jelmerpoolie, yeah, it's two progress bars working at once19:34
jelmerA function that iterates over a set of revisions by calling a generator19:34
jelmerthat function has a progress bar19:34
jelmerand the generator also has a progress bar19:34
enigma42jelmer: OK...I fixed up the rev-id....trying to branch again....19:38
pooliejelmer: ok, that's good to know19:39
pooliebecause i was wondering whether we needed to support two of them updating at the same time19:39
pooliethe api is a bit unclear about whether it's meant to be a stack or not19:39
jelmerpoolie: it does make sense to only have one in this situation I guess19:39
pooliejelmer: so is one of them nested inside the other?19:40
poolieor, are they unsynchronized?19:40
poolieand if so, how would you like them drawn in the text ui?19:40
phinzeokay, bazaar is confusing me today.  i have a local branch of a shared project branch i was working on (last pulled at 2117).  i made a commit (2118) locally and attempted to push, but the branches had diverged and bzr tells me to merge.19:40
jelmerphinze, what does "bzr missing" report?19:40
phinzeso i merge with the project branch which pulls down three revisions that had made it in while i was working19:41
jelmerpoolie, I need to check19:41
phinzethen i commit the merge 'merged with project branch', (2119)19:41
phinzeand i push19:41
pooliejelmer: just let me know19:41
enigma42jelmer: Woohoo! Branched just fine. Going to try a push and pull for good measure....19:41
phinzebut now the three revisions i pulled down (from someone elses work) show up as sub-revisions from my commit19:41
enigma42jelmer: Great! It's working fine. The tags are now in-sync between the bzr branch and the svn repo. :-D19:43
enigma42jelmer: Thanks again for your help. And thanks for showing me the "svn log --xml --revprops -r ___" trick.19:43
jelmerenigma42, Np, thanks for helping get this bug fixed before 0.5.0!19:44
jelmerphinze, yes, this is intentional behaviour of "bzr merge"19:44
Peng_What determines whether bzr-svn will spend a bunch of time "determining changes" when pulling or not?19:45
enigma42jelmer: I'm happy to help. Thanks for making bzr-svn! It lets some of us use a *real* VCS in a heavily centralized corporate environment!19:45
jelmerPeng_, "determining changes" means it's walking history, that can be triggered by various things19:48
phinzejelmer: okay, but say i didn't work that gets commited while i'm working to show up as a sub-revision when i merge... how would i change my workflow?19:48
phinze*didn't want work19:48
phinzeperhaps i need to add to my workflow a mirror branch rather than just maintaining one local branch that i sync with the shared project branch...?19:51
phinzeor perhaps the best answer is, "don't worry about other commits showing up as sub-commits from your merge... get over it!" :)19:54
jelmerphinze: Yeah, I think that summarizes it up well19:56
jelmerPeng_, I fixed that bug19:56
Peng_jelmer: Which bug?19:59
jelmerPeng_, 31893519:59
jelmerPeng_, bug 318935 I mean19:59
ubottuLaunchpad bug 318935 in bzr-search ""Did not find ids" when indexing a bzr-svn-imported branch" [Undecided,New] https://launchpad.net/bugs/31893519:59
davidstraussIs there a way to automate bzr-search indexing on a server?20:00
davidstraussI mean, other than crontab.20:00
Peng_jelmer: Oh. It was a bzr-svn bug?20:00
jelmerPeng_, yep20:00
jelmerPeng_, bug in the bugfix for that other bug :-)20:01
Peng_jelmer: Heh, nice. Have you pushed it yet? Do I need to do anything, like delete the cache or recreate the branches?20:01
jelmerPeng_, Yeah, it's been pushed. You need to recreate the branch and delete the cache.20:02
Peng_Both? Awesome! :D20:02
Peng_Thanks for fixing it.20:02
jelmerpoolie, I've fixed the progress bar issues20:03
jelmerpoolie, Simply by not using the inner progress bar, it wasn't adding much useful information anyway20:03
pooliei'm totally open to changing or fixing the api if you need something richer20:04
jelmerpoolie, I think it needs to be richer, but I'm not entirely sure how :-)20:06
jelmerpoolie: I think at least it's important for progress bars that each step takes an equal amount of time20:07
poolieor as near to it as you can get, allowing for environmental variations20:07
jelmerpoolie, the "Fetch phase X" thing where there's 4 phases that all take arbitrary amounts of time is very uninformative20:07
poolielike obviously if you're doing disk io and network io the relative speeds will be unpredictable20:08
pooliejelmer, i agree20:08
pooliei think the "phase" thing is questionable20:08
pooliethe basic idea there is that we want the progress bar to appear just once for each command and fill monotonically from left to right20:08
poolierather than one bar for fetching and then another for building the tree20:09
jelmeroh, ok20:09
poolieso it's not a bad thing to want20:09
pooliebut i don't think the result is very satisfying20:09
pooliethis patch improved a couple of things: you see all the stacked tasks, so usually more than just "fetch 1/4"20:09
jelmerI think I prefer separate bars but having bzr print a new line with what it's completed20:09
poolieand also, (currently only for sftp) you get an indication of network io20:10
poolieseparate bars would be good20:10
jelmerpoolie, Yeah, I agree the new progress bar is an improvement20:10
Peng_jelmer: Yay, it works. :)20:12
poolie'bzr serve --http' does what it should20:12
Peng_bzr+http or Loggerhead?20:12
jelmeror both ? :-)20:12
Peng_Oh, thank goodness, those pb-related warnings don't go in .bzr.log.20:13
jelmerPeng_, they're fixed in 237920:13
Peng_jelmer: Okay, thanks.20:14
pooliePeng_: actually loggerhead, but beuno and jml are making loggerhead serve bzr+http20:15
poolieso, this afternoon, hopefully both20:15
jmljust http to start with20:16
jelmerthat's a *really* neat thing to have20:16
poolieand loggerhead will be (optionally) a plugin20:20
poolieoptionally meaning you can use it in the same way as before20:21
Peng_#I'm being lazy here, but what was the summary of enigma42's tag conflict problem? I'm experiencing conflicts in some (but not all) tags, but I don't think20:34
Peng_Peng is an idiot.20:34
Peng_I didn't mean to send that. :)20:35
Peng_Although it's true, but anyway, I was going to investigate it more first.20:35
jelmerPeng_, It was related to a strange corner case bug caused by svn 1.4 on the server and bzr-svn not always looking at revision properties20:37
Peng_Oh, I think it's because some are using "svn-v3" revids and some are using "svn-v4".20:37
jelmerthat primarily caused diverging branches20:37
Peng_Oddly, the copy made 5 minutes ago is using more "svn-v3" ids.20:37
jelmerPeng_: Can you please file a bug?20:42
Peng_I wasn't using a 100% new repo; I "bzr branched" two (non-corrupt) branches into it.20:44
Peng_Oh, "bzr log" shows a lot of svn-v3 ids too.20:45
DBOyou know what would rock?  If bzr could figure out when you move a file without having to use bzr mv20:46
DBOmmhmmm mhmmm =)20:46
Peng_I've kind of confused the situation by swithing out the repos too. Hmm.20:46
jelmerPeng_, Yeah, it's correct there are svn-v3 ids there20:49
jelmerPeng_, that's because there are revisions created with older versions of bzr-svn20:49
Peng_jelmer: What do you mean? My branch is (almost) completely new.20:49
Peng_You mean revisions in the svn repo pushed by older versions of bzr-svn?20:49
jelmerPeng_, yes20:50
Peng_It looks like it's all "svn-v3" except for the very newest revision.20:50
jelmerPeng_, yeah, everything since the last revision pushed with bzr-svn 0.4.x will be a svn-v3 revision20:50
jelmerPeng_, That bit seems to work fine20:51
jelmerexcept bzr-svn gets confused about what mapping to use for those tags apparently20:51
Peng_Well, the more recent branch gets it right much more often.20:51
jelmermore often is not good enough :-)20:51
Peng_The new branch has: 22 tags (1 svn-v4, 1 bzr, 20 svn-v3), 20 of which it can map the revid to a revno, 2 of which show "?".20:53
jelmerso for what tags do you get conflicts?20:53
Peng_I've been doing lots of things to this repo today, so I don't even remember.20:54
Peng_I think I got the conflicts on about 6 tags with the old branch and old repo.20:54
Peng_jelmer: FWIW, pastebin of "bzr tags" on both branches: http://paste.pocoo.org/show/BIEg11uNyMGQ4Fr1phem/20:58
jelmerPeng_, thanks21:01
jelmerlifeless, ping21:01
* jml submits the branch for review.21:04
vilajam: ping21:04
nxsryanhi.. i'm trying to do brz branch lp:trac-bzr but i think i have an older version of bazaar that doesnt convert "lp21:09
nxsryanhi.. i'm trying to do brz branch lp:trac-bzr but i think i have an older version of bazaar that doesnt convert "lp" into a URI21:09
nxsryancan someone tell me what URI 'lp' stands for?21:10
Peng_nxsryan: You should upgrade bzr. You'd have to be on a really old version.21:10
nxsryansure but.. that's not a complete URI21:10
Peng_nxsryan: What command did you run and what error message did you get?21:10
nxsryanPeng_: i know i should but that's not an option at the moment21:10
Peng_nxsryan: Bazaar does a bit of magic to turn it into a real URL.21:10
vilawhat do 'bzr version' and 'bzr plugins' say ?21:11
nxsryan# bzr branch lp:trac-bzr21:11
Peng_nxsryan: lp:trac-bzr points to http://bazaar.launchpad.net/%7Etrac-bzr-team/trac-bzr/trunk/ or bzr+ssh://bazaar.launchpad.net/%7Etrac-bzr-team/trac-bzr/trunk/21:11
nxsryanbzr: ERROR: Not a branch: /root/trac-bzr/lp:trac-bzr/21:11
nxsryanPeng_: ah, nice, thank you21:11
Peng_/root? *cough*21:12
Peng_...The Launchpad plugin has been around *forever*.21:17
nxsryanhrm, bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 6 (bzr 0.15)\n'21:18
vilanxsryan: what do 'bzr version' and 'bzr plugins' say ?21:19
nxsryani'm using 0.1421:20
vilathen, you need to upgrade to at least 0.15 at the message is hinting21:20
vilabut since 1.11 is out, please, just upgrade to that instead :)21:21
Peng_Huh, lp: URIs are newer than 0.14?21:21
Peng_Hmm, I think it was added in revision 2275.21:22
dereinehi is it possible to update a certain branch without ssh access, just ftp21:22
vilaPeng_: I dont't know I have all releases available from 1.0 but not earlier21:23
viladereine: It should21:23
dereinevila: i pushed to files onto the server21:23
dereinethen i tryed to use update21:23
dereinebut it didn't wokred21:24
Peng_Yeah, it was added in revision 2275. Apparently it wasn't found NEWSworthy though.21:24
Peng_But that would've been around 0.15 or 0.16.21:24
Peng_Yeah, 0.15.21:24
viladereine: update updates your working tree from the branch, do you want pull instead ?21:25
pooliejam, nice work on the locking patch21:26
dereinevila: does pull changes the files itself?21:26
jamvila: pong21:26
viladereine: pull updates your working tree yes21:26
jampoolie: thanks. I don't really *like* doing it that way, but since we have been waiting a long time to actually do it the right way21:26
dereinei will have a try thx21:26
jamI figured we may as well do *something*21:26
pooliebeuno: if __name__ == 'bzrlib.plugins.loggerhead':21:59
jmlpoolie: that won't work :(22:04
jmltry: from bzrlib.plugins import loggerhead; except ImportError: pass; else: ...22:04
jmlhmm. actually, that would work22:07
jmlsilly me22:07
beunoPeng_, loggerhead trunk needs you22:08
Peng_Oh, it just serves them as static files so far?22:18
jmlmwhudson: good morning. :)22:18
beunoPeng_, yeap22:19
beunono smart server involved yet22:19
Peng_Hmm, this conflicts with my setup. I have the branches available (with hpss) at /bzr, with LH at /loggerhead.22:23
beunoPeng_, and how does this overlap?22:24
jmlPeng_: you mean the URLs that loggerhead gives are the static LH urls, not the smart /bzr ones?22:24
jmlbecause they should both quietly mind their own business wrt serving branches.22:24
=== dereine is now known as dereine[OFF]
Peng_beuno: Loggerhead suggests branching it from /loggerhead.22:26
Peng_I already handle this with redirects, but it's messy.22:26
beunoPeng_, ah!22:26
beunoso it should be configurable22:26
Peng_Well, I could do some ugly monkeypatch in serve-branches, so it already is "-ish". :D22:28
Peng_Or I could just edit branch.py itself, of course, but that seems wrong.22:31
Peng_Oh wow, monkeypatching actually works easily.22:33
beunowell, it *is* loggerhead22:35
beunoigc, ping22:36
Peng_I was expecting the property bits to make it difficult to monkeypatch.22:36
Peng_Yay, my evil monkeypatch worked.22:42
Peng_beuno: Anyway, I haven't experienced any problems.22:44
beunoPeng_, awesome22:45
beunoand if you file a bug about maybe not exposing the URLs to branch from22:45
beunowe'll get it done22:45
beunojust for you22:45
=== dereine[OFF] is now known as dereine
Peng_But I only tested /changes, /revision, and /annotate; not the other pages, or the .bzr serving itself.22:46
igchi beuno22:46
beunohiya igc. How are you?22:46
igcnot too bad22:47
beunoI've been playing for quite a while with your plugin22:48
beunoigc, are you up to explaining some concepts/code?   I'd like to pitch in a little bit if I can22:48
beunoyou're using repository._old_get_graph22:49
beunoto get the graph22:49
igcI'm about to hack on it right now btw :-)22:49
beunoawesome then!~22:49
igcI'm doing whatever Branch.get_revision_id_to_revno_map() uses now22:49
beunoI'm curious about you using that bit, since bzrlib has a big comment: """DO NOT USE. That is all. I'm serious."""22:50
igc'cause I'm monkeypatching it22:50
igcbeuno: the current code is very short term hopefully22:50
igcI have a patch up to Branch giving it a new method: iter_merge_sorted_revisions()22:51
igcas soon as that lands, I'll look against it rather than the revo lookup hack22:51
Peng_beuno: Wait, what do you want me to file a bug about?22:51
beunoPeng_, maybe hiding the branch URL?22:52
beunoigc, so there's not other (good) way of doing this without patching bzrlib?22:52
Peng_beuno: I like having to branch URL shown, I just want it to be different. :)22:53
beunoPeng_, fair enough. What could we do to address your use case?  Use hpss by default?22:53
igcbeuno: not sure22:53
igcbut the right direction is caching the graph ...22:53
beunoigc, absolutely22:54
igcbecause then revno lookup, log, missing and friends can all "go fast"22:54
Peng_beuno: I'm not sure what you could do to address my use case. :P22:54
beunoigc, I'm trying to understand it in depth, so I can make it play nic with loggerhead22:54
igcright now, it's only the first of these22:54
beunoigc, in LH, to get the revision graph I do something like: http://paste.ubuntu.com/108777/22:54
igcbeuno: see I think you want iter_merge_sorted_revisions() as soon as it exists22:55
beunoigc, I do!22:56
beunoI'm stalking the ML waiting for that to land22:56
igcbeuno: I just posted an updated version a hour or so ago22:56
beunoigc, I saw. Waiting for jam to be happy and approve  :)22:56
igcbeuno: please check that it's API is useful to you know that I've extended it as jam requested22:56
beunoigc, I'll go through the code now and add a comment22:57
igcbeuno: cool. If poolie is near-by, bug him to look at it too :-)22:57
beunoigc, he's across the table from me. Not very awake, but here. I'll poke22:58
igcpoolie: ignore that poke if you're tired. I understand the value of sleep :-)22:59
beunoigc, so this patch lets you limit the range of the graph you generate?23:01
beunoby using revids?23:01
igcbeuno: yes23:01
beunoigc, unless I request revnos?23:01
beuno+        # Note: depth and revno values are in the context of the branch so23:01
beuno+        # we need the full graph to get stable numbers, regardless of the23:01
beuno+        # start_revision_id.23:01
igcbeuno: my goal is that, once loggerhead uses iter_merge_sorted_revisions(), it needs to do nothing else and it will get faster if revnocache is installed as well23:03
poolieigc: i bet23:03
igcbeuno: so my patch now generates and caches (in memory) the full branch graph23:04
beunoigc, I see. We currently cache the revision graphs in LH as well, using LRUCache23:04
igcrevnocache will complement that by saving/restoring the full graph, eliminating the calculation stage (except after a tip move)23:04
beunoaha!  that's where it gets interesting23:05
beunowe would load the graph from disk instead of re-generating it23:05
igcyes - revnocache does not now23:05
igc(with the right CACHING_STRATEGY configured)23:06
beunoigc, I still get around 7sec to do 'bzr log -r X.Y.Z' on mysql-server23:06
beunowith mergegraph strategy23:06
igcright, because log is regenerating the graph!23:06
beunoand a bit less with revno strategy23:06
beunohence the patch23:06
igc(and a follow-up refactor of log to call the new API)23:06
beunoigc, ok, so for LH to take advantage of this, this patch has to land, and I have to switch LH over to using iter_merge_sorted_revisions23:07
igcbeuno: yes23:08
beunojust perfect23:08
igcbeuno: so my coming revnocache hacks are ...23:08
igc1. change the graph cache to drop the seqnum23:08
igc2. support chaining23:08
igcThe latter will let us store just the graph since the parent23:09
igcand point to the parent cache if it's local23:09
igcperfect for the usual mirror+feature-branches setup23:09
beunocool, so it'll be less expensive when the branch gets updated23:09
beunoas long as it hasn't done merges?23:09
igcright, and much less storage23:10
* poolie goes to look23:10
igcbeuno: tip moves aren't optimised yet, merges or otherwise23:10
beunoigc, I do wonder why your patch still uses repository._old_get_graph23:10
beunoigc, right, that was one of the things I thought I'd try to poke at, as soon as I figured out all of this. But you're already on it  :)23:11
igcbeuno: only because I wanted to ensure my monkeypatch was bug-for-bug compatible23:11
igcbeuno: actually, I've love it if you could optimise the tip move bit23:12
igc(it's not high on my list yet)23:12
enigma42jelmer: Ping23:13
jelmerenigma42, pong23:13
igcbeuno: but you may want to wait a few hours until my next round of hacks ...23:13
enigma42This has got to be the strangest error I've seen yet.23:13
beunoigc, I could very well give it a try. It's past 9pm here, so not sure *when*, but it will be high in my list  :)23:13
enigma42jelmer: bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack23:13
poolieigc, you're refering to iter_merge_sorted_revisions?23:13
enigma42Let me pastebin it.23:13
jelmerenigma42, full backtrace?23:13
igcpoolie: yes23:13
igcbeuno: I'll put comments in the code and/or fire you an email about how to do it23:14
beunoigc, FWIW, I changed LH from _old_get_graph to get_graph() without any consecuences  :)23:14
beunoigc, that would be awesome23:14
enigma42jelmer: http://pastebin.ubuntu.com/108782/23:14
igcbeuno: ok, it's saturday morning here so my time is limited23:15
igcbetter get on with this hacking or it won't happen for a few days (long weekend here) :-)23:16
beunoigc, oh, please don't feel imposed. I'll give it a quick whack and see if I can send a patch to your patch  :)23:16
enigma42jelmer: This is bzr-svn 0.5 revno 237223:16
pooliethe good thing about having an intense sprint in argentina is that people (and restaurants) _expect_ to eat dinner at 11pm :)23:16
jelmerenigma42, when does this happen?23:16
igcpoolie: :-)23:17
enigma42So, this is an svn repo that has been used by bzr-svn 0.4.x for a while.23:17
enigma42This happens when branching.23:17
enigma42This is the first time I've tried 0.5 on it.23:17
jelmerenigma42, so it's a different repository23:17
enigma42Right. Not the one from before.23:17
enigma42This is a new repo I haven't posted about before.23:17
enigma42Coworker of mine was using bzr-svn 0.4 on it.23:18
enigma42First symptom was...23:18
enigma42Could pull down a branch just fine, but then could not make a local branch.23:18
enigma42(with 0.4.x)23:18
enigma42When trying to make the local branch, it complains about missing revisions.23:19
enigma42So, I thought I would give it a try with 0.5-trunk to see what happens.23:19
enigma42And that's the backtrace I posted.23:19
jelmerenigma42: So this is an error trying to parse one of the bzr-svn file properties23:19
enigma42jelmer: That doesn't sound very fixable...is it?23:19
enigma42I guess what I mean is the file property is probably messed up....23:20
enigma42Let me check to see if there are any revprops on this svn repo....23:20
jelmerenigma42, it's not a revprop that is invalid, it's a fileprop23:21
enigma42hughesw: This is your repo...when did you start having the problem?23:24
hugheswmonday. after updating to bzr 1.10 and bzr-svn 0.4.16 from the package on the bazaar site.23:24
jelmerany chance you can try with a patch that shows a bit more information?23:26
enigma42I'm happy to.23:26
enigma42Send me the patch. :-)23:26
enigma42(this patch would be against 0.5, right?)23:27
enigma42jelmer: Should I zap the cache?23:29
jelmerenigma42, no23:29
enigma42jelmer: branching....there are some big files in this repo so it takes a while....23:32
hugheswyeah the trunk of that repo is 52 MB...23:32
beunoigc, maybe something like this: http://paste.ubuntu.com/108789/23:34
enigma42jelmer: http://pastebin.ubuntu.com/108793/23:37
jelmerAre you sure that's with the patch applied? it doesn't seem to trigger the exception handling23:38
poolie(back to reading igc's patch thread)23:38
enigma42jelmer: I'll double check to be sure. But I'm pretty sure...23:39
jelmerenigma42, alternatively, can you run with BZR_PDB=1 as environment variable set?23:40
enigma42Yup. I just double checked...it has the patch for sure.23:40
jelmerenigma42, ah, sorry23:41
jelmerenigma42, what did it print on the screen?23:41
jelmerenigma42, rather than to .bzr.log ?23:41
enigma42Just pasting.....23:45
enigma42Should I type anything at the Pdb prompt?23:45
hugheswhey that looks remarkably similar to the error it was giving me when I tried to branch on my home machine with 0.4.1623:45
beunojml, http://people.samba.org/bzr/jelmer/bzr-gtk/trunk/23:47
poolieigc, done23:49
igcpoolie: thanks23:50
pooliejml: http://groups.google.com/group/fp-syd?hl=en23:51
enigma42jelmer: Just let me know if you want me to send you more info.23:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!