[00:03] <lifeless> spiv: so am I booking for 3, 4 or 5?
[00:04] <lifeless> jml: ping me when you leave home
[00:06] <jml> lifeless: will do
[00:06] <johnjosephbachir> if i merge in some changes from the parent branch, and they all come in smoothly and their own commit messages are sufficient to describe the changes, and then i want to commit them to my branch without my own log comments, is there slick/standard way to do this, or must i type "merging in some changes"
[00:07] <spiv> lifeless: good question, just a sec
[00:09] <Peng_> johnjosephbachir: Well, I think it's good practice to give a short (one-line) description in the merge commit.
[00:09] <johnjosephbachir> Okay.
[00:11] <Peng_> You can always copy and paste it from one of the revisions you're merging. :D
[00:25] <spiv> lifeless: 5, I think
[00:45] <garyvdm> I'm getting an error in some qbzr code that I'm working on - that I just can't figgure
[00:45] <garyvdm> http://pastebin.com/d98bbf0e
[00:46] <garyvdm> I'm expecting a InvalidRevisionSpec to be raised, but I get the TypeError displayed ing the pastebin
[00:47] <garyvdm> Please can someone help me out
[00:48] <lifeless> garyvdm: TypeError: 'NoSuchRevisionSpec' object is not callable
[00:49] <lifeless> garyvdm: you have something called NoSuchRevisionSpec which isn't a class (callable) or function(callable)
[00:49] <garyvdm> there is errors.NoSuchRevisionSpec - but I'm not calling it
[00:50] <garyvdm> It's not getting called anywhere
[00:50] <lifeless> run with BZR_PDB=1
[00:50] <lifeless> then you can debug
[00:50] <garyvdm> ok
[00:50] <garyvdm> export BZR_PDB=1 ?
[00:51] <lifeless> or just BZR_PDB=1 ./bzr foo
[01:01] <garyvdm> lifeless: I just get the same traceback written to the console.
[01:01] <lifeless> garyvdm: uhm
[01:01] <lifeless> put a pdb import and trace at the point its raised then, perhaps
[01:02] <garyvdm> ok
[01:07] <garyvdm> lifeless: fixed :-)
[01:07] <garyvdm> I had except errors.NoSuchRevisionSpec, errors.InvalidRevisionSpec:
[01:08] <garyvdm> changed to
[01:08] <garyvdm> except errors.NoSuchRevisionSpec:
[01:08] <garyvdm>    ...
[01:08] <garyvdm> except errors.InvalidRevisionSpec:
[01:08] <garyvdm>    ...
[01:08] <garyvdm> thanks
[01:11] <meoblast001> hi
[01:23] <lifeless> meoblast001: hi
[01:23] <igc> lifeless: I've started on the process of preparing brisbane-core patches for landing into bzr.dev
[01:24] <lifeless> igc: cool
[01:24] <igc> lifeless: I just want to check how you want it done ...
[01:24] <lifeless> igc: theres nearly 800 commits in bbc, I was thinking we might want to just cherrypick bits
[01:24] <igc> me too
[01:24] <lifeless> until the branch has no content
[01:24] <igc> so my plan is ...
[01:24] <igc> merge bzr.dev into bbc (done)
[01:24] <igc> branch bzr.dev xxx
[01:24] <lifeless> and iterate
[01:24] <lifeless> sure
[01:25] <lifeless> lets start with chk_map
[01:25] <lifeless> actually
[01:25] <igc> merge ../brisbane-core/x ../brisbane-core/y ../brisbane-core/z ...
[01:25] <igc> right
[01:25] <lifeless> lets start with the knit changes to support autogenerating the keys from the sha
[01:25] <lifeless> 1
[01:25] <lifeless> that will lead into chk_map
[01:25] <lifeless> which leads into the inventory changes
[01:25] <igc> so first patch with be gc + chk as that's all new stuff + some tweaks to setup.py & tests/__init__.py
[01:26] <igc> knit stuff is knit.py + what else?
[01:26] <lifeless> gc and chk are separate things
[01:26] <lifeless> I'm not sure you should land them together if you want to be doing specific patches
[01:26] <igc> ok
[01:27] <lifeless> knit stuff is knit.py/weave.py/versionedfiles.py and their tests
[01:27] <igc> ok, I'll do that one first, then gc, then chk_map
[01:28] <igc> lifeless: and you can review/approve them :-)
[01:29] <lifeless> sure thing
[01:30] <lifeless> I'd be inclined to do knit stuff, chk_map, chk_inventory, gc, new-format. With anything not covered by that list as soon as it can be done topologically.
[01:46] <lifeless> Peng_: ping
[02:05] <Peng_> lifeless: pong
[02:05] <lifeless> Peng_: did you send a bundle to the list or just push your branch
[02:06] <Peng_> lifeless: Both.
[02:06] <lifeless> hmm, I can't see the bundle
[02:06] <Peng_> lifeless: Although my email client and/or IMAP server are screwy, so I can't *read* the list.
[02:06] <lifeless> I'll merge your branch to another branch fleshing out the config stuff I have
[02:06] <Peng_> Oh, really?
[02:06] <Peng_> Well, according to the list archive, there's *something* attached to my message.
[02:07] <lifeless> hmm
[02:07] <lifeless> anyhow, I'll incorporate it :)
[02:07] <lifeless> though your pushed branch is missing the test changes
[02:07] <Peng_> Oh, really?
[02:07] <lifeless> yes
[02:07] <Peng_> lifeless: BundleBuggy found it fine.
[02:08] <Peng_> lifeless: Oh, LP is, since it won't mirror the branch for a couple more hours. My server has them, though.
[02:08] <lifeless> http://bazaar.launchpad.net/~mnordhoff/bzr/fix_get_config_file/revision/4242
[02:08] <lifeless> ah k
[02:14] <Peng_> Hey, I think that's the first bug that got assigned to me. :D
[02:31] <spiv> lifeless: hmm, actually, just 4 for dinner; Mary can't make it after all.  Sorry about the late notice.  I'm still in.
[02:32] <lifeless> k
[02:33]  * lifeless books
[03:50]  * igc lunch
[04:03] <lifeless> spiv: your books are here
[04:04] <spiv> lifeless: funny you should say that, I was just about to head out the door to join them :)
[04:04] <spiv> lifeless: see you soon!
[04:40] <Cessen> Is there a reason that stacked branches require access to the stacked-on branch, even for operations that don't involve history prior to the branching?
[04:40] <Cessen> For example, I can't commit locally without access to the stacked-on branch.  This seems really weird to me.
[04:41] <Cessen> I'm wondering if there is a rationale for this, or if it's just something that hasn't been gotten to yet.
[04:42] <lifeless> Cessen: stacked branches federate the bzr database; they are not intended for disconnected operation.
[04:43] <lifeless> Cessen: We plan to have a thing called'history horizons' which would permit that, but its not in any developers current todo list that I know of
[04:44] <lifeless> Cessen: we're bringing in a massive improvement to history size though - a 60% reduction in disk and network utilisation, over the next few releases.
[04:44] <lifeless> Cessen: which should make the need for '--stacked' when making local branches a lot less
[04:45] <Cessen> lifeless: so are stacked branches mainly intended as an alternative to shared repos, then?
[04:45] <lifeless> yes.
[04:46] <Cessen> Okay.  Thanks.  That's where my misunderstaning was, then.
[04:46] <lifeless> also for publishing branches, so you don't have to upload a lot of data when giving someone your branch
[04:46] <lifeless> as uplinks are usually even smaller than downlinks
[04:46] <Cessen> Okay.
[04:47] <Cessen> When I read descriptions of it I thought it was like "history horizons" that you mentioned above.  So I was very confused when I tested removing the branch I branched from, and then couldn't do anything.
[04:47] <lifeless> Cessen: ah yes, I can understand that
[04:47] <Cessen> Anyway, thanks for your help. :-)
[04:49] <Cessen> I like to abuse bzr for revision control of media files.  History horizons would make it viable for collaborative online media projects, too, which would be cool.
[04:49] <Cessen> I can always dream. :-)
[04:51] <Cessen> I suppose bzr dev is focused more on code vcs, though.  Which makes sense.
[04:52] <lifeless> we're certainly open for improvements for all history needing projects
[04:52] <lifeless> but yes, code is the primary goal :)
[04:54] <Cessen> lifeless: thanks very much for your time. :-)
[05:12] <jfroy> I just pulled bzr.dev
[05:12] <jfroy> and, erm... I can't seem to be able to pull anything :p
[05:13] <spiv> jfroy: bug 354036?
[05:13] <jfroy> bzr just errors out with "bzr: ERROR: Not a branch" giving me the path of the cwd.
[05:13] <spiv> Oh, something different :)
[05:13] <jfroy> No matter which protocol I give it :p
[05:13] <jfroy> spiv: yeah, was trying to do the http pull.
[05:14] <jfroy> revno 4241 on bzr.dev
[05:14] <jfroy> anyone else seeing something similar?
[05:14] <jfroy> Getting something like
[05:14] <jfroy> jfroy:Projects bahamut$ bzr pull lp:rivenx
[05:14] <jfroy> bzr: ERROR: Not a branch: "/Volumes/Crossroads/bahamut/Documents/Projects/".
[05:14] <spiv> jfroy: things seem normal for me so far
[05:15] <jfroy> mmmm
[05:15] <spiv> jfroy: what's the traceback in ~/.bzr.log?  (pastebin it)
[05:16] <jfroy> http://pastebin.com/dfe6d1a1
[05:17] <jfroy> It makes no sense to me :p
[05:18] <spiv> jfroy: do you mean s/pull/branch/ ?
[05:18] <spiv> jfroy: or is /Volumes/Crossroads/bahamut/Documents/Projects/ meant to be a branch of lp:rivenx already?
[05:19] <jfroy> ahhhhhhhhhh
[05:19]  * jfroy rams head in wall
[05:19] <spiv> :)
[05:19] <jfroy> You are, of course, right on.
[05:20] <jfroy> http puling is sooooo slow
[05:20] <jfroy> well, slower
[05:23] <jfroy> OK, the pull worked fine through http.
[06:42] <kfogel> whew. Python PEP 0374 ended up on O'Reilly Radar blog.
[07:33] <vila> hi all
[07:33] <Peng_> Good morning.
[07:34] <vila> Peng: good morning :) Did your quota get restored ? :-P
[07:35] <Peng_> Yes, but then I traded it for some cold pizza.
[07:55] <igc> hi vila
[07:58] <igc> lifeless: shall I land the chk_map code into bzr.dev or leave that bit to a proper merge of the main bits?
[08:02] <fullermd> Wait.  I can get cold pizza just for handing over my quota?
[08:10] <igc> spiv: can I get a quick review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D59D2E.50500%40internode.on.net%3E
[08:11] <igc> spiv: vila wrote this code so he could approve it (given I think it's ok) but if you're still around, it will only take a minute or two
[08:25] <igc> vila: I think spiv and lifeless might be offline for a few hours
[08:25] <igc> vila: can I request a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D5B919.9090700%40internode.on.net%3E please?
[08:26] <igc> I'm landing all the trivial, next-to-zero risk stuff out of brisbane and I need a vote to keep pqm busy :-)
[09:00] <vila> igc: the diff by itself doesn't make much sense, I'm a bit concerned that landing pieces like that screw the annotations badly and will make debugging harder :-/
[09:00] <vila> igc... oh wait !
[09:01] <vila> igc:  may be there is a way to still merge the bbc branch once everything has landed...
[09:09] <vila> igc: regarding your request above, I approved it, but that doesn't carry much weight, except that I remember having seen that modifications and I'd say they come from at least 3 different sources
[09:25] <lifeless> igc: the one that got approved is good to land
[09:45]  * awilkins is interested in this "cold pizza" that is spoken of
[09:48] <visik7> when I merge from a branch do I need to put a insigniful comment in the commit after the merde ?
[09:48] <visik7> merge
[09:55] <vila> visik7: was there anything interesting brought in by that merge ? That's what *readers* want to know
[09:57] <visik7> I mean I usually  merge instead of update
[09:57] <visik7> 'couse I can see and revert if something goes wrong (usually I forgot at which revision I was)
[09:58] <visik7> but if I would commit I need to put a meaningless message
[09:59] <visik7> nevermind I run a revert and update
[11:04] <joie> Hi - I'm moving over from baz to bzr (gradually) and reading a lot about cherry picking changes, and how bzr doesn't support such things as "skip present" and so on, that baz did. I was wondering if there had been any improvements in this area in recent times (the discussions I've found about it are rather old). Ta!
[11:07] <james_w> joie: no improvements, but a bit more discussion recently
[11:08] <james_w> I'm not sure how close anyone is to working on it right now
[11:10] <joie> I essentially have a situation identical to this one as discussed some time ago "Cherrypicking workflows with bzr": https://lists.ubuntu.com/archives/bazaar/2006q1/007591.html
[11:11] <joie> So looks like for the forseeable future I'll have to live with more conflicts between branches/trunk, unfortunately. It's not all bad news - bzr is better in lots of other ways, I'll just have to be careful with merging!
[11:18] <joie> Even if we can't track cherrypicks, one thing that would be really useful is to be able to "pretend" to have merged all the changes from one branch to another - rather like baz sync-tree - do you know if something like this is possible in bzr? Thanks again!
[11:23] <james_w> joie: I'm not familiar with baz, so I don't know what the command does
[11:24] <james_w> in bzr it's possible to merge in all the changes from a branch, without actually making any of the changes
[11:24] <james_w> so that a further merge would not do anything, but your branch content hasn't changed ata ll
[11:28] <Stavros> hello
[11:28] <Stavros> i have some local commits, how can i push them upstream?
[11:28] <Stavros> bzr up shows them as local merges and asks me to commit again
[11:28] <joie> james_w: that sounds perfect!
[11:28] <james_w> Stavros: if you commit they will be committed upstream as well
[11:29] <james_w> joie: to do that you do the merge and then run "bzr revert ."
[11:29] <Stavros> but i have already committed them locally, i just want to push them
[11:29] <james_w> the "." means just revert the tree changes, not the pending merges
[11:29] <joie> james_w: I'll try that - thanks for the tip!
[11:30] <james_w> if you then run "bzr status" you will see no files changed, but there will be pending merges
[11:30] <james_w> you then commit
[11:30] <james_w> and then try "bzr merge" again and it will say "Nothing to do"
[11:30] <Stavros> james_w: is that for me?
[11:31] <james_w> Stavros: it's not possible to "just push" as upstream had also done some work, so you had diverged
[11:31] <Stavros> james_w: i don't think it had, as i'm the only person working on this
[11:31] <Stavros> how can i check?
[11:31] <james_w> ah, then perhaps "bzr up" with local commits and no changes to the master branch does something different to what I expect
[11:32] <james_w> run "bzr log -r -10.." and see what those revisions are
[11:32] <james_w> if they are things that were already there when you did your local commit then I am confused
[11:32] <Stavros> there were, all i see is my changes
[11:33] <Stavros> i committed revision 50, then 51 locally, and tried to commit 52 upstream
[11:33] <Stavros> but now i get odd messages about pending merges and inability to do select-file commits
[11:33] <fullermd> I'm pretty sure update with local commits always turns them into pending merges.
[11:34] <Stavros> probably, yes
[11:34] <Stavros> but what do i do?
[11:35] <fullermd> Commit.
[11:35] <Stavros> i can't commit, i have pending file changes
[11:36] <SamB> can you stash?
[11:36] <Stavros> hmm, yes
[11:36] <Stavros> bzr shelve?
[11:36] <fullermd> Well, there's not much point in committing if you DON'T have pending file changes  ;p
[11:37] <Stavros> i have changes i don't want to commit
[11:37] <Stavros> i only want to commit a file
[11:37] <Stavros> but it doesn't support it, apparently
[11:37] <fullermd> Yes, if you have pending merges, you can only commit the whole tree.
[11:37] <fullermd> No way to record a partial-tree merge.
[11:37] <Stavros> bzr: ERROR: Selected-file commit of merges is not supported yet
[11:37] <Stavros> hmm
[11:37] <Stavros> okay, i'll shelve then
[11:39] <SamB> why does bzr up do that without asking for any kind of okay ?
[11:39] <SamB> bzr merge requires --force to get you into this sort of mess ...
[11:42] <fullermd> I'm not the guy to ask  ;p
[11:45] <Stavros> hmm
[11:46] <ronny> hmm
[11:46] <ronny> bzr log in a svn workdir is painfull
[11:47] <ronny> at least the initial one
[11:55] <fullermd> I do that sort of thing in CVS workdirs sometimes.  That's not painful.  Just depressing.
[12:01] <SamB> isn't using CVS painful though?
[12:02]  * SamB remembers CVS getting stuck on his old 56k connection ... having to abort with only half of the files updated ...
[12:52] <OllieR> Hey I am trying to revert a branch to exactly how it was at revno 9. I added a whole load of files to do an upgrade, but now want to go back. I did bzr revert and all the files that were versioned have been reverted. Great! But there are a whole load of unknown files when I do bzr st. Can I issue a command to remove all these new unknown files so I am completely back at revno 9 as if I did a checkout?
[12:55] <OllieR> just wondering before I go off an do a long rm session
[12:57] <igc> abentley: can you poke BB soon please? Seems to be down
[12:57] <james_w> hi igc
[12:57] <james_w> OllieR: bzr clean-tree can do that
[12:57] <james_w> rm $(bzr unknowns) as well
[12:58] <OllieR> clean tree is not a core command right?
[12:58] <james_w> only recently
[12:59] <igc> hi james_w: how was your holiday btw?
[12:59] <OllieR> so i will go for the command substitued rm route
[12:59] <james_w> igc: very nice thanks
[13:00] <james_w> your city is very pleasant :-)
[13:00] <OllieR> james_w: thanks a lot
[13:01] <igc> james_w: it is. Did you get to see much outside the city?
[13:24] <ronny> jelmer: sup? does dulwich have a own api for building commits by now?
[13:29] <ricardokirkner> hi jelmer, I just wanted to tell you that everything went fine after your last commit
[13:29] <ricardokirkner> thanks a lot for the help
[13:47] <james_w> igc: I didn't unfortunately, but I had a very relaxing time.
[13:51] <jelmer> ronny: hi
[13:51] <jelmer> ronny: You can build and serialize the various objects and add them to a git repo
[13:52] <jelmer> ronny: but there's no function yet that you can tell "please go and do a commit in this working tree" yet
[13:52] <ronny> jelmer: but it should just work via bzr's workingtree for now?
[13:53] <ronny> (i want an reasonable way to build in-memory commits in memory)
[13:53] <jelmer> ronny: no, bzr's workingtree doesn't work on git indexes yet
[13:54] <jelmer> ronny: you can commit in bzr working trees and dpush into git though
[13:54] <ronny> jelmer: i dont need an index, just commit
[13:54] <jelmer> ronny: So you need to do in-memory commits?
[13:54] <ronny> well, more something like a commitbuilder
[13:55] <jelmer> ronny: and you have a tree in memory that you'd like to commit?
[13:56] <ronny> jelmer: yeah, this is supposed to be a simple backend for a cms/wiki - i want simple support for all dvc's, and no possibility of concurrent fuck up in workdirs
[13:57] <jelmer> ronny: so, while we don't have a commit builder it's trivially possible to create one yourself in a few lines of code
[13:58] <jelmer> and specific to your problem
[13:58] <jelmer> I'm happy to help, but it's hard to comment without looking at the code
[13:59] <ronny> hmm, ok, then i'll just try to do one in anyvc
[13:59] <ronny> bascially build blobs, build trees, build commit
[13:59] <ronny> well, and update refs ^^
[14:07] <abentley> igc: restarted.
[14:09] <igc> abentley: thanks
[14:27] <igc> night all
[14:32] <jelmer> ronny: cool
[14:38] <ronny> jelmer: btw, is subvertpy able to do commits without workdir?
[14:38] <ronny> (and is there a simple example ican steal)
[14:40] <jelmer> ronny: yes, it can
[14:41] <jelmer> ronny: I'll add an example to examples/
[14:44] <vila> igc: really gone ?
[14:48] <ronny> jelmer: btw, do you see any way to have the svn log as iterator instead of callback?
[14:48] <jelmer> ronny: not really
[14:48] <jelmer> ronny: in C it's a callback
[14:48] <jelmer> ronny: so the only way to do that is to use threads
[14:48] <jelmer> ronny: bzr-svn has a wrapper that does that
[14:49] <ronny> so threads + queue
[14:49] <ronny> sad
[14:49] <ronny> i wonder if greenlets could do
[14:50] <jelmer> ronny: yeah, that's a limitation of the svn unfortunately
[14:50] <jelmer> SVN *API* I mean
[14:50] <jelmer> ronny: I've committed an example of using ra.get_commit_editor()
[14:52] <ronny> ok, looks like a bearable startingpoint
[14:53] <ronny> jelmer: btw, does svn actually have anything to reliable figure branches/tags ? last time i asked the svn people about the actual structure they told me random gibberish about a dag and needing to read the api
[14:54]  * maxb wonders what it means to "figure branches/tags"
[14:56] <ronny> maxb: well, in svn branches/tags are bascialy copy's
[14:56] <maxb> Indeed.
[14:56] <ronny> so one needs to figure whats a normal copy,and whats a branch/tag
[14:56] <maxb> Well, the only way to do that is by conventions / naming scheme
[14:57] <jelmer> ronny: yeah, conventions are the only way
[14:57] <ronny> i know of projects that break them awfully nasty
[14:58] <maxb> Most svn users accept the advised trunk,tags,branches idea, some..... really don't :-)
[14:58] <jelmer> ronny: yeah, there's no way around that
[14:58] <ronny> well, i know of people that switched around conventsions various time in the early days of svn
[14:58] <jelmer> ronny: bzr-svn looks at the changes in the last 2k revisions and uses that to determine if one of the standard layouts is being used
[14:59] <jelmer> that seems to work pretty well
[14:59] <ronny> i'd like to take a look at the usual complete graph of copy's + deletes to see whats up in my absraction
[15:47] <ronny> jelmer: do i understand it right, that editor.close generates the commit?
[15:49] <jelmer> ronny: yeah
[15:50] <ronny> any exceptions for remote commits?
[15:50] <ronny> hmm, and i should figure how to deal with workdir status
[15:50] <jelmer> ronny: no, just specify a different URL to RemoteAccess() :-)
[15:51] <ronny> jelmer: sorry, bad workding, i mean what exceptions may it throw when i do conflicts
[15:51] <ronny> im preparing for a anyvc sprint over the weekend, parital history view + branches support + creating history
[15:52] <ronny> then later maybe merges and deal with local branches
[15:53] <ronny> since im not going for isomorph mappings, but just access its damn much more easy than bzr's stuff
[15:55] <jelmer> ronny: SubversionException
[15:55] <jelmer> ronny: is the only class of exception it will raise, with different error numbers
[15:58] <ronny> jelmer: so its bascially just a errno alike?
[16:02] <vila> fwiw bbc pass the full test suite under python 2.[456]
[16:03] <jelmer> ronny: yeah; "pydoc subvertpy" has the most common ones
[16:03] <jelmer> ronny: it also includes a (localized) error message
[16:10] <ronny> jelmer: how would i get the workdir status via subvertpy?
[16:13] <jelmer> ronny: subvertpy.wc.WorkingCopy
[16:14] <jelmer> allows you to open and inspect the working copy
[16:15] <ronny> hmm, looks weird, lets see if i can get it usefull in anyvc
[16:55] <mgedmin> awesome!  I'm in the middle of an editor writing a message for bzr commit, but I can run bzr log in a different window
[16:56] <mgedmin> I didn't expect I could do that
[17:10] <jelmer> hmm, can we use --parallel on the PQM machine ? (-:
[17:19] <vila> jelmer: hmmm, I don't think so :) Did you use it locally ?
[17:19] <jelmer> vila: no, I haven't tried it yet
[17:20] <vila> A lovely side-effect, IMHO, is that traceback for failing or erroring tests is now displayed as soon as it occurs
[17:21] <vila> unfortunately it's a bug that we should fix :)
[17:21] <vila> I confess that I'm not very motivated to fix it
[17:23] <jelmer> ahh
[17:51] <jelmer> vila: Hmm, it looks like lp:testtools doesn't export the right objects; do I need to use something else?
[18:04] <jelmer> ah, I was using the wrong branch
[18:04] <jelmer> --parallel is pretty quick compared to serial..
[18:41] <antoranz> Guys!
[18:41] <antoranz> I need some help
[18:41] <antoranz> after having imported from a git (imported from svn, by the way), I ended up with no room in my home
[18:42] <antoranz> there I had two directories: git-svn and master
[18:42] <antoranz> so I deleted them
[18:42] <antoranz> I moved .bzr to another partition, I "packed" the repo
[18:42] <antoranz> and now I want to see those two branches
[18:42] <antoranz> how can I "rebuild" them?
[18:43] <jelmer> antoranz: I'm not sure I understand completely what you mean
[18:43] <jelmer> but I think "bzr heads --all" is what you are looking for
[18:43] <antoranz> let's see
[18:44] <antoranz> I imported from git
[18:44] <antoranz> that, ok?, right?
[18:44] <antoranz> at the end of the import, I was told I had two branches: git-svn and master
[18:44] <antoranz> there were two directories with those names in the sahed repo
[18:44] <jelmer> sure
[18:44] <antoranz> but I had no room left in the partition
[18:45] <antoranz> so I moved .bzr (nothing else) no another partition
[18:45] <antoranz> to, I mean
[18:45] <antoranz> I packed it
[18:45] <antoranz> and now I want to be able to recreate those two branches in the shared repo
[18:45] <antoranz> how can I do that?
[18:45] <jelmer> just copy them over
[18:45] <antoranz> I deleted them
[18:45] <jelmer> run "bzr heads --all"
[18:46] <antoranz> ok
[18:46] <jelmer> and then you should be able to recreate them
[18:46] <antoranz> how about just a branch?
[18:46] <antoranz> heads is not in the bzr commands
[18:47] <antoranz> bzr: ERROR: unknown command "heads"
[18:47] <jelmer> I think you need bzrtools
[18:49] <antoranz> installing....
[18:50] <antoranz> I can see the last revision (I think). What's next?
[18:57] <antoranz> jelmer: ok... so how do i recreate them?
[18:58] <jelmer> bzr init trunk
[18:58] <jelmer> bzr pull -d trunk -rrevid:<somerevid>
[18:58] <antoranz> from the base of the shared repo?
[18:58] <jelmer> yeah
[18:59] <jelmer> at least I think that's how you do it, I've never done this before
[19:00] <jelmer> abentley: I see your patches still use the dirstate-with-subtree format rather than something newer, is that intentional?
[19:01] <abentley> jelmer: No, that's just what they've always used.
[19:02] <antoranz> jelmer: doesn't work
[19:02] <beuno> so, I'm going crazy here. I have a specific revision deep down in history, that does a bunch of changes to a bunch of files, that I want to revert
[19:02] <antoranz> bzr: ERROR: No pull location known or specified.
[19:02] <jelmer> antoranz: perhaps try this:
[19:02] <jelmer> antoranz: bzr pull -d trunk -rrevid:<somerevid> trunk
[19:03] <antoranz> just in case.. the <> are your remaks or they are necessary?
[19:03] <jelmer> antoranz: they're my remarks
[19:04] <beuno> how would I do that?
[19:06] <antoranz> ok
[19:06] <jelmer> beuno: reverse merge  ?
[19:06] <antoranz> jelmer: Could not determine revno for {konold@283d02a7-25f6-0310-bc7c-ecb5cbfe19da-19990503013312-xiqgf956oal5i62} because its ancestry shows a ghost at {konold@283d02a7-25f6-0310-bc7c-ecb5cbfe19da-19990503013312-xiqgf956oal5i62}
[19:06] <beuno> jelmer, bzr merge -r $oldrevno?
[19:07] <beuno> it says "nothing to do"
[19:08] <james_w> you need $oldrevno..$oldrevno-1
[19:08] <antoranz> or 0..oldrevno?
[19:08] <beuno> hrm, this gets complicated because the revno is burried inside a merge
[19:09] <james_w> we could do with a "parent:" revspec
[19:09] <abentley> james_w: We have one.
[19:09] <james_w> ah
[19:09] <james_w> even better
[19:09] <abentley> james_w: It's "before:"
[19:09] <antoranz> so, what do I do? Slash my wrists with a sharpless spoon? :-D
[19:10] <james_w> one that also allowed you to select which parent would be peachy, but that covers 99% of cases, thanks
[19:10] <beuno> so:  bzr merge -r:before:..7578 ?
[19:10] <james_w> bzr merge -r 7578..before:7578
[19:11] <abentley> beuno: "bzr merge -r:before:7578..7578 ."  Remember the .
[19:11] <james_w> won't that try and make the same changes again?
[19:11] <beuno> bzr: ERROR: No namespace registered for string: u':before:7578'
[19:12] <abentley> beuno: Sorry, should be "bzr merge -r 7578..before:7578 ."
[19:12] <beuno> new error!
[19:12] <beuno> bzr: ERROR: No namespace registered for string: u':7578'
[19:13] <abentley> beuno: Are you sure you didn't put an extra colon?
[19:14] <beuno> beuno@dell-desktop:~/canonical/lp-branches/blueprints_kill_portlet$ bzr merge -r:7578..before:7578 .
[19:14] <beuno> ah
[19:14] <jelmer> antoranz: probably easiest to redo the import
[19:14]  * beuno hides
[19:14] <antoranz> oh, man... don't say that... not even playing. :-)
[19:14] <beuno> abentley, jelmer, james_w, thanks
[19:15] <antoranz> but come on.... if the import ca recreate the branches, so should I right?
[19:15] <jelmer> antoranz: well, I'm not sure how the import determined the revno
[19:16] <jelmer> antoranz: how was the import done?
[19:16] <james_w> "bzr branch trunk temp -r revid:whatever" might work?
[19:16] <jelmer> james_w: that gives an error about not being able to termine revno because of ghosts
[19:16] <james_w> oh, missed that error, sorry
[19:16] <rbriggsatuiowa> I did a bad bzr revert
[19:16] <rbriggsatuiowa> is there a way to undo a revert?
[19:17] <james_w> rbriggsatuiowa: it will have left backup files in the tree
[19:17] <james_w> whatever.~<num>~
[19:17] <beuno> beatiful, this bzr thing is really amazing
[19:17] <rbriggsatuiowa> THANK YOU!
[19:19] <AnMaster> I'm trying to find a way to copy a directory (and all files in it) and keep it's history, but I can only find bzr mv to move, bzr cp doesn't seem to exist.
[19:20] <abentley> AnMaster: That's correct.  bzr does not support copies at present.
[19:20] <AnMaster> I need this because I'm splitting a certain sub-library of the projects in two diverging variants, which will be diverging and tuned/specialised for different loads (if project was in C I would probably use the preprocessor instead)
[19:20] <LeoNerd> A file in bzr just exists. It has revision controlled properties. One such property is its filename.
[19:21] <AnMaster> abentley, oh... any plans to add such support?
[19:21] <LeoNerd> A file can therefore only have one such name
[19:21] <AnMaster> hm ok
[19:21] <abentley> AnMaster: There are some ideas, but no firm plans.
[19:22] <NfNitLoop> AnMaster: Is that not a case for a new branch?  `bzr branch` works well. :)
[19:22] <AnMaster> NfNitLoop, both will be used in the same build, but for different tasks
[19:22] <NfNitLoop> AnMaster: aah.
[19:22] <AnMaster> NfNitLoop, need two very differently tuned internal hash libraries basically.
[19:23] <antoranz> jelmer: I tried heads --tips and bzr exploded
[19:25] <jelmer> antoranz: how did you do the original import?
[19:25] <antoranz> well.... I exported from git and gzipped ther result
[19:26] <antoranz> then i zcat | bzr fast-import - (basically)
[19:26] <jelmer> antoranz: I think you've hit a bug in bzr-fast-import
[19:26] <jelmer> antoranz: afaik it should never create ghosts
[19:28] <antoranz> wait till I recover from laughing on the floor at the sight of wasting so may CPU hours importing this. :-S
[19:28] <antoranz> I'll try to reimport to see if it just finishes the job.
[19:28] <jelmer> antoranz: please file a bug against bzr-fast-import
[19:28] <jelmer> antoranz: igc may also be able to help you further, I'm not very familiar with it
[19:34] <BasicOSX> lp speed today is making me cry
[19:34] <BasicOSX> Just posted to the mailing list as well, lifeless  are you awake? Looking for the 1.14 branch Ian claims is available for me :-)
[19:35] <BasicOSX> I see vila's 1.14 branch but that is it
[19:44] <antoranz> the import did recreate the branches
[20:34] <jrwren> I have a bound branch. is there a way I can tell what rev my branch is on?  bzr log -r -1 . is telling me latest rev of the branch to which I am bound, not my branch.
[20:35] <beuno> jrwren, bzr revno
[20:36] <jrwren> is that new?
[20:38]  * fullermd stabbies bound branches.
[20:39] <jrwren> I like my bound branch workflow :)
[20:39] <jrwren> sorry.
[20:39] <beuno> jrwren, no, it's as old as I can remember  :)
[20:39] <jrwren> i fail for not finding it sooner.
[20:39] <fullermd> If revno is telling you the revno of your local branch rather than the branch you're 'bound' to, I'd call it a bug.
[20:40] <jrwren> no, revno is fine.
[20:40] <jrwren> log -r -1 is showing me the bound rather than local.
[20:40] <fullermd> That's what it should do.  Sorta.
[20:40] <jrwren> I'd think revno should (and does) show me local rev.
[20:40] <fullermd> Unless we had bound branches, which we don't.  Quite.
[20:40] <fullermd> We have checkouts.  Almost.
[20:41] <jrwren> basically, i'm just trying to detect when a branch is out of date.
[20:41] <jrwren> while : ; do myrev=...; serverrev=... ; if [[ $myrev -lt $serverrev ]]...
[20:41] <fullermd> Why not missing :bound?
[22:08] <Peng_> I forget, does bzr use "Fix Committed" or "Fix Released" when a bug fix gets merged to bzr.dev?
[22:09] <beuno> Peng_, my instict says "committed", so probably "released"
[22:09] <beuno> I remember bzr does it the opposite of everything else
[22:10] <beuno> so, if IIRC, fix committed == it's committed "somewhere"
[22:10] <beuno> fix released == in trunk
[22:10] <beuno> but maybe jam or abentley can confirm
[22:10] <abentley> beuno: confirmed
[22:10] <Peng_> Thanks.
[22:14] <meoblast001> hi
[22:14] <meoblast001> i just had someone commit source into his launchpad account... i'd like to merge it into my project... how do i do that?
[22:15] <beuno> meoblast001, bzr merge LOCATION
[22:15] <meoblast001> ok thanks
[22:15] <meoblast001> how would i know where he's putting it
[22:15] <Peng_> meoblast001: https://code.launchpad.net/~him
[22:15] <Peng_> meoblast001: Then find the branch.
[22:16] <Peng_> meoblast001: The page gives an lp:~him/project/branch URL for the branch; bzre that.
[22:16] <meoblast001> ok
[22:16] <meoblast001> thanks
[22:16] <Peng_> ERrr.
[22:16] <meoblast001> and that will just import his code in with mine?
[22:16] <Peng_> "bzr merge that"
[22:16] <Peng_> meoblast001: Yes. (Don't forget to commit.)
[22:16] <meoblast001> yeah
[22:17] <meoblast001> bzr merge lp:blahblahblah && bzr ci && bzr push....
[22:17] <Peng_> Yep.
[22:17] <meoblast001> except i won't use the && just incase of an error
[22:19] <Peng_> :)
[22:21] <meoblast001> Peng_: this just pulls his code and throws it into mine right? it doesn't copy his commits too
[22:21] <meoblast001> oh no.... i'm so lost
[22:23] <Peng_> meoblast001: By default, yes, it copies the commits too.
[22:23] <meoblast001> Peng_: i think he had an outdated version
[22:25]  * meoblast001 is having a panic attack
[22:28] <Peng_> Outdated version of what?
[22:28] <meoblast001> Peng_: he had revision 10 when i have 15 revisions
[22:32] <meoblast001> i don't think i'm liking this merging stuff
[22:32] <meoblast001> >>>>>>> MERGE-SOURCE is going to cause compiler errors
[22:32] <Peng_> meoblast001: There were conflicts. Get out your text editor and fix them.
[22:32] <Peng_> Or fancy diff/merge software or whatever.
[22:35] <meoblast001> Peng_: i don't even think i want the guys changes anymore... it's not well commented
[22:35] <meoblast001> i don't understand any of it
[22:41] <Peng_> meoblast001: Well, you could "bzr revert" to throw it all out.
[22:41] <meoblast001> yeah
[22:41] <Peng_> meoblast001: You could also tell him to merge your branch and fix all of the conflicts so it'll be less work for you.
[22:41] <meoblast001> Peng_: so now am i not allowed to edit my source until he fixes his code?
[22:42] <Peng_> meoblast001: What? Why?
[22:42] <meoblast001> i just found out he did merge my branch
[22:42] <meoblast001> Peng_: if i change my code, wont his overwrite my changes?
[22:42] <meoblast001> idk... i've never merged before
[22:42] <Peng_> meoblast001: The point of merging is so that both side's changes will be preserved.
[22:42] <meoblast001> oh
[22:43] <Peng_> meoblast001: Of course, if you both modify the same code, the computer won't be able to figure it out, it'll result in conflicts and one of you will have to fix them manually.
[22:44] <Peng_> s/same code/same lines of code/
[22:45] <meoblast001> yeah
[22:46]  * Peng_ goes /away