[00:02] Well, technically, a .bzr/repository folder without an upload folder is corrupt. [00:02] It happens to be a very easy-to-repair corruption, though. [00:02] spiv, yes. :) [00:02] spiv, it's "corrupt" not "OMG THE SKY IS FALLING" ... [00:04] hello, i'm a bzr n00b, and it's printing this error with a "get" : bzr: ERROR: Lock not held: LockableFiles... [00:04] hmm.... it also happens with "info" on the same URL... is it a server issue? [00:11] I need to make a knit branch with lots of ugly, url-escape-needing paths. [00:12] anyone have one lying around? [00:12] bzr-svn is good at that :) [00:12] jml: https://code.edge.launchpad.net/~mwhudson/pydoctor/axiom-attr-support might fit [00:13] yeah, looks like it [00:13] mwhudson: sweet. thanks. [00:14] e.g. http://bazaar.launchpad.net/~mwhudson/pydoctor/axiom-attr-support/.bzr/repository/knits/06/ [00:22] jml: interesting; its a key goal of switch to switch with edits; you just want a '--with-edits' option, or ??? [00:22] lifeless: basically, yes. [00:23] lifeless: the thing that's happened a lot to me is that I've switched to trunk to pull, and got conflicts because I have uncommitted changes. [00:23] jml: would it help if switch told you about the remaining local edits? [00:23] e.g. switch == switch + status --short? [00:23] lifeless: before or after it switched? [00:24] post [00:24] pre is meaningless as the switch may eliminate outstanding changes [00:24] hmmm. well, it would help if there was a clear way to undo it, particularly in the case of conflicts. [00:25] jml: I think this needs more discussion; please mail the list and I'll try to reply tonight once backa tthe hotel [00:25] lifeless: will do. [00:28] i've always found it slightly weird that pull doesn't complain about local changes [00:28] if you're pulling, you're maintaining a local mirror [00:29] wth are you doing editing it? [00:29] other workflows may vary i guess [00:30] kenichi: :P [00:33] fwiw, kenichi is running bzr 1.10, and i experience the same problem in bzr.dev. [00:33] http://pastebin.com/d37ce3b4f <--- all two lines of my issue :) [00:36] Traceback: http://paste.pocoo.org/show/VFV2fMUc25uhKKEBIuRf/ (But it doesn't look very interesting; the exception is rather self-explanatory.) [00:37] is bzr-svn messing things up again? [00:38] mwhudson: For this? --no-plugins doesn't help. [00:39] ah well [00:40] Heh. [00:42] mwhudson: It's more for a workflow where you "bzr pull; bzr commit; bzr push". === abentley1 is now known as abentley [00:43] yeah, i guess so [01:02] use pyflakes guys [01:03] https://bugs.edge.launchpad.net/bzr/+bug/307327 [01:03] Error: bug 307327 not found [01:03] I smell replication lag :) [01:04] jml: by "guys", you mean "abentley" ;) [01:07] jml: ? [01:08] abentley: a -Dhpss mutter that moved in your patch from remote.py to graph.py is failing due to a missing import of mutter in graph.py [01:08] spiv: [01:08] Sorry. [01:09] abentley: not a big deal. I'm considering just deleting the offending mutter. [01:11] I don't think we've ever really used it, so it's just yet another thing filling log files. And -Dhpss isn't exactly the right condition for it now it's in a more general-purpose class. [01:12] Hmm, although, you did make a _debug variable for it. [01:12] So if we want to keep the debugging there ought to be tests for the debug case. [01:12] spiv: Yeah, I agreed that hpss was the wrong flag for a general-purpose thing. [01:13] I'm going to make a plugin that does: bzr down bottom:; bzr pull; bzr up-thread --auto; bzr switch [01:13] abentley: do you have any interest in keeping that debugging? I'm inclined to just delete it. [01:13] spiv: No, I don't. [01:13] jml: What about "shelve --all" first? [01:13] Ok, let's just remove it as cruft. It's not hard to reinstate if someone actually wants it. [01:14] abentley: and unshelve at the end? not a bad idea. [01:14] jml: yeah [01:21] jml, abentley: patch for 307327 sent [01:24] spiv: I see you also deleted an import. Was that deliberate? [01:25] * jml bundle buggers. [01:25] abentley: yes. That import statement was unused. [01:25] I meant to mention that in the email... [01:26] abentley: that import statement was all that was standing between me and clean "pyflakes bzrlib/graph.py" output :) [01:27] i cleaned up all the flakes in bzrlib/[ab]*.py at one point i think... [01:27] spiv: I'm not sure why that was there in the first place. It may have been backwards compatibility. [01:27] abentley: well, in the absence of a comment... [01:28] * spiv looks at how long it's been there [01:28] * spiv also wishes Python had a mechanism for deprecating module attributes [01:29] abentley: that line was added on "Fri 2007-06-08 17:48:42 -0400", in a commit by you saying "Rename graph to deprecated_graph" [01:29] abentley: I guess it's been deprecated long enough by now? [01:30] spiv: lemme check bzrtools [01:30] abentley: hah. :) [01:31] spiv: bzrtools is still importing that stuff, but I can change it to use deprecated_graph. [01:40] abentley: thanks [01:41] abentley: I guess I should add a note to NEWS just in case someone else is still using them. [01:41] spiv: please do [01:41] you can deprecate a module BTW [01:41] 1) make it demand loaded within bzrlib, 2) during import emit a warning [01:45] lifeless: I've reviewed tags. I'll get to the others later. [01:45] lifeless: really, part 1) isn't even necessary. [01:45] spiv: well, it helps :P [01:45] :) [01:45] Someone made a mistake and committed a sensitive file in the very first revision of a branch. Can I use rebase to fix this? I think I can, but I don't understand the documentation [01:46] jelmer: ^ we really need to make this a nobrainer [01:47] Rolly: its something like 'bzr init; bzr merge -1 ../source; bzr revert --forget-merges; bzr rm SENSITIVE; bzr commit -m 'first post'; bzr rebase -r 2.. ../source' [01:47] lifeless: thanks! I'll give it a shot [01:47] that's merge -r 1 ../source, i think [01:48] yeah [01:48] you'll need to use a new repository too, as the history data will stay in the repository and that would be annoying for you :) [01:48] Ah that's OK, it's not shared :) [01:52] * spiv -> food [01:53] whoops, there's also a sensitive change in revno 3 [01:54] I think I can figure it out [01:54] bzr expunge-swearing [01:59] whoops. "bzr merge -r 2 ../source" => bzr: ERROR: A nested progress bar was not 'finished' correctly. [02:00] Rolly: -r 1..2 [02:00] also file a bug [02:00] bbiab, bus time [02:00] thanks lifeless [02:01] still get the error [02:17] filed bug #307340 [02:17] Launchpad bug 307340 in bzr "bzr merge: A nested progress bar was not 'finished' correctly" [Undecided,New] https://launchpad.net/bugs/307340 [03:02] hi [03:02] Rolly: oh, try -r 1..2 --force [03:03] i want someone to pull from my project on launchpad but he's not a launchpad member [03:03] what should he do? [03:03] Rolly: though really, to get rev2 you want to be using rebase at that point [03:03] bzr pull bzr+ssh://bazaar.launchpad.net/~mysticgalaxies/opencollab/devel ? [03:03] meoblast001: go to the project page, then the branch and there is an http url [03:04] meoblast001: bzr branch http://bazaar.launchpad.net/~mysticgalaxies/opencollab/devel [03:04] ok [03:04] thanx [03:16] lifeless: --force still produces the same error [03:21] Rolly: ok, you're going to have to edit the code and disable the error about progress bar not closed to see the real error [03:21] Rolly: thats in bzrlib.progress.py [03:23] can do [03:25] bzrlib/progress.py? [03:27] Rolly: Yeah. [03:27] hi all [03:27] Peng: you'll have to guide me through it, I'm afraid. I don't know very much python. [03:27] Rolly: Eh. I just walked in on this conversation. [03:27] igc: Hello [03:28] oh sorry, I was addressing lifeless [03:29] Rolly: have a look for the error in the file [03:30] Rolly: line 150 [03:30] change [03:30] raise errors.Missing... [03:30] to [03:30] ah [03:30] return # raise errors.Missing [03:34] lifeless: http://pastie.org/337348 [03:37] Rolly: thats a bug; may be hard to reproduce. abentley ^ can you suggest anything? [03:37] Rolly: may need to fill abentley in on how you got that [03:37] Rolly: also, have you already done the init;merge;revert--forget;rm;commit dance to get the first rev across? [03:38] yes i did [03:38] Rolly: try bzr diff -r 1..2 ../source | bzr patch :) [03:40] That will work, but I can wait for abentley to give his input [03:48] Rolly: I wasn't aware of any bugs in that area. Is this a publically-available branch? === Quadduc1 is now known as Quadduc [03:48] I'm afraid not [03:48] Both target and source branches are 1.9-rich-root [03:50] Rolly: So you're running it on an empty branch? [03:52] abentley: I did a few things first: [03:52] bzr init ; bzr merge -r 1 /source ; bzr revert --forget-merges ; cp config.php config.php.template ; bzr rm config.php ; bzr add config.php.template ; bzr ci -m "Initial import" [03:54] by the way, that last commit produced messages like "renamed TODO => TODO", "renamed classes => classes", "renamed models => models", etc [03:54] just thought that was a little wierd [03:55] and at the end of the messages it said: [03:55] Rolly: So, you should never merge into an empty branch unless you're deliberately trying to get the effect of pull. [03:55] deleted [03:55] deleted config.php [03:55] Committed revision 1. [03:55] notice the empty "deleted" [03:55] I see [03:56] I try again, this time using pull [03:56] *I'll [03:57] Well, in your case, maybe that works. But the results are generally confusing. [03:59] Rolly: I *think* what you did is equivalent to "bzr pull -r -1; bzr uncommit" [04:00] Rolly: Why "bzr rm config.php"? [04:02] I don't want config.php versioned at all (I wanted a sanitized config.php.template instead) [04:02] I think pull was the wrong choice [04:04] Rolly: The empty deleted might refer to the root directory. [04:04] It did work, though. No errors when I tried merge -r 1..2 ../source [04:05] but config.php is right there, in revno 1 [04:06] oh, you suggested "bzr pull -r -1; bzr uncommit". I'll try that [04:07] doesn't uncommit still leave the old tip in the repo, though? [04:07] Yes. [04:08] Ah, that won't work for me, then. [04:08] Rolly: So does merge. [04:11] I think that's why lifeless initially suggested 'bzr init; bzr merge -r 1 ../source; bzr revert --forget-merges; etc...' [04:11] Rolly: That will still leave the old tip in the repo. [04:12] There currently isn't anything that removes revisions from a repo. You can gc the repo manually by making a new repo and copying across only the tips you want to keep. [04:12] Is there no way to rebase this branch so that the sensitive file in revno 1 of ../source is completely gone? [04:13] Rolly: removing the sensitive data from the history of the branch is different to also removing it from the repo. [04:13] spiv: what about the remove-revisions plugin? [04:14] Rolly: Rebasing will change the branch history, but you still need to take extra steps (i.e. making a new repo) to remove the revisions from the repo. [04:14] Rolly: If you create a new copy of the branch with "bzr branch", it won't copy the tip. [04:14] Rolly: I'm not familiar with it, sorry. [04:15] OK. Boy, this is extremely confusing to me ;D [04:16] if I branch -r 1 of ../source, the offending file I wish to remove is right there in my repo, no? [04:16] *in my new repo [04:18] Rolly: Yes. I'm talking about if you branch "." [04:20] What if I simply export or copy revno 1 of ../source into my new empty repository, delete the file, and commit? [04:20] Can I then continue to merge the rest of the revisions in ../source? [04:21] Rolly: You need to preserve the file-ids, or else merge won't work. So plain copy or export is not going to do what you want. [04:21] And will that keep the deleted file out of the repo? [04:21] I see [04:22] 'bzr remove-revision' will apparently 'Remove revisions from repository'. Do you think I could use that command to accomplish what I want? [04:22] Rolly: I don't know that command. [04:23] What plugin does it come from? [04:23] If it does do that, then that will accomplish what you want. [04:23] http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk [04:23] But how would it fit in to this whole process? [04:24] Rolly: Presumably, you could run it after you had generated your revised version of the branch. [04:24] bzr init ; bzr pull -r 1 ../source ; bzr remove-revision -r 1 ; bzr add . ; bzr ci [04:24] something like that? ^ [04:25] Rolly: that plugin looks like it needs revids, rather than revnos. [04:25] (which makes sense) [04:25] Rolly: No, you can't commit when your current revision doesn't exist. [04:25] Rolly: You don't need remove-revision. You just need to branch "." [04:26] Rolly: so the procedure would be: generate a branch without the offending revision in its ancestry (e.g. with rebase), then generate a repo without that revision (e.g. with remove-revision, or e.g. by making a new standalone branch). [04:26] abentley: Do you mean 'bzr branch ../source/.' ? [04:26] Rolly: EMPHATICALLY NO [04:26] :*( [04:27] spiv: the offending revision is revno 1. Is rebase still possible? [04:27] I mean "bzr branch . new_version_of_branch_without_offending_revision_in_repo" [04:28] thanks I'm trying that now [04:28] Rolly: I haven't used the rebase plugin enough to know. [04:29] Rolly: you need to do that after you've committed your alternate revno 1. [04:29] Rolly: And probably your alternate revno 2 also. [04:29] But it sounds like you want a different first revision, rather than to just remove the first revision? If so, the "init;merge;revert--forget;rm;commit dance" lifeless mentioned sounds reasonable. [04:30] abentleyL I'm really sorry, I don't understand. I just did "cd ../source ; bzr branch . ../new" and it branched all of the revisions [04:30] Rolly: The problem is that you did "cd ../source". [04:31] Rolly: You have a current directory, containing an alternate revno 1, which does not have config.php. *that* is what you need to branch. [04:32] You have not told me the name of that directory, so I'm calling it "." [04:32] Gotcha. And what does "new_version_of_branch_without_offending_revision_in_repo" mean? [04:33] is that the location I'm branching to? [04:33] Rolly: Yes. [04:33] Eureka, thanks [04:34] Is the "." somehow special? [04:35] No, it's a path like any other. [04:35] Well, a path meaning "the current directory", of course. But just a path. [04:35] Thanks spiv/abentley/lifeless. I'll continue tomorrow but I think I know what I'm doing now [05:55] How can I *permanently* obliterate all records of a file from BZR? [05:56] I'm trying to move some files from a previous closed SVN repo to an open BZR repository, and would like to maintain what history I can, but delete some files which aren't being opened [06:00] chrismurf: "A" method that I personally used: http://www.stedee.id.au/2008/11-06/manually_migrating_subversion_repository_launchpadbzr [06:00] there may be other better ways. YMMV. [06:01] hmm - doesn't sound like fun, but does sound like exactly what I'm looking for :-) [06:01] thanks [06:01] np [06:02] what's the benefit of faffing about with svndump and svnadmin, rather than just using svn2bzr --exclude? [06:02] We use bzr-svn instead now, and it can't exclude? :P [06:03] haha - I see :-) [06:03] oh yeah - svn2bzr doesn't even exist [06:03] how about that [06:04] svn2bzr doesn't exist anymore? [06:07] well, the repo linked to on the site is down: http://bazaar-vcs.org/svn2bzr [06:07] but there are branches in LP that I'm looking at. [06:07] chrismurf: which repo is that? The links I followed on that page all seem to work. [06:08] bottom of page [06:09] "Current development version can be found in" [06:09] chrismurf: that link works for me. [06:09] chrismurf: [06:09] $ bzr log -r -1 --line http://bzr.labix.org/svn2bzr/trunk/ [06:09] Format for http://bzr.labix.org/svn2bzr/trunk/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance [06:09] 13: Gustavo Niemeyer 2008-04-06 Merging changes from James Henstridge branch... [06:09] oop -I'm being stupid [06:09] no HTML page, but BZR Repo. [06:10] thanks === beuno_ is now known as beuno [06:26] Judicious use of svn2bzr is just the ticket. Thanks spm! [06:41] chrismurf: np. I found that bzr-svn just wouldn't work the way I needed it to. Could have been pebkac. Shrug. I got there in the end. :-) [06:41] yeah - I'm finding it doesn't quite do what I want either :-/ [06:42] in particular SVN mv's (of which there were some near the end) are not handled well [06:42] I think that's a problem on the SVN side, but I'm trying to figure out how to match up the move's manually... [06:42] sigh. [06:42] I need a repository editor ;-) [06:42] little delete here and tweak there.... voila! [06:43] what could possibly go wrong [06:43] I vaguely recall it would only process about half of the main repo and then barfed. Hence the switch to svn2bzr, which worked. [06:43] :-) [06:43] I tried to include /trunk/foo/bar and exclude everything else, and it barfed until I also included /trunk$ and /trunk/foo$ [06:44] wasn't smart enough to create dir's [06:44] heh - try and use svndumpfilter maybe? [06:44] may just look at the BZR python API and code the transfer by hand. [06:45] don't know svndumpfilter or particularly want to learn SVN internals :-) [06:46] or maybe I'll just horribly abuse svn2bzr -- hard to say. I'll come up with something. [06:46] svndumpfilter is documented enough in the red-bean book (from memory); and the actual dump file is pretty obvious - well I was able to use awk against it :-) [06:51] anybody know generally how to import "SVN MV" actions to BZR? [06:51] ie how to convert a "delete, add" to a "rename" [06:55] chrismurf: bzr pull will do that [06:55] ah - as opposed to bzr co? [06:56] well bzr co svn://foo will do a branch operation, same overall result [06:56] hm - seemed to not understand mv's somehow... [06:56] will try again. [06:56] sleeptime for me [06:56] gnight all [07:32] hi all [07:43] spm, you there? [08:30] spm, what were you trying to do exactly? [08:31] spm: Importing a svn branch into bzr but ignoring some files from the svn branch in the process? [08:31] lifeless, What should be made a no-brainer? [08:33] jelmer: hey. 2 things - 1. import trunk, ignore all the tags and branches made; and a series of files that I didn't want/need in bzr & 2. change the 'committer' so LP would register it as me. That 2nd was more of an everest challenge than truly being useful. :-) [08:34] * igc dinner [08:34] spm, ah, ok [08:35] spm: That's indeed not possible with bzr-svn [08:35] spm, The idea would be that bzr has some tools to do that sort of thing [08:35] :-) [08:36] jelmer: fwiw, I originally worked this out back in July, so reasons for/why etc are a tad vague now. The blog posting was the streamlined version when I redid for another project. [08:37] "I know this works; I will do it this way" [08:41] howdy [08:42] spm, ah, thanks [08:42] spm, (just curious, but it's good to know about that use case) [08:42] jelmer: np, glad to help even in such a small way :-) [08:43] I'm looking at setting up a central repository for a project and I'm not sure where the files are actually supposed to live [08:43] the manual says that "central shared branches typically only want to store history, not working copies of files" [08:43] so where do the files go? [08:44] tga: do you understand the distinction between working copy, repository and branch? [08:44] not fully, as it's probably evident [08:44] working copy = actual files I'm working on, checked out from repo [08:44] tga: they live inside the ... repository, kinda like inside a zip file, to use a really loose analogy. You can extract them in the dir in the cental location, but don't have to. [08:44] repository = bag of revision data [08:45] branch = pointer to one revision (and thus all that revision's ancestors) [08:45] working copy, yeah [08:45] so in a ceentral shared branch dealy, you just have branches and a repository, no working copies [08:46] so does the repository contain the actual files or just changes? [08:46] the latter, sort of [08:46] so when I check out a file is recreated by going through all changes? [08:47] conceptually [08:47] in reality it'll probably have a nearby copy cached [08:47] I see now, so there is no need for a working copy on the repo [08:47] *handwave* [08:48] tga: exactly [08:48] alright, thanks, I'm slowly getting to understand what's going on [08:50] tga: if you have access to 2 machines? create a local repo. add some files, commit, repeat a few times to get some simple history; now 'bzr push' that repo to the 2nd PC via, eg, ssh. You should only have a .bzr in the remote directory. [08:50] on the 2nd machine; now bzr branch from that .bzr only directory, and behold, all the files re-appear :-) [08:51] So in your case; that 2nd machine would be the central repo that everyone else could branch from. Clear as mud? [08:51] why do I need to explicitly create a repo? from what I can see, bzr init on a directory gets me the same thing [08:52] you don't need to. [08:52] what do I get by doing it though? [08:52] ... control over who can commit to trunk [08:52] it is just a storage optimsation [08:52] you only need to store changes shared between related branches once [08:52] rather than for each one [08:53] spm: you sure you need a repository for that? [08:53] sooo technically I could bzr init on my working dir and copy the .bzr dir to the server? [08:53] bob2: no - I misunderstood the question - your answer was more correct [08:53] tga: yup [08:53] that's nice [08:54] tga: is very nice. we rsync dir's all over the place that way. Even to the prod servers. [08:54] (if you 'bzr init' in a repository, though, you can't - .bzr in the branch doesn't store the "revision data", it just points at the repository's store) [08:58] just to make sure I'm on the right track here, does this sound alright: bzr init, add, commit on /local/project/src dir, bzr init-repo on empty /server/project, then in /local/project/src, bzr push /server/project/trunk [09:03] tga: I just walked in on this conversation, but yes, it does. [09:04] thanks Peng_ [09:04] * tga is fixing a million "file name too long" errors [09:04] tga: (You'd probably want to create a local repo too in /local/project or whatever, if you hadn't already.) [09:04] why? [09:05] In case you want multiple branches. [09:05] oh, I see [09:05] so I don't duplicate code all over the place? [09:06] Without a shared repository (bzr init-repo), "bzr branch" will copy the entire repository, which just wastes space. [09:07] gotcha [10:36] hi, does anyone know when the bzr-1.10 installer for windows will be released? [10:49] jonnydee: Posts on the list have said that there are problems with the machine they're built on, so the answer is either "When the people responsible for the machine fix it", or "When someone else manages to go through the complicated build procedure". [10:49] (Or, "When anybody manages to figure out what's wrong in the first place, and fix it" [10:50] ) [11:36] Peng_: thangs for your info :) [12:05] moin [14:03] is there anyway to merge repos? i need all the history out of one repo to go into another repo [14:07] rocky: You can just branch the branches into the other repo [14:07] Do you mean "can I splice the history of two branches together" though? [14:07] no i think your first suggestion is what i need [14:08] i have bzr repo X, repo Y ... repo Y has a couple branch histories that i need in repo X, and i need to destroy repo Y [14:08] The converse is also true - you can "split" repos by making new ones and only branching branches with history you wish to keep into them [14:09] hm... how do i make eshell display the status bar that comes up on a long bzr checkout? :) [14:16] rocky: export BZR_PROGRESS_BAR=tty === maxb is now known as Guest97053 [14:25] rocky: Repositories are just big bags of revisions. They don't have to be related at all. === Guest97053 is now known as maxb [14:44] how do i tell bzr to stop watching a file that is already being watched [14:44] bzr ignore tells me that it is already being watched and will not be ignored [14:45] bzr ignore foo [14:45] bzr rm foo --keep [14:45] aah [14:45] --keep [14:45] cool thanks awilkins [14:45] You're welcome [14:45] i did a bzr rm and the file went o00f [14:45] s/o00f/p00f/ [14:46] you could make an alias - "forget = rm --keep" [14:46] that would work too [14:46] sweet [14:49] i should have looked at http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.pdf more closely [14:49] what i was looking for is right there in the middle :) [15:16] how can I automatically update a working copy of a branch on the server every time there is a commit? [15:17] tga: If you're pushing over bzr+ssh or sftp, you can use the bzr-push-and-update plugin. [15:23] ah, plugin, right [15:31] with bzr-svn 0.5 rc1: "bzr: ERROR: Could not determine revno for {svn-v4::33292} because its ancestry shows a ghost at {}". Any idea? [15:32] (when committing, btw) [15:34] the last two days with bzr-svn have been hell, really. I don't know what I did, but it stopped working perfectly as it used to do and it's making me go nuts :( [16:05] marcoil: did that timeframe include a move from 0.4 to 0.5 [16:05] ? [16:05] yep, it was the only way of getting it to at least work. For one commit :) Then I got that strange message. Sorry, I didn't want to rant... [16:06] why did 0.4 not work? [16:06] I added a branch to the svn-branching-scheme and I stated getting lots of error messages [16:07] and couldn't commit [16:12] hi, is Marius here? [16:18] marcoil: aha [16:23] I guess no. [16:25] marcoil: branching-schemes are a painful area of bzr-svn, so I'm unfortunately not surprised changing it gave some problems [16:25] marcoil: as to 0.5, I haven't tried it yet. It's supposed to get rid of branching schemes, but apparently it's not yet ideal either. [16:26] anything that gets rid of the branching schemes is great... Our repo has some really strange scheme [17:01] so how do I get bzr visualize (bzr-gtk) in intrepid without getting that bzr-notify crack? [17:09] lamont: I'm pretty sure the notify stuff is only a "recommends" not a requires [17:09] I would uninstall bzr-dbus if it lets you easily [17:09] bzr-notify is delivered in the bzr-gtk package [17:09] which I just removed from my machine as the simplest way to get rid of the totally annoying popup [17:10] of course, if there's a way to have it _NOT_START_, that'd let me have bzr visulaize [17:10] I don't really know enough about it to help [17:10] I generally run from source [17:10] because every commit really wants to interrupt my thought process with a popup telling me that, oh wait: I just committed [17:11] mkdir -p ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr co lp:bzr-gtk gtk [17:11] ah [17:11] yeah - I'm a package kind of guy [17:12]