[00:06] <syncrondi> thanks lifeless
[00:08] <lifeless> nyu: I would use branches
[00:09] <lifeless> nyu: and when finishing the branch, merge it to trunk and commit
[00:14] <nyu> ok
[00:57] <syncrondi> If I've made an init on my server, do I also have to branch it before I can branch on my workstation?
[01:13] <syncrondi> Anyone know how I can remove a bzr project/repo?
[01:43] <lifeless> syncrondi: not sure I get the question
[01:13] <syncrondi> lifeless: I just deleted the .bzr/ and I hope that removes any projects created with init
[01:14] <syncrondi> But I can't seem to connect to my new project
[01:14] <syncrondi> I get bzr: ERROR: Not a branch: "C:/Documents and Settings/syncrondi/My Documents/My Webs/project/bzr:ssh:/me@project.org/home/project/htdocs/".
[01:16] <syncrondi> I'm just running the same command as I was before to connect to a server on another project : >bzr branch bzr:ssh://me@project.org/home/project/htdocs
[01:16] <spiv> syncrondi: you want "bzr+ssh" not bzr:ssh
[01:17] <syncrondi> ah..
[01:17] <syncrondi> I just noticed that myself
[01:17] <syncrondi> xD
[01:33] <syncrondi> I hate being pesty, but it seems as though I'm just unable to get this right. When I try branching, I get bzr: ERROR: Connection closed: Unexpected end of message. Please check connectiv
[01:33] <syncrondi> ity and permissions, and report a bug if problems persist.
[01:34] <syncrondi> I've got my key imported, host is accepted and now I get this :-\ Any ideas?
[01:45] <lifeless> syncrondi: check your bzr.log (bzr --version shows where that is)
[01:45] <lifeless> I suspect you don't have bzr on the server, or some such thing
[02:06] <syncrondi> lifeless: I'm pretty sure I apt-getted bzr.. What should I be looking for on the log?
[02:35] <offby1> .oO("apt-got"?)
[02:37] <lifeless> syncrondi: if you're on linux, ~/.bzr.log
[02:37] <MTecknology> !logs
[02:39] <lifeless> MTecknology: ?
[02:40] <MTecknology> lifeless: I just needed the link and this channel was the closest w/ ubottu in it - sorry for noise
[02:40] <lifeless> heh
[02:40] <lifeless> you can msg ubottu i think
[02:49]  * kfogel is away: zzz
[02:55] <syncrondi> lifeless: well, my tail has this http://pastie.org/668618
[02:57] <lifeless> syncrondi: you've clearly run other commands ;)
[02:57] <lifeless> syncrondi: is that on the client or the server?
[03:21] <syncrondi> lifeless: I thought you were asking for the server log. That's what I pasted and I was trying to init my project
[03:21] <syncrondi> my server is linux, client windows
[03:33] <lifeless> syncrondi: I was asking for the client log
[03:34] <lifeless> syncrondi: its going to be someting windows specific I suspect
[03:34] <syncrondi> ok lemme get that
[03:49] <syncrondi> http://pastie.org/668643
[03:50] <lifeless> so that means its not getting a connection via ssh to bzr on the server
[03:50] <lifeless> you might try BZR_SSH=paramiko
[03:50] <lifeless> I believe our windows devs think that works better
[03:55] <syncrondi> I can connect to my other server (that wasn't set up by me) just fine from that client, lifeless
[03:56] <lifeless> ok
[03:56] <syncrondi> that's why i thought it was something on the server side
[03:56] <lifeless> well, the sudden disconnect error like that means we didn't get a handshake
[03:56] <lifeless> if bzr is installed on the server
[03:56] <syncrondi> it is
[03:56] <lifeless> then its almost certainly client ssh issue
[03:56] <lifeless> e.g. a new host key
[03:57] <lifeless> plink doesn't prompt when its used in a subprocess
[03:57] <syncrondi> that could be the problem
[03:58] <syncrondi> the pw for my key and user are different, so perhaps I messed that up
[07:09] <MTecknology> How can I uncommit a revision?
[07:09] <MTecknology> I did bzr uncommit until I got back to where I wanted to be; then bzr push
[07:10] <MTecknology> but it's still at r5
[07:10] <bob2> you'll need to push --overwrite, I think
[07:10] <bob2> (back up remote side first)
[07:10] <MTecknology> thanks
[07:11] <Peng_> bob2: There's not really any need to back up. If you screw it up, you can always fix it.
[07:11] <GaryvdM> MTecknology: If other people allready have that revision, you may want to do bzr revert -r -2 bzr commit
[07:11] <MTecknology> ooh; it works nice too
[07:12] <MTecknology> the other guys are sleeping atm
[07:12] <GaryvdM> MTecknology: Otherwise they will need to do pull --overwrite
[07:13] <MTecknology> thanks :)
[07:13] <MTecknology> I like how uncommit kept my local files the same
[07:13] <MTecknology> that worked out very pretty :D
[07:17] <MTecknology> awesome stopping point for tonight
[07:21] <MTecknology> after using cvs, bzr makes me so so so happy
[07:22] <MTecknology> after dealing with svn servers, bzr makes me so so so happy
[07:22] <lifeless> we're glad :)
[07:23] <wgrant> bzr-svn means I don't have to deal with svn when it's mandated at uni.
[07:23] <wgrant> So no svn for me.
[07:37] <MTecknology> wgrant: I didn't know that existed.. happy day
[07:37] <MTecknology> wgrant: drupal.org might move from cvs to svn
[07:38] <MTecknology> so some more saps will be making bzr work over svn jsut to make the rest of us happy
[07:38] <Kamping_Kaiser> any step up is a good step *g*
[07:39] <MTecknology> svn is much better than cvs, but using bzr over svn... nice
[07:40]  * Kamping_Kaiser wonders how easy it will be to backport bzr-git from sid
[07:42] <MTecknology> I should try bzr-git.. I've been playing with the ubuntu kernel some
[07:42] <fullermd> MTecknology: By the way, you may recall we had a discussion a few months ago about mainline and revision numbering...
[07:42] <MTecknology> but git isn't too bad
[07:42] <MTecknology> ya?
[07:42] <MTecknology> I remember that
[07:42] <Kamping_Kaiser> it'll involve a new bzr, so its probably going to be annoying to backport. mutter. *puts on todo list*
[07:42] <fullermd> MTecknology: I stole the transcript of that out of my logs the other day and posted it up, to save having to type it again next time the question came up.  Hope you don't mind.
[07:42] <MTecknology> fnope
[07:43] <MTecknology> nope*
[07:43] <wgrant> Kamping_Kaiser: What are you running these days? Still gNewSense?
[07:43] <MTecknology> hope it helps others too
[07:43] <MTecknology> I should be sleeping......
[07:43] <fullermd> That's what you said then too, as I recall   :p
[07:43] <Kamping_Kaiser> wgrant: yeah, except the version based on Debian stable, not Ubuntu
[07:43] <MTecknology> I'll get ~5hr if I'm sleeping within the next 17min
[07:44] <Kamping_Kaiser> wgrant: gday and good evening, by the way.
[07:44] <wgrant> Kamping_Kaiser: Indeed. Evening!
[07:44] <Kamping_Kaiser> :)
[07:46] <MTecknology> fullermd: you have others ask the same thing?
[07:47] <fullermd> It comes up from time to time.  It's one of those things that's Obvious(tm) once you grok it, but kinda hard to see beforehand.
[07:47] <fullermd> And it's not necessarily obvious that it's important to understand either, until you run into it headon.
[07:48] <MTecknology> where's teh link?
[07:48] <fullermd> http://bazaar-vcs.org/MatthewFuller/AboutMainline
[07:49] <MTecknology> fullermd: you should s/USER/user/
[07:49] <MTecknology> just a thought
[07:50] <MTecknology> Thanks for the bookmark
[07:50] <MTecknology> I think I'll read it again
[07:52] <fullermd> I swear, someday I'll actually get time to distill that sorta stuff down into an actual doc...
[07:52] <fullermd> I expect to get to it shortly after my pony arrives...
[07:52] <Kamping_Kaiser> hehe
[07:52] <MTecknology> lol
[07:53] <MTecknology> if nothing else, the reader can have a laugh
[07:56]  * Kamping_Kaiser goes to see how fullermd 's discussion of mainline fits with the documentation
[07:57] <MTecknology> Kamping_Kaiser: I learned A LOT that day
[07:57] <MTecknology> I was too tired to retain it the first read though. It was almost the afternoon
[07:59] <MTecknology> that's when I started work at 02:00; I quit. Now I desperately need a new job
[07:59] <MTecknology> If I don't get one, idk about next tuition
[07:59] <fullermd> I specialize in blasting information at people too tired to retain it; that way I get to seem brilliant without all the hard work of actually being so  ;)
[07:59] <Kamping_Kaiser> hehe
[08:09] <MTecknology> this has been a while....
[08:09] <MTecknology> sending a process to the background - never do that intentionally
[10:26] <lifeless> Peng_: testtools is in 2a now
[10:30] <Peng_> Eh eh?
[10:30] <lifeless> Peng_: you're subscribed to lp:testtools; there isn't a list, but it just got upgraded to 2a
[10:30] <lifeless> I presume you're subscribed for some reason ;)
[10:31] <Peng_> Ah. I was wondering why you had singled me out.
[10:31] <Peng_> lifeless: Cool. I'll upgrade. :)
[10:33] <Peng_> Oh, the branch has moved too
[10:37] <Peng_> Working tree formats that support content filtering have to disable some optimizations, right? Do they even do that when content filtering isn't being used?
[10:45] <lifeless> Peng_: hardlinking, and yes, and there is a bug open I believe
[10:45] <Peng_> Ah. I don't use hardlinking, so I guess that's okay.
[12:22] <bialix> jelmer: ping
[15:58] <jelmer> bialix: pong
[16:25] <vadi2> Does bzr eclipse work with launchpad?
[16:26] <Peng_> What would be Launchpad-specific about bzr-eclipse's workingness?
[16:26] <vadi2> I think I read something about it not working with certain types of repositories. Anyway it's stuck uploading to a branch at 0% for a good while
[16:26] <vadi2> Was wondering if anyone knew something
[16:27] <Peng_> Oh. Well, I don't,
[16:29] <vadi2> cancelling didn't work either, so my whole eclipse is frozen on it
[16:29] <vadi2> @_@
[18:05] <jelmer> bialix: pong
[18:05] <bialix> hi jelmer
[18:05] <bialix> I've encounter bug in bzr-svn with russian characters
[18:05] <jelmer> bialix: that's been fixed :-)
[18:05] <bialix> today?
[18:06] <jelmer> 5 minutes ago
[18:06] <bialix> you're fast!
[18:06] <bialix> I'll try it
[18:07] <bialix> jelmer: in which branch?
[18:08] <bialix> all branches art https://code.launchpad.net/bzr-svn is at least 5 days old
[18:09] <bialix> jelmer: btw, how's your subvertpy-based fast-export-from-svn?
[18:14] <bialix> jelmer: are you still here?
[18:14] <jelmer> bialix: yeah, sorry
[18:14] <jelmer> bialix: it's in the main branch (launchpad only has mirrors)
[18:14] <jelmer> bialix: http://people.samba.org/bzr/jelmer/bzr-svn/1.0
[18:15] <bialix> aha, thanks
[18:15] <jelmer> bialix: the subvertpy-based fast-export-from-svn should work
[18:15] <jelmer> bialix: but it's only in the subverpty development branch
[18:16] <bialix> I'm interested in this, I want to glue together 2 fast-import streams
[18:16] <bialix> and then produce integrated branch
[18:17] <jelmer> bialix: you can rebase as well
[18:17] <jelmer> or import to bzr and then fastexport
[18:17] <bialix> no, I think I can't
[18:17] <bialix> I have CVS repo and forked svn repo
[18:18] <bialix> they are unrelated, because svn repo is not converted from CVS
[18:18] <bialix> so I need to figure out how to graft svn on CVS history
[18:18] <bialix> I have success with cvs2bzr though
[18:19] <bialix> now I think I need to get fast-import stream from svn repo and then join them somehow
[18:19] <bialix> I'll try svn-import, bzr fast-export
[18:21] <bialix> your bzr-svn branch is big
[18:21] <bialix> 3200 revisions... still branching
[18:21] <jelmer> yes
[18:22] <bialix> incredible
[18:28] <bialix> jelmer: does your 1.0 branch is compatible with bzr 2.0.1?
[18:28] <bialix> or I need cherrypick?
[18:28] <jelmer> bialix: it's compatible with 2.0.1
[18:29] <bialix> good
[18:29]  * bialix trying
[18:33] <bialix> jelmer: it working, many thanks
[18:35] <bialix> jelmer: after svn-import I have 2 branches with common history and 2 more branches w/o common history. is it normal?
[18:36] <jelmer> bialix: it depends on what happened in svn
[18:36] <jelmer> if there was common history in svn there will be common history in bzr
[18:37] <bialix> ok, I'll aske the author of that repo
[18:56] <bialix> jelmer: are you interested in the selftest result of bzr-svn on windows?
[18:56] <bialix> there is many unicode-related failed tests
[19:02] <jelmer> bialix: please file a bug
[19:02] <bialix> and attach test.log there?
[19:03] <jelmer> yeah
[19:05] <bialix> ok
[19:23] <bialix> jelmer: done: https://bugs.launchpad.net/bzr-svn/+bug/460613
[21:07] <igc> morning
[21:12] <jelmer> 'moin igc
[21:12] <igc> hi jelmer
[21:19] <jelmer> igc: this is probably a configuration issue on my end, but I wanted to try out bzr-explorer the other day and it seems to segfault when I try to start it
[21:19] <jelmer> "bzr qlog" segfaults in a similar way
[21:20] <igc> jelmer: which version of qbzr as you running?
[21:20] <igc> jelmer: it may me a PyQt thing in karmic which I beliebe bialix or garyvdm recently fixed
[21:20] <jelmer> r1006
[21:20] <igc> s/me/be/
[21:21] <igc> believe
[21:21] <jelmer> should I update my version of qbzr or my version of pyqt?
[21:22] <jelmer> Never mind, updating my version of qbzr fixed it - thanks
[21:22] <igc> jelmer: I'd try the latest qbzr
[21:22] <igc> jelmer: you on karmic now?
[21:24] <jelmer> igc: I'm on Debian sid/experimental
[21:24] <jelmer> igc: but that should have mostly the same (and newer) packages as karmic
[21:24] <igc> jlemer: right. I think pyqt 4.6 introduced some changes which triggered some issues
[21:25] <igc> jelmer: when explorer runs, try Help > About to see the version of PyQt you're running
[21:25] <jelmer> igc: Yeah, I'm indeed running 4.6
[21:53] <rubbs> Hello all. I'm doing a presentation for my local Linux Users Group on DVCS's and I had a few questions about some things I had trouble finding in the documentation.
[21:53] <jelmer> hi rubbs
[21:54] <rubbs> First, I am a little fuzzy on what packing does. My guess is that it makes the storage of the meta data more efficient, but I'm unsure as to how that works.
[21:54] <rubbs> Hello Jelmer.
[21:56] <rubbs> Second, if one were to track binary files, and a small change was made (say one line in a .odt file) does the storage double, or can it keep a diff stored similar to text files?
[21:58] <rubbs> The answers don't have to be bzr specific and any info on the differences about these questions in relation to git and hg would be greatly appreciated as well.
[21:58] <lifeless> rubbs: packing in bzr < 2.0 just reduces latency
[21:58] <lifeless> the db format consists of a number of files on disk
[21:58] <lifeless> packing coalesces these files
[21:59] <rubbs> ah thank you! That makes sense
[21:59] <rubbs> does this mean it's safe to delete the packs in the "obsolete packs" directory?
[21:59] <lifeless> in the 2a format it will recompress as well, as the compression algorithm isn't as fixed as it was
[22:00] <lifeless> yes
[22:00] <lifeless> that directory is used because there isn't such a thing as 'write barriers' on e.g. FTP/SFTP servers
[22:00] <lifeless> and fsync() on ext3 is appallingly slow
[22:00] <rubbs> Ok that makes sense to me then.
[22:01] <rubbs> thank you
[22:02] <rubbs> btw, I'd really like to thank the developers of bzr. I love it. I use it at work all the time.
[22:03] <lifeless> now, for binary files
[22:03] <lifeless> odt files are zipped
[22:04] <lifeless> so the size of a commit of a small change in the doc will be a large [size of .zip] delta
[22:04] <lifeless> sadly.
[22:04] <lifeless> however, we'd like to allow unpacking and deltaing the text
[22:04] <rubbs> That's what I thought, but I wanted to make sure before I said so in my presentation.
[22:08] <rubbs> The reason I asked about the binaries, was I'm trying to find reasons why a normal Linux user (non-developer and non-admin) would like to know about bzr/git/hg. I'm having trouble coming up with usage ideas for them (if there is any) now that binaries are for sure not saving space for each version, I'm running out of ideas.
[22:09] <lifeless> so, space isn't a reason
[22:09] <lifeless> but organisation
[22:09] <lifeless> backups
[22:09] <lifeless> logging
[22:09] <lifeless> 'what did I do yesterday'
[22:09] <lifeless> etc
[22:09] <lifeless> a VCS lets you rollback time, in a way that *some* apps allow, but not all - but the VCS lets you do it for all
[22:11] <rubbs> That's a good point. I'll put that in for sure
[22:12] <rubbs> Thank you for all your answers. I really appreciate it.
[22:12] <nyu> rubbs: it also helps with coordination
[22:12] <nyu> when different people want to modify the same code at the same time
[22:13] <rubbs> I also had thought of the fact that you could push a "history" of any file to the next maintianer of whatever project you may be working on (even word docs)
[22:14] <rubbs> got to go eat, but I'll be back. Thanks again.
[22:32] <Meths> In a pull or update what does a * next to a file mean?
[22:33] <lifeless> execute bit changed
[22:33] <Meths> Ah, okay.  Thanks.
[23:02] <igc> bbl
[23:33] <jelmer> LOL
[23:33] <jelmer> having both hg with hg-bzr and bzr with bzr-hg loaded is a bad idea :-)