=== Kissaki is now known as Kissaki^0ff
=== fta_ is now known as fta
[03:26] <AfC> Wow. Running `bzr viz` results in Bazaar crashing with a DBus error. That's great.
[03:29] <lifeless> meep
[03:36] <AfC> I didn't know bzr-gtk needed DBus to operate. {shrug}
[03:37] <AfC> DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0
[03:37] <AfC> Ah
[03:38] <AfC> from bzrlib.plugins.gtk import seahorse
[03:38] <AfC> thence
[03:38] <AfC> crypto = dbus.Interface(bus.get_object(BUS_NAME, CRYPTO_PATH), ...
[03:38] <AfC> "neat"
[03:38]  * AfC wonders what to do about it.
[03:38] <AfC> If I had to guess, I'd speculate it's ongoing wreckage from the Python 2.5 to 2.6 upgrade.
[03:38] <AfC> but we'll see
[03:46] <AfC> Bug filed
[03:50] <luke-jr> AfC: dbus is considered a standard component of any desktop system
[03:50] <luke-jr> I don't think you'll get much progress trying to break that dependency unless you do it yourself
[03:54] <AfC> luke-jr: I wasn't implying I don't have DBus present
[03:54] <AfC> (I'm a GNOME hacker)
[03:55] <AfC> luke-jr: I was merely expressing a bit of surprise that bzr-gtk was doing something that goes down that particular rabbit hole.
[03:56] <luke-jr> shrug
[03:56] <luke-jr> as far as I'm concerned, GTK sucks and has no place on my systems, so I can't say I'm surprised
[03:56] <luke-jr> KDE 4 sucks too, so here's hoping GNOME 3 is Qt4
[03:57]  * luke-jr ponders trying to make C bindings for Qt to encourage such a road.
[04:04] <jelmer> AfC: bzr-gtk doesn't need DBus, it will use it if it's available though (to communicate with seahorse)
[04:04] <AfC> jelmer: sure
[04:04] <AfC> jelmer: that's what I'm inferring
[04:05] <AfC> jelmer: the stack trace is at https://bugs.launchpad.net/bzr/+bug/377476 if you're interested
[04:05] <ubottu> Ubuntu bug 377476 in bzr "bzr visualize crashed with DBus error" [Undecided,New]
[04:05] <AfC> what puzzles me a bit is that after (fake) merging that branch to another the crash doesn't happen
[04:06] <AfC> so I'm really at a loss to say what's up. I also largely expect that it's something inconsistent and transient on my system, but again, no idea what
[04:07] <jelmer> AfC: fwiw I can't reproduce it with either but I'm on Debian (still python2.5)
[04:10] <AfC> jelmer: ok
[04:10] <AfC> jelmer: that's useful to know. I'll assume it's something local for now
[04:10] <AfC> jelmer: thanks
[04:11]  * AfC goes to find a coffee
[04:12]  * jelmer goes to find more beer
[07:07] <mwhudson> Peng_: you have quite a few loggerhead branches on the go
[07:08] <mwhudson> Peng_: how many of them are aimed at being merged into trunk in the end?
[07:09] <Peng_> mwhudson: Yeah, I know. The "cheezum" ones are the branch I run on my website, which isn't intended to be merged.
[07:09] <Peng_> mwhudson: The others, ehh.
[07:09] <Peng_> mwhudson: Want me to make a list? :D
[07:10] <mwhudson> well, just curious really
[07:24] <Peng_> mwhudson: FWIW, here's a list explaining them: http://paste.pocoo.org/show/7dCXpn7r0mCOoKejNiRM/
[07:24] <Peng_> And I'll land that branch in a second.
[07:25] <mwhudson> Peng_: thanks
[07:25] <mwhudson> Peng_: i'd say, just fix the pep8 stuff as you go
[07:30] <Peng_> I feel bad about spamming "bzr log -n 1" with it.
[08:25] <GPHemsley> Bazaar is good with branches and tags, right, (allegedly) unlike Mercurial?
[08:26] <Peng_> Um.
[08:26] <Peng_> I wouldn't say one is better than the other, just different.
[08:27] <Peng_> Mercurial versions the tags (just dumping them in a ".hgtags" file in the working tree), while Bazaar doesn't. There are advantages and disadvantages to both.
[08:27] <GPHemsley> Peng_: Well, I've heard a lot that Mercurial is bad at branches and tags, and that they shouldn't be used.
[08:27] <GPHemsley> Perhaps moreso with branches than tags.
[08:28] <Peng_> Regarding branches, with both bzr and hg, people usually make a new clone for a new branch, instead of supporting git's multiple-branches-per-directory thingy. Hg has some support for that, but it's not perfect; bzr doesn't at all.
[08:29] <GPHemsley> what about with regard to CVS/SVN?
[08:29] <Peng_> Who cares about cvs and svn? :D
[08:30] <GPHemsley> well, I want to replicate CVS's method... minus the politics ;)
[08:30] <GPHemsley> method of branching and tagging, that is
[08:30] <GPHemsley> I should probably elaborate
[08:30] <Peng_> Ah. I have just about zero experience with CVS.
[08:30] <GPHemsley> oh
[08:30] <GPHemsley> well
[08:31] <GPHemsley> I can explain what I want, and you can tell me if Bazaar does that
[08:31] <Peng_> OK, probably.
[08:32] <GPHemsley> FIrst off, I'll be using the centralized repository method
[08:33] <GPHemsley> I want to be able to branch at a point of release (0.1.0) to continue the latest development on the main branch, while still being able to make maintenance releases on the side branch (0.1.1, etc.)
[08:35] <GPHemsley> I'd also like to be able to tag each release as it happens
[08:35] <GPHemsley> on whatever branch it happens on
[08:38] <GPHemsley> Peng_: It seems fairly straightforward, and it's easy on CVS, because there's no distributed part to worry about. Can it work with Bazaar?
[08:53] <Peng_> GPHemsley: Sure, or hg. That's pretty basic stff.
[08:54] <GPHemsley> Peng_: Well, I'm not considering Hg for this. I'm just trying to make sure switching to Bazaar is a safe thing to do for what I want.
[08:54] <GPHemsley> I'd much prefer to use Bazaar. I just want to make sure it does what I want.
[08:54] <Peng_> Okay. It does.
[08:54] <GPHemsley> Oh, and, if it matters, I'll be stuck with 1.10.
[08:55] <Peng_> One thing to note is that cherrypciking between branches isn't very easy to do.
[08:55] <GPHemsley> Meaning what?
[08:55] <Peng_> Well, I mean, you *can* do it, but it won't reflect the history.
[08:55] <Peng_> GPHemsley: Branch A has revisions 1, 2, and 3. Then you branch off branch B, and commit revisions 4 and 5. Then you want to merge revision 5 back into branch A.
[08:56] <GPHemsley> so branch A would lose 4 and 5 history?
[08:57] <Peng_> GPHemsley: Err, revisions 4 and 5 were supposed to be on branch B, but I guess it works either way.
[08:57] <GPHemsley> right, that's what you said. I'm just trying to figure out what gets lost.
[08:57] <Peng_> GPHemsley: Nothing is /lost/ on the original branch, but the branch you cherrypick into won't automatically get the commit message and whatnot.
[08:57] <Peng_> Ehh, I suck at explaining things.
[08:57] <Peng_> Anyway! What you want is possible in bzr.
[08:57] <GPHemsley> heh, no problem
[08:58] <GPHemsley> So, can you merge in just a single changeset?
[08:58] <GPHemsley> or revision? or whatever they're called here?
[08:59] <Peng_> GPHemsley: Yes, but it won't be as smooth as merging in everything. It's basically equivalent to doing a diff, patch and making a new commit.
[09:00] <GPHemsley> right
[09:00] <GPHemsley> so no worse than CVS
[09:00] <GPHemsley> but better in the sense that you *don't* have to do three commands ;)
[09:02] <fullermd> To say nothing of actually using CVS  ;)
[09:04] <GPHemsley> fullermd: Heh. Well, I switched from CVS to SVN, but I really don't like SVN. And I've been finding myself yearning for Bazaar commands.
[09:05] <GPHemsley> So who would like to volunteer to walk me through the conversion process? :)
[09:07] <GPHemsley> Oh, and I'm doing all of this on Sourceforge, BTW
[09:09] <GPHemsley> fullermd: You up for the challenge? I know you've been helpful to me in the past. :)
[09:16] <Peng_> cvs to bzr or svn to bzr?
[09:17] <GPHemsley> SVN
[09:17] <Peng_> bzr-svn.
[09:17] <GPHemsley> I already did CVS to SVN a while back
[09:17] <GPHemsley> link?
[09:18] <Peng_> GPHemsley: http://bazaar-vcs.org/BzrForeignBranches/Subversion
[09:18] <GPHemsley> k, thanks
[09:19] <GPHemsley> So, will I have to use the version specifically for 1.10, or can I use the latest version?
[09:22] <Peng_> GPHemsley: You'll have to use an older release of bzr-svn.
[09:22] <Peng_> Upgrading bzr would really be better.
[09:22] <GPHemsley> Do you know why that is? It seems silly.
[09:22] <GPHemsley> And I can't upgrade. Like I said, I'm using SourceForge.
[09:23] <mwhudson> GPHemsley: you can use a newer bzr to do the conversion
[09:23] <mwhudson> then push it to sf just fine
[09:23] <GPHemsley> mwhudson: Oh, OK, so it's for the version that I have on my computer?
[09:23] <mwhudson> right
[09:23] <GPHemsley> oh, then that's easy
[09:24] <Peng_> FYI (since I don't want my grepping to go to waste!), the last version compatible with bzr 1.10 is 0.5rc1.
[09:25] <GPHemsley> heh, thanks
[09:25] <GPHemsley> it's on the page, though ;)
[09:26] <Peng_> Oooh. I skipped that section of the page. I'd put my foot in my mouth, but it isn't very clean.
[09:26] <GPHemsley> heh, I wouldn't recommend that then
[09:26] <Peng_> Oh well, it was still fun to figure out. :)
[09:27] <GPHemsley> was that in the source code or something?
[09:27] <Peng_> Yeah.
[09:27] <GPHemsley> cool
[09:34] <lifeless> Peng_: you should try washing your mouth sometime; then it will be clean
[09:35]  * fullermd has never done svn -> bzr.
[09:35] <fullermd> Facing up to the time to move to svn was what made me choose bzr in the first place   :p
[09:36] <GPHemsley> heh
[09:37] <Peng_> lifeless: I know. My dentist is going to murder me. Or she'll charge me a lot of money and be happy, I guess.
[09:38] <fullermd> To say nothing of your podiatrist.
[09:53] <GPHemsley> Alright, so I need subvertpy for this
[09:53] <GPHemsley> I try to install with via MacPorts and it tells me it doesn't know where my svn development files are
[09:53] <GPHemsley> And, well, neither do I
[09:53] <Peng_> They might not be installed.
[09:54] <GPHemsley> where do I get them?
[09:56] <lifeless> presumably via macports
[09:56] <lifeless> I believe we have .dmg installers for bzr which include bzr-svn though
[09:57] <GPHemsley> lifeless: Kindly point
[10:06] <GPHemsley> mwhudson: What format will bzr-svn use? Will it be compatible with the server's 1.10?
[10:07] <Peng_> GPHemsley: Yes.
[10:09] <GPHemsley> OK... but I'm still having trouble with subvertpy
[10:09] <GPHemsley> where would the SVN development files be?
[10:10] <GPHemsley> could the problem have to do with what I used to install SVN?
[10:20] <GPHemsley> ugh... I can't set the environmental variable for some reason...
[10:20] <GPHemsley> (I found the files)
[10:20] <AfC> Why does it say "bzr+ssh" but "<bzrlib"? (ie, what's with the extra '<' ?)
[10:20] <AfC> [actually, I'd like to know why it bothers to say this at all, but whatever]
[10:20]  * GPHemsley wonders what AfC is talking about
[10:21] <AfC> GPHemsley: bzr's current iteration of text presented while network operations are underway
[10:21] <GPHemsley> ah
[10:23]  * fullermd doesn't recall any bzrlib in the output.
[10:27] <Peng_> AfC: It displays < and > to show if it's currently reading from or writing to the network.
[10:32] <GPHemsley> Any idea why the subvertpy script is not picking up my environmental variables?
[10:32] <GPHemsley> the install script, that is
[10:32] <GPHemsley> (via MacPorts' port command)
[10:38] <GPHemsley> Peng_: Any idea?
[10:47] <lifeless> GPHemsley: http://bazaar-vcs.org/Download
[10:47] <GPHemsley> that's what I use
[10:47] <GPHemsley> bzr-svn is not included
[10:48] <lifeless> oh, ok
[10:48] <AfC> Peng_: no, that '<' and '>' are separate, also appearing on the line
[10:48] <AfC> Which is why I'm asking
[10:49] <lifeless> AfC: pastebin :P
[10:53] <davidstrauss> The date in NEWS.html for 1.15rc1 is wrong.
[10:53] <davidstrauss> Simple copy/paste error.
[10:54]  * davidstrauss goes to bed now.
[10:57] <AfC> lifeless: I'll try.
[10:58] <AfC> [/                  ] <bzrlib <      1KB     0KB/s |
[11:15] <GPHemsley> ugh.... I can't even compile subvertpy by hand because it fails with a different error...
[11:15] <GPHemsley> collect2: ld returned 1 exit status
[11:15] <GPHemsley> lipo: can't open input file: /var/tmp//ccJpbdpb.out (No such file or directory)
[11:15] <GPHemsley> error: command 'gcc' failed with exit status 1
[11:16] <GPHemsley> oh, hmm...
[11:16] <GPHemsley> looks like there's a bigger problem
[11:24] <GPHemsley> ugh, I don't know what to do
[11:24] <GPHemsley> everything I try errors out one way or another
=== Kissaki^0ff is now known as Kissaki
[11:30] <crisb> any loggerheads around?
[11:45] <Peng_> crisb: At least 0.2. Sometimes. Why?
[11:48] <crisb> just trying to do serve --http on the trunk - it blows up because BranchesFromTransportRoot has an arg missing, added that arg in and now it just says no such option --http!
[11:49] <Peng_> crisb: What's the missing arg?
=== sabdfl1 is now known as sabdfl
[11:50] <Peng_> crisb: Oh, I see. Hmm.
[11:50] <crisb> peng_: a config object.  used the serve-branches code as a copy
[11:50] <Peng_> crisb: Right.
[11:51] <Peng_> Darn. Now not only do I have to test start-loggerhead, but plugin mode as well.
[11:52] <crisb> peng_: dont think LoggerheadConfig() works in this situation which is what I did
[11:52] <Peng_> crisb: The problem is that the config object parses the command line arguments, but it doesn't know what to do with "serve --http".
[11:52] <crisb> ahah
[11:53] <Peng_> So now I've accidentally broken both start-loggerhead and "serve --http". Nice! :D
[11:54] <crisb> ;)
[11:56] <crisb> shall I file it?
[11:57] <Peng_> crisb: Sure.
[12:00] <crisb> peng_: number 377551 is born
[12:02] <Peng_> crisb: Thanks.
[12:07] <pmezard> what's the best way to detect lightweight checkouts programmatically, with maximum compatibility across bzrlib versions? is it what bzr info does?
[12:17] <Peng_> crisb: I have a fix up in a branch at http://bzr.mattnordhoff.com/bzr/loggerhead/serve-http-config -- does it work for you?
[12:22] <crisb> Peng_: sorted, yep looking great.
[12:22] <Peng_> crisb: It works? Really? Awesome. :)
[12:26] <crisb> ;) handy now I can package it for mandriva as a plugin
[15:21] <max_r> hi all. I have a question: I saw that you are developing new serialization format to replace XML called RIO. Why aren't you using something already implemented/stable/fast like google protocol buffers?
[15:34] <jelmer> max_r: Extra dependency in Bazaar, extra build complexity (need to compile .proto files)
[15:35] <jelmer> max_r: Also, RIO is already used in other places in Bazaar
[15:35] <jelmer> max_r: It just wasn't fast enough yet
[15:36] <Laney> is there a way to "merge" a commit with the current one without doing uncommit/commit?
[15:37] <amanica> Laney: you can't change a commit
[15:37] <Laney> ok
[15:38] <max_r> jelmer: I see thanks
=== abentley1 is now known as abentley
=== krisfree is now known as krisfremen
[18:41] <alefteris> hi all! lets say I want to create a new branch but bring only a single file, together with its history, is it possible? Or I have to branch the usual way and then delete the files I don't need?
[18:45] <davidstrauss> alefteris: Are you on bzr 1.14?
[18:45] <alefteris> yes
[18:45] <davidstrauss> alefteris: make a new directory, move the file there, and then bzr split that directory
[18:45] <davidstrauss> alefteris: This new directory should be in your existing tree
[18:45] <davidstrauss> alefteris: (and added)
[18:46] <davidstrauss> alefteris: That will turn the new directory into a distinct bzr tree that keeps all history for that file.
[18:47] <davidstrauss> alefteris: You may want to branch before doing the moving and splitting, just to avoid messing up your current branch.
[18:48] <alefteris> so make a new dir, add it, move the file in there, then bzr split this dir, correct?
[18:48] <davidstrauss> alefteris: Yes.
[18:49] <alefteris> davidstrauss, move the file manualy or through bzr?
[18:49] <davidstrauss> alefteris: And the split dir will be its own tree/branch with all history for that file pulled in.
[18:49] <davidstrauss> alefteris: through bzr
[18:49] <alefteris> ok thanks a lot
[19:07] <alefteris> all those different branch formats are meant to provide different options for different needs or newer ones are supposed to replace the previous ones?
[19:11] <alefteris> davidstrauss, I get a branch format error when doing the split, whats the required format that i should upgrade to?
[19:11] <davidstrauss> alefteris: you need a rich root format
[19:11] <alefteris> 1.14?
[19:11] <davidstrauss> alefteris: any rich root format will work
[19:12] <davidstrauss> alefteris: bzr upgrade --1.9-rich-root
[19:13] <davidstrauss> alefteris: I'm still wary of 1.14's format
[19:13] <davidstrauss> alefteris: There are issues with it being fixed in 1.15+
[19:13] <alefteris> davidstrauss, can you tell me anything about the previous question or there is any doc, explaning the various bzr formats?
[19:13] <davidstrauss> alefteris: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#upgrade
[19:14] <davidstrauss> alefteris: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#split
[19:14] <davidstrauss> "This command will produce a target tree in a format that supports rich roots, like 'rich-root' or 'rich-root-pack'."
[19:14] <alefteris> davidstrauss, I mean this one: all those different branch formats are meant to provide different options for different needs or newer ones are supposed to replace the previous ones?
[19:14] <davidstrauss> alefteris: The newer ones replace the older ones
[19:15] <davidstrauss> alefteris: Eventually old ones are obsoleted
[19:15] <davidstrauss> alefteris: The current default format is 0.92
[19:16] <davidstrauss> alefteris: Details are all here: http://doc.bazaar-vcs.org/latest/developers/development-repo.html
[19:16] <alefteris> davidstrauss, how come then that the default format is still so old? the newer ones are not so stable/tryed yet?
[19:17] <davidstrauss> alefteris: 0.92 is compatible with bzr >=0.92. Other versions require newer releases.
[19:18] <davidstrauss> alefteris: We're waiting for newer releases to become more widespread before upping the default version. It's not a question of stability.
[19:19] <alefteris> so it's basicaly in order to have branches compatible with older version of bzr in servers etc?
[19:19] <davidstrauss> alefteris: yes
[19:19] <alefteris> cool thanks a lot david for your answers :)
[19:22] <davidstrauss> alefteris: sure
[23:06] <dlee> I do net admin for a small office of Windows users, but since I write a number of utilities in Perl/Python that use Unix-like tools, I have set up a central way of running such tools under Cygwin without having to install Cygwin on each workstation.
[23:07] <dlee> Question:  Is there anything different in the Windows (stand-alone I suppose) Bazaar build, versus building from the tar, that would make it better than running the source Bazaar under Cygwin Python 2.5?
[23:07] <dlee> I'm mostly thinking of filename casing and EOL...
[23:09] <lifeless> I'm not aware of any patches in the code
[23:09] <lifeless> we do check platform forsome stuff, and IIRC cygwin shows up as a unix platform in python
[23:09] <dlee> I had problems in older Bazaar versions when, say, trying to version file sets on Windows machines when people saved with inconsistent name casing, but I think that even happened under Windows bzr stand-alone back then.
[23:10] <dlee> sys.platform == 'cygwin'
[23:11] <cr3> bzr is returning an assertion error for a file which was removed and later added again: bzr: ERROR: exceptions.AssertionError: name u'system_manager.py' already in parent
[23:13] <cr3> this is kinda preventing me from committing or doing anything else with my branch :(
[23:14] <cr3> meh, I just killed my other branch and rebranched
[23:14] <lifeless> dlee: yes, we should handle that better now
[23:15] <dlee> lifeless:  Wonderful!  Now just deciding whether to jump to 1.14.1 or wait for 1.15.
[23:33] <Peng_> beuno: ping
[23:35] <Peng_> cr3: fwiw, worst case, you probably just have to kill .bzr/checkout and run "bzr checkout" again. You don't even have to lose the files in the working tree.
[23:35] <cr3> Peng_: cheers
=== Kissaki is now known as Kissaki^0ff
=== Kissaki^0ff is now known as Kissaki
[23:50] <Peng_> beuno: unping. I sent an email instead.
=== abentley1 is now known as abentley