[00:00] <dev001> fullermd: There's a fc13 bug, https://bugzilla.redhat.com/show_bug.cgi?id=611405#c5, that seems to suggest that tho the warning exists, the problem has been negated.  hm ...
[00:00] <ubot5> bugzilla.redhat.com bug 611405 in python-paramiko "RandomPool_DeprecationWarning in fc13" [Medium,New]
[00:01] <fullermd> As far as I know (which isn't too far, so don't put much weight on it), there's not actually a _problem_ that it's broken.  But it took about 2 minutes for me to get sick of the crap in my terminal all the time...
[00:02] <dev001> fullermd: all of 2 minutes?  patient guy!
[00:02] <fullermd> Oh, yes.  I'm widely known as a calm, patient, tolerant kind of guy.
[00:03] <dev001> heh
[00:05] <dev001> fullermd: i'll post @ https://launchpad.net/paramiko.  maybe that'll get some attention.  thx.
[00:12] <dev001> fullermd fyi -> https://bugs.launchpad.net/paramiko/+bug/271791.  already there ...
[00:12] <ubot5> Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 4, heat: 20)" [Medium,Triaged]
[00:15] <fullermd> Mightn't hurt to pile yourself onto that and up the count of people hitting it.
[00:18] <dev001> fullermd: piled.
[00:55] <mtaylor> james_w: fascinating ... related to something else I was just trying building source packages on a lucid box ... and there I'm getting :
[00:55] <mtaylor> tar: tests/r/information_schema.result: Cannot open: File exists
[00:55] <mtaylor> tar: Exiting with failure status due to previous errors
[00:55] <mtaylor> dpkg-source: error: tar --no-same-owner --no-same-permissions --anchored --no-wildcards -xkf - gave error exit status 2
[00:55] <james_w> mtaylor: yeah, that's what I get too. Did you see the dpkg bug that I filed?
[00:56] <mtaylor> james_w: oh - no. I should go look
[00:58] <mtaylor> there it is
[00:59] <mtaylor> james_w: so essentially I'm just screwed for now :)
[01:02] <james_w> mtaylor: yeah, not a nice way to fix it
[01:02] <james_w> mtaylor: you can get your packages building with an ugly solution
=== Ursinha is now known as Ursinha-afk
[03:54] <FryGuy-> is there anything I can do in bazaar about my horrible line-ending situation on windows? We're currently using sourcesafe, but I've just been using bazaar and merging the changes manually (and I wrote a script to push bazaar -> ss). This works great for the windows c++ code i'm using
[03:55] <FryGuy-> However, I'm doing another project now, with a different tool. We recently switched from a unix version of a tool, to a windows version of a tool, and it's been generating mostly CRLF, but some LF in everything it saves out
[03:55] <FryGuy-> Everything in sourcesafe gets set to LF (from what I can tell), but the tool writes out the files with a mix.
[03:56] <FryGuy-> When I try to commit my changes to bzr, it rightly says there's a bunch of changes. Is there anything I can do, short of dos2unix everything manually before checking in, to change this?
[03:58] <FryGuy-> and the tool gets seriously confused if I just change everything to CRLF (so I can't just change everything at once, and use the tool normally after that)
[04:02] <lifeless> you can probably use a filter
[04:04] <FryGuy-> would that help for things like qdiff?
[04:10] <lifeless> probably
[07:48] <vila> hi all !
[07:53] <AfC> ! lla ih
[07:53] <AfC> (we're upside down here)
[07:57] <methods2> can i edit a log message ?
[07:57] <AfC> methods2: short answer, no (which sucks, even if there is a good reason for it)
[07:58] <AfC> methods2: medium answer: if its your commit, and recent (ie, -1) then `bzr uncommit` & then re- `bzr commit`
[07:58] <AfC> methods2: otherwise, no
[07:59] <AfC> methods2: long answer, you _can_ use the evil rebase plugin, but assuming this will only change YOUR [copies of] revisions and not any revisions out in thew wild, causing history divergence, and the end result of not getting rid of the message you want to change
[07:59] <AfC> so,
[07:59] <AfC> methods2: no
[07:59] <methods2> lmao
[07:59] <methods2> ok
[08:00] <methods2> satic it is
[08:00] <AfC> {shrug} it's all a consequence of immutable revisions and the (good) idea of wanting to preserve history for future merging purposes.
[08:00] <methods2> :]
[08:00] <methods2> satic was the typo in my log message
[08:00] <AfC> yeah, well
[08:00] <AfC> you'll get over t
[08:01] <methods2> already am
[08:01] <methods2> but a part of me never will
[08:01] <methods2> lol
[08:01]  * AfC still hasn't
[08:01] <AfC> :)
[08:03] <vila> Well, as far as concepts are involved, immutable is more important than preserving history. Once you've published your revision you want to make sure that everybody is referring to the same thing via the revision-id...
[08:04] <vila> Regarding history, your log message *is* the one you typed when the revision was created, any change to that *should* be tracked.
[08:04] <vila> Now, when people ask about this feature, they are right.
[08:04] <vila> There should be a way to edit such details, but given the constraint above, it's not a trivial problem
[08:06] <vila> The solution is certainly around making rebase/rewrite easier to use for such scenarios ensuring that only a minimal amount of data need to be distributed so propagate this kind of change...
[08:06] <vila> s/so prop.../to prop.../
[08:07] <vila> i.e. editing log should be a first-class citizen operation
[08:08] <AfC> vila: sure
[08:08] <AfC> vila: we've talked about it; the problem is that every time we raise it
[08:09] <AfC> the whole discussion gets torpedoed because someone turns it into the generic history editing problem,
[08:09] <AfC> (including texts, parent/child relationships, metadata, and tags etc)
[08:10] <AfC> rather than just keeping it constrained to "I want to commit a revision (sic) that magically alters [overlays] a previous log message"
[08:10] <AfC> which really ought to be do-able.
[08:10] <AfC> whereas the general case is indeed nasty.
[08:12] <vila> Well, it is doable to day as you pointed out above. With some limitations that... can only be addressed by more-or-less adressing the general case. Managing a "simple" overlay will quickly become more complex once people (rightfully) ask: we both fixed the bogus log entry, which version should be kept ?
[08:14] <vila> AfC: We should *at* least make your "medium answer" easier to use for recent (> 1) commits
[08:14] <AfC> vila: which actually (much to my personal disgust) brought me [after 4 years of going to lots of trouble to convince people to write good log messages] to realizing that I probably would have been better off with a ChangeLog file after all.
[08:14] <vila> AfC: hehe, at least the ChangeLog is versioned and as such address the problem :)
[08:15] <AfC> vila: yeah... it sure would be nice for something to do that in 1 step... cutting and pasting the commit message as (quite unhelpfully) formatted & indented by uncommit is a pain in the ass
[08:16] <AfC> so I still write good(-ish) commit messages, but my enthusiasm has waned substantially.
[08:16] <AfC> anyway
[08:16] <AfC> there are bigger problems facing the human race
[08:16] <vila> Well, I do typos....
[08:16] <AfC> like,
[08:16] <AfC> vi vs emacs
[08:18] <vila> ... but I still consider commit messages as capturing the intent at commit time. I.e. best effort. Errors occur. Tracing fixes is good.
[08:18] <vila> So, I kind of like the fact that my typos get tracked :)
[08:19] <AfC> vila: yeah, but that's not the point, and we both know it; in most projects, commit messages ARE considered the ChangeLog entry, and those projects build their release notes right out of history. bzr is just not good at serving that need.
[08:20] <AfC> anyway
[08:20] <AfC> nothing new
[08:20] <AfC> tough problem
[08:21] <AfC> there are bigger problems facing the human race
[08:21] <AfC> like,
[08:21] <AfC> why is there cat hair in my keyboard?
[08:21] <AfC> like,
[08:21] <AfC> why do I have to move to another cafe to get a coffee?
[08:21] <AfC> (See ya :))
[08:22] <vila> :)
[08:56] <knittl> vila: you recommended using bzr ppa?
[09:00] <vila> knittl: yes
[09:00] <vila> any problem ?
[09:00] <knittl> yeah. there's no package for maverick
[09:01] <vila> 8-/
[09:03] <vila> maxb: Is there any reason for not building packages for maverick in the bzr ppa ?
[09:04] <bialix> who I can ask about lp:bzr-website?
[09:05] <vila> knittl: try https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa , it seems to contain the right stuff
[09:06] <knittl> okay
[09:06] <vila> maxb: is it just that you copy the packages for bzr-beta-ppa to bzr-ppa *except* for maverick ?
[09:08] <vila> maxb: hmm, or am I mixing bzr-beta-ppa with the 'proposed' one you mentioned (which I can't find on lp by the way) ?
[09:09] <vila> ha, found it https://edge.launchpad.net/~bzr/+archive/proposed
[09:10]  * bialix waves at vila and says bonjour
[09:10] <vila> bialix: hey sacha !
[09:10] <knittl> so i should use proposed? but there are only two packages python-testtools and subunit
[09:10] <vila> privet
[09:11] <bialix> poolie has already eoled, hasn't he?
[09:11] <vila> knittl: huh, I see the same packages in proposed/maverick than in bzr-ppa/lucid
[09:11] <bialix> sorry
[09:11] <vila> bialix: eowed on tuesday I think ;)
[09:12] <knittl> i don't xD
[09:12] <vila> knittl: argh
[09:13] <bialix> vila: oh, so he's enjoying vacation?
[09:13] <vila> knittl: I'm at a loss here, I didn't closely follow what happen there, we need to wait for GaryVdm or maxb to pop up
[09:13] <vila> bialix: AIUI, yes
[09:13] <knittl> ok. i'll be here
[09:14] <bialix> vila: ok
[09:21] <bialix> vila: as I can see from log now only poolie maintains the bzr-website. I guess I need to wait for his review for may changes
[09:22] <bialix> s/may/my/
[09:27] <vila> bialix: where is your mp ?
[09:27] <bialix> right now filing the first (trivial)
[09:27] <bialix> https://code.launchpad.net/~bialix/bzr-website/mailman-icon/+merge/33878
[09:28] <bialix> then want to update info on released versions because it's out of date
[09:31] <vila> bialix: cool, thanks for caring about that
[09:31] <bialix> vila: do you know either bazaar.canonical.com using lp:bzr-website to update regularly or not?
[09:33] <vila> bialix: I think it is
[09:33] <bialix> hmmm
[09:33] <vila> bialix: if not, it should :)
[09:35] <bialix> it seems my patch is not quite right. there is build.py script which (I think) ought to update the index.html. maybe the site updated regularly using build.py? strange, while there is generated index.html then? questions, questions, questions. I need to wait for poolie
[09:36] <vila> bialix: yeah, things like that should be documented in this branch
[09:37] <bialix> vila: there is readme but it seems incomplete now
[09:38] <vila> bialix: yup, my point exactly
[09:39] <zoyd> hi
[09:41] <zoyd> what's the 'svn update' equivalent in bzr; i have an incomplete 'bzr branch' checked-out
[09:44] <AfC> zoyd: depends on what hole you've got yourself stuck in, but
[09:44] <AfC> zoyd:
[09:44] <AfC> $ bzr pull URL
[09:44] <AfC> in that branch will probably get you where you want
[09:44] <AfC> on the other hand, if you did branch and it never finished,
[09:44] <AfC> I think you have to start again
[09:44] <AfC> [there's a bug open for that, I believe]
[09:44]  * zoyd tries
[09:45] <zoyd> hmm, appears like i'll have to start over
[09:53] <AfC> zoyd: if you're on a really dodgy network link
[09:53] <AfC> zoyd: then try
[09:53] <AfC> $ bzr init dir
[09:53] <AfC> $ cd dir
[09:53] <AfC> $ bzr pull -r 1 URL
[09:53] <AfC> $ bzr pull -r 10 URL
[09:53] <AfC> $ bzr pull -r 20 URL
[09:53] <AfC> ...
[09:54] <AfC> that'll get you (safe) incremental pull,
[09:55] <AfC> for whatever Δ you find sustainable
[09:55] <vila> you can even omit URL once the first one succeeds (or use --remember URL if/when needed)
[09:55] <AfC> vila: yes, of course you're right
[09:55] <vila> AfC: damn bzr fighting copy/paste :)
[09:56] <bialix> vila: what is landing procedure for lp:bzr-website branch? can you cancel merging of my first patch?
[09:56] <zoyd> and that will resume the download then?
[09:56] <vila> bialix: no idea, I tried to pqm it to see, and cancelling is... hard. Don't worry, I'll take the blame for it :)
[09:57] <AfC> zoyd: no, it'll pull whatever you tell it to.
[09:57] <AfC> zoyd: if you're on revno 10
[09:57] <AfC> and you say pull to revno 20, well, you'll get 11,12..20
[10:01] <vila> knock knock ? Am I still here ? (I've got a lot of network failures all at once, trying to find a pattern...)
[10:01]  * zoyd checks if there's a way to know what revision you're at .. "nnnnkB  nkB/s - Fetching revisions:Inserting stream" is very sparse
[10:01] <vila> zoyd: where are you pulling from ?
[10:01] <zoyd> lp
[10:02] <AfC> zoyd: no
[10:04] <zoyd> then, why not do a 'bzr pull -r <latest-revision>'?
[10:07] <vila> zoyd: lp seems down for me right now...
[10:07] <vila> zoyd: or at least experimenting transient failures, you've been warned ;)
[10:08] <zoyd> lp is very slow here
[10:08] <vila> zoyd: in generall or just now ?
[10:08] <zoyd> :)
[10:08] <vila> funny typo :)
[10:08] <vila> I can't ping it right now :(
[10:09] <vila> can't ping google.com either...
[10:09] <zoyd> bzr branch is reporting a '11059kB 1kB/s ..' but a 'du -sh .bzr' shows 4.1MB only
[10:10] <vila> zoyd: interesting... anything in .bzr.log ?
[10:12] <zoyd> hhm no
[10:13] <vila> ha, my dns servers are back...
[10:13] <zoyd> ok, now 'du -sh' updated to 6.3MB
[10:13] <vila> so is lp of course
[10:13] <zoyd> weird, the buffer wasn't written even after a 'sync'
[10:15] <zoyd> seems it dumps to disk after large intervals
[10:16] <zoyd> 14MB downloaded, but 7.5MB on disk. funny.
[10:17] <zoyd> no wonder the thing can't resume :)
[10:21]  * maxb pop us
[10:21] <maxb> *up
[10:21] <maxb> vila: Hi. The situation is simply that no one really took the decision to support maverick fully yet
[10:22] <maxb> Also, many of the packages are already up to date in maverick itself
[10:23] <vila> knittl: ^
[10:23] <vila> maxb: thanks !
[10:23] <knittl> ok. so maverick is as recent/outdated as the ppa
[10:23] <knittl> :D
[10:24] <vila> :)
[10:24] <vila> knittl: I guess my initial "use stable version" recommendation doesn't really apply to maverick ;-)
[10:25] <zoyd> btw, is a web-directory sufficient to publish a repository/branch, or does one need to open any ports?
[10:25] <maxb> knittl: what specifically is missing for maverick?
[10:25] <vila> zoyd: for read-access, http is good enough
[10:26] <vila> maxb: almost everytinh since only testtools and subunit are available ;)
[10:26] <maxb> erh?
[10:27] <maxb> Oh, well the PPA is naturally always to be used in conjuction with maverick itself, so there's no point in uploading to the PPA until there's something newer than maverick itself to upload
[10:27] <vila> maxb: https://edge.launchpad.net/~bzr/+archive/proposed?field.series_filter=maverick
[10:27] <knittl> well, i'll have to live with it ;)
[10:27] <maxb> live with what?
[10:28] <maxb> You can still install everything you need from maverick itself, AFAIK
[10:28] <knittl> not having 'nightly' builds
[10:28] <maxb> bah
[10:28] <maxb> If you want nightly, run from a branch :-)
[10:29] <vila> maxb: I recommended against that yesterday :) But I didn't realize knittl was running maverick nor what exactly he wanted
[10:30] <vila> knittl: also note that there is a work in progress to make python-2.7 the default in maverick while bzr 27 support may not be perfect yet
[10:30] <maxb> hmm. I'd love to continue this conversation, but I'm still in bed, and need to be in the office in a meeting in 30 minutes, so bye!
[10:30] <vila> maxb: hehe
[10:30] <knittl> have fun xD
[10:31] <vila> maxb: and thanks for popping up for the clarifications !
[10:31] <knittl> yeah. thanks :)
[10:33] <vila> knittl: by the way, maxb is fully right, maverick is pretty much as the same level than bzr-ppa/lucid so I don't think you're losing anything here
[10:33] <vila> knittl: what exactly to you need ? bzr ? plugins (which ones) ?
[10:34] <knittl> i'm comparing bzr+git+hg (again xD) and it would be good if i could compare the most recent versions
[10:35] <vila> knittl: then bzr 2.2.0 sounds good enough if maverick is the reference platform
[10:35] <knittl> git and hg is compiled from source
[10:35] <knittl> :P
[10:35] <vila> knittl: with different settings than the binary provided by maverick ?
[10:36] <knittl> no, but more recent
[10:36] <vila> I see
[10:37] <vila> knittl: so back to yesterday discussions, 'make' + 'python setup.py' ought to work, bugs welcome if not
[10:37] <knittl> yeah, bzr-svn complained ;)
[10:38] <vila> well, that's exactly the kind of problem I warned about :-)
[10:38] <knittl> i know
[10:39] <knittl> good ol’ plugin system, everybody brings in in discussions ^^
[10:40]  * jelmer wakes up
[10:40] <jelmer> knittl: I'm not following, what did bzr-svn complain about?
[10:40] <vila> knittl: yup and the ppas is the answer for people that don't want broken setups :)
[10:40] <knittl> version mismatch
[10:43] <vila> jelmer: hi :)
[10:53] <cbz> jelmer - i'm having a problem with certificates, pycurl appears to be choking on a wildcarded ssl certificate
[10:53] <jelmer> cbz: ah, ok - that wouldn't be related to bzr-svn though, it's an issue with pycurl in general.
[10:53] <cbz> jelmer: interestingly it seems to work on windows but break on linux
[10:55] <jelmer> cbz: Do you have pycurl installed on windows?
[10:56] <cbz> i guess it's using whatever is bundled in with the windows bzr installer
[11:05] <zoyd> oh, this checkout won't get done
=== zyga is now known as zyga-lunch
=== zyga is now known as zyga-3g
[13:17] <bialix> vila: as I can see that patch is not landed, do you have any error message from pqm?
[13:18] <vila> bialix: yes, I got one, I'm not allowed to land. I tried to tell you but you had just disconnected, thank for poking (one less item in my stack :-)
[13:19] <bialix> vila: yep, i-net suddenly died for me. ok, thank you. I'll wait for poolie's review
[13:21] <vila> bialix: I had transient DNS faillures too, very unusual
=== Ursinha-afk is now known as Ursinha
[14:07] <rubbs> Ok, I know this question is probably asked billions of times, but is there a status on SVN externals type functionality? Being able to checkout/branch within another branches working tree? It's not that important for us, but the answer may influence which workflow i encourage (read force) my devs to use.
[14:10] <jelmer> rubbs, the feature you're looking for is called nested trees
[14:11] <rubbs> ah. I do some doc lookups. Thank you.
[14:11] <jelmer> rubbs, it's not implemented yet, though I've seen Martin say that it's one of the next things on his list.
[14:11] <vila> ghaa, what are the names of the plugins that offer an approximation of nested trees... my memory is failing right now :(
[14:12] <vila> scm-proj ?
[14:12] <rubbs> jelmer: ah, thanks. I think at this point I'll have to assume it won't be done in time.
[14:12] <jelmer> vila: bzr-externals, bzr-scmproj, config-manager
[14:12] <rubbs> We're looking to migrate in Oct/Nov time fraim
[14:12] <bialix> bzr-externals
[14:12] <rubbs> I'll check out bzr externals
[14:13] <vila> jelmer, bialix: thanks :-}
[14:20] <vila> how on earth can a python deprecation warning be emitted randomly....
[14:20] <vila> ...but persistently on babune...
[14:20] <rubbs> Well, first you must sacrifice a chicken, then throw salt in for directions... I'll just direct you to a black magic expert.
[14:21] <rubbs> ;)
[14:21] <vila> I do the chicken thing every morning, but tell me more about the salt one...
[14:54] <vadi2> bzr-fastimport mentions to do "front-end | bzr fast-import -", but I don't have front-end. Where does it come from?
[14:58] <maxb> vadi2: front-end is a placeholder term for "thing that exports from your source vcs". Which specific vcs are you exporting from?
[14:58] <vadi2> From git
[14:59] <vadi2> Can you suggest the command I should try? I'm not sure
[15:01] <vadi2> Ah, there is bzr fast-export-from
[15:01] <maxb> Yes, you could use that, or you could use git fast-export directly
[15:02] <montywi> hi!
[15:02] <montywi> anyone that can help with getting rid of a .THIS file that shows up in 'bzr gcommit' but doesn't exist on disk?
[15:03] <montywi> This happend after doing a merge where someone had deleted files changed in my tree, which I wanted to keep.  I copied the name.c.THIS file to name.c and did 'bzr resolved name.c' but now name.c.THIS still shows up in bzr gcommit
[15:04] <GaryvdM> montywi: What does bzr status say?
[15:08] <vadi2> How can I set a working tree for the bzr branch?
[15:09] <maxb> vadi2: bzr checkout (bzr co)
[15:10] <vadi2> Hrm. But I just created this branch and imported stuff from git into it. What do I check out?
[15:11] <GaryvdM> vadi2: Maybe you allready have a working tree. What does bzr info say?
[15:12] <vadi2> $ bzr info
[15:12] <vadi2> Shared repository with trees (format: 2a)
[15:12] <vadi2> Location:
[15:12] <vadi2>   shared repository: .
[15:17] <vadi2> It seems doing init again and re-importing worked, it's pushing happily now.
[15:22] <niemeyer> Hey there!
[15:22] <niemeyer> I'm trying to decide between looms and pipelines.. can anyone provide some insight into the difference between these?
[15:23] <niemeyer> Are either of these obsolete?
[15:23] <niemeyer> s/Are/Is
[15:23] <vadi2> Er, that went pretty terrible. All it did was duplicate my folders + files, with one set being what I want, and another set being taken off some other random branch...
[15:24] <vadi2> Is it possible to repair? All I did was import and then push to a new branch on launchpad
[15:33] <niemeyer> Found a useful thread about it
[15:33] <niemeyer> http://markmail.org/message/imo4jop3gcm3lgr4#query:+page:1+mid:sjjtebxtdh3th43m+state:results
[15:33] <vila> niemeyer: they are both maintained. I personally prefer looms but it seems to be a matter of taste
[15:33] <niemeyer> In case some else cares
[15:33] <niemeyer> vila: Cool.. I'm just finding it a bit hard to find anything comparing the two, and why someone might prefer one over the other
[15:35] <vila> niemeyer: both of them have some rough edges, my preference is mainly because I prefer to handle *one* loom rather than a set of branches. On the other hand some commands fly better with multiple branches than multiple threads. It heavily depends on your workflow...
[15:36] <niemeyer> vila: I don't have any workflow to handle the situation where I want to split work across several branches/threads/whatever to make it easier to review/merge/understand
[15:36] <niemeyer> vila: (besides a totally manual one)
[15:37] <niemeyer> vila: So I'm really trying to learn which workflow to adopt :)
[15:37] <niemeyer> vila: Do you know of any blog posts/documents which compare the workflows?
[15:37] <vila> "Looms on the other hand currently have no parent pointers per-thread. " is one such example. I.e. each pipe has its own branch.conf where loom has only one
[15:37] <niemeyer> vila: I see, that's interesting
[15:38] <vila> splitting will work for both and even the resulting graph should be pretty similar (but since I don't use pipelines I'm not definitive on this)
[15:38] <vila> s/graph/revision graph/
[15:39] <vila> 'switch' works for both too, it becomes important once you start pulling in your lowest thread (or first pipe).
[15:40] <vila> Generally your first thread is your upstream project and you then define successive layers that you want to propose/review independently
[15:41] <vila> so at commit time you decide where you want to commit. At various times you merge the lower threads into the upper ones (using 'up-threa' or 'up-thread <thread>')
[15:42] <vila> In any case you more or less need to know which threads haven't been merged up to the top
=== oubiwann is now known as oubiwann-away
=== oubiwann-away is now known as oubiwann
=== Ursinha is now known as Ursinha-lunch
[17:23] <smoser> Hey all, I've got a question.  I'm wanting to create a bzr repository with results of test runs.
[17:23] <smoser> the log output is around 10M size .
[17:24] <smoser> is there any benefit to checking in a output-testrun.tar.gz rather than output-testrun/*.
[17:24] <dash> no, that's probably worse
[17:24] <smoser> If bzr is doing intelligent things in the repository, it seems like doing so may not buy me anything other than local storage (on checkouts)
[17:24] <smoser> which i really dont care about.
[17:25] <smoser> dash, thats what i was thinking.  My eperience with git is that it is very good at keeping .git to a small size.
[17:26] <smoser> bzr does similar things ?
=== beuno is now known as beuno-lunch
[17:32] <rubbs> smoser: yes, it does do similar things
[17:33] <rubbs> IIRC bzr will even pack better than gz
[17:33] <smoser> so there is no good reason to compress the contents (other than a larger local checkout)
[17:34] <rubbs> with bzr, no, it's best to avoid checking in binaries as much as possible.
[17:34] <smoser> right.
[17:34] <rubbs> so if it's a log, your better off keeping it plain text and bzr will do the right thing.
[17:35] <smoser> so my only question, then woudl be if it is possible to check out only a given directory (or set of files) from a bzr repository
[17:36] <smoser> ie, not do a full checkout, so that i could avoid the local space if I had to, just to see files
[17:36] <smoser> (obviously I can just rm -Rf <other files> afterward, but wonder if i can only check out the onees i want)
[17:37] <rubbs> IIRC there is no way to check out only a subset of the branch at this point
[17:37] <rubbs> not sure if it's planned or not either
[17:41] <smoser> fair enough. In this case, I wouldn't mind having the whole repo (.bzr dir), but would only want to check out certain files at a given revision.
[17:41] <smoser> its probably not a common use case
[17:45] <rubbs> I think it's asked about every once and a while, but like I said I'm not sure about the planning or status of said feature.
=== Ursinha-lunch is now known as Ursinha
=== beuno-lunch is now known as beuno
=== r0bby_ is now known as robbyoconnor
[19:08] <niemeyer> lifeless: Sorry, I guess this is a better channel for that kind of question
[19:08] <niemeyer> Btw, just found out about bzr merge -i
[19:08] <lifeless> its nice :)
[19:08] <niemeyer> Does it actually bring the commit message/etc?
[19:08] <niemeyer> Or is it just a helper to cherrypick without history?
[19:09] <lifeless> its a helper to do partial merges
[19:09] <lifeless> so it has all the limitations of a cherrypick
[19:10] <lifeless> as/when cherrypicking is improved, it will improve
[19:10] <maxb> lifeless: Hi, do you possibly have time to read my email https://lists.ubuntu.com/archives/bazaar/2010q3/069878.html, and if you agree, activate a new ~bzr/builddeps PPA so I can work on that over the weekend? (New PPA requires team admin)
[19:11] <lifeless> maxb: I can certainly read it, but I'd want poolie to ack it - has he ? I say this because I'm a bit out of the loop on bzr right now
[19:12] <maxb> Fair enough. Is poolie travelling or something, do you know? I've not seen him on IRC for a while
[19:12] <lifeless> yah
[19:13] <lifeless> he may pop up today/tomorrow
[19:13] <niemeyer> lifeless: Ok, so no history merging..
[19:13] <niemeyer> (right now)
[19:14] <lifeless> yeah
[19:20]  * niemeyer starts a major manual branch split
[20:27] <ScottK> Does bzr support doing partial branches/checkouts, or is it required to branch/checkout the entire repository?
[20:28] <mkanat> ScottK: Whole branch.
[20:28] <mkanat> ScottK: But you could do a lightweight checkout, too.
[20:33] <ScottK> That makes checkouts faster, but doesn't really address my use case.
[20:34] <mkanat> ScottK: Okay. What's your use case?
[20:35] <ScottK> I've got a project were we'd like to have stuff in a bzr repo that only a few people actually need and it's a large/painful chunk of third party code.
[20:36] <ScottK> It'd be nice if there was some way the people who didn't need that could manage to not pull it down when they branch/checkout.
[20:36] <mkanat> ScottK: Hmm. Eventually, subtrees will solve that.
[20:37] <ScottK> I sold bzr on this project on the basis of svn people can use it like svn and git people can use it ~like git (dvcs anyway) and this is the one place we've run into where that's not quite true.
[20:37] <mkanat> Yeah.
[20:38] <mkanat> ScottK: Somebody else in this channel might have a better idea of how to solve your problem.
[20:38] <ScottK> OK.  Thanks.
[20:38] <mkanat> ScottK: If it's really only a few people that need it, though, you could just put it into a separate branch.
[20:38] <mkanat> But then they would have to know to branch that branch into the right place when checking out.
[20:39] <ScottK> Yep.  That's part of the problem, needing to know that and to know in advance what might need to be treated this way.
[20:39]  * mkanat nods.
[20:39] <mkanat> ScottK: I'm guessing this is an enormous amount of data?
[20:39] <ScottK> mkanat: Not in terms of say gigabytes, but compared to the rest of the tree, yes.
[20:42] <mkanat> Okay.
[20:46] <hno> Packaging question. Is there any good arguments why to package bzr-gtk + olive-gtk if also packaging qbzr + bzr-explorer?
[21:03] <ScottK> Some people have an odd affinity for gtk?
[21:15] <hno> ScottK: No idea. What triggered the question is that bzr-gtk just got dropped from Fedora due to not having an active Fedora maintainer.
[21:15] <dobey> what was the command to dump a revision's data in raw form?
[21:16] <ScottK> hno: I'm a fan of desktop environments that start with K, so you're unlikely to get good arguments from me.
[21:18] <hno> ScottK: I actuallly run Gnome, but never use bzr gui tools or even care what desktop environment i run in.. happy to run qt/kde apps under gnome when I need them.
[21:18] <rubbs> ScottK: not that it helps with checking out a subtree, but you may be able to hide some of that data with views.
[21:18] <maxb> Well, I do like bzr-gtk's integration into the libnotify notifications, even though I use qbzr for most stuff
[21:18] <dobey> bzr-gtk has some nice stuff
[21:18]  * hno maintains bzr for Fedora.
[21:18] <ScottK> The couple of times I've wanted a gui for bzr, I used qbzr.
[21:19] <dobey> ScottK: that's only because it's not called kbzr ;)
[21:23] <hno> dobey: can you specify what nice stuff you think bzr-gtk adds?
[21:26] <dobey> gdiff
[21:27] <james_w> the back button in gannotate
[21:33] <hno> dobey: The diff in bzr explorer looks nicer to me. But gdiff is a lot easier to run from the command line.
[21:34] <dobey> what's bzr explorer?
[21:34] <hno> james_w: Indeed. That back button is very powerful
[21:34] <hno> dobey: qbzr after it got split in qbzr qt bindings and bzr-explorer GUI application.
[21:35] <hno> same split is taking place for bzr-gtk btw.
[21:35] <mgz> hno: is gdiff from the commandline significantly different from qdiff?
[21:36] <dobey> i don't know. i don't really use bzr-gtk stuff any more
[21:36] <hno> mgz: Thanks. qdiff is equivalent to gdiff, and looks visually much nicer.
[21:39] <dobey> i don't think bzr-gtk has really been developed much in the 'look nice' department
[21:44] <mgz> s/bzr-//
[21:44] <hno> james_w: qannotate provides a full history view you can navigate. In some ways similar to the back button in gannotate, but not quite the same. Plus qannotate apparently have trouble showing revision numbers properly.. (cuts initial digits on revisions >999 for me)
[21:45] <hno> so +1 for gannotate there.
[21:45] <dobey> mgz: if you want to bash some toolkit, do it in #anti-$toolkit or something please
[21:45] <dobey> :)
[21:45] <mgz> :)
[21:49] <hno> The differences between qdiff and gdiff is not just pure visual candy. qdiff also shows a more detailed diff showing at character level what changed.
[21:50] <mgz> qbzr devs would probably be interested in you filing bugs on where you think they could improve qannotate hno.
[21:51] <mgz> might also be true for gdiff, but I'm not really sure there are any active devs.
[21:52] <hno> mgz: I know. Goal for tonight is to find if there is any reason for me to get bzr-gtk to resurrected in Fedora, or if it should be let to die until further notice.
[22:02] <hno> I thinks I will let it die in piece for now. Can easily get resurrected should someone feel sufficiently strongly that it's needed, and I guess we will know when Fedora14 ships without bzr-gtk.
[22:43] <Walex> Is there a largish (Linux kernel sized) publically accessible Bazaar2 repo that I may clone to play around with?
[22:43] <Walex> Either that or something not quite as large but still significant. Lots of small files (like headers, sources) in particular.
[23:45] <hno> Walex: Far from linux kernel size, but I find that the squid repository is sufficiently large to expose many sizing issues in bzr operations.. pretty sure there is larger examples around.
[23:50] <mkanat> Walex: I think people use the emacs repo usually for that.