[00:09] <beuno> mwhudson, I'm looking at bugs I can easily close for loggerhead, and I bumped into bug #121715, but I don't understand what that means  :)
[00:10] <mwhudson> i don't think i understood what that one meant either
[00:10] <beuno> lol
[00:12] <mwhudson> oh hang on, i filed it
[00:12] <beuno> yeah, that's why I asked
[00:12] <mwhudson> i think the idea was that you could mouse-over the line numbers and get annotation info
[00:12] <mwhudson> but feel free to ignore it
[00:13] <mwhudson> (especially now annotation isn't so very cheap with packs)
[00:15] <beuno> mwhudson, alright, I'll mark it as incomplete, and aim for a cleaner list of pending bugs to fix  :)
[00:15] <jelmer> mwhudson: sorry, don;t have experience with pysvn
[00:15] <mwhudson> jelmer: oh ok
[00:16] <mwhudson> in other pysvn news, pysvn.Client.update appears to ignore the ignore_externals code
[00:16] <jelmer> mwhudson: only with python-subversion
[00:17] <beuno> ah, I can't change bug importances
[00:17] <chandlerc> jelmer: please let me know if you need me to re-work my patch. i'm more than happy to bang on it until its up to par
[00:17] <jelmer> which patch is that? The one for dealing with "branches" being missing?
[00:18] <chandlerc> yea
[00:18] <jelmer> chandlerc: it would be nice to have a unit test that ensures that bug is fixed
[00:18] <chandlerc> k, i'll dig into the testing framework...
[00:21] <jelmer> chandlerc: Never mind
[00:21] <jelmer> chandlerc: This is a webdav-specific error, so it's hard to create a test for it
[00:21] <jelmer> chandlerc: I'll merge your patch
[00:24] <chandlerc> ok
[00:24] <chandlerc> =] it would have taken me a while to get comfortable with the test framework anyways
[00:24] <chandlerc> i got lucky with the patch, was much simpler than I had originally thought
[00:31] <jelmer> chandlerc
[00:31] <jelmer> : committed, thanks!
[00:40] <chandlerc> jelmer: thanks for the help debugging it yesterday! the fix was quite easy
[00:40] <lifeless> sweet!
[00:40] <lifeless> :!bzr search search
[00:40] <lifeless> Revision id 'robertc@robertcollins.net-20080608221948-66c28r366alynula'.
[00:40] <lifeless> Revision id 'robertc@robertcollins.net-20080608055724-c6tjpycts2476brf'.
[00:41] <lifeless> :!bzr search indices
[00:41] <lifeless> Revision id 'robertc@robertcollins.net-20080608133638-j5yazpedr3mlixju'.
[00:41] <lifeless> Revision id 'robertc@robertcollins.net-20080608114120-2gjfj34t8xuqp2qt'.
[00:41] <lifeless> Revision id 'robertc@robertcollins.net-20080608143716-0eq1vm6b2zj8mx2t'.
[00:41] <lifeless> :!bzr search indices run
[00:41] <lifeless> Revision id 'robertc@robertcollins.net-20080608143716-0eq1vm6b2zj8mx2t'.
[00:42] <lifeless> beuno: ^ searching now works
[00:43] <lifeless> (and I've pushed)
[00:43] <beuno> lifeless, if I hadn't met you in person, I'd be sure you're not human. Pulling now  :)
[00:44] <lifeless> there is a bug in the bzrlib index layer that makes it fall over and cry when indexing all of bzr
[00:44] <lifeless> the second-stage index layout will avoid this and actually have some chance of scaling too :P
[00:45] <lifeless> -> breakfast, then I might teach this to use slightly better apis so it doesn't load the entire index to search
[00:46] <beuno> lifeless, beuno@beuno-laptop:~/bzr_devel/bzr-search$ bzr index .
[00:46] <beuno> bzr: ERROR: Failed index creation. Internal error: mismatched output length and expected length: 12509112 3127278
[00:47] <lifeless> 09:44 < lifeless> there is a bug in the bzrlib index layer that makes it fall over and cry when indexing all of bzr
[00:47] <lifeless> oh
[00:47] <beuno> well, it's not on bzr.dev  :)
[00:47] <lifeless> you have a shared repository
[00:47] <lifeless> it *is* on bzr.dev :P
[00:47] <beuno> I do
[00:47] <beuno> ah
[00:47] <beuno> heh
[00:47] <lifeless> if you were to tighten up index.index_url
[00:48] <lifeless> then it would restrict itself to the plugin, and work
[00:48] <lifeless> get it working, make it correct, make it fast
[00:48] <lifeless> stage 1) done.
[00:48] <lifeless> if you branch the plugin to a standalone area it will be happier
[00:48]  * beuno sets aside loggerhead bug triaging and fires up VIM
[00:50] <beuno> works as a standalone branch  :)
[00:50] <lifeless> hmm, we want hit summaries soon as well
[00:50] <lifeless> just printing the rev id is not that helpful :P
[00:50] <lifeless> should pass branch to search, then it can pass to the hit objects
[00:51] <lifeless> dammit. BREAKFAST I AM COMING
[00:51] <lifeless> :P
[01:07] <beuno> lifeless, so, playing around with it, I replaced all_revision_ids() with get_graph and turned it into a dict, and it seems to not explode now :)
[01:07] <beuno> it's very hackish, as I just wanted to see if it worked
[01:08] <beuno> I'll try and cleanup enough to send a quick patch
[01:10] <lifeless> awesome
[01:26] <beuno> lifeless, ah, Verterok, which is working here today, has a simpler solution. Replace branch.repository.all_revision_ids() with branch.revision_history()
[01:26] <beuno> works fine here
[01:26] <lifeless> its wrong though
[01:26] <lifeless> your one was better
[01:26] <lifeless> revision_history is left-hand-side only
[01:26] <beuno> ah, I see
[01:29] <lifeless> ideally its actually find-the-new-revisions task
[01:29] <lifeless> but indexing the lot as a starting point isn't a problem
[01:30] <beuno> lifeless, this is what I have now: http://paste.ubuntu.com/18618/
[01:30] <beuno> it returns a dict, which, of course, isn't what it's expecting
[01:31] <beuno> and I suspect that will get repeated revids as parents, which we don't want to re-index
[01:32] <lifeless> try
[01:32] <lifeless> searcher = graph._make_breadth_first_searcher()
[01:32] <lifeless> for parents, ghosts in searcher.next_with_ghosts()
[01:32] <lifeless> revs_to_index.update(parents)
[01:32] <lifeless> revs_to_index.remove(NULL_REVISION)
[01:34] <beuno> lifeless, beuno@beuno-laptop:~/bzr_devel/search.beuno$ bzr index .
[01:34] <beuno> bzr: ERROR: Failed index creation. Internal error: mismatched output length and expected length: 12509112 3127278
[01:35] <lifeless> pass [_last_rev_id] to the searcher constructor
[01:44] <beuno> lifeless,     for parents, ghosts in searcher.next_with_ghosts():
[01:44] <beuno> ValueError: need more than 0 values to unpack
[01:44] <beuno> :/
[01:44] <toyto1> hello guys, using http like this 'bzr checkout http://www.example.com/myproject-as-repo' where the "myproject-as-repo" has the .bzr directory will require special configuration in the server?
[01:45] <lifeless> beuno:     def next_with_ghosts(self):
[01:45] <lifeless> ...
[01:45] <lifeless>         return self._current_present, self._current_ghosts
[01:45] <beuno> I didn't know about the searcher, it may be useful for loggerhead too (if I can get it to work)
[01:45] <toyto1> when i tried 'bzr checkout http://www.example.com/myproject-as-repo' I have error '... couldn't resolve host ..'
[01:45] <lifeless> toyto1: no special configuration needed, just have to serve the directory
[01:46] <lifeless> toyto1: if you want to allow writing, then you need special configuration
[01:46] <lifeless> beuno: next_with_ghosts does not return an iterator
[01:46] <toyto1> lifeless: yeah my purpose is writing is thru sftp, while checkout or read is thru http
[01:46] <lifeless> beuno: I was doing pseudocode
[01:46] <lifeless> toyto1: will work fine
[01:46] <beuno> lifeless, alrighty, let's see if I can figure this thing out...
[01:46] <toyto1> lifeless: but when I tried that it says 'couldn't resolve host'... error that looks like that :(
[01:47] <lifeless> toyto1: sounds like it can't figure out the host :)
[01:47] <toyto1> lifeless: nvm, I type a wrong path sorrry :) thanks for that
[01:48] <toyto1> lifeless: yeah hehe sorry, thanks lifeless :)
[01:48] <lifeless> no probs
[02:09] <lifeless> beuno: that work better?
[02:11] <beuno> lifeless, it seems a little trickier than that, but I got it not exploding now. Just need it to actually index  :)
[02:12] <beuno> meh, no, not working
[02:13] <beuno> I'm trying to iterate similar to repository.InterRepository._walk_to_common_revisions
[02:13] <beuno> leaving aside the logic that compares
[02:15] <lifeless> well, I would start with just the full graph collection
[02:15] <lifeless> as size(branch) better than size(repo)
[02:16] <beuno> including duplicate parents and such?
[02:16] <lifeless> searcher eliminates those
[02:16] <beuno> right
[02:23] <beuno> lifeless, http://paste.ubuntu.com/18624/
[02:23] <beuno> I must be something fundamentally wrong, as it gets StopIteration on the first loop
[02:24] <lifeless> [_last_revid]
[02:24] <beuno> argh, thanks
[02:29] <beuno> lifeless, some progress :)    have to cleanup a bit
[02:34] <lifeless> cool
[02:35] <beuno> lifeless, seems to work: http://paste.ubuntu.com/18625/   (delete the bzr-search index first)
[02:35] <beuno> seems to, as in, it works on a shared repo, and returns the search results expected
[02:36] <lifeless> two things
[02:36] <lifeless> there are two branches
[02:37] <lifeless> if you index twince on a shared repo you will blow up
[02:37] <lifeless> secondly, you don't need to filter the next revs, just update
[02:37] <lifeless> *outside* the loop, remove the NULL revision
[02:45] <beuno> lifeless, fixed the null filter, but I don't understand what you mean by "there are two branches"
[02:45] <lifeless> in the function
[02:45] <lifeless> new index
[02:45] <lifeless> update index
[02:45] <lifeless> you've made new index perform better
[02:46] <beuno> ah, yes, copy the logic
[02:47] <bpeterson> if I have a branch with bzr-email enabled on it and I reconfigure it to a checkout, will the bzr-email hook still run?
[02:47] <lifeless> yes
[02:47] <lifeless> though you may need to update your locations.conf depending on what rule you put in
[02:47] <bpeterson> I put it in .bzr/branch/branch.conf
[02:48] <bpeterson> because I couldn't get the wildcards right
[02:48] <lifeless> yah that should fire
[02:48] <lifeless> easy way to test :P
[02:48] <bpeterson> thanks again
[02:48] <bpeterson> It's even easier to ask here, though!
[02:50] <beuno> lifeless, something like this?  http://paste.ubuntu.com/18626/
[02:54] <beuno> mwhudson_, the searcher seems like it could help with the loggerhead needs-full-history problem. It's not straightforward to use right now, but with some refactoring...
[03:05] <lifeless> beuno: good; don't need the set() cast around next revs AFAIK, but otherwise should be good
[03:08] <beuno> lifeless, ah, I don't  :)
[03:08] <beuno> want a bundle for that, or will you just copy off paste.u.c?
[03:34] <lifeless> commit, bundle me up
[03:41] <beuno> lifeless, sent
[03:51] <lifeless> thanks
[04:28] <tro> "ERROR: Cannot switch a branch, only a checkout." why is this the case? why can't branches be switched (using bzrtools' "switch")?
[04:39] <jamesh> tro: a checkout is connected to some branch located elsewhere
[04:39] <jamesh> "bzr switch" connects the checkout to some other branch
[04:40] <jamesh> on the other hand, a branch doesn't have such a relationship to switch
[04:40] <tro> and you can't have both the branch and the checkout be in the same directory?
[04:41] <jamesh> what do you want to do exactly?
[04:42] <jamesh> if I know that, I'll be able to give better advice
[04:44] <tro> i've been playing with git a little bit, and i like that it could manage many branches in the same directory. i could switch between then without "cd"ing into a different directory. this is neat, because then i won't need to setup my IDE environment again for a different branch
[04:44] <tro> i've been trying to have something similar work with bzr
[04:45] <jamesh> okay.  So what do you want to happen to the existing work in your branch?
[04:46] <tro> well, if i had any local changes, i'd "stash" them or something. but i don't care much about that. i would commit my changes before switching to a different branch
[04:47] <jamesh> commit them to where?
[04:47] <jamesh> if you have a standalone branch and run "bzr commit", they'll be committed to that location
[04:47] <jamesh> if you overwrite the branch with another, then you won't have those changes
[04:49] <tro> i'd like to be able to create a new branch from the current branch, switch to the new one, work a bit there committing my changes, then maybe switch back to the original, work a bit there, and so forth
[04:49] <tro> at some point maybe merge them. i know you can do all of this, but i'd like ot be able to get all this done without changing directories
[04:51] <jamesh> so, you'll need to have some place to store the branches, and another for the working tree
[04:51] <tro> right. that's pretty much what i figured. ok, thanks.
[04:51] <jamesh> you can store the branches without working tree files, so it won't use more disk space
[04:52] <jamesh> and the bzrtools "bzr cbranch" command can help with the "create a new branch from this one and switch to it" workflow
[04:52] <tro> o neat. i'll try it out. thanks.
[04:52] <jamesh> as your branches are local, you'll get best performance by creating your working tree with "bzr checkout --lightweight"
[04:53] <jamesh> a non-lightweight checkout caches more information, which is good if the branch is on the other end of a slow network link, but is just overhead for local branches
[04:53] <tro> makes sense :)
[04:55] <jamesh> tro: it'd make sense to create a no-trees repository to store your branches in (bzr init-repo --no-trees)
[04:55] <jamesh> and then create your branches under that directroy
[04:56] <tro> if i ever need to move the entire repository to a different machine, will i be able to just move the repo files there?
[04:56] <jamesh> yep
[04:58] <tro> nice
[05:18] <beuno> mwhudson_, so, I seem to have gotten navigation with revnos working
[05:18] <beuno> URLs look nicer  :)
[05:19] <mwhudson_> great
[05:20] <beuno> still need to make it work everywhere, but it works for changelog well enough
[05:20] <beuno> anything else you'd rather I invest my time in?
[05:22] <mwhudson_> the whole area of url generation is a mess
[05:22] <mwhudson_> so cleaning that up just anyway sounds like a good idea
[05:23] <beuno> that would be even better than working around the current way  :)
[05:24] <beuno> from what I can see, it doesn't really make any sense to have automatic URL generator, but, instead, on function that generates it based on what values you want to pass on
[05:24] <beuno> would that seem ok?
[05:25] <mwhudson_> well, that's sort of what there is now
[05:25] <mwhudson_> but there's all this crazy **util.get_context(**kwargs) nonsense
[05:25] <beuno> yeah, that's what I was referring to
[05:26] <mwhudson_> also, please do this in a separate branch :)
[05:27] <beuno> alright, let's give it a try
[06:15] <toyto1> guys have you tried commiting a file(s) or directory(ies) but the internet is suddently gone?
[06:15] <toyto1> I am having a testing then internet is disconnected but it's now locked and can't commit.
[06:17] <beuno> toyto1, you can use --local to commit locally until you get access to your branch again
[06:18] <toyto1> beuno: i mean when I commit to the server, the branch is transferring it to the main branch (which is the server)
[06:18] <toyto1> beauno: while transferring, the internet was gone and I stopped it
[06:19] <beuno> ah, you may have to break the lock and commit again
[06:19] <toyto1> beuno: then I try to commit it again but it says Will continue to try until HH:MM:SS and i waited but after I wait, it shows an error
[06:19] <toyto1> beuno: how to do that?
[06:20] <beuno> toyto1, bzr break-lock LOCATION
[06:20] <toyto1> beuno: trying...
[06:23] <toyto1> beuno: thanks a lot brother! It works great ;)
[06:25] <beuno> toyto1, I'm glad
[06:44] <Peng> It would be neat if nosmart+http used If-Modified-Since/If-None-Match.
[07:10] <lifeless> how so
[07:12] <Peng> I dunno.
[07:12] <Peng> Well, how would it be neat, or how would it be done?
[07:15] <lifeless> both really; consider that bzr tries not to download the same thing twice anyway
[07:20] <vila> Peng: are you referring to bug #120697 ?
[07:21] <Peng> vila: I guess so, indirectly.
[07:22] <Peng> I'm just looking at my web server logs, and noticing that when Launchpad using several hundred KB of bandwidth pulling a branch daily when it hasn't changed in months, being able to return 304 Not Modified would save a lot of bandwidth.
[07:22] <Peng> Not that it matters.
[07:23] <lifeless> well, it should hit about 10 files:
[07:23] <lifeless> format, format, last-revision
[07:23] <lifeless> sorry, format, format, format, last-revision
[07:23] <lifeless> 4
[07:23] <lifeless> and possibly a check that the tip is there
[07:24] <Peng> Launchpad uses bzr 1.3. It also reads a bunch of one .rix.
[07:24] <Peng> Err, all of the .rixes.
[07:25] <Peng> By "a bunch of", I mean "the whole thing, using a Range request", of course.
[07:27] <lifeless> that will be the check for the existence of the tip revision (to detect corruption). Or possibly a bug.
[07:36] <Peng> lifeless: IIRC, whatever it was, more recent versions don't do it.
[07:40] <beuno> mwhudson, pushed to where I got to: lp:~beuno/loggerhead/zpt.cleaner_urls
[07:41] <beuno> stopped using get_context, switched from revids to revnos almost everywhere and cleaned up here and there
[07:42] <beuno> found a few bugs while I was at it
[07:42] <beuno> and that's it for me today
[07:44] <mwhudson> beuno: sweet
[08:35] <lifeless> needs to be faster
[08:35] <lifeless>  time bzr search workaround
[08:35] <lifeless> Revision id 'jelmer@samba.org-20080511215646-kxxs86xvurf96nuq'.
[08:35] <lifeless> real    0m0.658s
[08:35] <lifeless> user    0m0.476s
[08:35] <lifeless> sys     0m0.104s
[08:35] <lifeless> (still doing full index loading)
[08:37] <lifeless> real    0m3.863s
[08:37] <lifeless> user    0m3.036s
[08:37] <lifeless> sys     0m0.124s
[08:37] <lifeless> to do the same search on bzr.dev
[08:37] <lifeless> beuno: new index format, closer to stage-2
[08:42] <lifeless> beuno: and I've merged your patch
[08:42] <lifeless> beuno: you should give this a spin :P - it can index bzr.dev now
[08:43] <lifeless> (which takes it 15 seconds)
[08:43] <mwhudson_> heh heh heh
[08:43] <mwhudson_> that's 'slightly better' than loggerhead's index
[08:44] <lifeless> it doesn't index file texts yet
[08:44] <mwhudson_> what does it index?
[08:44] <lifeless> commit messages
[08:44] <lifeless> but very extensible
[08:44] <lifeless> I needed enough going on that I could write the infrastructure and engine
[08:45] <visik7> how can I use lp: over http is it possible (for checkout)?
[08:45] <mwhudson_> commit messages is all loggerhead indexes :-p
[08:45] <lifeless> so I haven't spent time working on getting term lists for texts, inventories, or author etc in commits
[08:45] <lifeless> mwhudson_: grab, play :)
[08:46] <mwhudson_> lifeless: i'll see if i can trick beuno into doing that first :)
[08:46] <lifeless> he already has
[08:46] <lifeless> and sent me a patch even
[08:46] <mwhudson_> cool
[08:47] <Peng> visik7: If you haven't run bzr launchpad-login, it will use http.
[08:47] <Peng> visik7: Why do you want to use http?
[08:47] <lifeless> mwhudson_: so next objection :P
[08:47] <thumper> visik7: just go bzr branch lp:whatever and it should use http if you haven't done a "bzr launchpad-login"
[08:47] <mwhudson_> lifeless: it's 1948
[08:48] <lifeless> mwhudson_: ah yeah fair enough
[08:48] <visik7> Peng: 'couse I'm firewalled
[08:48] <lifeless> this is me time, for me
[08:48] <lifeless> something lightweight and entertaining to tweak while I play WoW :P
[08:48] <visik7> Peng: and the only protocol allowed here is http on port 80
[08:48] <mwhudson_> yeah, i realize
[08:48] <mwhudson_> something to do with some old english person's birthday
[08:48] <lifeless> or so they claim
[08:49] <Peng> visik7: Oh. That sucks. No ssh?
[08:51] <visik7> Peng: ssh yes but I just want to checkout some branch
[08:51] <Peng> visik7: bzr+ssh uses ssh, so your firewall is not a problem.
[08:52] <lifeless> visik7: you can checkout over ssh, but you can also checkout over http; you just can't commit back to the branch over http (with launchpad)
[08:52] <visik7> with anything afaik 'couse http has not write methods
[08:52] <visik7> isn't it ?
[08:53] <Peng> What?
[08:54] <Peng> http does not allow writes.
[09:14] <lifeless> james_w: you might find bazaar.launchpad.net/~lifeless/+junk/bzr-search fun
[09:15] <james_w> hi lifeless
[09:15] <lifeless> -> dinner
[09:19] <Peng> I should probably RTFM, but how do you check the current revision of a checkout?
[09:19] <Peng> When upstream has new revisions?
[09:20] <thumper> does bzr support non-ascii filenames?
[09:20] <Peng> thumper: Sure.
[09:20] <Peng> I think.
[09:21] <Peng> Wasn't there a recent mailing list post about something being passed around as str instead of unicode?
[09:21] <thumper> I don't follow the mailing list closely
[09:22] <uws> Peng: bzr revno
[09:23] <uws> Peng: 'bzr missing' is also useful
[09:23] <james_w> thumper: yes, but not all filenames can be versioned. There are some banned characters for a start.
[09:23] <jamesh> '\n' for instance
[09:23] <mwhudson> also \
[09:24] <Peng> \ is banned?
[09:24] <thumper> james_w: what about u'\xf8'?
[09:24] <mwhudson> as periodically found out by ~vcs-imports
[09:24] <thumper> Peng: I think because of windows
[09:25] <james_w> thumper: not sure, sorry.
[09:25] <Peng> thumper: Yeah,
[09:25] <jamesh> thumper: it seems to
[09:25] <Peng> thumper: Yeah, Windows bans \, but does bzr?
[09:25] <Peng> uws: This is a checkout. Those just use the master branch, which does not help.
[09:26] <jamesh> thumper: you sure you aren't talking about the byte '\xf8' on its own?
[09:26] <jamesh> as opposed to the UTF-8 sequence '\xc3\xb8'
[09:27] <thumper> jamesh: Not sure
[09:27] <thumper> Groøvy
[09:27] <thumper> the non ascii value above
[09:28] <uws> Peng: Hmmm. dunno then. "bzr unbind; bzr revno; bzr bind" perhaps? :)
[09:28] <jamesh> thumper: okay.  Because '\xf8' as a byte value is not a whole character
[09:29] <thumper> jamesh: but is u'\xf8' valid?
[09:29] <jamesh> thumper: it is
[09:30] <thumper> jamesh: urllib.quote is choking on it
[09:30] <jamesh> I just tried committing a file with that name to a dummy branch with no problem
[09:30] <jamesh> thumper: if the function you are using expects a URL, you probably need to UTF-8 encode it then url encode that
[09:30] <jamesh> >>> urllib.quote(u'\xf8'.encode('UTF-8'))
[09:30] <jamesh> '8'
[09:30] <jamesh> bah
[09:31] <thumper> jamesh: :( it is in the guts of the svn bindings we are using for importing to bzr
[09:31] <uws> >>> urllib.quote(u'\xf8'.encode('utf-8'))
[09:31] <uws> '%C3%B8'
[09:31] <Peng> uws: Did I mention it's a lightweight checkout?
[09:31] <uws> Peng: Sorry, can't help you ;)
[09:32] <uws> jamesh: What you did works here
[09:32] <jamesh> thumper: well, if the function expects a (relative) URL, then it probably doesn't expect a unicode string
[09:32] <jamesh> since URLs are ascii
[09:33] <thumper> jamesh: yeah, however I'm not entirely sure what the original intent was
[09:33] <Peng> Shouldn't bzr have special url-handling routines?
[09:35] <jamesh> that's a point.  One of the bzrlib.urlutils functions might be what you need
[09:40] <thumper> hmm, normalize_url looks promising
[09:48] <lifeless> Peng: update?
[09:49] <Peng> lifeless: What?
[09:49] <lifeless> nevermind, brain fart
[09:50] <Peng> ok
[09:57] <scorpioxy> hey guys, first off, excellent work on bzr-fast-import...much appreciated. My question is that i used it to transform a git-svn repo that i was using, so how can i go on using it to update it from the main svn repo?
[09:58] <awilkins> scorpioxy: I'm not sure that is a supported use-case... it would have to have the same revision-id values as bzr-svn and I'm not sure that is the case
[09:59] <awilkins> scorpioxy: AFAIK the various SVN interop units do not share a common SVN-BZR mapping, and putting git in the middle probably doesn't help either.
[10:08] <lifeless> scorpioxy: I would say you need to keep doing git-svn, the bzr-fast-import, if that has an incremental mode
[10:08] <lifeless> scorpioxy: or, if you had no significant local edits, use bzr-svn from scratch
[10:15] <scorpioxy_> Sorry about the report(disconnected and don't know if anybody answered). So my question was, i used bzr-fast-import to convert a git-svn repo. How can i go on using this new repo by using bzr-svn? Is changing the repo format all that's needed?
[10:15] <Jc2k> lo scorpioxy_
[10:15] <Jc2k> a few people answered
[10:16] <scorpioxy_> Jc2k: oh sorry, can i see those on the irc log?
[10:16] <Jc2k> i'll summarise
[10:16] <Peng> scorpioxy: IRC log: http://paste.pocoo.org/show/65615/
[10:16] <Jc2k> ahh
[10:16] <Jc2k> i wont ;D
[10:17] <scorpioxy_> Peng: aha thanks
[10:17] <Peng> Or, http://paste.pocoo.org/show/65616/ has nicer syntax highlighting.
[10:17] <Peng> But it's the same thing.
[10:17] <Peng> Anyway.
[10:18] <scorpioxy_> they're both have a messed up layout due to long msgs, but yeah, i read it
[10:19] <scorpioxy_> ok well thanks all, i guess i'll just have to use bzr-svn directly although its a big repo
[10:20] <Peng> scorpioxy_: Oh, you're right. I didn't notice that.
[10:20] <Jc2k> scorpioxy_: i have converted a 2gb repository with bzr-svn
[10:20] <Jc2k> scorpioxy_: 23,000 revision
[10:20] <Jc2k> scorpioxy_: and i am aware of bigger ones
[10:20] <Jc2k> scorpioxy_: what distro are you using?
[10:21] <scorpioxy_> Jc2k: oh yeah, the problem is my internet connection, not bzr-svn...i've been using that for quite a while now...and it works very well
[10:21] <scorpioxy_> Jc2k: ubuntu hardy
[10:21] <Peng> If you have leaky svn bindings (which I think Hardy does), you should incrementally convert about 1,000 revisions at a time.
[10:21] <Jc2k> hmm
[10:22] <Jc2k> hardy has OK bindings
[10:22] <Peng> It does?
[10:22] <Jc2k> the fix i backported from hardy to etch meant i was able to convert the whole of GNOME SVN without it dieing
[10:22] <Jc2k> BUT some reallllly big repos can still leak
[10:23] <Jc2k> hardy is about as good as you can get without running subversion 1.5, or using jelmers bindings
[10:26] <scorpioxy_> In my case, the repo just has about 1500 revs but some big change sets...the original svn repo was badly setup and badly used so i have to live with that.
[11:19] <lifeless> james_w: did you give bzr-search a spin ?
[11:20] <james_w> lifeless: I've branched it, still doing email etc. currently.
[11:20] <lifeless> do a pull
[11:20] <lifeless> just landed proper partial read support
[11:20] <lifeless> 1/2 sec to query bzr.dev for a single term
[11:21] <lifeless> (though it doesn't handle bzr.dev fully correctly, because the document lists are too long)
[11:21] <james_w> what indexing package did you go for in the end?
[11:21] <lifeless> but, you can search for some terms - like workaround :)
[11:21] <lifeless> 'bzrlib'
[11:21] <lifeless> this is just a spike, for fun, in my weekend :)
[11:26] <james_w> works well.
[11:28] <lifeless> cool
[11:52] <fredreichbier> hi ;)
[11:53] <fredreichbier> is there a way to enable a hook only for a specific branch? put it somewhere in ./.bzr or something else?
[11:57] <lifeless> fredreichbier: depends on the hook - most have some config options
[11:58] <fredreichbier> lifeless: are there docs to that config options?
[11:58] <lifeless> depends on the plugin :)
[11:59] <fredreichbier> hehe
[11:59] <fredreichbier> ah sorry i misunderstood you
[12:00] <fredreichbier> i thought you meant the hook classes. what about a hook i wrote myself? ;)
[12:01] <lifeless> oh, hooks fire for every branch, but you can easily look for some option to enable/disable
[12:03] <lifeless> for an example, the email plugin looks for an email address to send the email to
[12:06] <fredreichbier> ok, i will read the code. thanks you :)
[12:29] <lifeless> k, moved the branch to lp:~lifeless/bzr-search/trunk
[12:39] <cjwatson> Hi, I'm trying to get bzr-git to work, and having no luck at all. Can anyone help out?
[12:40] <cjwatson> 'bzr get git://git.debian.org/git/tasksel/tasksel.git' says 'bzr: ERROR: Unsupported protocol for url "git://git.debian.org/git/tasksel/tasksel.git"'
[12:40] <cjwatson> 'bzr get http://git.debian.org/git/tasksel/tasksel.git' says 'bzr: ERROR: Not a branch: "http://git.debian.org/git/tasksel/tasksel.git/".'
[12:40] <lifeless> cjwatson: you will need to write quite some code to make that work
[12:40] <james_w> hi cjwatson
[12:41] <cjwatson> lifeless: what is bzr-git good for?
[12:41] <lifeless> ddaa did a branch that can clone locally I believe
[12:41] <lifeless> its still in development
[12:42] <lifeless> call it pre-alpha, not feature compelte
[12:43] <cjwatson> ah, I see; I mistakenly assumed that "enough support for bzrk to operate" would be enough to clone
[12:43] <lifeless> hell no
[12:44] <cjwatson> perhaps some indication could be added to its Launchpad project page so that more people don't get misled?
[12:44] <lifeless> indeed
[12:56] <mpt> I have a branch where "bzr diff" works, but "bzr log" returns an error
[12:56] <mpt> http://bzr.pastebin.com/m68ff744a
[12:56] <james_w> mpt: that's a bug with ghost handling
[12:56] <james_w> I think there is a patch for it, it may even be in bzr.dev, is that what you are using?
[12:57] <mpt> james_w, I'm using bzr.dev as of about last Thursday
[12:57] <james_w> maybe it's not made it yet then.
[12:59] <mpt> james_w, do you mean bug 235055?
[12:59] <james_w> yup, I think that's it
[13:00] <james_w> ah, so no patch yet.
[13:01] <mpt> james_w, so is it safe to continue working with the branch in the meantime?
[13:01] <james_w> yep, it's a bug specifically in the log code I believe
[13:02] <mpt> ok, thanks
[13:09] <lamont> is there a bzrtools to go with the bzr 1.6 beta?
[13:24] <uws> lamont: yes.
[13:24] <uws> lamont: http://launchpad.net/bzrtools/stable/1.6.0/+download/bzrtools-1.6.0.tar.gz
[13:24] <uws> lamont: linked from http://bazaar-vcs.org/BzrTools
[13:24] <lamont> any chance of that landing in the bzr beta ppa?
[13:28] <mpt> james_w, but now the branch won't push
[13:28] <lamont> uws: so bzrtools is non-beta 1.6?
[13:28] <lamont> interesting
[13:29] <uws> lamont: Well, I think the API is finalized, so bzrtools knows what to expect ;)
[13:30] <lamont> true enough
[13:30] <lifeless> this will be interesting when versionedfiles lands
[13:30] <lifeless> and deletes about 3000 lines of api
[13:30] <lifeless> we'll see
[13:32] <mpt> How can I get around this error with push? http://bzr.pastebin.com/m6244a2b1
[13:42] <mathrick> what is the bzr approach to integration with !python languages?
[13:45] <mathrick> mpt: that is just generic poking around, but is the remote repo consistent?
[13:45] <mathrick> then, what is the revno of your source repo?
[13:45] <mathrick> and last, run bzr with BZR_PDB=1, that will break into the debugger on errors
[13:46] <mpt> mathrick, by "consistent" do you mean it passes bzr check, or what?
[13:46] <mathrick> yeah
[13:46] <mathrick> not corrupted
[13:46] <mpt> I'll try that
[13:46] <mpt> mathrick, the revno of my local branch is "1", because of bug 235055
[13:47] <mpt> In reality it's 6416
[13:47] <mpt> (which seems to be what the traceback is complaining about)
[13:54] <mathrick> mpt: so it seems, I have no idea if you can do anything about it short of getting the bug fixed
[13:55] <mpt> ok, thanks for your time anyway :-)
[13:56] <mathrick> mpt: not much to thank for, I'm mostly a lurker/asker myself :)
[14:16] <tethridge> anybody know of a clear case plugin for bzr?
[14:21] <mtaylor> hey lovely folks...
[14:22] <mtaylor> if I wanted to add some print statements to merge so I could tell what file it's working on... where would be a good place to start?
[14:44] <ricardokirkner> hi folks. I am having this strange issue here. I configure bzr as a smart server with http authentication (using the bzr-smart.py handler). The strange thing is this. I have two projects set up to use different bzr repositories. When I hit the first project (for a log, status, info, etc.) everything works out ok, but when I try to access the second repository, I get an error 'Not a branch'. If I restart apache and try to access this last repository
[14:44] <ricardokirkner> everything works out ok, but now the first project's repository throws the 'Not a branch' error. Somehow it seems I can only have one repository working this way. Any ideas?
[14:52] <enquest> how do I revert one file to an older state... Without that some other files would come along?
[14:52] <tethridge> enquest, specifiy the name of the file bzr rever /path/to/the/file
[14:52] <tethridge> that should be "bzr revert"
[14:53] <enquest> something like : bzr revert -r 32 foo/bar.html
[14:53] <tethridge> yes
[14:53] <tethridge> enquest, I'm reading through this now.  Thought I would share.  http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[14:53] <enquest> ok thanxs... And if I want to go back to 33
[14:53] <tethridge> I'm a new user too
[14:53] <mathrick> enquest: revert -r 33
[14:53] <tethridge> it's an easy read
[14:54] <mathrick> enquest: revert only operates on the working tree, it never touches the repo
[14:54] <enquest> The docs are a big beef...
[14:54] <tethridge> can somebody tell me what the main benefit to "init-repo" is?
[14:54] <tethridge> the user guide doesn't really go into a lot of detail
[14:54] <tethridge> what is it doing, saving space?
[14:54] <mathrick> (therefore you should be careful not to confuse uncommit and revert, and there's a catch that after a revert bzr revno will not necessarily reflect the working tree's state)
[14:55] <Kinnison> repositories help when you have lots of related branches
[14:55] <tethridge> help how?
[14:55] <Kinnison> they can be used to save space by sharing the revisions between the branches
[14:55] <mathrick> tethridge: repo is a collection of branches
[14:55] <mathrick> they are able to share data
[14:55] <Kinnison> E.g. I have a repo for my project 'libgfshare'
[14:55] <Kinnison> which has branches 'devel' 'release-1.0' 'add-fs' etc
[14:56] <mathrick> the two benefits of repos as less space used and (much) faster branching
[14:57] <mathrick> both of which come from the fact revisions are shared
[14:57] <tethridge> ok, thanks
[14:57] <enquest> thxs that worked
[14:57] <mathrick> eg. bzr branch bzr.dev/ bzr.copy/ takes about 1m on standalone trees, and about 2s on a repo branch
[14:57] <tethridge> so if I already have a my-projects-branches directory with branches below
[14:57] <enquest> thxs that worked
[14:57] <mathrick> because there's 90m of data to shuffle around
[14:58] <tethridge> can I init-repo the my-projects-branches after the fact and have it work?
[14:58] <mathrick> tethridge: not directly, you need to bzr reconfigure --use-repo the branches
[14:58] <mathrick> after init-repo
[14:58] <tethridge> ok
[14:58] <mathrick> err, --use-shared
[15:00] <enquest> are there places where you can use bzr without having to install it your self. Auto backup and correct security and private?
[15:01] <fredreichbier> enquest: ehm... you can use any shared hoster with ftp access for bazaar hosting, if i understood you correctly
[15:02] <enquest> yeah but I don't want to setup anything... Just some commercial service?
[15:07] <doctormo> hey all
[15:07] <mathrick> enquest: all bzr needs is ftp or similar write access to use a remote location as a repo
[15:08] <tethridge> mathrick, can you give me the full command for --use-shared?
[15:08] <doctormo> trying to push something to launchpad as an inital push, looks like I've gotten a broken .bzr it says: you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again.
[15:08] <mathrick> tethridge: bzr help reconfigure
[15:08] <tethridge> thanks
[15:09] <kiko> kiko@gasolinux:~/devel/fix-rdf-icon-queries$ get-lp-branch bzr+ssh://devpad.canonical.com/code/tom.berger/launchpad/actionmenuless-bug-page-hold-off
[15:09] <kiko> bzr: ERROR: exceptions.AssertionError: unexpected response code ('error', "'launchpad@pqm.canonical.com-20080417230844-njz750l4kkk38m3c'")
[15:09] <kiko> mmmm!
[15:09] <kiko> wow, bzr 1.3.1
[15:09] <kiko> let me upgrade.
[15:09] <mathrick> humm, shouldn't 1.3 understand the new smart protocol already?
[15:10] <tethridge> mathrick, is that a new argument?  It doesn't show up when I do a bzr help reconfigure
[15:10] <mathrick> it sounds like something that would result from the confusion of old bzr caused by the new protocol
[15:10] <tethridge> I'm using gutsy
[15:10] <kiko> it does, but I think it does
[15:10] <mathrick> tethridge: bzr --version?
[15:10] <kiko> I think it dies in some corner cases
[15:10] <tethridge> 1.3.1rc1
[15:10] <fullermd> Doesn't seem likely.  You wouldn't get new version responses unless you made a new version request.
[15:11] <mathrick> tethridge: then it should have that, paste the result you get into http://pastebin.com
[15:11] <tethridge> mathrick, http://pastebin.com/d54445ad1
[15:12] <mathrick> hmm
[15:13] <mathrick> tethridge: oh, right, it's new in 1.4
[15:13] <mathrick> I think you can work around that, tho
[15:13] <mathrick> tethridge: move your existing branches somewhere, and try that: bzr branch /temp/branch /path/to/repo/
[15:14] <mathrick> bah
[15:14] <mathrick> bzr branch /temp/branch /path/to/repo/branch1
[15:14] <tethridge> mathrick, how can I tell if the branch under the repo is using the repo?
[15:14] <mathrick> bzr info
[15:14] <mathrick> it will tell you if it's standalone or not
[15:15] <doctormo> did my question apear? or did I get ignored?
[15:16] <tethridge> mathrick, that works
[15:17] <tethridge> can I delete the old branches once I create the new branches under the repo?
[15:17] <spiv> kiko: Try "bzr -Dhpss ...", and check the ~/.bzr.log on both sides.
[15:17] <Jc2k> doctormo: i dare say "accidentally not seen" rather than ignored ;)
[15:17] <spiv> kiko: (but do try upgrading the client to 1.5 first)
[15:18] <kiko> spiv, yeah, upgrading first
[15:19] <tethridge> mathrick, did you see my question about deleting the original branches?
[15:20] <doctormo> Jc2k: would you like me to retype?
[15:22] <Jc2k> doctormo: i can see your q, not that i know enough about bzr to help you
[15:23] <doctormo> Ah I see.. damn it, should I remove the code from launchpad and try again?
[15:23] <kiko> kiko@gasolinux:~/devel$ get-lp-branch bzr+ssh://devpad.canonical.com/code/tom.berger/launchpad/actionmenuless-bug-page-hold-off
[15:23] <kiko> bzr: ERROR: Generic bzr smart protocol error: unexpected response code (('error', "'launchpad@pqm.canonical.com-20080417230844-njz750l4kkk38m3c'"), <bzrlib.smart.protocol.SmartClientRequestProtocolTwo object at 0x89a656c>)
[15:23] <kiko> spiv, interesting, eh?
[15:23] <kiko> spiv, this is local to devpad
[15:24] <kiko> spiv, can you reproduce it?
[15:24] <doctormo> Jc2k: nope, recreating didn't work :-(
[15:24] <kiko> I'm just doing bzr branch
[15:24] <spiv> kiko: the ~/.bzr.log once you use -Dhpss would be much more interesting
[15:24] <Jc2k> doctormo: where are you pushing to?
[15:24] <kiko> spiv, can you try and reproduce? less chinese whispers that way
[15:24] <Jc2k> doctormo: and what version of bzr?
[15:24] <spiv> kiko: I'm about to sleep
[15:24] <doctormo> Jc2k: launchpad
[15:24] <doctormo> Bazaar (bzr) 1.3.1
[15:24] <kiko> spiv, so you can leave it running overnight
[15:24] <spiv> (It's past my bedtime on a public holiday)
[15:25] <Jc2k> doctormo: ys, but are you pushing to lp:somefoo/blah or sftp://some.launchpad.url.i.cant.remember ?
[15:25] <doctormo> I use bzr push https://code.launchpad.net/~ubuntu-us-ma/us-ma-loco-site/trunk, because lp doesn't work
[15:25] <spiv> kiko: you probably have a traceback in your ~/.bzr.log on the server side that would be helpful
[15:25]  * spiv -> zzz
[15:26] <kiko> spiv, um, yeah, and you can see it too -- and I won't be the one fixing that bug so..
[15:27] <Jc2k> doctormo: apparently you can also push to bzr+ssh://john.doe@bazaar.launchpad.net/~john.doe/+junk/myproject
[15:28] <Jc2k> doctormo: but i've only ever used the form bzr push sftp://uberperson@bazaar.launchpad.net/~uber-dev-team/ubuntu/development myself
[15:28] <doctormo> Jc2k: ah I think that is what I used for other projects
[15:31] <doctormo> thanks Jc2k
[15:35] <Pieter> haha
[15:35] <Pieter>   File "/opt/local/lib/python2.5/site-packages/bzrlib/index.py", line 834, in _parse_segment
[15:35] <Pieter>     raise AssertionError('no \n was present')
[15:35] <Pieter> AssertionError: no
[15:35] <Pieter>  was present
[15:36] <Jc2k> lol
[15:53] <tethridge> is there a skeleton plugin somewhere?
[16:17] <fredreichbier> hi. i have developed a plugin named nicehtml, as a "more flexible htmllog". it generates a html information page for a branch, example page: http://bzr.reichbier.de/pywmctrl-main/ - and I'd like to know what you think about ;) code available here: http://bzr.reichbier.de/nicehtml/ :)
[16:17] <Dauerbaustelle> now, actually, we have developed :P
[16:19] <fredreichbier> ah, sorry, dependencies are python-jinja and python-pygments :x
[16:29] <akojima> is there a way to ignore line end styles (\r\n vs \n) when merging/diffing?
[16:31] <Odd_Bloke> fredreichbier: I recommend sending an email to the list letting people know about it (if you haven't already done that; I'm a few days behind on list traffic).
[16:32] <victorng> hi all
[16:32] <fredreichbier> Odd_Bloke: thanks, I'll do ;)
[16:33] <victorng> has anyone had luck gettin bzr-svn working in osx 10.5?  the instructions @  http://bazaar-vcs.org/BzrForeignBranches/Subversion don't seem to work for me
[16:34] <victorng> i get the following error messages: bzr branch https://svn.collab.net/repos/svn/trunk test
[16:34] <victorng> bzr: ERROR: Not a branch: "https://svn.collab.net/repos/svn/trunk/".
[16:35] <Jc2k> victorng: what about if you try bzr branch svn+https://svn.collab.net/repos/svn/trunk ?
[16:36] <victorng> jc2k: uh... weird... i'm just trying with the svn binary i built as per the instructions on the bazaar-vcs page and the svn client doesn't seem to speak http
[16:37] <victorng> plain "svn co" doesn't seem to work with that custom svn binary
[16:37] <Jc2k> http or https?
[16:37] <victorng> both
[16:37] <victorng> :(
[16:37] <victorng> weird
[16:37] <victorng> i had to add a --without-gssapi --disable-gssapi when compiling svn
[16:38] <Jc2k> that might explain what is wrong with https, but i wouldnt have expected http to break
[16:38] <victorng> i kept getting errors in neon yelling about GSS_C_NT_HOSTBASED_SERVICE
[16:39] <victorng> so i tried to explicitly disable the GSS stuff
[16:39] <victorng> hmm
[16:39] <mpt> jam, good morning, do you have time to help me with a broken branch or two?
[16:39] <jam> mpt: morning mpt
[16:39] <jam> I think so
[16:41] <mpt> jam, so I have a branch that suffers from 235055. I can't bzr log, but I can still bzr st, diff, and commit
[16:41] <jam> bug #235055
[16:41] <mpt> jam, but when I try to push: http://bzr.pastebin.com/m6244a2b1
[16:42] <jam> mpt: that certainly sounds like the ghost problem
[16:42] <jam> the "revno' in the second case is so short because there is a ghost
[16:43] <mpt> jam, yes, bzr revno returns "1" when it should be 6416
[16:43] <mpt> I don't mind not being able to log, but I really do need to be able to push :-)
[16:45] <jam> mpt: I have a script around that copies revisions from other repos to fill in ghosts like this
[16:45] <jam> I attached it to a bug, but it wasn't *that* bug :(
[16:46] <jam> mpt: I'll paste bin it
[16:47] <jam> !paste
[16:47] <jam> mpt: http://paste.ubuntu.com/18789/
[16:48] <jam> Basically, you'll run it as "python copy_all_revisions.py remote_repo local_repo"
[16:48] <jam> It will probably copy more than you need, but if we can get it all done right away, so much the better
[16:50] <mpt> jam, should I uncommit to get a sensible revno in the branch before I run the script? or doesn't it matter?
[16:50] <jam> mpt: I don't think it will batter
[16:50] <jam> matter
[16:50] <jam> as long as the pointers are still there, which they should be
[16:55] <beuno> lifeless, plugin is looking very good. Maybe I should try and trick mwhudson into making me work on this as part of Loggerhead...  ;)
[16:58] <mpt> jam, thanks, trying it now
[16:58] <jam> mpt: we *might* need to go cheat and fix the revno, but we'll cross that when we get there
[17:00] <mpt> Target is missing 417 revisions
[17:11] <jam> mpt: some of those will be other heads, and some will be ghosts you want to fill. but it shouldn't take long with only 400 missing
[17:11] <mpt> It's halfway there
[17:12] <jam> mpt: and the first half is the "slow" half
[17:12] <jam> I sort topologically, and start fetching from the one that is likely to fetch the most ancestors
[17:12] <mpt> ok
[17:12] <mpt> Just out of interest, what's a "head"?
[17:13] <jamesh> mpt: each revision has a pointer to its parent(s)
[17:13] <jamesh> mpt: a head has no other revision pointing to it as a parent
[17:13] <mpt> ok
[17:14] <mpt> so as soon as I make a commit in a branch, that's a head
[17:14] <jamesh> and it'll stay a head until you commit a subsequent revision
[17:14] <mpt> but as soon as I make another commit, that previous one stops being a head
[17:14] <jamesh> if you "bzr uncommit", the head stays in the repository though
[17:14] <jam> mpt: mostly it is likely to be stuff from other branches, or someone doing 'bzr uncommit", etc.
[17:16] <mpt> ok, finished
[17:17] <mpt> jam, "bzr log" no longer returns an error, but it returns only one revision, my most recent one, r6416
[17:17] <jam> mpt: right, probably because of the 'revno = 1' stuff
[17:17] <mpt> yeah
[17:17] <jam> you *know* it is 6416, right?
[17:17] <jam> edit .bzr/branch/last-revision
[17:18] <jam> and fudge that number in
[17:18] <jam> if it doesn't say '1' then stop
[17:18] <mpt> My copy of the same branch in the remote repo doesn't have that revision, but it has 6415, 6414, 6413, etc
[17:19] <jam> mpt: sounds close enough :)
[17:19] <jam> mpt: we can always work out it if it is wrong again, but I'd like to get it right the first time
[17:19] <mpt> jam, .bzr/branch/last-revision doesn't exist
[17:20] <jam> mpt: is there a .bzr/branch/revision_history then?
[17:20] <mpt> should I create it?
[17:20] <jam> you might have an older branch format
[17:20] <mpt> yes, there's revision_history
[17:20] <jam> :(
[17:20] <jam> oh wait, you should be able to "bzr reconcile" the branch
[17:20] <jam> I added that in a recent release
[17:20] <mpt> wait
[17:20] <mpt> sorry
[17:21] <mpt> I was still looking at the copy in the remote repo
[17:21] <mpt> ... oh, the local copy doesn't have .bzr/branch/revision_history either
[17:21] <mpt> ok, I'll try reconcile
[17:22] <mpt> "Fixing last revision info 1 => 6416" - yay
[17:22] <jam> sometimes things work out well :)
[17:49] <korpios> Having a hard time finding an answer to this via the Bazaar website or Google: how would I cleanly delete a branch within a shared repository?  If I simply rm -rf'd the dir, wouldn't that leave old, now-unused data in the shared repo?
[17:49] <akojima> is there a way to revert a merge?
[17:51] <LarstiQ> korpios: yes, but that doesn't need to be a problem. Is it for you?
[17:52] <korpios> LarstiQ: Well, if I make lots-and-lots of feature branches and kill them once I'm done with them ...
[17:53] <jam> korpios: well if they are merged into the other branch, then you need the info anyway
[17:53] <jam> and otherwise when you copy stuff out of this repo, if they aren't referenced, they won't be transmitted
[17:53] <korpios> jam: True, but I'm thinking more failed ideas, screwups, and the like
[17:53] <jam> korpios: sure, but they rarely take up much space
[17:53] <jam> versus the size of everything else
[17:53] <jam> and it doesn't propagate
[17:54] <jam> I believe Jelmer has a plugin which will garbage collect your repo, but you have to be careful that there aren't any branches you forgot about
[17:55] <korpios> Somewhat related question that this brings to mind: would a new shared repo created by branching from a few branches of an old shared repo lose the benefits of a shared repo?
[17:56] <korpios> (at least for those branches, not new ones going forward)
[17:56] <jam> korpios: the branches in the new shared repo will still share between eachother
[17:56] <jam> but it will copy the data from the old to the new repo
[17:56] <korpios> right, that part is fine
[17:57] <korpios> but if I have shared repos A and B, I could branch A/* to B, and the new B/* would still be sharing data amongst each of the B's?
[17:58] <korpios> (I'm thinking "poor man's garbage collection")  :p
[17:58] <jam> korpios: branching from A/* => B/* will share stuff in B/*
[17:58] <jam> korpios: and that is exactly what Jelmer's plugin does for you
[17:58] <korpios> Ah ^_^
[17:58] <LarstiQ> korpios: yes, that is indeed the poor man's garbage collection approach
[17:58] <jam> it just replaces the repo in place at th eend
[17:59] <jam> korpios: the one thing it loses is parent pointers (where the branch was branched *from*) which is one of the benefits or the plugin
[17:59] <jam> since it doesn't actually create new branches
[18:00] <korpios> Nice ... I was worried that the B/* wouldn't share since they weren't created "together", but I'm guessing this has to do with the shared repo just seeing "hey, these two have the same object, let's share" regardless of source?
[18:01] <jam> korpios: correct
[18:01]  * korpios feels better :)
[18:02] <korpios> thanks!
[18:25] <rammel> Hi all. A team member is trying to commit to his branch over bzr+ssh on windows using bzr 1.5. After some seconds the console screen stalls and nothing happens any more. If the guy breaks with ctrl-c and trys to break the lock, bzr stalls again. If he ssh's to the server and enters bzr break-lock, it works. But the next try to commit fails again. What could it be?  Thank you!
[18:36] <victorng> hey - when i try to use bzr-svn and branch a svn repository over HTTPS - i get this: Assertion failed: (g->gc.gc_refs != _PyGC_REFS_UNTRACKED), function instancemethod_dealloc, file Objects/classobject.c, line 2285
[18:38] <victorng> when i branch a svn repo over plain HTTP, it seems to hang forever
[18:47] <mpt> mathrick, the "bzr check" you suggested just finished with a KnitCorrupt error :-)
[18:48] <korpios> Hmm ... I have a branch in my shared-repo that's just for mirroring a launchpad repo.  That works, pulls fine, etc.  I created a second empty branch as my "local dev mainline", and tried to merge in the mirror branch; it seems to merge okay, but on update it gives: "bzr: ERROR: Reserved revision-id {null:}"
[18:48] <korpios> (I'm using merge so I can avoid seeing the history on bzr log --short)
[18:48] <korpios> I've tried this with 1.5 and 1.6b1, same result
[18:49] <mathrick> mpt: heh, that was fast :)
[18:50] <korpios> I can't find any bugs in bazaar's launchpad tracker that seem directly related
[19:06] <emilis_info> hi, I have a question: will bzr autodetect moved files or do I have to use `bzr move src dest`?
[19:12] <gour> hard to believe...svn needs 10 rcs to release :-/
[19:13] <cr3> what does this mean: bzr: ERROR: Unknown bzrdir format: ''
[19:14] <korpios> Gah, even with bzr.dev (the "bzr: ERROR: Reserved revision-id {null:}" error)
[19:18] <cr3> wtf! bzr: ERROR: Revision {email-20080417161838-a2tfnk26kx1q7vjf} not present in "revisions.kndx".
[19:21] <gour> emilis_info: afaik, bzr does proper tracking for renames
[19:21] <emilis_info> gour, so, it should detect automaticly if I move a file?
[19:21] <cr3> googling for that error returns a message from irclog asked by myself, unanswered, and bug #232270, also unanswered :)
[19:24] <gour> emilis_info: i'd say - yes. but bear in mind i'm quite new with bzr coming from darcs and, iirc, bzr does the same thing. try on some test-case or wait for some bzr dev to get definite answer
[19:24] <emilis_info> gour, thx
[19:25] <emilis_info> gour, how is bzr compared to darcs? :)
[19:28] <gour> emilis_info: i LIKE it. it's not much complicated, or let's say quite easy with nice interface, simple-enough model so you can understand what's going on (unlike that kernel-VCS) and it is quite safe
[19:28] <emilis_info> :)
[19:29] <gour> emilis_info: good win32 support (it will be useful for my win32-dev-friends) and nice gui-tools (bzr-gtk) for my gui-friend-lovers (i'm satisfied with cli)
[19:29]  * emilis_info too
[19:29] <gour> regular release, active community, friendly #bzr...
[19:30] <gour> i'm not so much concerned with performance, but this is also improving...
[19:30] <gour> all in all...bzr is for me, without competition ;)
[19:33] <cr3> are there bzr commands to fix a bzr repository?
[19:36] <gour> cr3: bzr reconcile ?
[19:53] <Pilky> emilis_info: you need to use bzr mv for bzr to pick up you've renamed/moved a file
[19:53] <Pilky> otherwise it will think you've removed it and added a new file
[19:53] <beuno> cr3, try: bzr reconcile LOCATION
[19:54] <emilis_info> Pilky, thanks
[19:54] <emilis_info> that answered my question
[20:38] <beuno> jam, btw, happy birthday  :)
[20:44] <dvheumen> I've been looking at the site and documentation, but I couldn't find the answer to my question exactly, so I'm asking here... When I do a lightweight checkout, what is the bandwidth cost when a commit changes? (since it seemed to me that no original files are stored in the lightweight checkout)
[20:45] <fbond> Hi, I have a source tree that contains an svn repository.  I need to add the svn repository to my bzr branch.
[20:46] <fbond> bzr add refuses because I have bzr-svn installed and it refuses to see that directory as a simple directory.
[20:46] <fbond> I.e., it wants to treat it as a repo.
[20:46] <fbond> Any way around this (besides uninstall bzr-svn)?
[20:47] <Stavros> hello
[20:47] <Stavros> can someone tell me what update does exactly/
[20:48] <Stavros> does it get the changes from the branch to your working copy?
[20:49] <beuno> Stavros, yes, it updates the working tree, and, if it's a checkout, it also updates to the latest revisions
[20:50] <Stavros> hmm, checkout is a subcategory of update you mean?
[20:50] <Stavros> i don't understand that
[20:50] <Stavros> if it updates the WC, shouldn't it also update to the latest revision?
[20:51] <beuno> Stavros, well, if it's not a checkout, than you may not want the latest revision
[20:51] <Stavros> you mean latest revision in general?
[20:52] <Stavros> not just in my repository?
[20:52] <beuno> in the case of a checkout, it updates to the last revision the branch you're bind to has
[20:53] <Stavros> ah
[20:53] <Stavros> and what if the branches have diverged?
[20:59] <beuno> Stavros, well, when you commit to a checkout
[20:59] <beuno> it doesn't let you unless you're up to date
[20:59] <beuno> because it commits to the bound branch
[20:59] <Stavros> well no, i mean if you pull and you have local changes and the other branch has changes as well
[20:59] <Stavros> what do you do in that case?
[21:00] <beuno> Stavros, if you pull, you're not using a checkout
[21:00] <Stavros> well yes, i didn't say i was, you did :P
[21:00] <beuno> in that case, update just updates the working tree, which would be up to date if it's local
[21:00] <Stavros> a checkout is just a pull/update, isn't it?
[21:01] <beuno> a checkout is bound to a branch
[21:01] <beuno> so it may be a bit more complicated than pull/update, since you commit *to* the bound branch
[21:02] <beuno> if you're pulling changes locally, than you don't need update
[21:02] <Stavros> ah
[21:02] <Stavros> i see, thanks
[21:02] <beuno> when you push remotely, like, for example, via sftp, the remote branch WT is not updated
[21:02] <beuno> it has the latest revisions
[21:03] <beuno> but you have to explicetly run update on it
[21:03] <Stavros> ah, yes
[21:03] <Stavros> i'm a bit unclear still on how you resolve collisions
[21:03] <Stavros> conflicts
[21:04] <Stavros> you merge manually and then you commit?
[21:04] <beuno> basically, you edit the file that has the conflicts to how you really want it to look, and remove all herring markers
[21:04] <beuno> than, bzr resolve FILE
[21:04] <beuno> commit
[21:04] <beuno> you're set
[21:04] <Stavros> ah
[21:04] <Stavros> i tried that once and it turned all the other commits into one with my name on it
[21:04] <beuno> well, yes and no
[21:04] <Stavros> so i wasn't sure if that was the right thing to do
[21:04] <beuno> they are sub-commits
[21:05] <Stavros> ah
[21:05] <beuno> you will see them as merges into your commit
[21:05] <beuno> with subrevnos like 13.1.1
[21:05] <Stavros> ah yes
[21:05] <Stavros> interesting, thanks
[21:05] <Stavros> that clears it up
[21:05] <beuno> I'm glad  :)
[21:05] <Stavros> thanks :)
[21:06] <beuno> my pleasure
[21:31] <aantn> hello
[21:31] <aantn> I'm having some trouble pushing a revision to a new branch I just branched
[21:31] <aantn> I get the following error
[21:32] <aantn> http://rafb.net/p/vvGXf170.html
[21:32] <beuno> aantn, try:  bzr launchpad-login your_username && bzr push --use-existing-dir
[21:32] <aantn> I tried running bzr launchpad-login aantny, but it didn't help
[21:32] <beuno> ah, well, it should  :)
[21:33] <aantn> beuno: it doesn't
[21:34] <beuno> aantn, that error message is *after* you ran launchpad-login?
[21:34] <aantn> beuno: that's correct
[21:34] <beuno> aantn, try:  bzr push lp:~screenlets-extras-team/screenlets/screenlets-extras
[21:35] <aantn> beuno: thanks, that works
[21:35] <aantn> the url I was using shouldn't have began with http://
[21:36] <beuno> aantn, you should do that again, and add a --remember
[21:36] <beuno> so it doesn't happen again
[21:36] <beuno> aantn, exactly, http is read-only
[21:36] <aantn> beuno: I know; thanks
[21:36] <beuno> aantn, np  :)
[21:47] <LaserJock> with bzr-svn are svn tags and branches just normal bzr branches?
[22:02] <Peng> LaserJock: Yes.
[22:38] <jelmer> fbond: bzr --no-plugins add ...
[23:00] <beuno> vila, around?   I have a tests question  :)
[23:05] <beuno> vila, anyway, when you are, I added a --dry-run command to bzr-upload, and I wanted to add tests for the new switch, but I'm not sure duplicating all tests is the right way to go  :)
[23:45] <jml> abentley, lifeless: what did we end up deciding with the bzrdir.clone changes for stacking?
[23:49] <abentley> jml: I applied your patch and then made the behavior optional.
[23:49] <jml> abentley: ok. thanks.
[23:50] <abentley> jml: And then regaled you with tales of how clone isn't really clone.
[23:51] <Kinnison> thus jml blocked the episode from his mind.
[23:52] <jml> long weekend had more to do with it, I think :)
[23:54] <Kinnison> :-)