[00:13] <poolie> hello igc
[00:13] <igc> hi poolie
[00:27] <snot> I'm working on a linux distributed based on ubuntu. I wanna do some version control... is bzr the right tool for such a task?
[00:28] <Peng_> You could look at how other Debian- and Ubuntu-based distros manage everything.
[00:30] <snot> Peng_: yeah, but I was just hoping to make a shortcut here and either eliminate bzr or use it straight. the dude who was in chage of this before me didnt do any versioning
[00:30] <snot> s/straight;2/right away/
[00:30] <snot> -;2
[00:30] <snot> :)
[00:30] <zsquareplusc> snot: ubuntu likes bzr, you can can even have you .deb packages built automatically on lauchpad.net
[00:31] <snot> zsquareplusc: yeah, this is all very new to me. and it's not opensource so AFAIK launchpad isnt an option
[00:31] <zsquareplusc> yes, the server side is not yet open
[00:32] <snot> the distro I'm developing isnt open source :)
[00:32] <snot> (sadly)
[00:32] <snot> sort of it actually is...
[00:32] <zsquareplusc> is it really worth doing your own, compared to just have your custom package repository?
[00:32] <snot> parts of it isnt shared so I dont belive launchpad is an option... and beside I just wanted to know if I could manage an entire distribution with bzr'
[00:33] <snot> zsquareplusc: it's a must... it runs on this "thin" box
[00:33] <snot> a little box with only a flash harddisk and very limited cpu
[00:34] <zsquareplusc> a big part of a distro are packages or at least the core source of a package from upstream. they will use what they want anyway.
[00:34]  * zsquareplusc runs debian on a NSLU2 with 1GB flash disk :-)
[00:34] <snot> indeed... we have our own repository setup as well and I'm very much encuraged to make the mopst changes with packages as well
[00:35] <snot> mmmm... debian :)
[00:44] <snot> zsquareplusc: damn... now I want to get a Linksys NSLU2
[00:44] <snot> I have too little time :)
[00:45] <zsquareplusc> snot: it doesn't take too much time. its an official platform fore debian. so you have all the stuff you know from larger boxes ;-)  but i think we're a bit OT here..
[00:46] <snot> zsquareplusc: indeed, I easily get side tracked :)
[00:47] <snot> I'll go see what I can find at the ubuntu hp, tahnks for your time, take care :)
[00:47] <zsquareplusc> so you want to trac a few package sources. i've not yet used bzr for large things, but i got the impression that is should be quick on larger trees too
[00:49] <snot> that as well and I got that setup already. I did bzr init, bzr add and bzr ci -m 'inti... bla bla as we spoke
[00:49] <snot> it does not seem fast but it seems to... well work
[00:50] <snot> I just wanna version whatever changes I make to etc the users home folder and such
[00:50] <snot> I think I'll just give it a try and see how this goes
[01:02] <snot> in case anyone cares, I can inform that it didnt go... it's way way too slow
[01:03] <snot> I'm handling about 120000 files and bzr st took about 8 mins to execute... I'll have to find another way
[01:04] <snot> hmm... the second time I executed bzr st it went quite a lot faster
[01:05] <snot> http://nopaste.org/p/aJ4kY0sWg
[01:07] <jam> lrrrr
[01:07] <igc> hi jam
[01:07] <jam> sorry cleaning the keyboard :)
[01:07] <igc> 'lrrrr' ???
[01:07] <jam> hi, btw
[01:12] <jam> snot: that URL gives me a 404
[01:12] <jam> I would guess the first time is computing the sha sum for all files
[01:12] <fullermd> igc: Obviously, his yox was already clean   :p
[01:12] <jam> and from there on it should be just doing a stat
[01:12] <jam> Though with 120k files
[01:12] <jam> it is possible to have the OS take a long time to page in the inodes
[01:12] <jam> after say a restart
[01:13] <igc> fulermd: obviously :-)
[01:14] <jam> snot: also, what version of bzr?
[01:14] <snot> jam: yeah, sorry, I deleted it... had a few lines I didnt felt like sharing anyway. but the second time around it only took about 19 secs
[01:14] <jam> I thought the code had been updated in 1.8 so that it would update the sha values during commit
[01:15] <snot> Bazaar (bzr) 1.6.1
[01:15] <jam> snot: ok, so some of that should be better with newer versions of bzr
[01:16] <snot> so version 1.8 might be worth a try
[01:16] <snot> true, damn now I'm lagging also
[02:21] <igc> poolie: if you get a chance, can you have a look at my 1.12-preview formats patch?
[02:21] <igc> (the filtered-views patch will be quite a bit smaller once that's landed)
[02:34] <poolie> igc, i can
[03:03] <ia> hello, everybody. could you tell me please, in which articles or docs i can found some internal information about bazaar? for example, practically any user of git knows, that it uses sha1 for store objects, how it save content, etc. Does exists some docs about this for bzr? i just would like to know internal concept of bzr and how it works.
[03:06] <nosklo> ia, source code is pretty comprehensive
[03:07] <jelmer> ia: see also doc/developers/ in the source tarball
[03:08] <igc> ia: see http://doc.bazaar-vcs.org/bzr.dev/developers/index.html
[03:41] <igc> thanks poolie
[03:50] <markh> igc: hi ian - some advice on docstring folding in your review if you don't mind:
[03:50] <markh> eg: >> +    def get_canonical_inventory_paths(self, paths):
[03:50] <markh> >> +        """Returns a list with each item the first path that
[03:50] <markh> >> +        case-insensitively matches the specified input paths.
[03:50] <markh> Its ok to make that a single line, which would end at char 115?  I can't see how to obviously shorten it...
[03:51] <igc> mrkh: hmmm
[03:51] <markh> actually, I could shorten that to make it the "singular" version, and just make the "plural" version's docstring refer to the shorter one...
[03:52] <igc> markh: sounds sensible
[03:52] <igc> going over 80 is ok but 115 is a bit long
[03:53] <markh> so to be clear, while the docstring can go over 80 chars, there is a kinda fuzzy "sensible" upper limit probably ~100?
[03:53] <markh> yeah
[04:08] <poolie> hello markh
[04:08] <markh> hi poolie
[04:17] <poolie> abentley, if you're here, BB is apparently stuck...
[04:19]  * igc bbl
[04:39] <Leefmc> Question: Bzr has taken a branch and saved a push location that i do not want (originally i pushed to "temp_branch", and now it is always using that push branch as the default), how can i remove/overwrite this saved location?
[04:40] <bob2> push --rememver somewhereelse
[04:40] <bob2> or edit .bzr/branch.conf (iirc)
[04:43] <Leefmc> k thanks
[05:28] <Peng_> That'd be .bzr/branch/branch.conf.
[05:28] <Peng_> It's easier to use "bzr push --remember" unless you want to delete the saved location completely.
[06:11] <abentley> poolie: fixed
[16:04] <ia> hello. could you tell me please, does bzr has any color support (or some plugin, maybe) for output of basics commands and actions? (something like [colors] section in .gitconfig)
[16:14] <LarstiQ> ia: there is color diff in bzrtools at least
[16:36] <IslandUsurper> Interesting. I have a shared repository that contains a checkout of a project on a different server. I then made a lightweight checkout from the repo. Apparently local commits from the lightweight checkout work just like I expect them to. Uncommitting didn't, because I had to update and then revert the pending merge, but that's ok.
[17:23] <ia> in 'bzr viz' there is 'summary' column; how get this information from command line?
[17:26] <ia> oh, via 'bzr log' - in summary shows just commit messages. :-)
[17:56] <cr3> I have a general revision control question: lets say I branch my project for a particular release, 0.2 for example, does that imply the trunk should now be on 0.3 or can it still progress on 0.2 releases?
[17:57] <beuno> cr3, so, trunk can be "trunk", and not a version
[17:57] <beuno> and you only assign version numbers to release branches
[17:57] <beuno> but there's probable a dozen different ways of working
[17:58] <cr3> beuno: but when I make changes to the changelog under the trunk...
[17:58] <beuno> cr3, personally, I keep the top section of the changelog as "development"
[17:59] <beuno> and only rename that when it's spun off to a release
[18:17] <MattCampbell> I see that no Windows installer is available yet for bzr 1.10.  Is this just because the bzr team needs someone with Windows to build one?
[18:26] <Emmanuel> Hi , i would like to know if anyone would be aware of any recent benchmark ( as suggested on Bazaar web site ) of bzr,hg,git ... ?
[21:49] <kfogel> I've got a patch ready to suggest for merging.  Couple of questions: the change is actually two revisions (3910 and 3911 in branch http://bazaar.launchpad.net/~kfogel/bzr/306394-status-tolerate-nonexistent).  Can I post a "[MERGE]" request just pointing at that branch, or should I package up the changes as a "bundle" and attach that to the mail?
[21:49] <kfogel> (I guess that's my main question.)
[21:51] <bob2> bundles are more common these days
[21:51] <beuno> kfogel, a bundle is the only way to file merge requests in bzr
[21:51] <kfogel> beuno: thanks
[21:51] <beuno> make sure you do a send against a recent version of bzr.dev so it applies cleanly  :)
[21:51] <bob2> you sure?
[21:51] <bob2> HACKING needs an update then
[21:52] <beuno> bob2, where?
[21:53] <beuno> it says generate a bundle
[21:53] <beuno> AFAICS
[21:53] <bob2> "If you'd like to propose a change, please post to the
[21:53] <bob2> bazaar@lists.canonical.com list with a bundle, patch, or link to a
[21:53] <fullermd> Merge directives don't have to contain the bundled revs; they can point at a branch.
[21:53] <bob2> branch"
[21:53] <jam> beuno: you can send a branch, or you can send a patch, or you can send a lot of things with [MERGE] in the header, and bundle buggy will track them.
[21:53] <fullermd> (I don't know how BB deals with that, but...)
[21:53] <jam> We just highly recommend sending a bundle
[21:53] <jam> because it is far easier for us to review it.
[21:54] <beuno> oh, I didn't know BB was so smart...
[21:54] <jam> Anything with [MERGE] gets tracked
[21:54] <jam> even if there aren't any attachments
[21:54] <beuno> right, but not the diff and such
[21:54] <jam> right
[21:54] <jam> which is why we *prefer* getting a bundle sent :)
[21:54] <beuno> got it  :)
[22:00] <kfogel> beuno: just some sanity checking.  I have a branch locally (call it LB) that was created by 'bzr branch lp:~kfogel/bzr/306394-status-tolerate-nonexistent LB'.  Then I committed my two changes in LB (3910 and 3911), and did 'bzr push' to send them up to the parent.  Now in my LB directory, I just need to do 'bzr send -o fix-306394.patch' and that will create the right bundle?  (Because I did that, but it's hard for me to tell if the resultant
[22:00] <kfogel> bundle contains the right stuff...)
[22:00] <kfogel> FWIW, I only did the 'bzr push'es so people could review the changes; I understand that pushing them up was not necessary to make the bundle in LB.
[22:00] <jam> kfogel: to be *positive* you can do "bzr send -o fix...  http://bazaar-vcs.org/bzr/bzr.dev"
[22:01] <kfogel> jam: hmmm.  I'll do 'bzr help send' now to grok that command :-).
[22:01] <jam> That will ensure the target branch is set correctly, and that the bundle applies to the target branch
[22:01] <jam> kfogel: you are setting "SUBMIT_BRANCH" which is the branch that you want the bundle applied to
[22:02] <kfogel> jam: ENLIGHTENMENT.
[22:02] <kfogel> Thank you.
[22:03] <jam> kfogel: happy to help. There are other ways, like using a local mirror with the public_branch set, but that is the most straightforward
[22:03] <kfogel> jam: one thing I'm slowly getting used to is that there are usually 3 to 5 different ways to do anything.
[22:03] <kfogel> :-)
[22:04] <kfogel> That's a sign of a flexible tool, I think, but also means a steep learning curve.
[22:04] <LarstiQ> indeed.
[22:04] <igc> kfogel: send needs a bit more love in the User Guide I think
[22:05] <LarstiQ> the wealth of workflow posibilities can be rather overwhelming.
[22:05] <igc> specially when to comes to patches on top of patches and stuff like that
[22:05] <kfogel> LarstiQ: exactly
[22:05] <kfogel> igc: mmm, yes
[22:05] <kfogel> wouldn't hurt
[22:08] <kfogel> jam: Fascinating!  When I included a SUBMIT_BRANCH in the 'bzr send' command this time, my bundle looks completely different: it includes a human-readable diff now, and the encoded bundle portion at the end is much larger than it was the first time (when I did not use a SUBMIT_BRANCH).
[22:09] <kfogel> jam: One thing that's too bad, though, is that my log messages are not included in human-readable form in this new bundle.
[22:13] <kfogel> Question: some [MERGE] requests attach the bundle, others just include it inline in the body of the mail.
[22:13] <kfogel> Is one way better than the other?  http://bazaar-vcs.org/BzrGivingBack says to attach.
[22:15]  * LarstiQ attaches.
[22:16] <LarstiQ> kfogel: just make sure the content encoding isn't set to something so mail readers won't show it as text
[22:16] <LarstiQ> since reviewing from within the mail client is nice
[22:16]  * LarstiQ forgets which clients mail patches like that
[22:17] <LarstiQ> mutt plays nice :)
[22:17] <kfogel> LarstiQ: oh, I can make sure it's text/plain or text/x-patch or whatever.  But the easiest thing is just to include it inline, as some people seem to do.  I can't tell whether that's "officially approved" though.
[22:17] <kfogel> :-)
[22:19] <LarstiQ> kfogel: applying the patch would then a bit more work I guess, I have no strong opinion on it though.
[22:19] <LarstiQ> kfogel: so I'd say, try it and see if you get away with it ;)
[22:20] <fullermd> Wait...  there are people who use something other than mutt?
[22:20]  * kfogel growls "Gnus"
[22:22] <fullermd> That sounds like a nasty throat infection you've got there...
[22:24] <jam> kfogel: Without setting the SUBMIT_BRANCH it defaults to the parent, IIRC. Which would mean submitting a bundle that doesn't include any changes, because your parent == your local branch
[22:24] <jam> Which is why you get a better result the other way
[22:25] <jam> We don't include the log messages by default, though BundleBuggy is capable of extracting them
[22:25] <jam> that said, it often doesn't matter, as we'd rather have a nice human summary
[22:25] <jam> which isn't always present in the log messages.
[22:25] <jam> especially since we'd like explanations, etc.
[22:25] <jam> I would recommend attaching the bundle
[22:25] <kfogel> jam: it's sent
[22:25] <jam> because it makes it easier *for me* to download and apply it
[22:26] <jam> I think it is easier for BB as well, but I'm not sure.
[22:27] <kfogel> jam: I guess "log message" can mean the individual log msg associated with each commit in the bundle, and then (in theory?) a summary message explaining the bundle itself.  Which I should have passed with -m or -F to 'bzr send', right?  (I didn't.)
[22:29] <jam> I believe "-m" just sets the subject
[22:29] <kfogel> ah
[22:30] <jam> so it has no effect her
[22:30] <jam> here
[22:30] <kfogel> jam: that explains why bzr send does not take -F, but bzr commit does.
[22:30] <jam> Older bundle formats actually had a summary message it would display
[22:30] <jam> but we didn't really use it
[22:33] <kfogel> jam: so there's no way for one to attach such a summary to a bundle, as a kind of log message?  Instead one just includes it in the mail where one is submitting the bundle?
[22:34] <jam> kfogel: yep
[22:37] <jam> kfogel: Your "trivial typo fix" email doesn't seem to actually have a bundle
[22:37] <jam> Just a *description* of the attachment it wanted to send
[22:37] <jam> <#part type="text/x-diff" filename="~/src/bzr/bzr.dev/fix-typo.patch"
[22:37] <kfogel> ???
[22:38] <kfogel> jam: mail client error.  That's weird.  I'll resend.
[22:38] <kfogel> thanks