#bzr 2007-11-01 <hendrixski> beuno, I've been trying the send command, and I get "nothing to do" <hendrixski> even though there are changes :-/ * hendrixski reads man bzr and finds "push" <beuno> hendrixski, exactly <beuno> it's push not send <beuno> send is for sending bundles (patches) <hendrixski> beuno, the manual didn't do a good job of explaining that <hendrixski> from looking at it I thought that push was just for creating... not for updating * beuno goes look at the manual <beuno> hendrixski, you are right <beuno> I'll send an email to the list and see if we can clear that up a bit, thanks <hendrixski> :-) <hendrixski> Thanks for looking into it and following up <beuno> hendrixski, :D * hendrixski continues to explore the awesome world of bzr * hendrixski while throwing candy at little kids who show up at his door <beuno> hendrixski, you can follow up on the issue in the following thread: https://lists.ubuntu.com/archives/bazaar/2007q4/033441.html <hendrixski> cool <beuno> (and add any input that might help) <beuno> time to head home <beuno> have fun learning the ropes hendrixski, and welcome! <hendrixski> :-) It feels like a very worthwhile project... I tried it out with a friend a few days ago but I had .15 he had .91... so things didn't work... we're gonna try it again with the centralized model in a few days <beuno> Verterok! <Verterok> beuno: Hi <beuno> Verterok, all good? <Verterok> all good, you? <beuno> pretty good too, just started working on the html-thingie a few minutes ago <Verterok> nice! :D <beuno> and, I have a small glitch in the XML to look into, because today, one of the repos generated invalid HTML <beuno> er, XML <beuno> closed </log> twice <Verterok> ups <beuno> but I haven't looked into it deep enough to file a bug/patch it <beuno> oh, quick question, are you going to Lujan on saturday? <Verterok> well this is enough to make me review the tests <Verterok> if all go as planed, I'll <Verterok> do you? <beuno> Verterok, all I know up to know is that it generated from a asking for a single revision, not the whole log <beuno> Verterok, I'm still undecided if I'm going or not, haven't got enough reasons to go yet :p I was thinking I migh catch you there for some brainstorming/sprint, but thinking it through, I'm not sure if those events are the best moment for such things <Verterok> beuno: If I go, is mainly to participate as a member of PyAr, but not sure if I'll go to the Â¿presentations? (I don't known how to translate "charlas" :P) <beuno> Verterok, right, I don't usually go either. I'll keep thinking about it <beuno> looking into the bug now <Verterok> me too <Peaker> Hey i created a repo with a default of no working trees but if I "bzr branch" in there it does create a working tree, can I avoid that? <ignas> hi <ree> hi all! Are there any usage examples for nested tree support (join and split) ? <fullermd> I don't think there are... <ree> fullermd, does it work actually on a usable level? or yet risky? * ree cannot figure out how to use it <fullermd> Well, it's not really intended to be used :) <ree> haha <fullermd> The backend pieces of it are pretty much in place, but most of the frontend doesn't exist. <ree> I would like to include a separate branch as a subdir of another branch. <ree> I cannot make any sensible use of join / split, don't understand what's going on. <mathrick> jelmer: any luck with my bugs? <jelmer> mathrick: not yet, sorry <mathrick> ok <mathrick> just checking <lifeless> moin <fullermd> It's downright disturbing hearing you say that when my clock says A.M. <corporate_cookie> is there a way to edit commit messages, after committing ? <james_w> corporate_cookie: no, you have to uncommit and then commit again. <corporate_cookie> thanks james_w <corporate_cookie> alas : ) <lifeless> hi <corporate_cookie> lifeless: hello : ) <lifeless> hi corporate_cookie ; I have to go sorry <corporate_cookie> its cool : ) i was just being friendly <fullermd> Is it a coincidence that check shows me a number of "inconsistent parents" and "file versions not referenced by their inventory" that are exactly the same? <ubotu> New bug: #159351 in bzr "reconcile's progress bar is broken" [Undecided,New] https://launchpad.net/bugs/159351 <ubotu> New bug: #159370 in bzr-eclipse "xml-output not detected" [Undecided,New] https://launchpad.net/bugs/159370 <Peaker> Say, is there any way to get a nice GUI for branch management (create a branch, remove a branch, etc) on some standardized branch URL scheme? <Peaker> some folks really want a GUI to do everything <ubotu> New bug: #159377 in bzr "commit-builder-based InterRepository implementation" [Wishlist,New] https://launchpad.net/bugs/159377 <Peaker> can I set the parent of a branch? <jam-laptop> Peaker: "bzr pull --remember", "bzr merge --remember", etc <Peaker> jam-laptop: that sets pull branch, not parent, doesn't it? <jam-laptop> there is only 1 other branch <jam-laptop> called 'parent' <jam-laptop> well, there is a 'push' branch <Peaker> what does the "submit:" revisionspec look for? <Peaker> If I am going to merge into a branch, I want to review what the merge is gonna do <Peaker> Is it best to just start the merge and review a diff, or to diff against ancestor:other_branch or submit: ? I asked about parent because I thought it affected submit: <jam-laptop> bzr diff -rancestor:other/branch is usually agood approximation <jam-laptop> but it won't tell you about conflicts <jam-laptop> many people feel like 'bzr merge' is the only truly accurate way <Peaker> yeah I guess I'll do that <Peaker> how do I check if a branch is pull'able, without pulling it? <Peaker> I don't want to run merge if its pull'able <Peaker> I do want to get uncommited changes so I can diff them <Peaker> (for review purposes) <Peaker> what is the "recommended" reviewing strategy? <beuno> Peaker, bzr missing <beuno> will tell you what the difference between branches is <Peaker> oh, so if he's not missing anything from me there's no divergence so pull would work <beuno> what revisions one has that the other doesn't <beuno> Peaker, exactly <Peaker> cool thanks <beuno> :D <Peaker> so if I use merge it will basically be a pull-as-uncommitted? <Peaker> so for review I can always just use "merge" I guess.. <beuno> Peaker, pretty much, yes <beuno> merge does introduce conflicts and such <beuno> but I guess that concept would work <Peaker> I think "bzr merge" should probably warn you when you could have pulled, it creates an unnecessary revision <Peaker> I don't think conflicts can exist if its pullable <beuno> Peaker, no, only in merges <Peaker> yeah its probably important to know of conflicts when you review it before merger <jelmer> Peaker, there is 'bzr merge --pull' <jelmer> Peaker, which will pull if possible, merge otherwise <Peaker> jelmer: yeah I know but I thought of my case as a reviewer who uses bzr merge, but I guess that's silly, I already know that from "bzr missing" #bzr 2007-11-02 <abentley> Peaker: When you pull into a branch where you've been making changes, your changes stop being shown as the mainline. We don't think this is a good default. <Peaker> abentley: I am not sure what you mean, I was just wondering about the best method to review someone's changes <Peaker> to accept/reject them <abentley> I would generally merge them, then use diff or cdiff. <abentley> That is, if they haven't sent you a merge directive. <Peaker> merge directive? <abentley> Merge directives are recipes for merging someone's changes. They are created by the "send" command. <abentley> They typically include a bundle of revisions in case you don't have them. <fullermd> Unless you make them with bundle --no-bundle! :> <abentley> fullermd: I wish you wouldn't be so snarky. <fullermd> Eh. That was more whistling in the dark. I'm too tired this week to work up good snark :| <abentley> Well, I put in a lot of thought and effort, and it's not fun having you be constantly critical of my work. <fullermd> I wasn't aware that I was. I didn't intend to be. <fullermd> I always found it mildly amusing that you were so against that command combo; that's the sort of vague nonsense I always find fun in tools. <abentley> You go on and on about rollup formats. Now you mock the bundle --no-bundle thing. And there are others I don't remember right now. <Peaker> what is rspush good for? <Peaker> (in bzrtools) <abentley> Most of the time, not much. <abentley> There are a few users, so I'm actually updating it right now. <abentley> But you're generally better off with push. <abentley> Unless rsync is the only supported protocol. And even then, it doesn't work with shared repositories. <fullermd> It does push WT's though, right? I think that's the big thing people want from it... <fullermd> Or was that the other rsync-push plugin? <Peaker> why is send/bundle useful? Why not merge locally and push? <abentley> fullermd: You're right, it does do trees by default. <fullermd> Yeah, that's a plus. Sadly, it seems like there are a surprising number of people who come in here asking for tree-pushing, when they only have FTP access. It's like waking up in the middle ages. <abentley> push requires you to publish a branch, which is a higher barrier than just sending an email. Send works especially well with email, so it's great for mailing lists. <Peaker> abentley: so its basically a way to allow bzr over email? <Peaker> how does it generate the merge directive? Do you first merge, and then send instead of commit? <abentley> You run "bzr send --mail-to email@example upstream_branch". You don't need to merge in advance. <Peaker> it will work under the same predicate as push would, and then it generates the diff? if not, how does it resolve the merges required? <Peaker> also, is this how you ask pqm to merge things? <Peaker> is "bzr patch" smarter than patch? Looks at metadata for extra information? <abentley> Peaker: No, the upstream_branch is the branch that you want someone else to merge your changes into. <abentley> For me, this is typically http://bazaar-vcs.org/bzr/bzr.dev <abentley> But I use a local mirror, of course. <abentley> bzr patch is not smarter in the way you're thinking. <abentley> It's better because it auto-detects the branch root and applies the changes there, and because it can download a patch from a URL. <abentley> PQM does not use merge directives yet, but we plan to update it. <abentley> You apply a merge-directive with "bzr merge" or "bzr pull". The machine-readable portion of the merge directive is used for merging. The patch is mainly for human eyes. <Verterok> Hi all <coffeedude> lifeless: Thanks for the tarball. Grabbing it now. <bialix> hi! lifeless here? <bialix> it seems like PQM is not working <lifeless> a/away <lifeless> bleh <lifeless> moin <Peaker> abentley: thanks, I was already in bed by the time you replied there :) <ree> Hi! <ree> Is is possible to use a bazaar branch directly from easy_setup like in svn? (http://....#egg=...) ? <bitmonk> ree: you'd probably have to extend setuptools somehow.. <bitmonk> i was actually thinking of patching setuptools and some buildout recipes to try and use bzr to checkout svn repos with bzr-svn.. <ree> allright... there is setuptoolsbzr that allows easysetup to use bazaar branches in dependency_links <bitmonk> really? i'll have to check that out.. <ree> but that indeed does not help with buildout <ree> it's on launchpad <bitmonk> well, the buildout recipes i've seen are just calling svn command <bitmonk> so i say start there, just call bzr command, then when you have time, go back and try to use the python apis directly <ree> with buildout I've seen it done with Makefile, that uses bzr directly. but the ideal would be if setuptools could use a bzr source directly <bitmonk> svn isn't written in python, but it's not like there aren't python apis. nothing wrong with os.system() in a buildout recipe.. <bitmonk> yesh that would be ideal.. <bitmonk> ah you want it for eggs, duh <Peaker> os.system->subprocess.call :-) * bitmonk salutes <ree> bitmonk, if it worked for setuptools, it would natively work with buildout without need to support it fromwithin <ree> <bitmonk> yeah <bitmonk> i'm thinking like plone.recipe.bundlecheckout <bitmonk> or .distros maybe <bitmonk> which are sort of lazy, b/c they are doing Product checkouts <bitmonk> anyway, let me know how your journey with setuptools and bzr goes, esp if i can help test.. <bitmonk> maybe once i finish this server migration i'll take a look at setuptoolsbzr at least <keir> is anyone other than bzr using patience diff? <Peng> I wish they would. <fullermd> I think someone else was. <fullermd> cdv, maybe. <Peng> Oh, yeah, it probably does, since Bram Cohen invented them both. <Peng> Anyone know how to get 'python -m bzrlib.patiencediff' to run on a directory instead of just a file? <jam-laptop> Peng: adding a --recursive flag to patiencediff.py wouldn't be too hard, or you could just do it with shell tricks <Peng> Yeah, it would probably be pretty easy with some shell trick, but I haven't wanted to bother. <Peng> It would have to be modified to accept a file existing in one directory and not in the other, wouldn't it? <jam-laptop> well, you would have to write some loops that recurse through the directories <jam-laptop> and that is where you would look for one-side but not the other <jam-laptop> oh, if you mean in shell... yeah <jam-laptop> It would be tricky to get it right in shell, and have it detect present/missing on both sides <Peng> I didn't mean in the shell. <keir> we really need a page of 'compelling reasons to use bzr' instead of git/hg... patience diff should go on there! <Peng> Well, once patiencediff.py is changed to support directories, it could be used by hg's extdiff extension. That's the reason I'm interested in it. :P * Peng hides. <keir> peng, why hg instead of bzr? <Peng> keir: I personally use it over bzr because of speed. Bzr has recently caught up, but I don't want to go through the hassle of switching back. Also, I doubt bzr's network performance is up to hg's. <Peng> keir: Even if I didn't, there are projects I'm interested in that use hg, so it would be nice to have a non-sucky diff algorithm there. <Peng> (It takes like 2 minutes to pull a dozen new revisions of bzr.dev. Yikes. It'd probably take 3 seconds with hg. But that's with a dumb server.) <keir> Peng, no argument there. packs help that. <keir> Peng, the next pack refresh should have a smarter dumb protocol index too <keir> heh, yup, 41 seconds for 11 revs on bzr.dev <Peng> Smarter index access sounds good. How much does it have to transfer to find the new revisions? <dato> Peng: well, hg does not use a dumb transport. <Peng> dato: Yeah, that's what I meant. <Peng> dato: I didn't contruct the sentences well, but that's what I meant. hg has the benefit of a smart server. <Peng> s/benefit/advantage/ <lifeless> ree: setuptools can use bzr <mneisen> Hi, i use bzr and bzrtools on Ubuntu. My problem: bzr is always released well before bzrtools, so apt wants to upgrade bzr and remove bzrtools. Is there any way to solve this? <Peng> I haven't seen bzr get released before bzrtools. <Peng> Except for bzr 0.92rc1 being out for a like week before bzrtools 0.92.0, but 0.92rc1 is only a release candidiate. <Peng> Well, anyway, this isn't helpful. <mneisen> Peng: Well, apt-get tells me the following: http://paste.ubuntu-nl.org/43030/ <Peng> I guess Ubuntu upgrades bzr more quickly than bzrtools. <james_w> Peng: it is an exception this time hopefully. <james_w> the aim is to upload them together, but this time bzrtools was later than the rc, and other things have now got in the way. <james_w> (not ruling out exceptions being the norm up to this point). <james_w> mneisen: you should just wait. <mneisen> james_w: Will do. <james_w> great. <mneisen> james_w: Thanks for the info. <mneisen> james_w: Any guess when bzrtools will be out? <james_w> no problem. You can expect bzrtools to be updated on tuesday or wednesday hopefully. <mneisen> james_w: Alternatively: Is there a way to "block" updates in apt-get? <james_w> you can pin the package. <james_w> google for "apt pinning", I can't remember how to do it now. <mneisen> james_w: Thanks again. <james_w> alternatively you can use aptitude and put the package on hold. <AnMaster> Using saved location: bzr+ssh://djennings@example.org/~anmaster/envbot/module-help/ <AnMaster> No handlers could be found for logger "bzr" <AnMaster> bzr: ERROR: Could not acquire lock "(remote lock)" <AnMaster> sigh, what is going on, #launchpad ppl redirect me here <james_w> damn, I was going to point you there. <AnMaster> I don't have any problem with other servers <james_w> The "No handlers" thing is known and shouldn't cause this issue. <AnMaster> james_w, well, I can push with bzr+ssh just fine to other servers <AnMaster> and since I got redirected here.... <james_w> can you run using "bzr -Derror" please? <AnMaster> sure <james_w> and paste the result. <AnMaster> just that or the push bit too? <james_w> sorry? <AnMaster> bzr -Derror push or just bzr -Derror ? <james_w> 'bzr -Derror -Dhpss -Dlock push' please <AnMaster> ah ok <james_w> that should tell us what is happening <AnMaster> sure will pastebin <james_w> -Dwhatever turns on debugging output of a certain type. <AnMaster> it takes a while before it errors out <AnMaster> maybe 5-10 minutes <AnMaster> between the "No handlers could be found for logger "bzr"" <AnMaster> and the next line <james_w> that's fine. I'm going anywhere. <AnMaster> nor am I <AnMaster> ah <AnMaster> http://pastebin.ca/758938 <AnMaster> james_w, ^ <AnMaster> james_w, well? <AnMaster> guess I won't get help then <james_w> AnMaster: no need to be like that. <AnMaster> ok :) <AnMaster> problem is I got to leave soon :/ <james_w> sorry for ignoring you though. <james_w> It is raising LockContention, suggesting the lock is held. <james_w> Is anyone else going to be pushing? <james_w> no, it is your branch I see.# <james_w> so you can try 'bzr break-lock URL'. <james_w> also if you could post the end of '~/.bzr.log' that would allow me to confirm. <AnMaster> james_w, can't be anyone else as far as I know, it is a private branch but I will try <AnMaster> ouch that file is nearly 50 MB, that is nasty <AnMaster> james_w, break-lock reported 2 locks that I broke <AnMaster> but why is '~/.bzr.log' so huge <AnMaster> for another account it is over 250 MB <AnMaster> james_w, any way to turn off the ~/.bzr.log, I can't afford that space <AnMaster> james_w, but here is the end of it http://pastebin.ca/758981 <james_w> I'm not sure about turning it off, it is limited in size, but I am not sure about the size. <AnMaster> james_w, well for another account it was 250 MB <AnMaster> doesn't seem limited to me <fullermd> Yeah, it should auto-rotate long before it gets near that big. * AnMaster symlinks to /dev/null for now <fullermd> Weird. But yah, I've got it /dev/null linked in some places too. <james_w> AnMaster: you should be ok now then, I'll file some bugs for you. <jam-laptop> If he is pushing to launchpad, the "no loggers found" is actually an LP smart server bug <jam-laptop> it means the bracnh is already locked <ubotu> New bug: #159589 in bzr "LockContention has unhelpful text" [Undecided,New] https://launchpad.net/bugs/159589 <jam-laptop> unfortunately it isn't being sent to the user <james_w> ah, thanks jam-laptop <james_w> if size <= 4 << 20: <james_w> that seems rather large <jam-laptop> james_w: it rotates when it gets to 4MB <jam-laptop> but it only rotates at the beginning <jam-laptop> so if a single bzr action builds 250MB then it takes 2 rotations to go away <jam-laptop> (It goes to .old <jam-laptop> and then then new one overrwrites .old) <jam-laptop> Some actions log more than others. <jam-laptop> Off-hand i think "bzr add + bzr commit" might print out a line for each file <jam-laptop> If you run a converter... that is one of the bigger ones <jam-laptop> I'm not sure about bzr-svn <jam-laptop> lifeless: any chance you could check on pqm? It seems to be stopped <jelmer> jam-laptop: not sure about what? <jam-laptop> jelmer: how much stuff it dumps in ~/.bzr.log <jam-laptop> Especially on first push/pull <jelmer> jam-laptop: less than 10 lines during connect, etc <jam-laptop> Nothing about what files it finds, or revision, etc? <jelmer> jam-laptop: and one line for special cases when pulling changes <jelmer> jam-laptop: what branching scheme it's going to use mainly <jelmer> more verbose data can be enabled using -Dtransport and -Dcommit <jam-laptop> not a big deal. I just know that my converters would spew quite a bit into ~/.bzr.log, and it might be something to consider about bzr-svn <jelmer> -Dcommit for push/pull <jam-laptop> (well, *not* spitting out a lot) <jam-laptop> jelmer: is -D printing to the screen, or only to the log <jelmer> jam-laptop: only to the log <jelmer> to the screen would mess with the progress bar <lifeless> jam-laptop: sure <lifeless> jam-laptop: looks ok <jam-laptop> hmm.. both bialix and vila have had problems submitting <jam-laptop> I haven't tried anything myself <lifeless> ok, found the issue <lifeless> it's being rectified by is now. <lifeless> upstream ISP did naughty stuff to our network <jam-laptop> thanks <jam-laptop> ouch <jam-laptop> didn't like you using 7GB/s for so long? <jam-laptop> well, that is probably 7Gb/s <lifeless> plugged a cable where it shouldn't be; knock on effects lead to our mail feedb being disabled. <lifeless> jam-laptop: I'm offline again for some time LEAN traininig; please phone me or poolie on further issues. <jam-laptop> k <Peng> Woah, I have 65 messages from the mailing list in my inbox from after I signed up but before I set up procmail to filter it to another folder. Whee, something to read. <gotgenes> jelmer: thanks for fixing bug #159111 <ubotu> Launchpad bug 159111 in bzr-svn "bzr-svn can't push, commit to rebound SVN repository" [High,Fix released] https://launchpad.net/bugs/159111 <jam-laptop> Peng: I think you'll find you get more than enough to read from the bazaar mailing list <jam-laptop> I currently have 4.4k messages since 8/1 <jam-laptop> and 31,376 in my "archive" folder that goes back to 2005-05-08 <Peng> I currently have...167. <Peng> That's close to 31,376. <Peng> I didn't know the list was nearly this busy. <jam-laptop> usually less than 2,000 messages per month, 1k is probably average <fullermd> Well, this is the week to catch up, while half the list members are off being meetingly. <jam-laptop> fullermd: next week will be even more so <jam-laptop> As I go to the conference <jam-laptop> This week was UDS <jam-laptop> next week is AllHands <jam-laptop> Peng: and that doesn't count the "bazaar-commits" list, or the bug list <jam-laptop> I don't archive the bug list <fullermd> Yeah, so next week there will be about 6 mails. The whole week :p <jam-laptop> but sometimes it can be as active as bazaar@ <fullermd> Fortunately, I'm on enough other lists to sustain me through these hard times, when I run out of mail reading and have nothing to do but get work done. <jam-laptop> fullermd: yeah, I used to be on a whole bunch of lists, until it just became too much <jam-laptop> having BundleBuggy actually contributes to a bit of bloat for number of emails <jam-laptop> as it likes to send at least 1 extra email per submission <fullermd> Handy for traffic analysis, though. <fullermd> I've got an xbuffy watching my bzr mailbox, and when it suddenly jumps by 2 in a sample period (30 seconds), I know somebody posted a [merge]. <jam-laptop> well http://dir.gmane.org/gmane.comp.version-control.bazaar-ng.general is a nice graph of it <jam-laptop> peaking at close to 60 per day <jam-laptop> I have the feeling that the last dip was when I was on paternity leave <jam-laptop> I'm completely wrong, the dip I see was caused by our last conference <jam-laptop> around 5/26 <dato> siretart: okay, found time right now to upload. I hope you don't mind I use my name for the changelog :) <dato> siretart: btw, I'm retrospectively adding a tag for 0.91-2 :) <jelmer> dato: if you're going to upload 0.92rc1, please also upload bzr-rebase 0.2 and bzr-svn 0.4.4 <jelmer> if possible <dato> jelmer: sure <dato> I should have some minutes left for that right now <dato> jelmer: "Depends: bzr (>= 0.92~), bzr (<< 0.92~)" <-- s/92/93/ (the second one)? <jelmer> euhm, yep! <dato> all uploaded. <jelmer> dato: thanks very much <dato> jelmer: np <dato> jelmer: a small remark: it's considered good practice, when closing in debian/changelog upstream bugs closed in a new relesae, to say: <dato> * New upstream release: <dato> + no longer frobnicates your files when bar is set. (Closes: #1234) <dato> rather than only: <dato> * New upstream release (Closes: #1234) * dato leaves now. <jelmer> dato: Ok, I'll keep that in mind fior next time <jelmer> thanks #bzr 2007-11-03 <schierbeck> jelmer: ping <jaavaaguru> Hi, we're trialling using Bazaar in place of SVN in the place I work, primarily because it handles merging, and multiple personal branches much better. Some of my colleagues using Windows have had problems setting up bzr-gtk, and it looks like the problems are GTK related. <jaavaaguru> One of the guys mailed the list today, but it doesn't seem to have arrived... although that may be something he did wrong <jaavaaguru> I was wondering if it's worth pursuing a wxWidgets client, as we have other things using GTK, and there are various installations of GTK going around on Windows <jaavaaguru> (they're mainly looking for GUI diff/merge support) <Peng> I know you can set bzr to use external diff programs (difftools plugin), and there's probably something for merging too. <Peng> I doubt anyone would be mad if you made a wxWidgets client, though..... <jaavaaguru> Peng: really? cool. I haven't seen that yet <jaavaaguru> I'll have a look now <jaavaaguru> I may have a look into wxWidgets support in the long term, as I've made a wxWidgets client for one of our internal systems using Python. I'm loving Python and wx seems pretty simple to develop for <Peng> https://bugs.launchpad.net/bzr/+bug/41435 <ubotu> Launchpad bug 41435 in bzr "Framework for external diff/merge tools" [Medium,Confirmed] <Peng> difftools and extmerge, apparently. <jaavaaguru> cool, that will make some of my colleagues happy. I'm pretty happy with the standard bzr diff, and have had no merge problems that I can't solve myself, so I'm happier using bzr than svn so far <jaavaaguru> I'm in the UK, so it's getting kind of late just now. I intend having a look at Bazaar's API tomorrow. Any suggested URLs? <Peng> Bazaar has a cool diff algorithm. :) <Peng> patiencediff. <Peng> jaavaaguru: I dunno. http://bazaar-vcs.org/ <jaavaaguru> One thing we miss though: being able to ignore changes between CRLF and LF line endings <jaavaaguru> ;-) <Peng> jaavaaguru: http://doc.bazaar-vcs.org/latest/developers/HACKING.html , perhaps. <jaavaaguru> we do mixed Linux/Solaris/Mac/Windows stuff <Peng> jaavaaguru: Yeah, there are proposals about that, but none of it is finished. <jaavaaguru> Thanks Peng, sorry if I'm coming across as being lazy just now <jaavaaguru> If I come up with anything cool, I'll add it to Launchpad along with the CCNet plugin I wrote for Bazaar, and let you guys know <jaavaaguru> I've been watching the progress of 0.92 on the list... looks very good :-) <Peng> Yep. <jaavaaguru> I'm in a team of 6 people within our department and our team has been using bazaar for the last 4 weeks. We're developing a Mono/.Net app, and are using CruiseControl.NET. Seems like some of those choices may be making things difficult for ourselves, but it's all a good learning experience <jaavaaguru> From my experience so far, I'm all for anything that helps pick up support for bazaar among the Windows guys :-) <Peng> :) <keir> jaavaaguru, what choices have made it hard? bzr? <jaavaaguru> Initially, there was the "we know svn now, and we don't want to change" problem, but now I have a few colleagues using bzr, and they're amazed at how simple merging is compared to svn, and that we can have our own personal branches with no extra effort. That's a big thing for us, as we're developing a project from scratch. <keir> jaavaaguru, glad to hear that. but you mentioned 'some of those choices may be making things difficult for ourselves'; which choices were those? <jaavaaguru> Now that all of my team is using it (I'm not the project manager, but he's also using bzr now), the PM is looking for integration with things like KDiff3 <jaavaaguru> ah... <jaavaaguru> I was meaning the CruiseControl.NET and ASP.NET things <jaavaaguru> I suggested bzr about a month ago, and once I got some adoption amongst out team, we discovered that our chosen continuous integration tool (CCNet) didnt support it <jaavaaguru> I got round that by writing a plugin <keir> jaavaaguru, was that hard? <keir> jaavaaguru, that quote you had was nice; would you mind if you rephrased it as a quote on bzr / why it's good / etc? to go on bazaar-vcs.org/Testimonials (currently empty) <jaavaaguru> sure <jaavaaguru> I'll make an iCal note to do that in the morning and jump back on here to confirm <keir> jaavaaguru, great! i may not be here but feel free to post it yourself <jaavaaguru> thanks :) <jaavaaguru> As we're still in the early stages of adoption, do you think it might be better if I wait until next week where we have to finalize integrating out web app client with our business logic (BL is using bzr, and web app is using SVN at the moment) <jaavaaguru> we plan on deciding to go with one or the other <jaavaaguru> (not my choice, i'll be pushing for both parts staying with what they currently use) <jaavaaguru> I imagine we'll have a decision by Wednesday <keir> i believe in 'right tool for the job'... depends on your needs <jaavaaguru> regardless of what happens, all my personal projects at work will be using Bazaar, and I have a reasonable say in these things :-() <keir> neat! <jaavaaguru> I'm trying to stay away from the ASP.NET bit... I have worked on it, but it seems like doing MVC development in ASP.NET will be a battle against the system until MS release their MVC framework later this year <jaavaaguru> even then, it will be a beta, so I'm not holding out for it * jaavaaguru is getting to love TurboGears <jaavaaguru> Anyway, I have that calendar note to review my quote/testimonial, and will do after discussing our way forward on Monday <keir> jaavaaguru, great. i also like TG. django is nice too. <jaavaaguru> I've recently put together a TG app that renders our internal API documentation (mixture of Docbook XML and MS's XML documentaiton format) as web pages <jaavaaguru> as soon as I can get agreement that the company has nothing to do with the non-standard docbook-esque format we use, I'll put that on Launchpad too <jaavaaguru> I know it's probably not that much use to Ubuntu people, but for people working in a mixture of Windows/Linux, it's handy <jaavaaguru> thanks keir and Peng, I'm heading to bed. I'll have a good look at this stuff tomorrow <Peng> Good night. :) <jaavaaguru> good night <robcruseme> http://apps.facebook.com/prezident <jdub> jelmer: which version of bzr-svn should i be using with bzr 0.91? <jdub> jelmer: i've just updated to the latest in the 0.4 branch, which requires 0.92 <jdub> and rebase doesn't load <jdub> ah, it needs 0.92 too <jelmer> jdub: Yeah, they both need 0.92. I believe the bazaar-vcs.org has 0.92rc1 debs <lifeless> hi jelmer <jelmer> 'morning lifeless <lifeless> jerry seems to be having fun with packs <jelmer> ah, that's good to hear <jelmer> what about the workflow issues, multi-push/pull? <lifeless> don't know yet <lifeless> I did explain that we treated it like a cp -a/rsync of directories situation, and that you did not need a tree per branch <fredp> hello; I have a local bzr branch of a remote svn repository; I could merge upstream change for a long time but now as I get back to work on this project I get this error message: <fredp> $ bzr merge <fredp> Merging from remembered location svn+ssh://djennings@example.org/svn/jhbuild/trunk <fredp> bzr: ERROR: Repository KnitRepository('file:///home/fred/src/jhdebuild/.bzr/') is not compatible with repository SvnRepository('svn+ssh://djennings@example.org/svn/jhbuild') <fredp> does anybody know what is happening there, and how I could fix that ? <jam-laptop> fredp: newer versions of bzr-svn require you to use Knit3 repositories <jam-laptop> fredp: bzr upgrade --format=dirstate-with-subtree <jam-laptop> however, you may also need to create a new conversiosn <lifeless> there is a bzr svn-upgrade command <jam-laptop> since I'm guessing this is going from bzr-svn 0.3 to 0.4 <lifeless> that jelmer wrote; I believe that that is the recommended way to convert <lifeless> jelmer: we really need to make this easier; especially if its going to happen in the future. What can I do to make it easier? <lifeless> brb <jelmer> lifeless: Make svn-upgrade easier or the rich-root stuff? <lifeless> jelmer: make the user experience more pleasant when they dist-upgrade <lifeless> jelmer: and suddenly have a new version of bzr-svn <lifeless> and no warning <jelmer> If we do a pull/merge and the remote host diverges, we could check if the local branch contains revision generated with an older version of bzr-svn and warn <jelmer> another option would be to support multiple versions of the mappings in one instance of bzr-svn <lifeless> well right now it's hurting folok we really want to impress - users of svn in gnome <lifeless> if I was at home I'd start hacking on making it better <fredp> $ bzr merge <fredp> Merging from remembered location svn+ssh://djennings@example.org/svn/jhbuild/trunk <fredp> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. <fredp> but I only did bzr upgrade; I will do bzr svn-upgrade. <jelmer> lifeless: 0.4 was released ages ago (august 4), why is it such a problem all of a sudden? <fredp> bzr svn-upgrade <fredp> Using saved location: svn+ssh://djennings@example.org/svn/jhbuild/trunk <fredp> bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): No module named rebase.rebase <jelmer> fredp: You need to have the bzr-rebase package installed <fredp> jelmer: I came with this; because I went back on an older project; dating back before 0.4, I guess. <jelmer> ah, ok <jelmer> fredp: bzr-rebase is part of the distribution if you're running Debian sid, otherwise you should be able to install the plugin from http://people.samba.org/bzr/jelmer/bzr-rebase/trunk <fredp> jelmer: fails with an exception; http://pastebin.ca/759795 <jelmer> fredp: that looks like bzr-rebase 0.1, it should be 0.2 :-/ <fredp> jelmer: yes, looks debian only has 0.1; I'll get 0.2 <jelmer> fredp: sid has 0.2 <jelmer> http://packages.debian.org/sid/bzr-rebase <fredp> oh, mirror not uptodate, I'll use another one, damned. <jelmer> but that also relies on bzr >= 0.92rc1 <fredp> jelmer: it ran fine without error; but now bzr diff lists all files, as removed then added <fredp> will I lose history if I commit ? <jelmer> oh, darn - it doesn't fix file ids in the working tree yet <jelmer> fredp: I'd suggest creating a copy of the branch you've just upgraded <fredp> I nevertheless commited and tried to bzr merge and got this AssertionError <fredp> http://pastebin.ca/759808 <jelmer> or removing the working tree in the branch you've upgraded and then creating it again <jelmer> (bzr remove-tree; bzr checkout) <jelmer> perhaps we should mark svn-upgrade as experimental for now <lifeless> jelmer: gutsy release <jelmer> lifeless: ahh, ok <jelmer> lifeless: gutsy has bzr-svn 0.4.1!? <lifeless> yes <fredp> jelmer: branching off then bzr merge, and it worked. <lifeless> apt-cache madison bzr-svn <lifeless> bzr-svn | 0.4.1-1 | http://au.archive.ubuntu.com gutsy/universe Packages <lifeless> bzr-svn | 0.4.1-1 | http://au.archive.ubuntu.com gutsy/universe Sources <lifeless> the software escaped <fredp> thanks for your support; I can get to resolving the few conflicts. <jelmer> fredp: no worries, sorry this process is a bit less smooth than it could be :-/ <lifeless> jelmer: more info <lifeless> 00:06 < jdub> i pulled in bzr from hardon, but his latest rebase/svn require 0.92 <lifeless> 00:06 < jdub> so it just got beyond a joke <jelmer> lifeless: they require 0.92 or 0.92rc1, the latter of which is packaged <jelmer> and they're all three packaged in debian <lifeless> yes, but gutsy is out, so we're going to have a little bit of a problem getting fixes to users <lifeless> I'll had rebase to the bazaar-vcs.org packages asap <jelmer> I'm surprised though that gutsy has 0.4.1 - 0.4.2 was released and packaged for debian on 9 sept, was that already before the UVF? <lifeless> 9 sept was after UVF I think <lifeless> ok, bztools -> bazar-vcs.org repo <jelmer> lifeless: bzr-svn doesn't appear to be on bazaar-vcs.org either <lifeless> its not <lifeless> I need to get a svn build for the indings foo for dapper; hmm <lifeless> perhaps ignore dapper for a bit <jelmer> Having bzr-svn up would improve the user experience a lot methinks <jelmer> 71 bugs have been fixed since 0.4.1 <lifeless> ok <lifeless> I have to do some shopping now; will look into it later <jelmer> k <lifeless> jam-laptop: a review of my reconcile stuff would be nice <lifeless> jam-laptop: if you have time :) <lifeless> ciao for now <siretart> dato: no, djennings@example.org. Thanks for the upload! <simony> are there packages for dvc for ubuntu? <dato> simony: dvc? <simony> the emacs bzr frontend <dato> ah. I don't know, sorry. <simony> don't you have some bzr integration in your editor of choice? :) <radix> http://pics.livejournal.com/deeptape/pic/000dp4t6/ <mwhudson> radix: awesome <vila> simony: no package as dvc is currently evolving at a fast peace, but it is hosted in a bzr branch: http://bzr.xsteve.at/dvc/ <jaavaaguru> Peng, as I was talking about last night, I started writing a wxPython Bazaar client today. <jaavaaguru> http://sorn.net/~sandyd/blog/bzr-wx-2005.png <jaavaaguru> It's got init and commit support. moving onto merge support now <Peng> jaavaaguru: Cool. <Peng> jaavaaguru: I have to admit that I probably wouldn't use it (unless it was much better at something than the command line), though. <jaavaaguru> same here <Peng> Okay. <jaavaaguru> I'm creating it to make life easier for the Windows users who are used to things like Rapid SVN <Peng> Hmm. <jaavaaguru> I have also had some interest from OS X users <Peng> Maybe I should check out VCS GUIs. GUIs really are better for some things than CLIs. <jaavaaguru> I like diffing and merging in the GUI, it's usually faster <Peng> Hm. <Peng> Well, anyway, I'm AFK. Bye. <jaavaaguru> bye <jelmer> jaavaaguru: Have you tried qbzr at all? <jaavaaguru> I did try, and didn't get far on djennings@example.org. I don't have a PC here to try it on at the moment. I should probably get the error message and try and figure out what went wrong <lifeless> jam-laptop: also there is a gtk gui as well FWIW <lifeless> jelmer - you could review teh patch too :) <jelmer> lifeless: which patch was that, the reconcile one? <lifeless> yes <jelmer> voila <somerville32> Hi <lifeless> hi <somerville32> Would it be possible to have it setup so that I have one main branch but then several other branches which are just parts of the pie of the first one? <somerville32> I'd like to have branches that represent modules in my project and than one big one that puts them all together. <lifeless> somerville32: the nested tree functionality can do that; its a bit raw right now though. which reminds me... LarstiQ: ping #bzr 2007-11-04 <somerville32> Hey. I've made Bzr quotes! :] <lifeless> night all <Peng> Good night. <beuno> lifeless, you wouldn't happen to be around, would you? I'm working with Verterok on some changes to bzrlib we would like included before 1.0, and I can't commit to the bzr's branches anymore. Is there a chance I can get activated again? <jelmer> beuno: which bzr branch would you like to commit to ? <jelmer> bzr.dev isn't accessible directly - please send merge requests to the list <beuno> jelmer, no, we want to uplaod a branch to the group so both of us can commit <beuno> and it really doesn't make sense to create a new group just for this purpose <beuno> so we want to upload it to the bzr group, and work on it there <jelmer> ah, ok <beuno> (seemed to me like the logical workflow) <Kamping_Kaiser> would i be able to install bzr on a sparc running debian Etch? <Peng> If Python runs on it, bzr should have no problem. <Kamping_Kaiser> thanks <Peng> Bazaar has some C components for performance, but even if they didn't compile for some reason, it doesn't need them (it'll just be slower). <Kamping_Kaiser> bzr intalled from backports fine. thanks. <Peaker> If I decide to reject/destroy a branch in a shared repo, I'll get ghost revisions left, right? Is there a way to clean up such ghosts? <LarstiQ> Peaker: ghost revisions are the opposite, they are referred to by a branch but don't actually exist in the repository. <Peaker> LarstiQ: oh, how can that happen? <LarstiQ> Peaker: after removing a branch you have revisions in your repo that are not referenced instead, and yes you can remove those (although 'bzr gc' still isn't written) <gsuveg> re <LarstiQ> Peaker: one very good source for that is branches converted from arch, where it was almost trivial to get to that state. <gsuveg> bzr-gtk is broken? <LarstiQ> gsuveg: nafaik <gsuveg> gutsy and from bzr site <Peaker> LarstiQ: How can I remove them? <LarstiQ> Peaker: the remove-revisions plugin <Peaker> LarstiQ: ah, thanks <LarstiQ> Peaker: but be careful, that can also create ghosts <Peaker> LarstiQ: if it can't see all the branches? <Peaker> LarstiQ: or, how would it cause that? <LarstiQ> Peaker: if you tell it to remove revisions that are still used <Peaker> LarstiQ: Oh, I was hoping its more like "gc" :) <LarstiQ> Peaker: the step of figuring out which ones to use is not automated afaik <gsuveg> bzr-gtk: Depends: bzr (< 0.91~) but 0.92~rc1-1bazaar1 is to be installed <LarstiQ> Peaker: right :) <gsuveg> LarstiQ, sry. me sound like its a bit broken <gsuveg> apt sources deb http://bazaar-vcs.org/releases/debs/gutsy ./ <LarstiQ> gsuveg: you're talking about specific situations wrt a distribution, your original statement was way broader <LarstiQ> gsuveg: so that probably means newer bzr-gtk debs have to be uploaded <LarstiQ> but bzr-gtk itself works just fine <dato> gsuveg: we're waiting that bzr-gtk 0.92 gets releseased, otherwise it can't be packged :) <LarstiQ> jelmer: ^^ <LarstiQ> dato: oh well, that might also block a bit ;) <gsuveg> dato, ah. <gsuveg> but .91 would work with .92 not? <Peaker> why is ubuntu bleeding-edge not up-to-date with newest released bzr's? <gsuveg> dato, and on repo bzr-gtk is only the 0.90 <gsuveg> you can edit the dependecy not ? <dato> gsuveg: well, it's better not to <jelmer> LarstiQ, Szilveszter does the releases these days <gsuveg> i've back to 0.90 what in gutsy is <LarstiQ> jelmer: k <lifeless> moin <ryanakca> Since codebrowse appears to be down, how could I get a file from revision 4 if that file is no longer versioned? I've tried bzr revert -r4 file ... but it complains about not being versioned... <dato> ryanakca: try bzr cat -r 4 path/to/file >file.v4 <ryanakca> dato: thanks :) <lifeless> ryanakca: bzr revert -r4 file should indeed have worked; <lifeless> desperately seeking reviewers <vila> lifeless: hi :) You have two patches pending revisions, I already expressed my concerns about transport.list_dir, I didn't dig enough reconcile nor packs so far to comment on the second (stage 1 of pack reconcile) <vila> AIUI you plan to rework the first to avoid list_dir, if that's the case, I'd be happy to give you a +1 if that makes it happen quicker :) <vila> ghaa, s/revisions/reviews/ <lifeless> vila: well, you know I disagree on the list_dir usage <lifeless> there is no technical reason I know of yet to avoid list_dir for writable transports <vila> lifeless: ha, thanks for the precision, I was wrong then :) <lifeless> I plan in a future packs format to see if we can remove list_dir <lifeless> but for the current format there is no alternative <lifeless> that isn't worse. <vila> hmmm, so putting the webdav plugin on the back burner still depends on that then <vila> I'll to monitor that point more closely <lifeless> still, I'm seeking a reviewer for the stage1 reconcile packs patch <lifeless> jelmer: ping <jelmer> lifeless, pong <lifeless> jelmer: I've looked at the setup.py patch; and it seems less clean to me than th autotools it's replacing <lifeless> jelmer: I wanted to chat interactivvely about this, because I may be missing something <jelmer> lifeless: at the moment, the python package doesn't get installed at all <jelmer> so you're forced to run out of the source tarball <lifeless> right, so I want to fix that <lifeless> and I ocmcmented in the bug that I had no objection per se t o moving everything to setup.py if it was a net win; but thats clearly more than just fixing the bug <jelmer> Also, the dependency on automake just to install a few files is a bit heavy <jelmer> make check doesn't work currently (for me at least) <lifeless> what goes wrong ? <jelmer> let me check <jelmer> lifeless: never mind, looks like config-manager got deinstalled for some reason * jelmer wonders if it'd be a better idea to start from scratch <lifeless> jelmer: with pqm ? <jelmer> not with pqm specifically, but the sort of thing I'm looking for myself <lifeless> a little more detail might help me here :) <jelmer> I don't need support for baz, config-manager or creating repositories and things like the current testsuite in shell, automake make it hard to add the features I am looking for (bundle support, python gpgv, loading bzr plugins, better status page) <ubotu> New bug: #160012 in bzr "http urllib hides programming errors related exceptions" [Low,In progress] https://launchpad.net/bugs/160012 <jelmer> perhaps git support <lifeless> jelmer: so, pqm is getting cleaned up slowly; <lifeless> pqm does load bzr plugins - the plan is to drop all other VCS upport; support git etc via bzrlib plugins <jelmer> pqm doesn't load bzr plugins at the right time yet, that's what my other patch fixed <lifeless> bug #? I'll commit it now <jelmer> I don't think there's a bug #.. was a merge request I sent to you on may 23 <jelmer> should I resend it? <lifeless> I've found it I think. one sec, playing with it. <jelmer> lifeless: We could still ditch autoconf and automake, use a simple Makefile for building the docbook stuff and setup.py for the python-specific things? <lifeless> PEP8 issues but otherwise fine I think <lifeless> (VWS after class is needed) <lifeless> also ou create a heavweight checkout not a lightweight one <jelmer> lifeless, what about using Makefile for docbook for bug 117197 ? <ubotu> Launchpad bug 117197 in pqm "Doesn't install required Python package" [High,Fix committed] https://launchpad.net/bugs/117197 <jelmer> lifeless: still alive? <mc_> how can i tell bzr which editor to use? <dato> mc_: there are several ways, all explained in the tutorial. basically some environment variables (EDITOR, BZR_EDITOR) <dato> mc_: and the "editor" option in ~/.bazaar/bazaar.conf <mc_> ty <schierbeck> jelmer: pingz0r! <jelmer> schierbeck, pong! <schierbeck> what do you think about using commit messages to identify revisions to the user? <schierbeck> when they have to choose from a revision's parent <lifeless> that might be nice <schierbeck> i've sent a branch url to the ml <schierbeck> have a look and tell me what you think :) <schierbeck> currently only the toolbar buttons use it <jelmer> lifeless: see my comments from about an hour ago <schierbeck> ? <schierbeck> i only just sent it in <schierbeck> damn you're fast! <dato> heh <jelmer> schierbeck, that was about some pqm stuff <schierbeck> oh <schierbeck> :) <lifeless> jelmer: Sorry, eating etc <lifeless> I've merged your patch, it's off to people now <jelmer> lifeless: any thoughts wrt using make+setup.py rather than automake? <jelmer> lifeless, thanks for merging it <lifeless> done, revno 172 <lifeless> network here sucks worse than well most things <lifeless> I don't entirely get the objection to automake; automake isnot huge, it's well understood <jelmer> It's not really aimed at installing python packages <jelmer> you'd have to add some magic to find the right directory to install it in, the right python executable to use, etc <jelmer> also, automake sucks in general imo <schierbeck> jelmer: don't you think we call the navigation buttons in the viz something other than "back" and "forward" <schierbeck> it doesn't fit with the visual representation of the history <schierbeck> i'd rather have "up" and "down" <jelmer> yeah, up and down sounds fine to me <dato> but history is *time* independently of how you repreesnt it <jelmer> I'm not so sure about using commit message to identify revisions <dato> and time goes forwards and backwards, not up and down <dato> IMHO :) <jelmer> there are a lot of people that don't use clear enough commit messages <schierbeck> jelmer: i still think it's MUCH better than, say, revision id <schierbeck> and i think it's good enough for now <schierbeck> until we find something better <schierbeck> dato: but normal people don't think that way <schierbeck> they say "i want to go down on this list" <dato> well. you won't convince me but, alas, I'm not the bzr-gtk maintainer. :) <schierbeck> user interfaces aren't about what's right, they're about what's right for the users <schierbeck> :) <jelmer> schierbeck: I'd rather not experiment like this in the branch that's used for releases <phanatic> schierbeck: i'm about to release 0.92 and jelmer and i were talking about broken lines (ui option to disable it would be nice to have) <jelmer>
{'channel': 'bzr', 'month': 11}