[00:05] <poolie> hello naitandu
[00:05] <igc> jkakar: the latest User Guide might help. It's currently online here: http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html. The section on Reusing a checkout explains some ways around the "switching locations configured in tools/databases" issue. The very first chapter puts the case for Bazaar as well.
[00:06] <naitandu> where can i get current information on bazaar for Visual Studio? The bazaar-site did only mention it as part of GSoC ?!
[00:08] <jkakar> igc: Thanks!  I'll check that out.
[00:09] <igc> jkakak: no problem. Also see http://bazaar-vcs.org/BzrWhy, particularly my paper on Why DVCS matters.
[00:58] <Peng> Hahaha. Reconcile over sftp took 230 minutes. I think it takes 20 locally, and it might take up to an hour to upload; don't remember.
[00:58] <Peng> (This was of bzr.dev. Well, close it it.)
[00:58] <Peng> Augh!
[00:58] <Peng> I have a copy of bzr.dev there too that I could reconcile.
[01:00] <poolie> hm
[01:03] <Peng> Also, there were 12-13,000 SFTP.readv()s in .bzr.log. :)
[01:39] <jml> igc: thanks
[01:40] <igc> jml: can you tweak that and submit to pqm or do I need to?
[01:41] <jml> igc: I've tweaked it, but you need to submit it to PQM.
[01:41] <igc> ok
[01:45] <ubotu> New bug: #174055 in bzr "can't run bzr info while dirstate is locked" [Low,Confirmed] https://launchpad.net/bugs/174055
[01:55] <ubotu> New bug: #174059 in bzr "test__create_temp_file_with_commit_template_in_unicode_dir fails if test platform doesn't allow unicode filenames" [High,Confirmed] https://launchpad.net/bugs/174059
[02:07]  * igc food
[02:12] <jml> igc: I've found the cause of the selftest failures: I wasn't unregistered my test transport.
[02:25] <bac> spiv: ping
[02:28] <spiv> bac: pong
[02:30] <lifeless> jkakar: 'bzr switch'
[02:54] <xjjk> hi... I think I'm going in circles trying to find something
[02:55] <xjjk> I want to use the latest bzr packages from bazaar-vcs.org's Ubuntu repositories, but bzr-svn is not included... are there up-to-date packages of that somewhere as well?
[03:02] <igc> jml: cool. Can you submit an updated patch for me to land?
[03:03] <jml> igc: yep. in a sec
[03:05] <jml> sent
[03:22] <igc> hi WeirdArms
[03:22] <WeirdArms> Hey
[03:22] <WeirdArms> Had a talk with our QA lead
[03:22] <WeirdArms> he's not interested in Bazaar
[03:23] <igc> did he say why?
[03:23] <WeirdArms> was just wondering if you had suggestion for two-way tools to cross import
[03:23] <WeirdArms> pretty much what we discussed
[03:23] <WeirdArms> so badly burnt on baz
[03:23] <WeirdArms> and far enough into choosing Hg to reconsider
[03:25] <WeirdArms> So I'd like to try it out
[03:25] <igc> two-way tools are a two-edged sword as you know
[03:25] <WeirdArms> but would need to be able to import out central repo into Hg and then push Bzr comments back to Hg
[03:25] <WeirdArms> yeah
[03:26] <igc> we do have bzr-hg but I suspect it's more about migration that full two-way interaction
[03:26] <WeirdArms> ok
[03:26] <igc> by migration, I include local mirroring
[03:30] <fullermd> Last I heard (which was long ago), it could at least pull from local hg branches, but wouldn't work with remote.
[03:30] <fullermd> I don't think it's had much love.
[03:38] <fullermd> igc: Was that checkout/bound mail reasonably clear (or at least, definitively muddy)?
[03:38] <igc> fullermd: it was great thanks
[03:39] <igc> I like your explanation but I wonder whether most people think that deeply about it?
[03:40] <fullermd> Well, most people probably have lives instead   ;>
[03:40] <igc> :-)
[03:40] <igc> it does matter though ...
[03:40] <fullermd> I tend to /think/ that most of the people using those capabilities are wanting checkouts, but there's probably a core of people wanting bound branches.
[03:41] <igc> particularly when implementing switch on heavy checkouts
[03:41] <fullermd> (but those impressions aren't based on anything real concrete)
[03:41] <igc> I think switch ought to be the same as "unbind; pull --overwrite URL;bind URL" ...
[03:41] <fullermd> It's stuck me as one of our low-level (in the sense of 'minor', not 'architecturally fundamental') stress points for a while.
[03:42] <igc> i.e. to make the local cache a true reflection of the remote branch
[03:42]  * fullermd nods.
[03:42] <igc> there's an argument for switch meaning "bind + update" though
[03:42] <fullermd> I think you can probably mostly ignore the schism as far as 'switch' goes; people who really want 'bound' probably wouldn't use it.
[03:42] <igc> i.e. be safe and don't throw away any local changes
[03:43] <fullermd> Is there a difference?  I know 'pull' merges WT changes...   never tried --overwrite.
[03:43] <fullermd> I guess it might.  You'd probably want '--overwrite-branch-but-merge-wt'.
[03:43] <igc> it's necessary if the branches have diverged
[03:44] <fullermd> It gets a little sticky if you have --local commits; do you want to throw them away?  Can you even tell, without contacting the upstream (which may have gone away)
[03:47] <igc> not sure if I can tell
[03:49] <mlh_> tee hee Is this naughty of me: http://svn.haxx.se/users/archive-2007-12/0065.shtml
[03:49] <mlh_> "Watch out though - you may like them (bzr or git) so much you might not want to
[03:49] <mlh_> go back to svn.
[03:50] <mlh_> It's weird though, time and time again I see questions that would be suitable addressed by using a DVCS.
[03:51] <Peng> What would be weird is if someone *did* want to go back to svn...
[03:51] <dash> so, um... I typed "bzr add" by mistake and added a bunch of files I didn't want to
[03:51] <mlh_> And yet the SVN bigwigs say they don't see the demand
[03:51] <dash> will "bzr added|xargs bzr revert" get me back to where I was? :)
[03:52] <fullermd> I'd use "bzr rm --keep" instead of revert, but I think the result would be the same.
[03:53] <dash> oh, what's the difference
[03:54] <fullermd> I'm not sure there is one.
[03:54] <fullermd> Just 'feels' clearer to me what I'm doing.
[03:54] <dash> errrrm hm
[03:55] <dash> 'bzr added' does not print anything, despite 'bzr status' showing a pile of added files
[03:55] <fullermd> added might go down from $CWD instead of the tree root...
[03:56] <dash> weird
[03:58] <dash> well, that worked
[04:06] <dash> thanks!
[05:57] <Peng> How important do you think it really is to back up before running reconcile? I mean, is it just in case something goes *really* wrong, where reconcile would traceback? If "bzr log -r -1" works and check seems fine, is it okay to delete the backups?
[06:08] <spiv> Peng: if check passes, then I'd be pretty comfortable with the reconcile.
[06:09] <spiv> Peng: I guess it depends on how much you trust our code vs. how much it's costing you to keep a .bzr.backup directory lying around :)
[06:13] <Peng> spiv: Well, I'm on a very small partition, so the cost is > nothing.
[06:14] <spiv> Peng: In that case, I'd just delete the backup.
[06:14] <spiv> Peng: If bzr check is happy, then the branch is pretty healthy.
[06:14] <Peng> But on the other hand, all of my backups are just another 60 or 70 MB.
[06:15] <spiv> Peng: if you can "bzr check" a branch, you know that every revision is intact.
[06:15] <Peng> Also, I still have a few ".bzr.knits.tar.7z" files from when I converted to packs, so I guess the clutter doesn't bother me much, either.
[06:18] <Peng> Okay.
[06:18] <Peng> Well, I'll keep 'em around anyway.
[06:19] <Peng> Anyway, thanks
[06:19]  * Peng wanders off.
[07:09] <Peng> bug 165080
[07:09] <ubotu> Launchpad bug 165080 in bzr "Quick Start Guide doesn't document "bzr send"" [Medium,Fix committed] https://launchpad.net/bugs/165080
[07:09] <Peng> Thanks ubotu.
[07:09] <Peng> Sorry for the interruption. Now back to your silence.
[07:17]  * mlh_ finishes counting out 4'13" of silence, sends royalties to John Cage
[07:20] <AfC> Silence is underrated.
[07:24] <mlh> AfC: hypocrite!  :-)
[07:27] <Peng> Oh no, the foam slip my DS came in is slightly rotn.
[07:27] <Peng> rotn?
[07:27] <Peng> torn.
[07:28]  * Peng wanders off.
[08:25] <Peng> Erk.
[08:25] <Odd_Bloke> Peng: Erk?
[08:25] <Peng> I ran 'bzr remove-tree' to save some disk space, and it didn't delete a bunch of directories due to .pyc files, so then I tried to run 'bzr clean-tree', but it wouldn't run because there was no working tree!
[08:25] <Peng> So now I ran 'bzr co' and I'm going to try clean-tree again.
[08:40] <ubotu> New bug: #174105 in bzr "move glossary from web site into user docs" [Medium,Confirmed] https://launchpad.net/bugs/174105
[09:06] <lifeless> igc: pull overwrite clobbers local changes doesn't it? switch shouldn't do that ;).
[09:58] <terdmonk> hi, im new to bzr and am trying to see if it fits RCS model my team is looking for
[09:58]  * terdmonk is trying to understand where branches fit in
[09:58] <terdmonk> if i start a project called foo-1.0
[09:58] <terdmonk> and also start project foo-2.0
[09:58] <terdmonk> should both projects belong under a foo branch?
[09:59] <terdmonk> or is foo-1.0 and foo-2.0 put under their own branches?
[09:59] <terdmonk> and if so, how will a developer be able to check out the latest branch without knowing what version is the latest?
[10:00] <terdmonk> i could see how a developer could checkout the latest branch if i had foo/foo-{1,2}.0 as a branch
[10:00] <terdmonk> could someone kindly shed some light? :)
[10:01] <Odd_Bloke> terdmonk: What you would tend to do is have your main development taking place in one branch, normally called 'trunk'.  When time for a release comes, you branch from 'trunk' to 'foo-n.n' and any release-specific stuff goes into 'foo-n.n' while development can continue in 'trunk'.
[10:01] <Odd_Bloke> So unless a developer is specifically working on a release branch, they should always be referencing 'trunk'.
[10:01] <terdmonk> Odd_Bloke, ah yes. i see :)
[10:03] <terdmonk> so my directory structure would be project-foo/{trunk,foo-1.0,foo-2.0}, where trunk, foo-1.0 and foo-2.0 would be their own branches?
[10:03] <Odd_Bloke> Something along those lines, yeah.
[10:04] <terdmonk> Odd_Bloke, excellent. thanks mate
[10:04]  * terdmonk continues digging at bzr doco
[10:04] <Odd_Bloke> You would want 'project-foo' to be a shared repository (look at 'init-repo'), so that any shared history from the branches will only be stored once.
[10:06] <terdmonk> ahh, init and init-repo do different things :)
[10:06] <terdmonk> gotcha
[10:06] <Odd_Bloke> Yeah, 'init' creates a branch, 'init-repo' creates a shared repository.
[10:07] <terdmonk> and a shared repository is meant for hosting branches?
[10:08] <Odd_Bloke> terdmonk: All branches have a repository, where revisions are stored.  Having a shared repository simply reduces duplication.
[10:10]  * terdmonk nods
[10:11] <Odd_Bloke> So they should be used wherever more than one branch with the same history will be stored.
[10:11] <Odd_Bloke> They also make using branches for features and bug fixes a lot easier.
[10:14] <Peng> terdmonk: FWIW, I like it better when the main branch of a project is called "foo" or "foo-dev" or something rather than just "trunk". That way if I just want to get a copy of that branch and no others, the directory has a useful name.
[10:15] <Odd_Bloke> +1 on that.  bzr uses 'bzr.dev'.
[10:15] <Odd_Bloke> s/trunk/foo.dev/ throughout. :)
[10:15] <lifeless> you can also have foo - a repo and foo/foo-1.0
[10:15] <lifeless> a branch at the root which is trunk :)
[10:19] <Peng> lifeless: Bleh, that would be confusing.
[10:34] <Lo-lan-do> Hi all
[10:34] <Lo-lan-do> Quick question: is bzr-git more-or-less usable?
[10:35] <Lo-lan-do> Also, would you happen to know whether there's a git-bzr floating around somewhere?
[10:36] <Odd_Bloke> Lo-lan-do: Toward the less ATM, I believe.  Enough for bzrk, the Launchpad page claims.
[10:37] <Lo-lan-do> Yeah, but that page doesn't seem very recent, hence my quest for someone alive
[10:37] <Odd_Bloke> Lo-lan-do: I believe the 'refactoring' branch is still the most recent work that has been done...
[10:38] <Odd_Bloke> jam would know more.
[10:38] <Odd_Bloke> (implicit ping :p)
[10:38] <Lo-lan-do> Yeah, I'm told jelmer also has an interest in it since Samba apparently moves to git
[11:31] <ubotu> New bug: #174127 in bzr "Requesting a --names-only option for bzr diff" [Undecided,New] https://launchpad.net/bugs/174127
[12:42] <blauwal_> Hi, I've got a question about bazaar workflows. Assume we have an existing workspace and want to work on a new feature branch: With Subversion I would do: svn copy REMOTE:SOURCE-URL REMOTE:DEST-URL; svn switch REMOTE:DEST-URL; with git I would do git branch feature; git update feature. With bzr I guess I would have a shared repository with trees and would do an bzr branch foo feature inside the repository. This would still require to copy the whole w
[12:42] <blauwal_> orking tree, albeit without the history. Is there any way around it?
[12:44] <Peng> Not at this time, and I don't think they plan one.
[12:45] <blauwal_> Peng: Thanks for your answer. It's a pitty though, copying 1.8 GB of sources is a pain in the ... :)
[12:47] <ddaa> is there a way to bypass the confirmation prompts of "bzr break-lock"?
[12:48] <Peng> Is there a --force?
[12:48] <ddaa> nope
[12:48] <abentley> then I guess you can't use the --force.
[12:49] <ddaa> and "< /dev/null" causes it to busy-loop printing the confirmation message
[12:49] <Peng> Oh.
[12:49] <Peng> I recently found out uncommit has a --force. Why not break-lock? Too dangerous?
[12:50] <abentley> Breaking a lock that is actually being used can cause data corruption.
[12:50] <ddaa> abentley: I figure you know that I realize that :)
[12:51] <abentley> ddaa: Yes.  I was answering Peng.
[12:52] <abentley> ddaa: I think you would have to use bzrlib.
[12:52] <abentley> I'm not sure it would be wise to provide a way to bypass break-lock's prompt.
[12:52] <Peng> What about some shell thing to pass it a few "y\n"s?
[12:55] <Odd_Bloke> 'yes' FTW. :)
[12:56] <mwhudson> ddaa: you have to supply a ui factory
[12:56] <Peng> I think I tried yes for something, and it didn't work.
[12:57] <mwhudson> ddaa: hm, are you reviewing my launchpad branch by any chance?
[12:57] <mwhudson> ddaa: if not, you should and your questions will be answered :)
[12:58] <mwhudson> also 173941
[12:58] <mwhudson> bug 173941
[12:58] <ubotu> Launchpad bug 173941 in bzr "hard to programmatically break a lock" [Wishlist,Triaged] https://launchpad.net/bugs/173941
[13:01] <ddaa> actually, I'm just trying to fix up stale locks in a ad-hoc way
[13:01] <ddaa> I already grepped the oops report into a list of bzr break-lock commands
[13:02] <mwhudson> ah
[13:02] <mwhudson> find ... -name held -type d | xargs rm -f ?
[13:02]  * mwhudson runs away, terribly fast
[13:02] <ddaa> mh
[13:03] <mwhudson> not serious, at all :)
[13:03] <ddaa> that actually sounds like a plan
[13:03] <mwhudson> i guess it would work
[13:03] <ddaa> I'll be a bit more specific though :)
[13:06] <ddaa> function h4X0rL0cK () { rm -rf $1/.bzr/{repository,branch}/lock/held; }
[13:06] <ddaa> while read b < tobreak.txt ; do h4X0rL0cK $b ; done
[13:06] <ddaa> that should do it
[13:07] <ddaa> abentley: does that sound okay to you?
[13:09] <abentley> ddaa: It looks like it would probably work, but it doesn't seem to prevent you from deleting non-stale locks.
[13:09] <ddaa> the tobreak.txt file is a list of branches with known stale locks
[13:09] <ddaa> at least, known stale assuming nobody else broke the stale locks without telling me
[13:10] <abentley> Well, you're no doubt aware it isn't 100% safe.  But it looks like it will do what you are asking.
[13:11] <ddaa> anything more specific about unsafety than "it's a scary hack"?
[13:15] <abentley> Just the race condition.  A lock that you think is stale may no longer be stale.
[13:15] <ddaa> how's that
[13:15] <ddaa> if there's a stale lock, then the branch cannot be locked
[13:15] <ddaa> so it cannot become unstale
[13:16] <abentley> Someone can run break-lock after you have generated tobreak.txt
[13:16] <ddaa> right
[13:16] <abentley> And then commit.
[13:16] <ddaa> it's assuming nobody else is breaking locks
[13:16] <abentley> Right.
[13:16] <ddaa> mwhudson: please do not break stale locks kthxbye
[13:16] <ddaa> race condition fixed :)
[13:21] <ddaa> okay mass stale lock cleanup done
[13:54] <muffinresearch> Hi I am preparing a presentation about decentralised VCS and bazaar in particular. Can anyone explain what makes bazaar's diff algorithm better than others?
[13:55] <muffinresearch> Having looked here http://bramcohen.livejournal.com/37690.html  there's not a lot of detail that will make it straight forward to explain.
[13:58] <ddaa> abentley: this is for you
[13:59] <ddaa> bzr does not even use Bram's patience diff exactly, but a modified version.
[14:00] <ddaa> In a nutshell, the intent is to make the diff as close as possible to something that reflects the intent of the programmer, for changes typically found in source code.
[14:00] <ubotu> New bug: #174153 in bzr "bzr export --format=tar should have excludes options" [Undecided,New] https://launchpad.net/bugs/174153
[14:00] <ddaa> I cannot tell you how that translates in algorithmic technicalities though.
[15:49] <naitandu> hello
[16:45] <Lo-lan-do> Um.  Wasn't the packs format supposed to be faster than dirstate?
[16:46] <Lo-lan-do> "bzr missing" takes 5.2 seconds on a dirstate repo, and 7.7 seconds on a copy of that repo upgraded to packs...
[16:46] <Lo-lan-do> (Between branches stored in the same repo, both times)
[16:48] <mwhudson> Lo-lan-do: "it depends"
[16:48] <mwhudson> missing sounds like one of those operations that might read the entire index
[16:49] <mwhudson> which is slower with packs
[16:49] <Lo-lan-do> Oh.  Hm.  What's faster then? :-)
[16:49] <mwhudson> well, it depends what you're doing
[16:49] <mwhudson> in this case what probably needs to happen is that missing needs to be rewritten to use more graph based apis
[16:50] <mwhudson> Lo-lan-do: for example "pull" is waaaaaaaaaaaaaaay faster with packs
[16:51] <Lo-lan-do> status?  diff?
[16:51] <mwhudson> i think status might be slower, with a band-aid applied to the 1.0 branch
[16:51] <mwhudson> diff is likely about the same
[16:52] <Lo-lan-do> Okay, I'll keep my dirstate-with-subtree then :-)
[16:53] <mwhudson> well, you can keep both around easily enough
[16:54] <Lo-lan-do> Is there some doc on rich-root?
[16:55] <dato> not sure. but for bzr-svn is preferred over d-w-s
[16:55] <jelmer> Lo-lan-do: what sort of documentation are you looking for?
[16:55] <jelmer> bzr init --help lists the rich root formats
[16:56] <Lo-lan-do> jelmer: What it's supposed to bring :-)
[16:57] <jelmer> it doesn't bring anything additional except the bits required to be used by bzr-svn, and is stable as opposed to dirstate-with-subtree which is experimental
[16:58] <Lo-lan-do> Hmm.  So I should upgrade my repo to rich-root then.
[16:58] <Lo-lan-do> I'll try that right away :-)
[16:59] <jelmer> I don't think you can downgrade from dirstate-with-subtree to rich-root yet
[17:00] <dato> I've done it by pulling, I think
[17:12] <vila> Lo-lan-do: you should file a for any operation that is slower with packs than with knits, they are likely to fixed quickly
[17:12] <vila> s/file/file a bug/
[17:12] <Lo-lan-do> Okay
[17:24] <Lo-lan-do> I've started branching one branch of my dirstate-with-subtree repo into my rich-root repo about 20 minutes ago, it's still going.
[17:27] <Lo-lan-do> Not much disk I/O, but lots of CPU eaten.
[18:10] <dato> is it safe to rm repository/obsolete_packs/*? does bzr automatically do that, and when?
[18:11] <Peng> dato: I think they're deleted next time it repacks.
[18:12] <dato> riiight, placing the new old ones there. so it's never empty, it seems.
[18:12] <james_w> dato: yeah, you should only ever have one generation of obsolete packs, and so the disk usage wont grow indefinitely.
[18:12] <james_w> but you are right, it will never be empty after the first repack (except if you delete it, and the short time before the new packs go there).
[18:13] <james_w> but yes, you should be safe to delete it.
[18:15] <dato> ok, fair enough.
[18:16] <dato> I can see it being ok when pushing over sftp, since it's just a mv.
[18:16] <dato> but I push all my personal branches (those I'm the only commiter) with plain rsync since day 0, so I'd find a bit annoying having to sync obsolete_packs as well.
[18:16] <dato> which is what I'll do, pass --exclude obsolete_packs to rsync.
[18:17] <Peng> Why use rsync?
[18:18] <Peng> It's probably faster, but unless you have gigs od data here it shouldn't be that dramatic.
[18:19] <bialix> privet
[18:19] <bialix> is Ian here?
[18:19] <dato> Peng: rather than remembering to push after each set of changes in *each branch*, I just run `sync-code` once at the end of the day, or so.
[18:20] <james_w> bialix: no, it's a bit early yet I think.
[18:20] <Peng> dato: Huh.
[18:20] <Peng> dato: There's like a repo-push plugin.
[18:20] <bialix> heh, people from Oz
[18:20] <Peng> Erk, I can't keep track of who's who.
[18:21] <dato> Peng: huh wtf, kthxbye.
[18:22] <jam> bialix: He won't be in for about 3 hrs
[18:22] <jam> dato: use checkouts for everything (it is what I do between by desktop and laptop and my server)
[18:22] <bialix> ok
[18:22] <jam> He will definitely be around in 5
[18:23] <jam> but that may be too late for you
[18:23] <bialix> may I ask anybody else, about our user-guide
[18:23] <jam> (the other problem with igc is that he is in a different part of Oz, which doesn't do DST, so he is an hour off of lifeless and poolie)
[18:23] <jam> bialix: you can ask, I may not tell :)
[18:23] <dato> jam: nah, this suits me very fine. :)
[18:24] <jam> I believe Aaron uses a local treeless repository and lightweight checkouts which he rsyncs between home and office
[18:24] <jam> but that may have changed over time
[18:24] <jam> since he has "repo-push" and "multi-pull"
[18:24] <jam> in bzrtools
[18:24] <Peng> jam: Part of Oz doesn't do DST? Cool.
[18:25] <bialix> repo-push is not the part of bzrtools
[18:25] <dato> jam: plus, I like to sync the trees as well
[18:25] <jam> IIRC igc is in Brisbane (north east AU)
[18:25] <jam> bialix: separate plugin... hmm, sounds a lot like bzrtools material, though.
[18:25] <jam> bialix: anyway what is your user guide question?
[18:26] <bialix> it's a small and picky question actually, http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#introducing-bazaar section about history
[18:26] <Peng> You guys seriously use rsync? You know, you added push and pull commands like 20 versions ago.
[18:27] <bialix> generations: 1. file versioning tools, e.g. SCCS, VCS <-- is VCS correct here? perhaps it should be RCS?
[18:30] <bialix> Peng: I don;t use rsync, because I'm win32-guy
[18:31] <Lo-lan-do> bialix: I usually collapse generations 2 and 3 together, as well as 4 and 5.
[18:31] <Lo-lan-do> To me, distributed VCS is 3rd gen.
[18:32] <bialix> Lo-lan-do: right now I ask as translator
[18:32] <Peng> bialix: You == Alexander Belchenko, the guy who's been working on repo-push and -pull?
[18:32] <bialix> repo-push only because James Henstridge don;t support this plugin
[18:33] <bialix> I'm not aware about existence repo-pull
[18:34] <Peng> Oh.
[18:34] <Peng> Okay, then.
[18:34] <Peng> I'm not either, then.
[18:35] <Lo-lan-do> jam, jelmer: By the way, any details on bzr-git?  The Launchpad page is sketchy, as is the wiki page, but Odd_Bloke tells me you're both involved in it.
[18:35] <jam> Peng: I haven't used rsync since 0.8
[18:36] <jam> But then, I wrote the original Transport code to make remote operations possible.
[18:36] <Peng> jam: Oh, good. :)
[18:36] <jam> bialix: The one you are looking at should be RCS
[18:36] <jam> 1. file versioning tools, e.g. SCCS, RCS
[18:36] <jam> is the correct programe
[18:37] <jam> program
[18:37] <jam> Lo-lan-do: I was working on it a bit back at our company meeting
[18:37] <jam> I started working on the ability to build git branches to spec, so that I could make sure they get transformed into Bazaar branches properly.
[18:37] <bialix> what's actually difference between revision control and version control -- for english speakers?
[18:37] <jam> But I got side-tracked by everything else.
[18:37] <jam> bialix: in effect, not much
[18:37] <Lo-lan-do> jam: Heh, that tends to happen :-)
[18:38] <bialix> jam: revision -- is one of the hardest term to translate
[18:38] <jam> bialix: http://www.m-w.com/dictionary/revision
[18:38] <jam> 2:  a revised version
[18:38] <jam> So a revision is... a version
[18:39] <jam> that is somewhat modified from another version
[18:39] <bialix> :-)
[18:39] <jam> so "revision" has a bit more of the concept of evolving from another version
[18:39] <jam> (the "re" part)
[18:39] <jam> well revise maybe..
[18:40] <jam> So a "version" is a bit more standalone, and "revision" makes you think there was another one it came from
[18:40] <jam> but they are pretty much interchangable
[18:41] <bialix> oh, thanks. version is frozen, revision is vivd
[18:41] <bialix> vivid
[18:42] <jam> bialix: bzr.dev has already been updated to say RCS
[18:42] <jam> we probably just need to regen the docs
[18:42] <bialix> hmm, then my mirror of bzr.dev is out-of-date
[18:43] <Peng> jam: You need to regen http://doc.bazaar-vcs.org/latest/developers/ anyway so packrepo.html will work! And create a redirect from knitpack.html to it!!
[18:43] <Peng> Should I have filed a bug on that?
[18:43] <bialix> btw, question about HistoryHorizon
[18:44] <bialix> in ru_bzr one guy asked about such feature
[18:44] <bialix> he said git already has it. It's true?
[18:44] <Peng> Hah!
[18:44] <dato> yes
[18:44] <jam> bialix: git has the ability to 'graft' in history
[18:44] <jam> which  means your local tree claims to have more history
[18:44] <bialix> heh
[18:44] <jam> than what gets pushed and pulled
[18:44] <Peng> In doc.b.o/bzr.1.0, packrepo.html works but it links to knitpack.html which 404s!
[18:45] <jam> I know you can start with a snapshot, and graft in history
[18:45] <jam> I don't know if you can take something that already has history
[18:45] <jam> and break it
[18:45] <bialix> sounds very good
[18:45] <jam> but I guess  if you just did a fresh import
[18:45] <bialix> i'm thinking about this
[18:45] <bialix> many times
[18:45] <jam> bialix: but it is one of the key items that Canonical wants in the next 6 months
[18:46] <bialix> also sometimes I think about semi-commit
[18:46] <jam> bialix: semi-commit?
[18:46] <bialix> when actual work is not finished to do fullcommit, but I need to go home/work and somehow I need push my changes to server or my USB stick
[18:47] <jam> something wrong with "commit + push + uncommit" ?
[18:47] <bialix> repo-push plugin don;t like uncommits
[18:48] <bialix> and I'm a bit worrying about repo history pollution by temp garbage
[18:48] <jam> just make a 'repo-clone' which supplies "overwrite=True".
[18:48] <jam> bialix: not a lot of garbage, and when people pull from it, it doesn't get transferred
[18:48] <jam> otherwise, you could commit to the side, generate a Merge Directive for that
[18:48] <jam> and send the MD
[18:48] <jam> and merge it on the other side
[18:49] <jam> but that still installs the revisions into the repo
[18:49] <bialix> yeah
[18:49] <Peng> Any way to get the LCA of two branches?
[18:49] <jam> The other is to just use "bzr shelve" and copy your .shelf across
[18:49] <jam> but you need "patch" for that
[18:49] <lifeless> jam: bialix: you can only graft on a local client in git
[18:49] <jam> Peng: yes
[18:49] <lifeless> it doesn't propogate
[18:49] <jam> lifeless: right,
[18:49] <jam> I think the point is that it doesn't
[18:49] <bialix> no shelve is not silver bullet. it's still don;t support binary files
[18:50] <jam> Peng: "bzr log -r ancestor:../other-branch .
[18:50] <jam> the final '.' is probably not needed
[18:50] <jam> Peng: or are you in bzrlib itself?
[18:50] <Peng> jam: Not in bzrlib.
[18:50] <jam> lifeless: good to see you around, now go play WoW :)
[18:50] <bialix> IMO shelf should operate more like temp branch, not as side patch
[18:51] <Peng> (Actually, I just want to create a small patch that can go in bzr.1.0 and bzr.dev without cherrypicking.)
[18:51] <dato> jam: (jfyi, GFDL's invariant sections are optional, and Debian will happily take GFDL material if it does not make use of such sections)
[18:51] <jam> dato: thanks
[18:51] <jam> Peng: hmm.... I think you can do
[18:51] <jam> cd bzr.dev; bzr revision-info -r ancestor:../bzr.1.0
[18:52] <jam> and then bzr branch -r XXX  bzr.dev bzr.ancestor
[18:52] <Peng> Right.
[18:52] <Peng> Thanks.
[18:53] <jam> If there is no revision number, then you need to use "revid:..."
[18:53] <jam> Though when I just tested it, it seems to give the dotted revision number in the current branch.
[18:54] <Peng> Oh.
[18:54] <Peng> Well, I hope it did, because I just used that.
[18:54] <bialix> jam: I just thought: is it possible to generate snapshot of working tree packed in zip or tar.gz as semi-commit?
[18:56] <bialix> generating patch is not enough, because we need to know fileid for newly added files
[18:57] <bialix> is it safe to save snapshot of dirstate and then apply it to fresh tree?
[18:57] <Lo-lan-do> Ouch.  Branching from dirstate-with-subtree to rich-root took 108 minutes.
[19:00] <jam> Lo-lan-do: ouch and a half... I don't know why it would be that slow....
[19:00] <Peng> knit -> pack?
[19:00] <jam> bialix: I believe if you take a snapshot of the WT and .bzr/checkout/dirstate it will work
[19:00] <jam> Peng: no, rich-root is still knits
[19:00] <jam> (rich-root-pack is packs)
[19:00] <jam> And knit => pack is reasonably fast
[19:00] <bialix> jam: I think it will enough to pack unfinished work for me. will try to write plugin
[19:00] <jam> pack => knit is slow
[19:01] <jam> bialix: if you want to get extra fancy
[19:01] <jam> you can use "tree._iter_changes" to only pack up files which have been modified
[19:01] <jam> which would make for a smaller .zip file
[19:01] <bialix> nice, thanks
[19:02] <Peng> jam: Oh.
[19:02] <Peng> Right.
[19:03] <Peng> I think the LCA should be 3055, but 3052 works.
[19:04] <jam> Peng: remember, both sides need to have it, so A merging B isn't enough, B also needs to merge A
[19:04] <jam> Well, A merging B will give you the last revision of B as the common ancestor
[19:07] <Lo-lan-do> Same branching into a pack-0.92-subtree repo takes 5 minutes.
[19:08] <jam> Lo-lan-do: it sounds like it is doing something like regenerating all of the inventory files
[19:08] <jam> since the source might have fields that aren't allowed in the target.
[19:09] <jam> but man... almost 2 hours is something that should be looked at.
[19:10] <Peng> jam: 3053 in both branches is identical.
[19:10] <jam> (not necessarily by me... :)
[19:10] <Lo-lan-do> I'll report it, just after I report the regression in bzr missing.
[19:10] <Peng> jam: 3054 was merged from bzr.dev into bzr.1.0.
[19:10] <bialix> I'd like to ask one more question about english (or maybe australian?) recently Andrew Bennets wrote in reply about criss-cross: "wiggeda wiggeda wack". It's sounds very funny, but I have no idea what's it
[19:11] <jam> bialix: there was a rock group named "Criss-Cross"
[19:11] <jam> well, a hip-hop group
[19:11] <bialix> "jump jump"
[19:11] <Lo-lan-do> The two youngsters wearing their clothes the wrong way?
[19:11] <jam> bialix: http://www.lyrics4all.net/k/kriss-kross/totally-crossed-out/jump.php
[19:11] <jam> Kris Kross will make you Jump Jump
[19:12] <jam> ...
[19:12] <jam> And inside-out is wiggida wiggida wack
[19:12] <jam> bialix: or if you prefer: http://www.youtube.com/watch?v=4UgficQpYE4
[19:13] <radix> o/`
[19:13] <jam> radix: yes?
[19:13] <jam> (Assuming that is a person putting their hand up)
[19:14] <Lo-lan-do> I think maybe he means ♪
[19:14] <jam> ah
[19:14] <jam> probably
[19:15] <radix> o/` some-o-them try ta rhyme but they can't rhyme like this o/`
[19:15] <radix> jam: yeah. you're confusing o/` for o/ :)
[19:16] <Peng> What do we lose when doing cherrypicking?
[19:16] <lifeless> data
[19:16] <bialix> history
[19:16] <Peng> Very specific. :P
[19:20]  * dato gives o/~ to radix ;)
[19:21] <fullermd> Hopefully, we can lose evil 90's hiphop references...
[19:21] <bialix> jam: thanks, LOL * 100
[19:22] <radix> dato: pshaw. o/` is superior to o/~. but of course u"\N{EIGHTH NOTE}" is the best :-)
[19:38] <Lo-lan-do> There.  Debian bugs #454503 and #454504.
[19:38] <ubotu> Debian bug 454503 in bzr "bzr: Performance regression with pack format" [Normal,Open] http://bugs.debian.org/454503
[19:38] <ubotu> Debian bug 454504 in bzr "bzr: Large performance regression with rich-root format" [Normal,Open] http://bugs.debian.org/454504
[19:39] <Peng> :D
[19:40] <Peng> "And what have you been busy with this holiday season?" "Creating large performance regressions!"
[19:40] <Lo-lan-do> Sorry about that
[19:41] <Lo-lan-do> But, well, 108 minutes is a tad long for me.
[19:41] <Peng> :P
[19:42] <Peng> The missing thing is probably known and related to logs or complete-history-traversal or something. Did you check Launchpad?
[19:43] <Lo-lan-do> I checked the BTS, and I checked on IRC, and IRC told me to report it, so I report it.
[19:43] <Peng> Ah, okay.
[19:44] <bialix> jam: can't pull your branch https://code.launchpad.net/~jameinel/bzr/index-buffer-all
[19:44] <bialix> so, can't test your patch
[19:46] <bialix> for #172975
[19:47] <Peng> bialix: If it's a missing revision, the branch might be against bzr.1.0 instead of bzr.dev.
[19:47] <bialix> no, it's just absent at launchpad
[19:48] <bialix> "This branch has not been mirrored, as Launchpad has been unable to access it."
[19:48] <Peng> Oh oh.
[19:49] <bialix> jam's server may be down
[19:49] <Peng> Serves me right for replying before opening the link. :P
[19:50] <bialix> or as daemon in Grim Fandango said: the server is never down - it's temporarily unavailable ;-)
[19:53] <Peng> :)
[19:53] <Peng> Launchpad has actually given up on trying to mirror it? How long was it down?
[19:54] <Jammer> is there way to see who has edited certain line last time?
[19:54] <elmo> Jammer: bzr annotate
[19:56] <Jammer> elmo, thanks... dunno how I missed that >_<
[20:09] <Peng> Wait, bound branches != checkouts?
[20:16] <jam> mwhudson: any luck on getting the importer to mirror my slow branches?
[20:20] <Peng> jam: Poke about https://code.launchpad.net/~jameinel/bzr/index-buffer-all not being mirrored because Launchpad couldn't access it?
[20:26] <fullermd> Peng: I keep my bound branches in the closet.  That way I can't hear them scream.
[20:31] <jam> Peng: that is what I was pinging mwhudson
[20:31] <jam> about
[20:32] <jam> I'll hit try again
[20:32] <Peng> jam: Oh oh. Okay.
[20:32] <jam> but basically it was failing because it was taking longer than 15min to get progress
[20:32] <jam> which is because inventories.knit is big enough
[20:32] <jam> that it cannot stream all of it over my slow pipe in 15 minutes
[20:33] <jam> vila's patch should help that
[20:33] <Peng> You haven't upgraded to packs?
[20:33] <jam> Peng: not on my main public repository
[20:33] <Peng> (Well, I guess a 50 MB pack would be even worse than a 5 MB kndx. :P )
[20:44] <mwhudson> jam: haven't tried to be honest
[20:44] <mwhudson> jam: maybe you can mirror them off people.ubuntu.com to start with?
[20:53] <jam> mwhudson: well, the whole point is I don't want to have to go manually uploading my branches to launchpad
[20:54] <jam> if I wanted to do that, I would just push there directly
[20:54] <jam> I use "bzr register-branch" and then I can just forget about it from there forward
[20:54] <mwhudson> jam: it should be fixed by the next rollout
[20:55] <mwhudson> i guess we could bump up the timeout too
[22:56] <ig1> morning all