[01:08] <mwhudson> splorf
[01:08] <mwhudson> mwh@grond:trunk$ cd /home/mwh/canonical/repos/bzr-git/trunk
[01:08] <mwhudson> mwh@grond:trunk$ python setup.py sdist
[01:08] <mwhudson> running sdist
[01:08] <mwhudson> warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)
[01:08] <mwhudson> error: .plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/
[01:08] <mwhudson> .plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git: Too many levels of symbolic links
[01:09] <mwhudson> (something to do with the test suite i think...)
[01:09] <lifeless> rotfl
[01:09] <spiv> Whee!
[01:10] <jelmer> mwhudson: yeah, 'make check' creates an empty directory .plugins and a symlink to .. in that (to point BZR_PLUGIN_PATH at)
[01:26] <poolie> spiv, how are you today, and what are you up to?
[01:26] <poolie> for myself i'm going to do a bit more mail and then perhaps try the startup time test i've been wanting to do
[01:27] <lifeless> poolie: which one is that?
[01:28] <poolie> making some assertions about the output of 'python -v bzr st'
[02:04] <spiv> Drat, missed poolie.
[02:06] <igc> back
[03:20] <igc> afk for a few hours - bbl hopefully
[06:34] <poolie> jelmer: hi?
[06:36] <poolie> spiv: hi? did you send that mail about ubuntu stories?
[06:36] <spiv> poolie: working on that atm
[06:37] <poolie> kthx
[06:41] <lifeless> EOD for me
[06:58] <vila> hi all
[06:59] <lifeless> hi vila
[07:15] <poolie> hello vila
[08:06] <vila> lifeless: KnownFailure are still failures for --parallel=fork --subunit so bug #419776 is not fixed ?
[08:07] <vila> lifeless: that's with: your fix and trunk version for subunit and testtools
[08:10] <lifeless> vila: try now, rev 25 of testtools
[08:13] <vila> lifeless: trying
[08:17] <poolie> spivvo?
[08:23] <vila> lifeless: BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork --subunit | subunit-stats
[08:24] <vila> lifeless: Failed tests:     38
[08:24] <vila> with revno 25
[08:27] <lifeless> vila: *interesting*
[08:27] <lifeless> vila: name one of the tests please
[08:29] <vila> bzrlib.tests.per_repository.test_fetch.TestFetchSameRepository.test_fetch_into_smart_with_ghost(RepositoryFormat5)
[08:29] <vila> bzrlib.tests.test_lock.TestOSLock.test_read_locks_block_write_locks(fcntl)
[08:30] <vila> BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork --subunit -s bzrlib.tests.test_lock.TestOSLock.test_read_locks_block_write_locks | subunit-stats
[08:30] <vila> Failed tests:      1
[08:43] <visik7> anyone have used the win32-symlink plugin ? it doesn't behave like the msys ln command
[09:11] <TigerP> is there a list of exit values of the bzr commit command?
[09:12] <lifeless> vila: works for me
[09:12] <vila> lifeless: argh
[09:12] <lifeless> vila: possibly the expectedFailure support improvements in my protocol branch of subunit
[09:13] <poolie> TigerP: i think it's in the manpage
[09:13] <vila> lifeless: sounds quite probable :-) url ?
[09:13] <vila> lp:~lifeless/subunit/protocol ?
[09:14] <vila> lifeless: indeed, works for me with that branch, can you merge it on subunit's trunk ?
[09:16] <TigerP> poolie: I can only see exit codes of the bzr diff command
[09:16] <lifeless> vila: I'll submit it for review
[09:17] <lifeless> vila: oh
[09:17] <lifeless> vila: actually, try this
[09:18] <lifeless> vila: just delete BzrTransformingResult
[09:18] <lifeless> and use subunit release
[09:18] <lifeless> that should work, I think.
[09:20] <vila> lifeless: yup, works !
[09:20] <vila> lifeless: can you update lp:~lifeless/bzr/subunit and resubmit then ?
[09:21] <lifeless> vila: this branch is for --subunit, not --parallel, primarily.
[09:21] <vila> lifeless: *you* linked it to bug #419776 :-)
[09:21] <lifeless> vila: as you have fast test environment, perhaps you could delete BzrTransformingResult completely, and its tests.
[09:21] <lifeless> vila: yes, with a comment that perhaps more work was needed ;)
[09:22] <vila> wow, I missed that comment !
[09:22] <vila> ok, I thought it was linked to indicate it fixed the issue, I'll assign it to myself and fix it after having approve your patch
[09:23] <lifeless> vila: anyhow, I know the current branch passes all tests.
[09:23] <lifeless> So I'd like to review and land that before making other changes that need a full test run
[09:25] <vila> lifeless: I had reviewed and was ready to approve but thought I tested for that bug first, I'll approve now
[09:25] <vila> lifeless: approved
[09:30] <vila> lifeless: please land asap so I can submit the fix for deleting BZRTransformingResult ;)
[09:32] <lifeless> vila: pushing up now
[09:33] <vila> lifeless:  ? Pushing what ?
[09:33] <vila> lifeless: if I could pull working versions what do you need to push ?
[09:34] <vila> or did you mean pqm-submitting ?
[09:35] <vila> err. wait I was too fast, that does work !
[09:35] <vila> err. wait I was too fast, that doesn't work !
[09:36] <lifeless> vila: to -integration, where I pqm submit from
[09:36] <vila> ok, approved anyway, my objection was about fixing the bug so irrelevant
[09:39] <vila> lifeless: deleting BTR works only with your subunit-protocol branch, so I'll wait for that to land before submitting the fix fr bug #419776
[09:39] <lifeless> vila: huh?
[09:39] <lifeless> vila: what happens with subunit release?
[09:40] <vila> KnownFailure is seen as a failure
[09:40] <lifeless> but BTR does that
[09:40] <lifeless> its BTR's fault ;)
[09:43] <vila> yes and no, with subunit release KnownFailure is seen as a failure with or without BTR :)
[09:43] <lifeless> testing
[09:44] <vila> and with your subunit branch it works with and without BTR :) But I'd love to get rid of BTR anyway.
[09:47] <lifeless> vila: so, 0.0.2 TestProtocolClient has no addExpectedFailure
[09:47] <lifeless> so that should be degrading to success in _do_known_failure
[09:51] <vila> lifeless: lost in the indirection via AutoTimingTestResultDecorator ?
[09:52] <lifeless> ah yes
[09:52] <lifeless> thats a policy change in subunit
[09:53] <lifeless> to degrade more gracefully
[09:53] <lifeless> I can do a separate branch for that
[09:53] <lifeless> -protocol- isn't fully baked yet
[09:53] <vila> ha :-/
[09:53] <lifeless> Wire changes are tricky
[09:53] <vila> certainly
[09:54] <vila> I'm not complaining, just trying to understand the migration path
[09:54] <vila> on the other hand 419776 is not blocking so there isn't an urgency either
[09:55] <lifeless> vila: how isn't it blocking ? :)
[09:56] <vila> well, it blocks subunit usage, not --parallel=fork usage :-p
[10:02] <lifeless> vila: I want to get stdout/warnings/log capturing working in testtools
[10:02] <lifeless> vila: and the bzr log stuff using the same PAI
[10:02] <lifeless> *API*
[10:03] <vila> you mean log as in trace.py, not bzr log the command right ?
[10:05] <lifeless> I mean as in printErrorList
[10:06] <vila> ha ok
[10:08] <vila> lifeless: that's the missing part for making your subunit protocol fully baked ?
[10:08] <vila> s/protocol/& branch/
[10:08] <lifeless> it will show that I've closed the loop in a tolerable way
[10:08] <lifeless> I also need t-i-p by-in
[10:10] <vila> t-i-p ?
[10:10] <lifeless> testing-in-python
[10:11] <vila> ECONTEXT :-/
[10:11] <lifeless> its a mailing list
[10:11] <vila> haaa, you need approval there ?
[10:14] <lifeless> social not technical
[10:14] <lifeless> buy-in, not approval
[10:15] <vila> yes, that what I meant.
[10:15] <lifeless> if I have t-i-p buy-in its a good indicator for an eventual PEP and API changes in Python itself
[11:10] <jml> anyone know why bzr was removing from ohloh?
[11:27] <vila> jml: no idea :-/ Where did you see that ?
[11:29] <jml> ohh, I see https://www.ohloh.net/p/bzr is gone https://www.ohloh.net/p/bazaar is there
[11:37] <vila> fullermd: around ?
[12:20] <bialix> hi all
[12:36] <igc> bialix: hi
[12:36] <bialix> hi igc
[12:38] <igc> bialix: could I ask a favour?
[12:38] <igc> bialix: we have new translations I'd like to get into Explorer ...
[12:38] <igc> and then tag it as 0.9.0
[12:39] <bialix> you want import?
[12:39] <igc> I'd like that to go out with the 2.1.0beta2 installer jam is packaging today
[12:39] <igc> bialix: I was planning to do it but I'm really tired
[12:39] <igc> (started chemo again today) :-(
[12:39] <bialix> ok, I'll do it now
[12:39] <bialix> sad to hear this
[12:39] <igc> bialix: mega thanks
[12:40] <igc> bialix: I put out a plea for more translations on the weekend to launchpad-users and the response was *awesome*
[12:40]  * bialix also has mixed feelings about today poolie's mail
[12:40] <igc> bialix: so you'll notice a few more
[12:41] <igc> bialix: I've responsed to that thread btw
[12:41] <bialix> igc: I'll just import them, have no time to review
[12:41] <igc> bialix: that should be ok. All I wanted was ...
[12:41] <bialix> yeah, a bit more :-)
[12:42] <igc> (1) import of transations
[12:42] <igc> (2) tag as 0.9.0
[12:42] <igc> (3) jam to package 0.9.0 in 2.1.0b2.
[12:42] <igc> I think 2.0.2 should stick with 0.8.3 of explorer
[12:43] <bialix> import may take half hour or couple of hours. it depends how fast lp will react
[12:43] <bialix> igc: according to garyvdm mail in qbzr ML I think bzr 2.0.x should stick with latest stable releases
[12:43] <igc> bialix: right
[12:43] <bialix> so 0.8.3 is ok
[12:44] <igc> bialix: I hope all is going well work wise - I hear you're flat out right now
[12:44] <igc> bialix: if there's no questions, I'll say good night
[12:44] <bialix> flat out?
[12:44] <igc> busy
[12:45] <bialix> yep, night Ian, I'll tag it for you
[12:45] <igc> thanks
[12:45] <igc> night all
[13:16] <bialix> igc: done.
[13:34] <jml> igc, do you know if there's an agenda for the bzr sprint?
[13:35]  * jml missed the "night all"
[13:35] <jml> sleep well, I'll send an email
[14:02] <vila> jml: apart from the focus defined on the wiki, not that I know of
[14:08] <jam> morning all
[14:09] <bialix> hi jam
[14:15] <jam> bialix: thanks for tagging bzr-explorer 0.9.0
[14:15] <bialix> jam: :-)
[14:16] <bialix> jam: garyvdm has planned to release qbzr 0.16 but it seems he's not finished it. use qbzr 0.15 for 2.1.0b2 please
[14:16] <jam> well, he's got a couple of hours :) but yeah
[14:16] <jam> I'll use whatever is available
[14:16] <jam> I'm going to be pushing for a faster "gone gold" to "official release" this time
[14:16]  * bialix has wanted to release 0.15.1 but...
[14:17] <bialix> jam: will be nice to speed up this process, really ;-)
[14:18] <jam> well, I did some 'pre-build' work last week
[14:18] <jam> so hopefully the build process for the windows installers is smoothed out
[14:51] <vila> morning jam
[14:51] <jam> hey vila
[14:52] <vila> jam: care to recheck https://code.edge.launchpad.net/~vila/bzr/186920-lp-proxy/+merge/14238
[14:52] <vila> ?
[14:52] <vila> jam: I can summarize here if you want
[14:53] <vila> james_w`: ping, sorry for friday, I had more reading to do than I thought :)
[14:53] <james_w`> vila: hi, np
[14:53] <jam> vila: a quick summary would be nice
[14:55] <vila> jam: I took your remarks into account. There was an additional glitch that is now fixed and Gordon Tyler confirmed it now works in all his setups
[14:55] <jam> so a quick question about http://bazaar.launchpad.net/~vila/bzr/186920-lp-proxy/revision/4782
[14:55] <vila> jam: the remaining question is where to land (in addition to bzr.dev), you and I seem to agree for 2.1
[14:55] <jam> What happens if you were trying to use a non-standard https port?
[14:56] <vila> before ?
[14:56] <jam> vila: so you have the comment that "self.port" is always None, and so you grab the port attribute from whether you are using http or https
[14:56] <jam> however, what if I was trying to go through my proxy to get to something like:
[14:56] <jam> http://babune.ladeuil.net:26862/waterfall
[14:56] <jam> You don't have to fix this to land the code, btw
[14:57] <jam> I'm just probing to see if I understand what is going on
[14:57] <vila> the comment is about urllib2.Request being brain-damaged and always using host  = 'xxx:nn' instead of host  ='xxx' and port = 'nn'
[14:58] <vila> i.e. self.port is *never* used so alwats None
[14:59] <vila> this is trappy because HTTPConnection objects cleanly separate host and port
[15:00] <vila> there is a grey area about the proxy behavior *without* that patch regarding what port were used... but only for the CONNECT request, all other cases are ok (AFAIK)
[15:00] <jam> vila: doesn't CONNECT have to go to the same port as the rest of the requests?
[15:01] <jam> (to be clear, I approve your patch, but I'd like to keep chatting to understand)
[15:01] <vila> it *has* to, it weren't for CONNECT
[15:01] <vila> all other requests ended up calling HTTPConnection.connect() which handle the default port, the last part of the patch is mimicking that for CONNECT
[15:02] <vila> because CONNECT is like connect expect it obviously wasn't (as fullermd would put it I think :)
[15:02] <jam> vila: so how does that work when connecting to a non-standard port?
[15:04] <vila> jam: port is not None in that case and is propagated correctly
[15:05] <jam> self.proxied_host = '%s:%s' % (self.get_host(), conn_class.default_port)
[15:05] <jam> There is no "port" in that statement
[15:05] <bialix> hmm, does ftp dumb transport unable to read part of file?
[15:05] <jam> bialix: So there is a "resume" sort of command in ftp
[15:05] <jam> which I believe means you can start in the middle
[15:05] <jam> I don't know how to set it up, or what the command is, etc.
[15:06] <jam> Just that I've seen it happen before
[15:06] <jam> I wouldn't be surprised if we don't properly support that in bzrlib
[15:06] <bialix> working with bzr over ftp is so slow
[15:07] <jam> bialix: FTPTransport doesn't seem to implement readv, which means it uses the base implementation
[15:07] <jam> which is get+seek
[15:07] <jam> which is, certainly, going to download the whole file
[15:07] <bialix> or bzr do something wrong, there is one pack ~3MB in ftp repo and bzr trying to download much more than that
[15:07] <jam> and then do it for each request
[15:08] <bialix> f***
[15:08] <jam> bialix: 3MB for every readv() request
[15:08] <jam> FTPTransport should either implement partial reading, or download to temp files and do it from there
[15:08]  * bialix wonders why not cache already downloaded data
[15:08] <jam> because nobody who cared enough to work with FTP put in the time to do so
[15:09] <bialix> right
[15:09] <bialix> I prefer to not care too, but I have not found any decent and cheap way to have private repos
[15:11] <vila> jam: hmm, you're right, there is still something wrong here :-/ I need a more complex setup to test it (i.e. an https server on a non-standard port)
[15:12] <jam> vila: anyway, it is good enough for now
[15:12] <jam> you should be able to test with an http server on a non-standard port
[15:12] <jam> such as babune.net :)
[15:12] <vila> jam: no
[15:13] <vila> CONNECT is called for https only
[15:13] <jam> really?
[15:14] <jam> ok I guess
[15:15] <vila> that's how you established the ssl wrapping if using an http proxy for example
[15:16] <jam> what if you were using an SSL proxy to a non SSL host?
[15:16] <jam> anyway, I've voiced my observation, and the code is still far better than what we have today
[15:16] <jam> so please land it in bzr.dev
[15:16] <jam> if you want, you could land it in 2.1.0b2 if you hurry
[15:19] <vila> jam: If I target 2.1.0, it will come back soon in bzr.dev right?
[15:20] <jam> vila: Once I get around to releasing, I'll be 'merging up' everything
[15:20] <jam> so it will be done today
[15:21] <jam> (2.0.2 => 2.1.0b2, 2.0.2 => 2.0.x, 2.1.0b2 => bzr.dev, 2.0.x => bzr.dev)
[15:21] <jam> not necessarily in that order, but approximately so
[15:21] <jam> 2 integration branches is... a bit of overhead for RMs
[15:21] <vila> jam: sorry, I'm confused, should I target bzr.dev or lp:~bzr-pqm/bzr/2.1.0 or both ? Ha ok, so I'll target 2.1.0
[15:21] <jam> vila: 2.1.0b2
[15:21] <jam> 2.1.0 does not exist
[15:22] <jam> merge-up is painful because of the number of combinations to take care of
[15:24] <vila> meh, why 2.1.0b2 and not 2.1.0 ? The later can be used for all releases leading to 2.1... Still confused >-/
[15:26] <jam> vila: every release gets its own branch
[15:26] <jam> so you can later "bzr branch lp:~bzr-pqm/bzr/x.y.z.b"
[15:26] <jam> we *could* do it differently
[15:26] <jam> so far, we have chosen not to
[15:28] <vila> rats, I branched too late to merge cleanly :-/
[15:29] <vila> huh ? Only for NEWS >-/
[15:31] <vila> oooh, no, the bug fixes were part of 2.0.2...
[15:31] <vila> wow, weird conflict
[15:31] <jam> yeah, there is some 'unknown' as to whether bug fixes in 2.0.2 should be repeated in 2.1.0b2
[15:31] <jam> for now, I've said no
[15:31] <jam> others have said yes
[15:31] <jam> but I don't like seeing them twice
[15:31] <jam> and we're always releasing a 2.0.x at the same time as 2.1.0x
[15:32] <jam> I believe lifeless originally posited that they would have different release schedules
[15:32] <vila> ok ok, RM priviledge :-) I haven't seen the physical consequences yet :-)
[15:32] <jam> and thus we may release one without the other
[15:32] <jam> and thus we should have the bug comments listed
[15:34] <vila> as long as you merge things in a coherent way, your way is good enough, you may add a note that 2.1.0b2 includes the fixes for 2.0.2 for completeness
[15:34] <jam> vila: so are you targetting 2.1.0b2 ?
[15:34] <jam> vila: it is in the summary
[15:34] <jam> if you didn't read it
[15:34] <jam> make sure it is there
[15:34] <jam> because I thought I did
[15:34] <vila> It is !
[15:34] <vila> Good, we agree then :)
[15:34] <jam> vila: so I should clarify slightly... we need a separate 2.0.x branch from a 2.0 branch, so that once the branch is split off, we can still land updates into 2.0
[15:35] <jam> just like we need a separate release branch for at least 2.1.0 so that we can keep landing in trunk
[15:35] <jam> (bzr.dev)
[15:35] <jam> we *could* have a single '2.0-releases' or something like that
[15:35] <jam> and then match that with a 2.1.0-releases
[15:35] <jam> however, once 2.1.0 is final, we will then need 2.1-releases, etc.
[15:35] <vila> that's how I organized my integration branches, 2.0, 2.1, etc
[15:35] <jam> for now, we just have 1 branch per release
[15:36] <jam> and not worry about what would be clustered with what
[15:36] <jam> I currently have "lp" and "lps" for stable targets versus dev targets
[15:37] <jam> bialix: i would think that "bzr serve" would be the easiest to set up, and provide ~ the same security as ftp
[15:37]  * vila runs to dentist 
[15:38] <vila> jam: pqm'ed, I'll be back soon
[15:41] <jam> vila: I don't see it on pqm
[15:58] <jam> Peng: looks like I reproduced your earlier failure: bug #471193
[15:58] <jam> I'm trying to sort it out now
[15:58] <jam> I'm a bit surprised we don't run into this more often since I've been using bzr.dev for a while and doing bzr up/bzr pull regularly...
[16:02] <jam> vila: I'd like to chat about possible fixes if you get a chance
[16:08] <vila> huho, pqm acting again ?
[16:11] <jam> vila: your patch is there now
[16:11] <jam> do you have any time to chat about bug #471193 w/ me?
[16:13] <vila> jam: sure, that's clearly a red-button case
[16:13] <jam> vila: so I can fix it in a variety of ways
[16:14] <jam> I can make the chk map code not require StaticTuples
[16:14] <jam> either by changing the internals not to fail
[16:14] <jam> or by wrapping more locations with "StaticTuple.from_sequence(key)"
[16:14] <jam> In my ideal world, all keys in memory would be ST
[16:14] <jam> so I've been trying to push the 'from_sequence' code higher in the stack
[16:15] <jam> so it doesn't have to be reproduced everywhere
[16:15] <jam> It isn't terribly expensive, but it is a couple of function calls
[16:15] <vila> the higher in the stack they are, the less we care
[16:15] <jam> alternatively, I can fix *this* bug by changing either the code that reads from Remote
[16:15] <jam> (such as _benencode.decode_as_tuples)
[16:15] <jam> to cast into StaticTuple earlier
[16:16] <jam> or I can change BTreeBuilder
[16:16] <jam> to cast into StaticTuple
[16:17] <vila> so, the bug shows that the test suite is incomplete, as long as you can reproduce it with a test, you will increase the robustness
[16:17] <vila> the worrying thing is: can you revert some changes to avoid the issue ?
[16:17] <bialix> jam: setup bzr serve on my hosting?
[16:18] <vila> and why nobody running bzr.dev encoutered it sooner ?
[16:18] <jam> bialix: I was mostly doing a jab that ftp is not very secure
[16:18] <Peng> jam: Huh! I thought my original failure was just because I had forgotten to recompile the extensions?
[16:18] <Peng> jam: I do a lot of bzr+ssh pulls too, so I'm surprised I haven't run into this one, either.
[16:18] <bialix> jam: I know it's not very well secure but it's ok for me
[16:18] <jam> Peng, vila: I have very little clue why this wouldn't be deterministically failing for everyone repeatedly...
[16:18] <bialix> bzr serve --alow-writes is not secure at all
[16:18] <jam> perhaps it has to do with the chk_map cache
[16:19] <jam> it is possible that the chk_map page cache is intercepting the calls and returning the contents differently than hitting the BTreeBuilder
[16:19] <jam> so only 'big-enough' pulls that overflow the cache are caught
[16:19] <jam> however, _read_nodes_from_store doesn't *use* that cache at all...
[16:20] <jam> so that doesn't seem to be the answer
[16:20] <hexmode> quick, easy, switching between branches on bzr.  How do I do it?
[16:20] <jam> hexmode: 'bzr switch' ?
[16:20] <jam> depends on how you have your branches/working trees laid out
[16:20] <vila> jam: are you sure you're not running into a running-pull-with-pulled-code issue ?
[16:20] <jam> vila: "pull with pulled code" ?
[16:21] <jam> I think I know what you mean, and this dir has no tree
[16:21] <jam> just a branch
[16:21] <hexmode> jam: so, I've modified code in my current checkout/branch/whatever
[16:21] <bialix> jam: if you talk about cache with me then I should say that I'm still using pack-0.92 / 1.9 formats
[16:21] <jam> vila: and I can step through the code and see the problem
[16:21] <vila> jam: so you can reproduce it at will ?
[16:21] <hexmode> and want to switch back to the pristine source, but still have my changes available.
[16:21] <jam> vila: on *this* branch it reproduces every time
[16:21] <hexmode> I haven't tried switch yet.
[16:21] <jam> as the pull fails to complete
[16:21] <vila> jam: in a branch where your extensions are up to date ?
[16:21] <jam> hexmode: perhaps 'bzr shelve' if you want to revert to pristine
[16:21] <vila> ha, the pull fials...
[16:22] <hexmode> jam: k, reading the docs
[16:22] <jam> vila: I've diagnosed the specific steps in the bug, and it is fully reproducible
[16:22] <jam> the BTreeBuilder has a tuple() key
[16:22] <jam> and when yo ucall "get_record_stream()" the record.key attribute is that same tuple
[16:22] <vila> what I meant was: 'bzr pull' in my bzr.dev branch, i.e. the code is updated while running
[16:22] <jam> vila: sure, that's what I thought, and no, that isn't happening here
[16:22] <vila> jam: ok
[16:22] <jam> I'm updating a tree-less branch of 2.0.2
[16:23] <vila> with a bzr.dev bzr ?
[16:23] <jam> vila: yse
[16:23] <jam> yes
[16:23] <jam> hexmode: 'bzr shelve' will revert your changes to the previous commit, and put them 'on a shelf' to be restored later with "bzr unshelve"
[16:24] <hexmode> jam: right, just saw that, but was thinking of a way to maintain it: i.e. branches, not temp shelves
[16:24] <jam> hexmode: it also depends what you mean by "pristine source", is that a different branch, or the previous commit on this branch
[16:24] <hexmode> jam: I think shelve will do for now, though
[16:25] <jam> hexmode: I can go into deeper config to make multiple branches a bit easier to work with, but it does take a bit of explaining
[16:25] <hexmode> jam: maybe later.  Was looking at help for bzr switch: where can I find out about lightweight vs heavyweight checkouts?
[16:26] <jam> hexmode: you might try 'bzr help checkouts'
[16:26] <hexmode> jam: excellent.  thanks
[16:27] <vila> jam: I just pulled in my 2.0 branch without trouble :-/
[16:27] <jam> vila: so it will depend explicitly on the data stream
[16:28] <jam> specifically, you 1 have to pull from bzr+ssh
[16:28] <jam> 2 it has to try to read a page from the newly created btree
[16:28] <vila> I do (AFAICS)
[16:28] <vila> confirmed by .bzr.log
[16:29] <jam> so it needs to transfer a chk page from the source, which it then needs to verify
[16:29] <vila> what revno are you at when pulling ?
[16:29] <jam> 4696
[16:29] <jam> note, though, that it will probably depend what pages are in your local repo already
[16:30] <vila> yeah...
[16:30] <bialix> jam, vila: does one still should write tests for each bugfix? e.g. for fixing https://bugs.launchpad.net/bzr/+bug/389648 there is need only to add Hooks.__init__(self) to some derived classes constructors...
[16:30] <hexmode> bzr shelve: I'm in love
[16:31] <jam> vila: I feel like I understand the bug, I'm just trying to get a feel for the fix
[16:31] <jam> specifically, do I make the code *stricter* everywhere
[16:31] <jam> or *more relaxed*
[16:31] <jam> do I push to require StaticTuples in BTreeBuilder
[16:31] <jam> or do I relax requiring StaticTuples in chk_map
[16:31] <jam> and to what degree ...
[16:31] <vila> jam: I'm from the more stricter school by default :-) And you said you want ST everywhere. BUT,
[16:32] <vila> you're also the RM and you want to release today
[16:32] <jam> vila: So I *think* that for performance and memory minimal that pushing ST everywhere is ideal
[16:32] <vila> So I'd say, relax for today, it's a beta, and dig that asap in bzr.dev
[16:32] <jam> There is always the "transition" phase
[16:32] <jam> and wondering about when is good-enough
[16:32] <jam> vila: ok, I'll create a 'relax' patch in about 10 min
[16:33] <jam> if you can review it, it would be nice
[16:33] <vila> the decisions IMHO is about is that bug likely to hit people ? You seem to think it's quite hard to reproduce, so.
[16:34] <vila> I sure will
[16:34] <vila> jam: could you replace the check with a upcast ?
[16:36] <jam> vila: of course I can cast it, the point is how strict to be
[16:37] <jam> casting random tuples => StaticTuples makes memory consumption worse
[16:37] <jam> as now you have 2 objects representing the same thing
[16:37] <jam> so you *want* the caller to do the cast
[16:37] <jam> I'm doing a quick "assert when a debug flag is set" patch
[16:37] <jam> and cast
[16:37] <vila> jam: oh sure, I was thinking of the 10min approach, not the long term one
[16:39] <vila> ouch, 1h30 time drift in 5 hours on my FreeBSD8 slave :-/
[16:39] <jam> wow
[16:40] <vila> fullermd: whenever you have a minute to discuss possible workarounds ^, I don't blame FreeBSD here, more likely VB (and they seem to be aware of the overall issue), but that seems to have to many side-effects for me to ignore :-/
[16:42] <vila> and same thing for the FreeBSD7 slave, I love coherent OSes :)
[16:42] <bialix> jam, vila: can you look at my fix http://pastebin.com/m125a467e for bug 389648 please?
[16:42] <bialix> fix is 2 liner, and ten lines of tests
[16:43] <vila> bialix: hehe, you're getting in the TDD mood :-D
[16:43] <bialix> I'm stuck with my current job, so I've decided to fix this simple one
[16:43] <bialix> vila: :-P
[16:44] <bialix> vila: I do very much TDD at my job
[16:44] <vila> bialix: why don't you push that branch and make a merge proposal ?
[16:44] <vila> it makes reviews easier
[16:45] <bialix> if you say that it ok in principle then I'll push
[16:45] <vila> but from the paste bin, I'd say, put these import at the beginning of the file, use import mod ; mod.func instead of from mod import func ; func
[16:46] <vila> bialix: hehe, that's not how we review :-D You asking for approval before review here :D
[16:46] <bialix> imports in the tests?
[16:46] <vila> yup
[16:46] <bialix> I'm asking about tests approach
[16:46] <bialix> the fix is obvious but I have no time to rewrite my tests zillion times later
[16:47] <vila> if they fail without your patch and your patch make them pass, who will argue ?
[16:47] <bialix> I dunno, lifeless?
[16:47] <bialix> sometimes he argue about things I don't care so much
[16:47] <vila> You think you put them in the wrong files ? Or that you test at the wrong layer ?
[16:48] <bialix> ok, I'll push
[16:49] <bialix> from the bug description bzr-svn triggers that bug registering a hook
[16:49] <bialix> I don't register a hook and anyway can trigger the bug
[16:50] <vila> bialix: 8-/
[16:50] <bialix> I don;t know how in ideal world the tests for such bug should like
[16:51]  * bialix bbl
[16:52] <vila> It seems to me the bug in format_rio, so the tests could be in the corresponding test file, or we could try to make hook more resistant by ensuring the right constructor is always called, but that will certainly be quite ugly
[16:52] <vila> oh, info.py is bogus too
[16:55] <vila> bialix: right, so please do like the other classe that derived from Hooks, use the super() notation
[16:55] <vila> bialix: of course, I found other examples that don't use super() :-/
[17:00] <nxvl> hi, i just reported Bug #471292
[17:00] <nxvl> bzr import-dsc is failing basicaly because the debian chagelog has UTF-8 characters
[17:01] <nxvl> wich is odd since there are packages in the ubuntu repo that has them aswell
[17:01] <nxvl> and bzr supports them
[17:05] <james_w> urgh, sorry nxvl
[17:11] <jam> vila: sorry about the delay, got hit by a "Jehova's Witness' if you know what that means
[17:11] <vila> jam: hmpf
[17:12] <vila> jam: yeah, I know, not seen for years... luckily :)
[17:12] <jam> it being the end-of-days and all
[17:12] <jam> I suppose fixing this doesn't matter then
[17:12] <jam> :)
[17:12] <vila> lol
[17:14] <vila> bialix: argh, he's gone :-/
[17:26] <jam> vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b2-471193-st-and-chk-map/+merge/14309
[17:26] <lugo> hi
[17:27] <AnMaster> oh 2.0? when did that happen
[17:27] <lugo> a checkout i use has recently changed it's name
[17:27] <lugo> well the branch name has changed actually
[17:28] <jam> AnMaster: Sept 22, approx 1.5 months ago.
[17:29] <AnMaster> jam, sigh, university really made me miss out on the rest of the world recently
[17:29] <lugo> since i'm really new to bzr i just don't know how to tell it the name change ;)
[17:29]  * AnMaster looks for some release notes or overview of the major changes since 1.17 or so
[17:29] <GaryvdM> lugo: bzr bind new/url
[17:29] <jam> lugo: 'bzr switch --force' ?
[17:29] <jam> GaryvdM: /wave
[17:29] <GaryvdM> lugo: sorry bzr switch
[17:29] <GaryvdM> Hi jam
[17:30] <vila> jam: you requested merging against lp:bzr ?
[17:30] <jam> GaryvdM: 'bzr bind new/url' is accurate if using a heavy checkout, I think
[17:30] <lugo> switch ok i'll try that
[17:30] <jam> vila: meh, you know what I mean :)
[17:30] <jam> it *is* for 2.1.0b2
[17:30] <jam> Just forgot to set the target
[17:30] <jam> it will get into bzr.dev soon anyway
[17:30] <vila> jam: ok, just checking, I'll stop waiting for lp to generate the diff then and do it locally
[17:31] <jam> GaryvdM: bialix mentioned you were hoping to get qbzr 0.16 released for 2.1.0b2, do you think that will happen?
[17:31] <lugo> yay worked, thank you guys
[17:32] <GaryvdM> jam: Yes - My weekend was a nightmare (Partially self inflected.)
[17:33] <GaryvdM> There were some features that I was hoping to finish, Which are not done yet.
[17:33] <vila> jam: so the plan is to get rid of expect_static_tuple in the end right ?
[17:33] <jam> vila: long term, yes
[17:33] <GaryvdM> Trunk is stable so I guess I should just release it as it is.
[17:34] <GaryvdM> jam: What is my deadline?
[17:34] <jam> GaryvdM: take your pick. *I'm* happy enough to release w/ 0.15
[17:34] <jam> GaryvdM: I'd like to cut bzr tonight
[17:34] <jam> and then have the windows installers by tomorrow
[17:34] <GaryvdM> Jam: I'll try, but if I miss it, no worries
[17:35] <GaryvdM> jam: After  2.1.0b2, how many release cycles before 2.1.0 Final?
[17:35] <jam> GaryvdM: well, do what you can, and realize that I'm pushing to be more 'timely', mostly because that should *ease* your burden
[17:36] <jam> since if you miss it, it won't be long til you get to try again
[17:36] <jam> GaryvdM: https://edge.launchpad.net/bzr/ says we should expect b3, rc1 and rc2 before final
[17:37] <jam> https://edge.launchpad.net/bzr/+milestone/2.1.0 says final is 2010-02-03
[17:37] <vila> jam: approved, running the full test suite right now just in case
[17:38] <GaryvdM> jam: Ok - My motivation is to have new features tested before the final, so I'm going to let it slip, as there is another beta.
[17:39] <vila> jam: full test suite passing
[17:40] <jam> vila: thanks.
[17:40] <GaryvdM> Hi vila
[17:40] <jam> of course, it was passing before my patch...
[17:40] <jam> I would like to test it, but the setup is hard
[17:40] <vila> hey GaryvdM
[17:40] <jam> the real fix is to test the index code to make sure they return ST
[17:41] <jam> and the Remote streaming code, etc.
[17:41] <vila> jam: no worries, I always run the full test suite when I review, I wanted to give view the approval in advance
[17:41] <vila> s/give view/give you/ wow..... what's that for a typo ?
[17:42] <vila> lol
[17:42] <jam> vila: you know, I didn't even notice
[17:43] <jam> I read 'you' just fine
[17:43] <jam> 'give you'
[17:43] <jam> it sounds the same as 'give view'
[17:44] <vila> yeah, that's what surprises me the most...
[17:44] <vila> *I* supposed to make typos because my fingers slip, not that kind of typo (I don't even think I ever do that in French...)
[17:45] <vila> OR only on purpose for jokes...
[17:47] <jam> it *was* an impressive coincidence.
[17:47] <jam> you had just talked about 'review', so it could be just that
[17:49] <vila> it also carries the meaning: "I wanted to give you visibility on my review" more freudian that way :)
[17:50] <vila> bialix: http://pastebin.com/m829db9b is an alternative that *also* fail before your patch and succeeds after
[17:50] <vila> bialix: just to maintain the universe balance, that makes a two-line fix with one-line test fix :)
[17:51] <vila> bialix: hope you're reading the log history...
[17:51] <GaryvdM> vila: lol - Was just about to point out to you that he's not here...
[17:52] <vila> GaryvdM: I know he's gone, but I'll quit shortly... But now, *you* are responsible to carry that paste :-D
[17:52] <GaryvdM> Oh No.
[18:42] <phoenixz> I do "cd /home/sven/project/test" then "bzr whoami 'Sven <sven@blah.com>'", then a bzr whoami, and it shows the right thing.. Then I do a "bzr whoami /home/sven/project/test" and bzr tells me: "/home/sven/projects/kloud" does not seem to contain an email address.  This is allowed, but not recommended.
[18:42] <phoenixz> what is this about? the whoami is a global setting or just per project?
[18:43] <Peng> phoenixz: Well, "bzr whoami /home/sven/project/test" tries to set your name to "/home/sven/project/test".
[18:43] <phoenixz> Peng: ah, doh!
[18:43] <Peng> phoenixz: s/tries to set/sets/, probably.
[18:44] <Peng> phoenixz: I'm not sure if you can set it per-project. You could try setting it in ~/.bazaar/locations.conf or $branch/.bzr/branch/branch.conf
[18:47] <jam> phoenixz: you can use "bzr whoami --branch USERNAME" to set it for a specific branch
[18:47] <jam> or, as Peng said, use locations.conf to set it recursively somewhere
[18:48] <Peng> Oh, I didn't know that.
[19:09] <kfogel_>  this one ring a bell to anyone? http://paste.ubuntu.com/307835/  "bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for parent_id_basename_to_file_id maps"
[19:11] <phoenixz> When  I do an bzr annotate --all --long file.php, I get lines like this: 1   sven@kionetworks.com 20091102 |  * blah blah blah
[19:11] <phoenixz> I see email, a date, but what is the 1 in the first position of that line?
[19:12] <Tak> revno
[19:13] <phoenixz> Tak: yeah, just found it in the help too, thanks!
[19:18] <phoenixz> Another question.. BZR does NOT have support for copy, right? How do I do it with.. well, under SVN I had a template library, I used to copy all my libraries from there.. Make a small update to the template library, merge it to the other libraries, etc.. But with BZR, there seems not to be such a history possible.. How would I do this?
[19:23] <kfogel_> rockstar: (see my question above?)
[19:23] <rockstar> kfogel_, what version of bzr are you using?
[19:23] <rockstar> kfogel_, fair warning: if you say 1.17 I will slap you.  :)
[19:23] <kfogel_> rockstar: 2.0.1
[19:23] <kfogel_> rockstar: :-)
[19:24] <rockstar> kfogel_, huh, okay.  jam? ^^
[19:37] <phoenixz> Another question.. BZR does NOT have support for copy, right? How do I do it with.. well, under SVN I had a template library, I used to copy all my libraries from there.. Make a small update to the template library, merge it to the other libraries, etc.. But with BZR, there seems not to be such a history possible.. How would I do this?
[19:37] <Peng> Right. Bazaar does not support copies.
[19:38] <phoenixz> Peng: so how could I do what I just mentioned?
[19:38] <phoenixz> or better, will copies be supported in the future?
[19:38] <Peng> phoenixz: Probably, but likely not any time soon.
[19:38] <phoenixz> And another one.. I just added an entire tree, and one directory keeps showing as unknown.. When I specifically add that directory with bzr add, I get bzr: ERROR: '/home/sven/projects/blah/lib.e/blah/directemplate' is not a working copy
[19:38] <Peng> phoenixz: Why not make the template thing a branch, and make your other projects branches of it?
[19:38] <phoenixz> what is this about?
[19:39] <Peng> phoenixz: Not sure. Does that directory have a .bzr, .svn, .git or .hg directory in it?
[19:39] <phoenixz> Peng: Well, Im considerring making each library a branch, but since we have like 140+ libraries to manage.. gets to be a lot of branches..
[19:39] <phoenixz> Peng: bingo, it has an .svn directory in it yeah!
[19:56] <phoenixz> If I have a  branch with in there various directory, and each directory is a library.. Can I -at one point- branch each of those libraries from the current branch?
[19:56] <phoenixz> simply said, can I create branches from sub directories in a branch?
[20:14] <Peng> phoenixz: Eh. Are you looking for "bzr split"?
[20:15] <bialix> vila: thanks for paste, but your variant is completely new. I think you have to send merge request yourself
[20:17] <vila> bialix: well, *you* found the fix, I was just curious about how to test it :-)
[20:18] <vila> bialix: I'll send the fix tomorrow and give you credit. Deal ?
[20:18] <phoenixz> Peng: I dunno, let me see what "split" does :)
[20:27] <bialix> vila: the fix was so simple, so I don't dare to get credits really
[20:28] <bialix> vila: do as you wish, please
[20:28] <bialix> vila: and thanks
[20:29] <blackxored> hello
[20:30] <blackxored> how can I instruct my friend on windows to checkout to a branch at a gforge install with bzr plugin?
[20:30] <bialix> what?
[20:31] <bialix> GaryvdM: heya
[20:32] <GaryvdM> Hi bialix
[20:32] <bialix> how's 0.16?
[20:33] <GaryvdM> Has not happend yet... :-(
[20:33] <bialix> do you want 0.15.1?
[20:33] <GaryvdM> Weekend was not productive, but I'm making some progress now.
[20:33] <bialix> btw about qcommit anf grouping
[20:34] <bialix> I found several really weird cases on weekends while I'm working on my project
[20:34] <bialix> e.g. remove many files and dir itself
[20:34] <bialix> or rename many files to some folder
[20:35] <GaryvdM> Ok  -I'll take a look
[20:35] <GaryvdM> also bug 471591
[20:35] <bialix> things like '/foo.txt => foo.txt' is not really looks fine
[20:35] <GaryvdM> Huh - I though I fixed that.
[20:35] <bialix> sometimes I just think folders does not works good
[20:35] <bialix> err
[20:36] <bialix> I mean sometimes group by folder is not really fine
[20:36] <bialix> and absence of any icon for deleted files/dirs is irritating
[20:37] <GaryvdM> bialix: It's easy to make a config option for it. Should I do that?
[20:37] <GaryvdM> (switching off trees)
[20:37] <bialix> group/no group?
[20:37] <GaryvdM> yes
[20:37] <bialix> maybe, but not tonight perhaps
[20:37] <GaryvdM> yes - other things I need to do
[20:37] <bialix> I don't want to slow down, just produce some feedback because you asking me in saturday
[20:38] <GaryvdM> Yes - I do want feedback.
[20:38] <GaryvdM> These things are so subjective.
[20:39] <GaryvdM> So you don't like the way moves show?
[20:40] <bialix> I can't say for sure
[20:40] <bialix> it's not very intuituve
[20:40] <bialix> sometimes it looks buggy
[20:41] <bialix> I'm not sure what it should be in ideal
[20:41] <bialix> plain list is more straightforward, though I understand some people may want folders
[20:45] <lifeless> moin
[20:45] <GaryvdM> bialix: If a file has moved, then I try show the path it was moved from relative to it the dir it has been moved to.
[20:50] <jam> morning lifeless
[20:50] <GaryvdM> bialix: like ../../foo => foo
[20:50] <bialix> :-/
[20:50] <bialix> IMO we need to show moves separately
[20:51] <GaryvdM> bialix: maybe "foo (moved from /bar/)
[20:51] <bialix> or show full pahs, e.g. foo.txt =>dir/foo.txt
[20:51] <GaryvdM> dir/
[20:51] <bialix> this first slash is really weird for windows-minded people
[20:53] <GaryvdM> ? I use to do "\Program File\xxx\bzr.exe" long before I ever heard of linux
[20:53] <bialix> maybe "foo (moved from bar/)
[20:54] <bialix> I understand your intent to highlight root of the tree
[20:54] <bialix> GaryvdM: I don't try to hurt you, sorry
[20:55] <GaryvdM> No problem - Just trying to work out what is the best for all.
[20:55] <bialix> heh
[20:56] <bialix> best for all :-)
[20:57] <GaryvdM> bialix: I've just pushed to trunk the rename and move functionality for qcommit and qbrowse
[20:57] <bialix> ok
[20:58] <bialix> my i-net is not very well tonight though
[20:58] <GaryvdM> and if you rename/move a file out side of bzr, you can select the missing, and the non-versioned, right click, and choise "Mark as moved", which does a mv --after :-)
[21:03] <corp186> I've got my own project in bzr, and I've currently got a populated debian directory
[21:04] <corp186> I'm thinking the debian dir would be a good candidate for splitting into a sub tree
[21:04] <corp186> I ran bzr upgrade (on karmic), and then ran bzr split debian
[21:04] <corp186> then I did bzr join --reference debian
[21:04] <corp186> I committed both . and debian
[21:04] <corp186> but now if I branch from the repo, I don't get the debian subtree
[21:04] <corp186> what am I doing wrong?
[21:06] <lifeless> corp186: at least for ubuntu, standard packaging practice is to use a single tree for the code & debian dir
[21:06] <lifeless> corp186: thats what the build-by-commit code will be looking for
[21:06] <corp186> lifeless: what about when after I submit it for ubuntu, some debian dev wants to maintain the package in debian?
[21:07] <lifeless> they've a bunch of options
[21:07] <lifeless> debian developers do it all sorts of different ways
[21:07] <lifeless> what I do recommend is that you have two branches:
[21:08] <lifeless> 'upstream' and 'packaging'
[21:08] <lifeless> the packaging branch adds the debian dir and other packaging metadata.
[21:08] <corp186> first, I'm upstream
[21:08] <corp186> so this isn't traditional in that sense
[21:08] <corp186> and second, I don't want to have to continually merge code between branches
[21:09] <corp186> if I have a subtree for the debian/ dir, I can keep all the code in one branch, and have separate debian branches for different distros/releases
[21:10] <lifeless> corp186: I'm upstream for a number of things too, and it is quite traditional.
[21:10] <corp186> lifeless: even so, isn't it a pain to be merging between different branches just for packaging?
[21:10] <lifeless> Debian policy frowns on upstreams having a debian dir in their releases
[21:11] <lifeless> and a nested branch will show up as a debian dir
[21:11] <lifeless> corp186: not at all, I package about 20 things from cron at the moment, using bzr-builder and a merge recipe.
[21:12] <corp186> lifeless: release tarballs would have the debian dir manually removed
[21:13] <corp186> and I'm not that interested in maintaining release scripts merging things between various branches
[21:13] <corp186> I guess, why wouldn't the debian dir be a good candidate for being a subtree?
[21:14] <corp186> I see that it may not be that bad to have separate branches, but subtree still seems like a better approach
[21:14] <bob2> then you'd still have a debian dir in the upstream branch
[21:15] <corp186> bob2: it's not against policy to have a debian dir in the repo
[21:15] <corp186> just not in the tarball releases
[21:17] <corp186> side-stepping details about packaging, can anyone help diagnose why bzr branch doesn't branch the subtree as well?
[21:21] <lifeless> corp186: nested trees aren't a supported feature yet
[21:22] <corp186> oh?
[21:22] <corp186> I didn't realize that
[21:22] <corp186> I figured since it's in there, it must work
[21:26] <corp186> lifeless: since you've had some experience with being upstream and doing packaging, do you do things as native packages, or do you somehow generate the diff.gz file with the debian directory?
[21:28] <lifeless> I generate the tarball from my trunk or release branch, which doesn't have the debian dir.
[21:28] <lifeless> I merge to my debian packaging branch & build debian packages from there, which uses the tarball and generates a regular package.
[21:29] <enatom> I dont understand
[21:29] <enatom> how would i setup bazaar for team collaboration ?
[21:30] <enatom> ?
[21:31] <GaryvdM> enatom: Bazaar can be use in many ways. Some of these are documented here: http://doc.bazaar-vcs.org/latest/en/user-guide/bazaar_workflows.html
[21:32] <enatom> do i have to install it on the internet, to get my team from overseas to work together
[21:32] <enatom> i dont get it
[21:32] <GaryvdM> enatom: I guess that you want to have "Decentralized with shared mainline"
[21:33] <GaryvdM> enatom: All you need is a shared location that any of the team can access.
[21:34] <GaryvdM> enatom: this can be via sftp, ftp, webdav, smb etc...
[21:34] <GaryvdM> enatom: If you can setup a bzr server, you will have better performance. But this is not a requirement.
[21:36] <GaryvdM> enatom: Do you have such a location?
[21:37] <enatom> GaryvdM, i have a hostgator account
[21:37] <enatom> would that be ok ?
[21:39] <GaryvdM> enatom: Not ideal, but it would work. You would need to give the password to each of the team.
[21:39] <enatom> ok, fair enough but i dont understand
[21:40] <enatom> what do i actually install on the server
[21:40] <enatom> like with phpmyadmin, its just a php script
[21:40] <enatom> but what the hell is bazaar, it aint a php script
[21:40] <enatom> is it?
[21:40] <enatom> btw if you havent noticed
[21:40] <enatom> iv never used a versioning control system
[21:40] <enatom> but would like to
[21:41] <GaryvdM> enatom: As I said, you don't have to set up a server. All you need is a shared folder, that you can all right to.
[21:41] <enatom> so would i need my computer on, so people can connect to my computer and work of it, with bazaar installed ?
[21:41] <corp186> enatom: it wouldn't hurt to read http://doc.bazaar-vcs.org/latest/en/user-guide/index.html through to get an idea of what bzr is, how to use it, and how to install it
[21:44] <GaryvdM> enatom: If you are working on a open source project, there are sites that will host it for you for free, e.g. http://launchpad.net/
[21:44] <enatom> and does launchpad use bzr ?
[21:44] <GaryvdM> Yes
[21:44] <enatom> oh cool
[21:45] <enatom> so is git or bzr better?
[21:45] <enatom> coz im hearing github is pretty big
[21:45] <corp186> enatom: I doubt you'll get an honest answer in #bzr
[21:45] <GaryvdM> bzr, but I'm biased...
[21:45] <corp186> I didn't mean dishonest, just biased
[21:45] <enatom> yeah but what exactly is the difference
[21:46] <GaryvdM> enatom: http://bazaar-vcs.org/BzrVsGit
[21:46] <enatom> gits way complex anyway
[21:46] <RAOF> github is big, but does a *lot* less than launchpad.
[21:46] <RAOF> Also, I think it's smaller than launchpad, too, so if you're going by size... ;)
[21:46] <GaryvdM> enatom: Oh - don't go to that page, it's out of date.
[21:47] <enatom> im using ubuntu btw
[21:47] <enatom> anyone heard of Nautilius SVN
[21:47] <enatom> and also , is there any Video tutorials or similar on using bazaar
[21:48] <phoenixz> Where can I find a list of the short status indicators that BZR might give me for bzr st -S ?
[21:49] <GaryvdM> enatom: There is a Nautilius bzr, but it's needs some work. I can recommend using bzr-explorer if you looking for a gui to easy you into things.
[21:49] <enatom> wait, doesnt BZR already have a GUI
[21:50] <enatom> wtf is BZR if it aint a GUI
[21:50] <enatom> someone here, should really do a Youtube Video tut
[21:50] <enatom> 137 people, would it hurt to do a quick video
[21:51] <enatom> to get beginners into things
[21:51] <enatom> like theres no videos on youtube or google
[21:52] <Peng> enatom: Bazaar started out as a command-line program, like many/most other VCSes.
[21:53] <enatom> yeah
[21:53] <enatom> but i mean does it have a Gui now ?
[21:53] <GaryvdM> Yes  - bzr-explorer
[21:53] <enatom> or do i need to isntall certain things like this nautilius thing or bzr explorer
[21:53] <enatom> so do i install both?
[21:53] <enatom> bzr and bzr-explorer?
[21:54] <GaryvdM> enatom: If you install bzr-explorer, it will automatically install bzr
[21:54] <GaryvdM> enatom: what version of ubuntu are you running?
[21:54] <enatom> karmic
[21:55] <enatom> so is the standalone bzr just a command line app?
[21:55] <GaryvdM> yes
[21:56] <enatom> ok, so iv gone into Ubuntu Software Centre, ... and iv typed in bzr
[21:56] <enatom> it has Bazar version control system
[21:56] <enatom> and olive bazaar branch manager
[21:56] <enatom> and it also has "diffuse merge tool"
[21:57] <GaryvdM> enatom: I just checked - bzr-explorer is not in karmic, but you can install it easily by adding the bzr ppa
[21:58] <enatom> what is a "ppa"
[21:58] <GaryvdM> package archive
[21:58] <enatom> ok whats the ppa for it
[21:59] <GaryvdM> Ah - just hold on a sec.
[22:01] <GaryvdM> enatom: This will install bzr-explorer in 2 steps - Form the command line run:
[22:01] <GaryvdM> sudo apt-get install qbzr
[22:01] <enatom> ok ill do that now, and how would i unistall it when i need to
[22:01] <GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:02] <enatom> ok
[22:02] <GaryvdM> sudo apt-get remove qbzr
[22:03] <GaryvdM> rm ~/.bazaar/plugins/explorer -r
[22:03] <GaryvdM> To uninstall ^^^^
[22:04] <GaryvdM> enatom: Someone is working on packing bzr-explorer this miniute, so it will be more easy in the future.
[22:04] <enatom> btw is this the explorer bzr homepage
[22:04] <GaryvdM> enatom: http://doc.bazaar-vcs.org/explorer/en/
[22:04] <enatom> by packing do you mean, available on the ubuntu software center ?
[22:04] <GaryvdM> Yes
[22:04] <GaryvdM> enatom: what do you hope to use bzr for?
[22:05] <enatom> i sware to god, if i learn how to use it, ill make the video tutorials for others like me to learn easier
[22:05] <enatom> php app
[22:05] <GaryvdM> Great
[22:05] <enatom> im developing a social networking app for graphic designers onlocalhost
[22:05] <enatom> why is what ill be doing with it, importnatn ?
[22:05] <enatom> important*
[22:06] <GaryvdM> Just intrested. bzr will work well for that.
[22:07] <enatom> oh ok
[22:07] <enatom> ill wait for the guy to package it
[22:07] <enatom> that way i can install it via software center, and which will be easier to remove if needed
[22:07] <enatom> i dont like typing stuff in terminal
[22:08] <enatom> wow
[22:08] <enatom> bazaar is made by canonical
[22:08] <enatom> :)
[22:12] <enatom> GaryvdM, has he packaged it yet?
[22:12] <GaryvdM> enatom: Not yet - It will take some time.
[22:12] <enatom> how long ?
[22:13] <enatom> kind of waiting for him, to do it, so i can install it
[22:14] <GaryvdM> https://bugs.launchpad.net/bugs/425507
[22:14] <GaryvdM> enatom: you can subscribe to that bug. It will notify you when it he is finished.
[22:15] <enatom> how long does things like tha ttake
[22:15] <enatom> 1 week ?
[22:15] <enatom> 2 hours?
[22:16] <enatom> also what is "signed revisions" ... in the features comarison table of all VCSs its says bazaar does "partial" signed revision
[22:17] <Peng> enatom: Signing them with GPG, so that you can be sure of their authenticity. Unfortunately, Bazaar doesn't support the "verifying" part yet...
[22:17] <enatom> whats GPG ?
[22:17] <GaryvdM> enatom: I would just install it with the command I gave you - It is quite a simple command.
[22:17] <enatom> sure GaryvdM
[22:17] <Peng> enatom: Google it.
[22:17] <enatom> i have, many abbreviatiosn come up
[22:18] <enatom> which GPG?
[22:18] <GaryvdM> http://en.wikipedia.org/wiki/GNU_Privacy_Guard
[22:19] <phoenixz> Where can I find a list of the short status indicators that BZR might give me for bzr st -S ?
[22:21] <enatom> GaryvdM, you gave me to commands to remove it, which where "bzr branch ip:bzr-explorer" and sudo apt-get remove qbzr
[22:22] <enatom> what does this do : bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:22] <GaryvdM> enatom: I gave you 2 commands to install it, and 2 command to remove it.
[22:22] <GaryvdM> To install:
[22:22] <GaryvdM> sudo apt-get install qbzr
[22:22] <enatom> ok i installed that
[22:22] <enatom> i did that now
[22:23] <GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:23] <enatom> i pressed y
[22:23] <enatom> it installed
[22:23] <enatom> now the termainal says "processing triggers for python-support..."
[22:23] <enatom> and its kind of stuck here
[22:25] <enatom> how to i run bzr-explorer ?
[22:28] <GaryvdM> enatom: run bzr explorer
[22:28] <enatom> yeah how, there is not icon in the applications menu, or the desktop
[22:30] <enatom> how do i run bzr explorer
[22:32] <GaryvdM> enatom: when the packing is done, it will create a icon for you.
[22:32] <GaryvdM> enatom: for now: step 3: create the icon your self
[22:33] <enatom> how?
[22:33] <GaryvdM> or run it form the command line.
[22:33] <enatom> where?
[22:33] <enatom> how?
[22:33] <enatom> whats the command?
[22:33] <GaryvdM> bzr explorer
[22:33] <enatom> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:33] <enatom> sorry i mean
[22:33] <enatom> enatom@enatom-laptop:~$ bzr explorer
[22:33] <enatom> bzr: ERROR: unknown command "explorer"
[22:33] <enatom> enatom@enatom-laptop:~$ ^C
[22:33] <enatom> enatom@enatom-laptop:~$
[22:34] <GaryvdM> enatom: did you run bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:34] <enatom> GaryvdM, i typed bzr explorer... and i got this :enatom@enatom-laptop:~$ bzr explorer
[22:34] <enatom> bzr: ERROR: unknown command "explorer"
[22:35] <enatom> no i didnt run that command line, that was just on my clipboard accidently pasted it here
[22:35] <enatom> but
[22:35] <enatom> enatom@enatom-laptop:~$ bzr explorer
[22:35] <enatom> bzr: ERROR: unknown command "explorer"
[22:35] <GaryvdM> enatom: you must run alos run this command to install bzr-explorer:
[22:35] <GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:35] <GaryvdM> *also
[22:36] <GaryvdM> enatom: that will get the source code for bzr-explorer using bzr
[22:36] <enatom> dude can you refer to a tutorial that i can follow to install this easeily
[22:36] <enatom> this is complicated
[22:37] <GaryvdM> entom: http://doc.bazaar-vcs.org/explorer/en/install-linux.html
[22:38] <GaryvdM> you allready have qbzr
[22:38] <GaryvdM> entom: now you need to get bzr-explorer
[22:38] <enatom> im getting this error: You have not informed bzr of your Launchpad ID, and you must do this to
[22:38] <enatom> write to Launchpad or access private data.  See "bzr help launchpad-login".
[22:39] <enatom> when i enter this bzr branch lp:bzr-explorer explorer
[22:39] <GaryvdM> enatom: you can ignore that for now
[22:39] <enatom> ok ignored
[22:39] <phoenixz> Where can I find a list of the short status indicators that BZR might give me for bzr st -S ?
[22:39] <enatom> its not working
[22:40] <enatom> enatom@enatom-laptop:~$ bzr branch lp:bzr-explorer explorer
[22:40] <enatom> You have not informed bzr of your Launchpad ID, and you must do this to
[22:40] <enatom> write to Launchpad or access private data.  See "bzr help launchpad-login".
[22:40] <enatom> Branched 311 revision(s).
[22:40] <enatom> enatom@enatom-laptop:~$ bzr explorer
[22:40] <enatom> bzr: ERROR: unknown command "explorer"
[22:40] <enatom> enatom@enatom-laptop:~$
[22:40] <GaryvdM> enatom: You did not read the instructions on http://doc.bazaar-vcs.org/explorer/en/install-linux.html
[22:40] <GaryvdM> "Then change to the directory holding your plugins (normally ~/.bazaar/plugins) and run"
[22:41] <GaryvdM> or just ran the commad I gave you:
[22:41] <GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:41] <enatom> ok
[22:42] <GaryvdM> phoenixz: the source code. I'll look for you now.
[22:42] <enatom> ok i did what you said, and its still not working GaryvdM
[22:42] <enatom> : enatom@enatom-laptop:~$ bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:42] <enatom> You have not informed bzr of your Launchpad ID, and you must do this to
[22:42] <enatom> write to Launchpad or access private data.  See "bzr help launchpad-login".
[22:42] <enatom> bzr: ERROR: Parent of "/home/enatom/.bazaar/plugins/explorer" does not exist.
[22:42] <enatom> enatom@enatom-laptop:~$ bzr explorer
[22:42] <enatom> bzr: ERROR: unknown command "explorer"
[22:43] <GaryvdM> enatom: run:
[22:43] <GaryvdM> mkdir ~/.bazaar/
[22:43] <phoenixz> GaryvdM: Im not too much for the sourcecode myself.. thanks! Maybe something that could be documented in a wiki somewhere?
[22:43] <GaryvdM> mkdir ~/.bazaar/plugins
[22:45] <enatom> ok did that and i just typed in : bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
[22:45] <enatom> after making the directories
[22:45] <enatom> its downloading something
[22:46] <enatom> ok so its done
[22:46] <enatom> basically
[22:46] <enatom> all i had to do was setup a plugins folder
[22:46] <enatom> its running now woop
[22:46] <enatom> the next hurdle : understanding
[22:46] <enatom> cheers GaryvdM
[22:46] <GaryvdM> \o/
[22:46] <enatom> just for clarification
[22:47] <enatom> what is qbzr and what is bzr-explorer ?
[22:47] <enatom> GaryvdM,
[22:48] <GaryvdM> phoenixz: not sure. Docs are here: http://doc.bazaar-vcs.org/latest/
[22:48] <phoenixz> GaryvdM: could you find anything in the sourcfe code?
[22:48] <GaryvdM> enatom: I'm one of the devs for qbzr
[22:48] <enatom> cool
[22:48] <enatom> but what is it ?
[22:48] <GaryvdM> phoenixz: yes in multiple places
[22:49] <GaryvdM> enatom: we started building a gui based on the Qt toolkit. We have many powerfull commands: bzr qlog, bzr qcommit, etc..
[22:50] <GaryvdM> enatom: We have not finished our main window.
[22:50] <GaryvdM> enatom: The starting point
[22:50] <enatom> so whats the difference between Bzr-eplorer and qbzr ?
[22:50] <GaryvdM> enatom: bzr-explorer is just a main window, that uses qbzr for all its other windows.
[22:51] <enatom> oh ok
[22:53] <phoenixz> GaryvdM: Guess I'll just have to figure this the hard way
[22:53] <GaryvdM> phoenixz: http://paste.ubuntu.com/307983/
[22:54] <phoenixz> GaryvdM: another question.. in SVN I could svn delete a file.. How do I do that with bzr? don't see no delete... bzr remove? bzr help remove shows more soemthing about stopping with tracking
[22:54] <Peng> phoenixz: Yes, bzr remove (aka rm).
[22:54] <phoenixz> okay
[22:56] <phoenixz> GaryvdM: thanks for the list!
[22:56] <GaryvdM> pleasure
[22:56] <GaryvdM> phoenixz: It was gather with a quick skim over the source. So I may have missed somthing...
[22:58] <phoenixz> GaryvdM: don't worry, I just want the most important one.. Working on an web based versioning interface that can work as front-end for SVN, SVK (strarted on that), GIT and bazaar.. Since I work with PHP and don't have a BZR library available, I just shell interface for the commands
[22:58] <phoenixz> not perfect, but it works
[22:58] <GaryvdM> I see
[22:59] <enatom> GaryvdM, if i want to add a new project to my localhost as the location what would i enter in "location" field ?
[23:00] <enatom> should i enter /var/www/ ?
[23:00] <GaryvdM> /var/www/my_project
[23:00] <spiv> Good morning.
[23:00] <GaryvdM> Hi spiv
[23:01] <enatom> and how would i access the files via a browser
[23:01] <enatom> would http://localhost get me to that folder
[23:01] <enatom> OMFG !!!!
[23:01] <enatom> I JUST GOT A GOOGLE WAVE INVITE
[23:01] <enatom> I JUST GOT A GOOGLE WAVE INVITE
[23:01] <GaryvdM> enatom: I think thats a question for #apache
[23:02] <RAOF> enatom: As I understand it, that means you now have 8 invites to give out.  I hereby stake my claim to one!
[23:02] <enatom> CALM DOWN PEOPLE, LET ME REGISTER MINE
[23:02] <enatom> I ONLY JUST RECIEVED THE EMAIL
[23:03] <enatom> OMFG
[23:04] <enatom> omfffffffffff gooood!
[23:04] <enatom> google wave
[23:08] <phoenixz> GaryvdM: bzr add file will always producs +N when bzr st -S ?
[23:08] <enatom> GaryvdM, Do you have a google wave account ?
[23:08] <enatom> I GOT 8 GOOGLE WAVE INVITES TO HAND OUT
[23:09] <GaryvdM> enatom: Nope - But I would not mind one. garyvdm@gmail.com
[23:09] <enatom> OK, ILL SEND YOU ONE NOW
[23:09] <GaryvdM> phoenixz: Yes
[23:09] <enatom> ANYONE ELSE ?
[23:09] <RAOF> Throw one at raof@ubuntu.com, please :)
[23:09] <GaryvdM> enatom: thanks
[23:10] <enatom> ROAF
[23:10] <enatom> ROAD
[23:10] <enatom> ROAF
[23:10] <RAOF> r. a. o. f. ;)
[23:10] <enatom> RAOF HOW EVER THE HELL YOU SPELL YOUR NAME
[23:10] <enatom> uhm where abouts do you live ?
[23:10] <RAOF> .au
[23:10] <enatom> GaryvdM, where abouts do you live ?
[23:11] <enatom> raof, you have to suck my balls abit, coz it aint fair on GaryvdM , his helped me quite abit today
[23:11] <enatom> and you aint done shit
[23:11] <enatom> so... do something
[23:11] <RAOF> Um...
[23:12] <RAOF> I can point you at GNOME Do?
[23:12] <enatom> point me?
[23:12] <RAOF> apturl://gnome-do
[23:12] <enatom> whats the do ?
[23:12] <enatom> what does that do ?*
[23:12] <GaryvdM> What ever you tell it to :-)
[23:13] <RAOF> It's a bit like quicksilver on Mac.  It's an... "action interface", I guess.
[23:13] <GaryvdM> enatom: He has a @ubuntu.com address, which mean he is a ubuntu memeber, which mean he allready rocks!
[23:13] <enatom> GaryvdM, is RAOF an important person, like does he develope things like you ?
[23:13] <enatom> or is he just a bum, who hangs around here
[23:14] <RAOF> If you *haven't* tried gnome-do, I'd suggest giving it a whirl.  It's awesome, and I don't only say that because I'm the maintainer :)
[23:14] <GaryvdM> enatom: He is a ubuntu member which means he is a hardcore dude
[23:14] <fullermd> Hm?  Somebody call for a bum?
[23:14] <enatom> no we dont need bums
[23:14] <GaryvdM> enatom: You have to do lots of work to become a ubuntu member!
[23:14] <fullermd> Oh.
[23:14] <enatom> oh ok
[23:14]  * fullermd slumps back to his cardboard box.
[23:14] <enatom> well ill send you guys one
[23:15] <enatom> raof and GaryvdM  will be getting an invite soon
[23:15] <RAOF> Thanks.  And try out gnome-do.  It's awesome!
[23:15] <enatom> yeah i already have gnome do
[23:15] <enatom> using it now, pretty good actually ¬_¬
[23:15] <enatom> nice work
[23:15] <phoenixz> fullermd: Just a question... SVN has Add, modified and "added and modified"... does BZR has that last one too?
[23:16] <phoenixz> RAOF: gnome-do? whazda?
[23:16] <fullermd> phoenixz: Well, I don't know what svn means by that.  It doesn't seem to make sense; if it's added, there's no previous version to say 'modified' against.
[23:17] <RAOF> phoenixz: Heh.  Install the package, give it a whirl :)
[23:17] <phoenixz> fullermd: ah, now I remember.. added and modified is where the previos revision was a copy.. SVN supports copy, BZR does not..  if I would svn copy a file and then modify it, it would be added and modified..
[23:18] <GaryvdM> phoenixz: you can have modified and renamed in bzr though
[23:18] <phoenixz> GaryvdM: ah, thanks, another one for my list..
[23:19] <enatom> GaryvdM, and RAOF , apparently i have to wait a couple of days till i hand out the wave invites, since im a new user i can only go through the "Preview" period
[23:20] <enatom> its pretty shit actually
[23:20] <enatom> i cant "wave" to anyone else, since no one i know has a google wave account
[23:20] <GaryvdM> enatom: I see. They did the same thing with gmail.
[23:20] <enatom> yeah and also... you get another email
[23:20] <enatom> enatomx@googleWAVE.com
[23:20] <phoenixz> oh THAT sucks..
[23:21] <enatom> yeah, well ill send you a blank email, to keep you in my contacts when till i can actually send the invites out
[23:30] <phoenixz> by the way, may I add that I really hope BZR will be supporting file copies? This was really a rather nice option of SVN / SVK, where all file history was preserved...
[23:33] <spiv> phoenixz: we'd like to add that, but it's not at that top of the todo list yet.
[23:45] <enatom> i cant write to my WWW folder,