[00:01] <ubotu> New bug: #208566 in bzr-svn "missed commit never get pushed between branches and trunk" [Undecided,New] https://launchpad.net/bugs/208566
[00:12] <james_w> beuno: nice photos. The make you look like you spent a week whiteboard shopping
[00:37] <bronson> Hi.  I have a single repo tracking an upstream bzr project.
[00:38] <bronson> I'd like to have 3 different local configurations, and be able to merge between them during development.
[00:38] <bronson> In git, I'd just have 3 branches.
[00:38] <bronson> I don't quite see how to accomplish the same thing in bzr?
[00:39] <bronson> (the changes are very small so I'd like to keep everything in the same repo)
[00:39] <james_w> bronson: you are confusing the terms repo and branch, from the bzr point of view anyway
[00:40] <james_w> you currently have a single branch tracking an upstream project
[00:40] <bronson> OK so far.
[00:40] <james_w> so in bzr you would make three branches and merge between them
[00:40] <james_w> just like git
[00:40] <james_w> however bzr identifies branches with a location on the filesystem, so unfortunately you need three copies of the upstream source
[00:41] <bronson> ack.
[00:41] <bronson> not good.
[00:41] <james_w> however if you use what's called a "shared repository" then you can share the history between them, which makes it less painful
[00:41] <bronson> OK, I'll look into shared repository.
[00:41] <bronson> thanks!
[00:41] <fullermd> And you could always blow away the WT's of the branches you aren't using at a given time.
[00:42]  * fullermd does that with some regularity.
[00:42] <james_w> there are two ways that you can use a single directory to do what you want, they're not that straightforward, but they will work.
[00:42] <james_w> the first is to use the "loom" plugin, that provide functionality similar to git-style branches. However looms are ordered, so it's a bit different.
[00:43] <james_w> the other, and probably better way for you, is to use a "checkout" and the switch command.
[00:43] <TFKyle> james_w: I assume it'd be pretty hard not to have 3 copies of the source (hmm, a custom FUSE fs might be able to do that actually, then only create new copies on-demand when you save first)
[00:43] <bronson> Ah, I saw the switch command in the faq.
[00:43] <TFKyle> (working copy wise that is)
[00:44] <james_w> there you create a treeless shared repository, with the tree branches.
[00:44] <james_w> this still takes up three directories, but the cost is minimal, about a dozen files in total, and virtually zero size
[00:44] <james_w> you then use "bzr checkout" of one to create a working area.
[00:44] <TFKyle> ah, guess loom/shelve would sort of work, as long as you don't need them both to exist on the filesystem concurrently
[00:45] <james_w> you can then use the switch command to change which branch your working area is pointed at, which makes it act like "git checkout" here.
[00:45] <james_w> I can walk you through the steps if you like.
[00:45] <bronson> Shared repo doesn't seem to do what I want...  It still has individual WTs.
[00:45] <bronson> That second suggestion sounds more like it.
[00:46] <bronson> switch command.
[00:46] <james_w> TFKyle: I guess shelve would work as well, but it's not what I'd do.
[00:46] <bronson> I can picture how it would work.
[00:46] <james_w> bronson: yeah, I think it's the winner for you.
[00:46] <james_w> bzr init-repo --no-trees project
[00:46] <orutherfurd> hi, can anyone give me pointers re figuring out files involved in a revision (added, modified, removed, renamed)?  I'm trying to write an importer from bzr to hg and while parsing bzr output is easier, I figure using bzrlib would be better.
[00:46] <james_w> cd project
[00:46] <bronson> OK, thanks james_w
[00:46] <james_w> bzr branch whatever
[00:47] <james_w> then bzr checkout branch working-area
[00:47] <james_w> cd working-area
[00:47] <james_w> and play with switch, passing it the path of the branch that you want to work on
[00:47] <james_w> also see cbranch from bzrtools if you are going to be creating a lot of new branches with this style.
[00:48] <james_w> hopefully we'll have some improvements in this area soon to make your workflow easier.
[00:48] <james_w> orutherfurd: get the revision_id
[00:48] <james_w> then tree = repository.revision_tree(revision_id)
[00:49] <james_w> changes = tree.changes_from(tree.basis_tree())
[00:49] <james_w> changes is then a tree delta
[00:49] <james_w> it has .added .removed .renamed etc.
[00:49] <james_w> you can also pass the parent trees directly if you need to know what changed compared to each parent.
[00:50] <orutherfurd> james_w: that's great, though, does basis_tree() the 'tip'?
[00:51] <orutherfurd> oh, right -- didn't see your last message
[00:51] <james_w> orutherfurd: does this mean you are converting away from bzr, or are you a hg user that wants to use that to work on a bzr project?
[00:53] <orutherfurd> james_w: well, I am a bzr user, but at work we'll be moving to hg -- and want to convert projects we have in bzr
[00:53] <james_w> ah, ok.
[00:53] <james_w> can I ask why you are moving?
[00:57] <orutherfurd> sure, there are a few reasons: people find the docs better (the hg book), the convert extension worked really well (we're also converting some cvs repositories), plus other extensions people like (mq, springs to mind), the bundled web viewer which can be run as a cgi (vs loggerhead which has lots of deps)
[00:57] <orutherfurd> (not to hit you with a pile of reasons)
[00:58] <orutherfurd> the main reason for starting w/bzr was not needing to install software on a central server, but with the ssh directory permission problems, that didn't end up working
[00:59] <orutherfurd> but from a maintenance point of view, having to install 1 piece of software, vs bzr + plugins, etc... is easier -- we're running an ancient version of rhel
[00:59] <james_w> cool, thanks
[01:00] <james_w> most of those are known I think.
[01:00] <james_w> there is bzr-webserve which is a port of the hg one, so it runs the same way
[01:01] <orutherfurd> oh, right -- I'd forgotten about that
[01:02] <james_w> I can argue with the rest of your reasons as well if you would like :-)
[01:02] <orutherfurd> if you' like :-P
[01:05] <orutherfurd> have been using bzr since 2005 though, so not new to it, but for our setup, I think hg is a better fit; I do use bzr for personal stuff, so as not to come off as totally down on it ;-)
[01:09] <james_w> longer than me then, so I'm sure you know it all
[01:12] <orutherfurd> certainly didn't mean to suggest that -- otherwise I wouldn't be hear asking for help!
[01:12] <orutherfurd> hear -> here
[01:13] <orutherfurd> just figured I should disclose I've been hanging aorund for a while (reading the lists and as an end-user) for a while before you started in on your convincing ;-)
[01:14] <james_w> well, ok
[01:14] <james_w> the hg book is a great asset for them. The bzr docs have improved a lot recently thanks to Ian, but they are still lagging.
[01:15] <james_w> I'm not familiar with the convert extension, but hopefully bzr-fastimport will be stable soon, and that should be really useful
[01:16] <orutherfurd> the bzr docs do seem much improved lately
[01:16] <james_w> bzr-loom is intended to do a similar thing to mq, and it has some features that I don't think mq has
[01:16] <james_w> it's not there yet though
[01:17] <james_w> the installation point is tricky, I think you are right.
[01:17] <orutherfurd> the convert extension is pretty neat -- you provide some classes to interact as source or sink for another vcs and then you can, well, convert
[01:17] <james_w> However bzr doesn't actually require installation, as long as you have python >= 2.4 and paramiko etc.
[01:18] <orutherfurd> it already has support for cvs, svn, git, and darcs, I think
[01:18] <awmcclain> Is there a way to specify a different status bar type via the command line?
[01:18] <james_w> and plugins can just be dropped in bzrlib/plugins
[01:18] <james_w> though keeping them up to date can be a pain, hopefully beuno's work will make that really easy soon
[01:18] <james_w> awmcclain: I don't think so.
[01:19] <awmcclain> okee doke.
[01:19] <james_w> I think there is an environment variable
[01:19] <orutherfurd> james_w: initially, the big draw was not having to install bzr on the server (which is the primary reason I use it for personal projects)
[01:19] <james_w> that's a pretty neat feature.
[01:27] <fullermd> Funnily enough, I've always considered that one of the least important features  :)
[01:31] <awmcclain> Ok, I'm in a funky state. I thought I was working on a checkout, but it's actually a branch. I've made one checkin. I can't ci after I bind because my tree is "out of date". I'm pretty sure if I merge, I'll lose my updates. What should I do?
[01:31] <fullermd> You need to 'update' after bind.
[01:32] <awmcclain> Won't that remove the file I just added in my local ci?
[01:32] <fullermd> No, it turns what you have locally that isn't upstream into a pending merge.
[01:41] <awmcclain> hrm. ok. conflicts. "conflicts:
[01:41] <awmcclain>   Conflict: can't delete load_tests because it is not empty.  Not deleting.
[01:41] <awmcclain>   Conflict adding file load_tests.  Moved existing file to load_tests.moved."
[01:42] <awmcclain> Ah, I see. Looks like I've deleted the directory and then readded. Hrm. How do I resolve the conflilct without removing my changes?
[01:43] <james_w> put the directory that you want there, and then run resolve load_tests
[02:26] <ubotu> New bug: #208608 in bzr-gtk "bzr-icon-64.png not included in package" [Undecided,New] https://launchpad.net/bugs/208608
[13:00] <MrLieven> hi
[13:00] <MrLieven> is there a way to combine two bzr branches into one
[13:01] <i386_> perhaps your looking at merging ?
[13:01] <i386_> check the docs
[13:01] <MrLieven> ie. I have one bazaar branch, and want to import a different bazaar branch into a subfolder of that branch
[13:01] <Kinnison> aah yes
[13:01] <Kinnison> yes there is
[13:01] <MrLieven> how?:)
[13:01] <Kinnison> give me a sec
[13:01]  * Kinnison is working it out again
[13:02] <james_w> MrLieven: you can use "join"
[13:02] <MrLieven> ok, i'll look it up
[13:02] <james_w> however it is pretty experimental at the moment
[13:02] <james_w> and will probably break in interesting ways
[13:03] <MrLieven> hmm.. well, I can give it a try:)
[13:03] <Kinnison> The way I was taught was:
[13:03] <james_w> There is also a "merge-into" plugin that can do this, but if you want to continue merging from the other branch it does some interesting things.
[13:03] <james_w> Is this a one time thing?
[13:03] <Kinnison> in the branch you've adding *IN*, commit a change moving everything into the subdir of the name you want
[13:03] <MrLieven> james_w, probably only once, yes
[13:04] <Kinnison> then in the branch you're merging *TO*, do: bzr merge -r 0..-1 /branch/you/bring/in
[13:04] <Kinnison> but that is a one-time-only operation
[13:04] <james_w> that would work too.
[13:05] <Kinnison> That's how Aranha (one of my programs) has a branch with three ultimate ancestors :-)
[13:07] <AnMaster> is there something like git bisect for bzr?
[13:07] <dato> there is a bzr-bisect plugin
[13:07]  * AnMaster googles
[13:07] <MrLieven> I guess I will go for kinnison's solution. Sounds the safest
[13:08] <MrLieven> thx
[13:08] <AnMaster> how do you install plugins? can you do it in your home dir?
[13:08] <AnMaster> I don't want to mess up /usr/lib really
[13:08] <dato> AnMaster: drop it in ~/.bazaar/plugins/bisect
[13:09] <AnMaster> ok, I don't know python, don't you need a setup.py thing or something (why can't everyone just use a single build system...(
[13:09] <AnMaster> s/($/)/
[13:09] <james_w> AnMaster: no, just place it there.
[13:10] <AnMaster> hm
[13:10] <AnMaster> Unable to load 'bzr-bisect' in '/home/arvid/.bazaar/plugins' as a plugin because file path isn't a valid module name; try renaming it to 'bzr_bisect'.
[13:10] <AnMaster> hm
[13:11] <james_w> AnMaster: as dato said use ~/.bazaar/plugins/bisect
[13:11] <AnMaster> ah seems it didn't like the result of a plain  bzr branch lp:bzr-bisect
[13:11] <james_w> yeah, that's unfortunate
[13:12]  * dato wonders if bzr-bisect, the directory, could not be imported as bzr_bisect
[13:12] <dato> but, alas, I don't know much about python's import mechanism
[13:13] <AnMaster> I'm no python programmer
[13:13]  * AnMaster codes in C
[13:14] <james_w> dato: I think it used to work, but it was changed so that one plugin could use bits from another
[13:15] <james_w> I think that may still work with your scheme, but it makes it harder to know what the other plugin will be named for the import statement
[13:15] <dato> yes; but that relies on for example plugin bzr-foo being installed as directory "foo" and not "bzr_foo"?
[13:16] <dato> what I meant, it would be nice if the directory could be named $whatever, and then for its code to appear under bzrlib.plugins.<name_provided_by_the_code_inside_the_plugin>
[13:16] <asabil> I agree with dato on this
[13:16] <asabil> also it would be cool to have a plugin-manager plugin
[13:18] <dato> james_w: btw, two things bzr has that git doesn't: (1) patience diff; (2) pulling into a dirty tree where the pulled revisions touch dirty files (and, relatedly, merge --force)
[13:18] <TFKyle> dato: hmm, I'd expect it to be possible with sys.modules hacking, might be a bit ugly doing it though (havn't looked at bzr's plugin code though)
[13:19] <TFKyle> hmm, actually it might be slightly harder than just changing sys.modules, probably need to change the bzrlib.plugins namespace as well
[13:19] <james_w> dato: cool thanks. Is patience diff that much better?
[13:19] <dato> it seems git will always refuse merge files with uncommitted changes, no matter how hard you try to convince it to do so (as far as I've investigated, that is)
[13:20] <james_w> dato: yeah, I think Robert's proposal for plugin metadata may allow that
[13:20] <james_w> asabil: beuno_ is working on one
[13:21] <dato> james_w: well, I guess I've only noticed the cases where it's indeed better (in my case, mostly rewriting a file). but other git users have told me that, indeed, git is very willing to consider empty lines as "common" lines, thus making big changes appear interspersed with the old, deleted code
[13:22] <dato> james_w: (http://chistera.yi.org/~adeodato/tmp/2008-03-28/diff/ fwiw)
[13:24] <james_w> wow, thanks
[13:24] <AnMaster> dato, not very useful that bisect, it gives a traceback
[13:24] <AnMaster> bzr: ERROR: exceptions.RuntimeError: attempting to add revid anmaster@envbot.org-20080324152901-taj150bcztmhtf8q twice
[13:25] <james_w> ouch
[13:25] <dato> aha. well, I'm afraid I can't be of much help, I've never used, only knew that it exists.
[13:27] <james_w> are you using https://code.launchpad.net/~jeff-licquia/bzr-bisect/bzr-bisect ?
[13:27] <james_w> ah, you did lp:bzr-bisect didn't you? so you will
[13:28] <james_w> AnMaster: can you rub with -Derror and pastebin the traceback?
[13:28] <AnMaster> rub?
[13:28] <asabil> run
[13:28] <AnMaster> ok
[13:28] <asabil> :)
[13:29] <AnMaster> like bzr -Derror bisect ...  or?
[13:29] <AnMaster> also I think I need to redo the bisect from start as it is probably messed up now
[13:30] <AnMaster> anyway I did run with -Derror, no change in output
[13:30] <asabil> paste the output in a pastebin
[13:30] <AnMaster> http://rafb.net/p/dBp98k79.html
[13:32] <AnMaster> asabil, yes I did just then
[13:32]  * AnMaster waits
[13:33] <asabil> poke james_w
[13:33] <AnMaster> james_w, there?
[13:33] <AnMaster> james_w, http://rafb.net/p/dBp98k79.html
[13:33] <james_w> hehe, rub with -Derror
[13:33] <AnMaster> james_w, I did that yes?
[13:33] <AnMaster> $ bzr -Derror bisect yes
[13:33] <AnMaster> looks like a -Derror to me
[13:33] <james_w> I was just laughing at my typo
[13:34] <AnMaster> ah
[13:34] <james_w> ok, talk me through all the steps you did
[13:34] <AnMaster> james_w, was looking for a bug, so I started with bzr bisect start on my source (can be found at http://rage.kuonet.org/~anmaster/bzr/cfunge)
[13:35] <AnMaster> and did bzr good first to tell it the last had the think I wanted to check
[13:35] <AnMaster> err bzr bisect good*
[13:35] <AnMaster> do you want the order of good and bad bisects?
[13:35] <AnMaster> james_w, if it matters I got this branch in a shared repo
[13:36] <AnMaster> I can pastebin entire output if you want
[13:36] <james_w> yeah, pastebin the session please
[13:37] <james_w> I've never used it, and so I'm not sure whether you're doing something wrong or it's really buggy
[13:37] <AnMaster> a sec just need to check for any sensitive info
[13:37] <james_w> ok
[13:38] <AnMaster> james_w, http://rafb.net/p/0wxvte63.html
[13:39] <AnMaster> now I am happy I did a branch for this and didn't just run it in trunk
[13:39] <AnMaster> james_w, what I'm doing is looking for when the test suite started outputting odd non-printable chars in case you wonder
[13:41] <AnMaster> james_w, any idea? :(
[13:41] <AnMaster> branch format is pack-0.92
[13:41] <AnMaster> if it matters
[13:42] <james_w> so you land on "BUGFIX: Fixing a series of improbable bugs that together made mycology pass on y when it shouldn't have..."
[13:42] <james_w> twice, so it might well be a bug in the plugin
[13:42] <AnMaster> james_w, not sure where I should have landed exactly, that is what I'm trying to find out using bisect :)
[13:43] <AnMaster> james_w, but that one sounds quite possible like the one that could have caused it, the changes were in the affected area so
[13:44] <AnMaster> the old way was broken too, but looks like new is as well heh
[14:04] <james_w> AnMaster: I can't see anywhere in the code that actually reports that you have found the critical revision, which is odd
[14:04] <AnMaster> indeed
[14:05] <james_w> can you tell me if the revision mentioned above is a merge revision?
[14:05] <AnMaster> james_w, no I have not worked with anyone else on this project, or rather they sent classical patches from diff -Naur
[14:05] <AnMaster> and I only used one branch
[14:06] <AnMaster> up until now where I branched to do a bisect
[14:06] <james_w> ok, it's proabably just that problem then
[14:06] <AnMaster> I do not wish to mess up my trunk
[14:06] <james_w> a "bzr revert" will undo anything that bisect does
[14:06] <AnMaster> yes, except it places some files into .bzr
[14:07] <james_w> a bzr bisect reset should remove those I think
[14:07] <james_w> however the plugin looks dangerous as it doesn't check for uncommitted changes in the tree first.
[14:07] <AnMaster> james_w, anyway I got stuff in trunk that is not versioned (stuff like test files and so on) and jumping between revisions where the file doesn't exist could cause problems
[14:08] <AnMaster> I mean directory where file is doesn't exist
[14:09]  * AnMaster removes the bisect plugin from his system
[14:36] <ChristopheT> Is there a reason when pushing through FTP that the .bzr/checkout/ is not trasferred?
[14:37] <ChristopheT> This may be a problem when FTP pushing but others trying to branch via HTTP (some services only allow FTP upload).
[14:51] <james_w> ChristopheT: yes, that's the expected behaviour
[14:51] <james_w> you only push the branch, not the working tree
[14:52] <james_w> others will be able to branch from that fine
[14:52] <james_w> however if you want the working tree files to be available on disk on the server you are a bit stuck
[14:59] <ChristopheT> My problem is exactly the following https://bugs.launchpad.net/bzr/+bug/129307 (the dummy server configuration -- of the service provider -- redirects the URL instead of issuing a 404)
[14:59] <ubotu> Launchpad bug 129307 in bzr "Unable to branch from http server after ftp push" [Undecided,New]
[14:59] <ChristopheT> How do I go about it?
[15:08] <james_w> ChristopheT: is there anyway you can override this behaviour?
[15:08] <james_w> ChristopheT: for instance a .htaccess?
[15:08] <james_w> it would perhaps be possible to make bzr handle this better, I don't know
[15:32] <muszek> hi
[15:33] <muszek> my bzr suddenly started to freeze while commiting to a repo that's binded to an external server
[15:34] <muszek> I have bzr 1.2.0.candidate.1 (on Hardy) and 1.1.0.candidate.1 (on production server running Debian Sarge)
[15:38] <muszek> here's the output: http://pastebin.us/?show=m2e622911
[15:40] <bob2> press cancel?
[15:40] <bob2> ctrl-c?
[15:41] <muszek> bob2: that's what I did...
[15:41] <muszek> bob2: then I do bzr break-lock and repeat commit - same thing happens
[15:41] <bob2> is it still doing anything or really hung?
[15:41] <bob2> e.g. does tcpdump show traffic
[15:41] <muszek> I'll try to run it
[15:43] <muszek> err... I don't think I'll be able to learn using tcpdump in the next few minutes :)
[15:44] <bob2> 'sudo tcpdump host poradnik.org and port 22'
[15:44] <muszek> the commit is rather small (I'd say less than 1kB of changes in 4 files)
[15:44] <bob2> does ssh'ing normally work fine and as fast as expected?
[15:45] <muszek> yes
[15:46] <muszek> hmmmm... not as fast as usually.  I've just initiated a download over ssh - 15kB/s
[15:48] <muszek> upload goes at 8kB/s... could that be a reason?
[15:48] <bob2> still should only take 1/8th of a second, right ;)
[15:49] <muszek> yep
[15:49] <bob2> ~/.bzr.log might show you where it's stuck
[15:49] <muszek> well, it was never extremely fast, but commits usually took 10-20 seconds
[15:49] <muszek> ok
[15:52] <muszek> http://86.144.127.50/temp/.bzr.log
[15:55] <bob2> it says it was packing the remote repository...does 'ssh -t muszek@poradnik.org bzr pack -v /home/tomekg/ifront/app/' return quickly or sit for a while?
[15:57] <muszek> bob2: it executes in 14 seconds
[16:01] <bob2> does commit work now?
[16:02] <muszek> doing it right now...
[16:03] <muszek> btw... I had an old commit hanging in there for some time... it finished with an error 'bzr: ERROR: No such file: '/home/tomekg/ifront/app/.bzr/repository/packs/631446bfbfbaf528bfa3518f048fd76d.pack'' (propably after that bzr pack you gave me)
[16:03] <muszek> it finished successfully
[16:03] <muszek> thank you very much
[16:03] <bob2> yay
[16:03] <bob2> no worries
[16:04] <bob2> dunno why that helped, maybe the autopack code executes on the client instead of the server
[16:04] <muszek> I'll keep that command around in case it happens again
[16:06] <muszek> well thanks again and have a nice weekend :)
[16:06] <bob2> you too :)
[16:06] <muszek> bye
[17:16] <ubotu> New bug: #208869 in bzr "info command failed at committers" [Undecided,New] https://launchpad.net/bugs/208869
[17:42] <cdleary> I just did a bzr split [subdir] and now performing bzr status in the subdir returns "No working tree exists for [subdir]/.bzr/checkout/"
[17:42] <LasseP_> hi
[17:43] <LasseP_> does bazaar work with ant?
[17:44] <bob2> in the sense that sccs works with make?
[17:44] <luks> how does a version control system need to work with a build system?
[17:44] <bob2> (as in magically checking thins out)
[17:45] <LasseP_> i used to work with CVS and now i'm thinking about switching to bzr. i used ant as a build system so i can commit my changes, update specific working copies in a specific testing environment and to create automatic releases with just one keystroke ;)
[17:46] <bob2> what does cvs integration does ant have?
[17:46] <bob2> (I've never heard of it nor of simialr integration wih bzr)
[17:48] <LasseP_> ant has some tasks available to work with CVS. i was wondering if there is something like that for bzr.. otherwise i will just execute the command lines from ant
[17:49] <james_w> I've not heard of it
[17:49] <james_w> you could probably write the stuff for ant to do it and then share it with everyone
[17:50] <LasseP_> i will write the ant file, so it will execute the bzr commands. :)
[22:49] <gdoubleu> I've got a bunch of small fixes to the core_concepts.txt docs.  Would it be ok to submit that as one patch or should I break it up?
[22:51] <gdoubleu> Also I tried looking for some sort of style document for the documentation, but didn't find anything.  Are there any defined standards for the documentation?
[22:51] <gdoubleu> For example, I noticed that bulleted lists had inconsistent indention.
[22:52] <gdoubleu> Some, the bullet started in the first column of the line, and others it was spaced over one or two spaces.