| 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:05 |
| naitandu | where can i get current information on bazaar for Visual Studio? The bazaar-site did only mention it as part of GSoC ?! | 00:06 |
| jkakar | igc: Thanks! I'll check that out. | 00:08 |
| igc | jkakak: no problem. Also see http://bazaar-vcs.org/BzrWhy, particularly my paper on Why DVCS matters. | 00:09 |
| === edencane is now known as edencane_ | ||
| === edencane_ is now known as edencane | ||
| 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. | 00:58 |
| poolie | hm | 01:00 |
| Peng | Also, there were 12-13,000 SFTP.readv()s in .bzr.log. :) | 01:03 |
| jml | igc: thanks | 01:39 |
| igc | jml: can you tweak that and submit to pqm or do I need to? | 01:40 |
| jml | igc: I've tweaked it, but you need to submit it to PQM. | 01:41 |
| igc | ok | 01:41 |
| ubotu | New bug: #174055 in bzr "can't run bzr info while dirstate is locked" [Low,Confirmed] https://launchpad.net/bugs/174055 | 01:45 |
| 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 | 01:55 |
| * igc food | 02:07 | |
| === mw is now known as mw|out | ||
| jml | igc: I've found the cause of the selftest failures: I wasn't unregistered my test transport. | 02:12 |
| bac | spiv: ping | 02:25 |
| spiv | bac: pong | 02:28 |
| lifeless | jkakar: 'bzr switch' | 02:30 |
| xjjk | hi... I think I'm going in circles trying to find something | 02:54 |
| 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? | 02:55 |
| igc | jml: cool. Can you submit an updated patch for me to land? | 03:02 |
| jml | igc: yep. in a sec | 03:03 |
| jml | sent | 03:05 |
| 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:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:30 |
| fullermd | igc: Was that checkout/bound mail reasonably clear (or at least, definitively muddy)? | 03:38 |
| igc | fullermd: it was great thanks | 03:38 |
| igc | I like your explanation but I wonder whether most people think that deeply about it? | 03:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| igc | not sure if I can tell | 03:47 |
| 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:49 |
| mlh_ | It's weird though, time and time again I see questions that would be suitable addressed by using a DVCS. | 03:50 |
| 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:51 |
| fullermd | I'd use "bzr rm --keep" instead of revert, but I think the result would be the same. | 03:52 |
| dash | oh, what's the difference | 03:53 |
| 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:54 |
| 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:55 |
| dash | weird | 03:56 |
| dash | well, that worked | 03:58 |
| dash | thanks! | 04:06 |
| 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? | 05:57 |
| spiv | Peng: if check passes, then I'd be pretty comfortable with the reconcile. | 06:08 |
| 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:09 |
| Peng | spiv: Well, I'm on a very small partition, so the cost is > nothing. | 06:13 |
| 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:14 |
| 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:15 |
| Peng | Okay. | 06:18 |
| Peng | Well, I'll keep 'em around anyway. | 06:18 |
| Peng | Anyway, thanks | 06:19 |
| * Peng wanders off. | 06:19 | |
| === thumper is now known as thumper-afk | ||
| 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:09 |
| * mlh_ finishes counting out 4'13" of silence, sends royalties to John Cage | 07:17 | |
| AfC | Silence is underrated. | 07:20 |
| === mlh_ is now known as mlh | ||
| mlh | AfC: hypocrite! :-) | 07:24 |
| Peng | Oh no, the foam slip my DS came in is slightly rotn. | 07:27 |
| Peng | rotn? | 07:27 |
| Peng | torn. | 07:27 |
| * Peng wanders off. | 07:28 | |
| 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:25 |
| ubotu | New bug: #174105 in bzr "move glossary from web site into user docs" [Medium,Confirmed] https://launchpad.net/bugs/174105 | 08:40 |
| lifeless | igc: pull overwrite clobbers local changes doesn't it? switch shouldn't do that ;). | 09:06 |
| === kiko-afk is now known as kiko | ||
| 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:58 |
| 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? | 09:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| 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:06 |
| terdmonk | and a shared repository is meant for hosting branches? | 10:07 |
| Odd_Bloke | terdmonk: All branches have a repository, where revisions are stored. Having a shared repository simply reduces duplication. | 10:08 |
| * terdmonk nods | 10:10 | |
| 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:11 |
| 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:14 |
| 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:15 |
| Peng | lifeless: Bleh, that would be confusing. | 10:19 |
| Lo-lan-do | Hi all | 10:34 |
| Lo-lan-do | Quick question: is bzr-git more-or-less usable? | 10:34 |
| Lo-lan-do | Also, would you happen to know whether there's a git-bzr floating around somewhere? | 10:35 |
| Odd_Bloke | Lo-lan-do: Toward the less ATM, I believe. Enough for bzrk, the Launchpad page claims. | 10:36 |
| 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:37 |
| 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 | 10:38 |
| ubotu | New bug: #174127 in bzr "Requesting a --names-only option for bzr diff" [Undecided,New] https://launchpad.net/bugs/174127 | 11:31 |
| 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:42 |
| Peng | Not at this time, and I don't think they plan one. | 12:44 |
| blauwal_ | Peng: Thanks for your answer. It's a pitty though, copying 1.8 GB of sources is a pain in the ... :) | 12:45 |
| ddaa | is there a way to bypass the confirmation prompts of "bzr break-lock"? | 12:47 |
| Peng | Is there a --force? | 12:48 |
| ddaa | nope | 12:48 |
| abentley | then I guess you can't use the --force. | 12:48 |
| 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:49 |
| 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:50 |
| abentley | ddaa: Yes. I was answering Peng. | 12:51 |
| 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:52 |
| Odd_Bloke | 'yes' FTW. :) | 12:55 |
| 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:56 |
| 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:57 |
| 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 | 12:58 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:06 |
| ddaa | abentley: does that sound okay to you? | 13:07 |
| 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:09 |
| abentley | Well, you're no doubt aware it isn't 100% safe. But it looks like it will do what you are asking. | 13:10 |
| ddaa | anything more specific about unsafety than "it's a scary hack"? | 13:11 |
| 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:15 |
| 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:16 |
| ddaa | okay mass stale lock cleanup done | 13:21 |
| 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:54 |
| === kiko is now known as kiko-phone | ||
| 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:55 |
| ddaa | abentley: this is for you | 13:58 |
| ddaa | bzr does not even use Bram's patience diff exactly, but a modified version. | 13:59 |
| 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. | 14:00 |
| === mw|out is now known as mw | ||
| === cprov is now known as cprov-lunch | ||
| === kiko-phone is now known as kiko | ||
| === cprov-lunch is now known as cprov | ||
| naitandu | hello | 15:49 |
| === kiko is now known as kiko-fud | ||
| Lo-lan-do | Um. Wasn't the packs format supposed to be faster than dirstate? | 16:45 |
| 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:46 |
| mwhudson | Lo-lan-do: "it depends" | 16:48 |
| mwhudson | missing sounds like one of those operations that might read the entire index | 16:48 |
| 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:49 |
| mwhudson | Lo-lan-do: for example "pull" is waaaaaaaaaaaaaaay faster with packs | 16:50 |
| 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:51 |
| Lo-lan-do | Okay, I'll keep my dirstate-with-subtree then :-) | 16:52 |
| mwhudson | well, you can keep both around easily enough | 16:53 |
| Lo-lan-do | Is there some doc on rich-root? | 16:54 |
| 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:55 |
| Lo-lan-do | jelmer: What it's supposed to bring :-) | 16:56 |
| 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:57 |
| 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:58 |
| jelmer | I don't think you can downgrade from dirstate-with-subtree to rich-root yet | 16:59 |
| dato | I've done it by pulling, I think | 17:00 |
| 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:12 |
| 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:24 |
| Lo-lan-do | Not much disk I/O, but lots of CPU eaten. | 17:27 |
| === kiko-fud is now known as kiko-afk | ||
| dato | is it safe to rm repository/obsolete_packs/*? does bzr automatically do that, and when? | 18:10 |
| Peng | dato: I think they're deleted next time it repacks. | 18:11 |
| 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:12 |
| james_w | but yes, you should be safe to delete it. | 18:13 |
| dato | ok, fair enough. | 18:15 |
| 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:16 |
| Peng | Why use rsync? | 18:17 |
| Peng | It's probably faster, but unless you have gigs od data here it shouldn't be that dramatic. | 18:18 |
| 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:19 |
| 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:20 |
| dato | Peng: huh wtf, kthxbye. | 18:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| bialix | generations: 1. file versioning tools, e.g. SCCS, VCS <-- is VCS correct here? perhaps it should be RCS? | 18:27 |
| bialix | Peng: I don;t use rsync, because I'm win32-guy | 18:30 |
| 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:31 |
| 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:32 |
| bialix | I'm not aware about existence repo-pull | 18:33 |
| Peng | Oh. | 18:34 |
| Peng | Okay, then. | 18:34 |
| Peng | I'm not either, then. | 18:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| bialix | oh, thanks. version is frozen, revision is vivd | 18:41 |
| bialix | vivid | 18:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| jam | something wrong with "commit + push + uncommit" ? | 18:47 |
| bialix | repo-push plugin don;t like uncommits | 18:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| jam | and then bzr branch -r XXX bzr.dev bzr.ancestor | 18:52 |
| Peng | Right. | 18:52 |
| Peng | Thanks. | 18:52 |
| 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:53 |
| 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:54 |
| bialix | generating patch is not enough, because we need to know fileid for newly added files | 18:56 |
| 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. | 18:57 |
| 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:00 |
| 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:01 |
| Peng | jam: Oh. | 19:02 |
| Peng | Right. | 19:02 |
| Peng | I think the LCA should be 3055, but 3052 works. | 19:03 |
| 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:04 |
| Lo-lan-do | Same branching into a pack-0.92-subtree repo takes 5 minutes. | 19:07 |
| 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:08 |
| jam | but man... almost 2 hours is something that should be looked at. | 19:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| radix | o/` | 19:13 |
| jam | radix: yes? | 19:13 |
| jam | (Assuming that is a person putting their hand up) | 19:13 |
| Lo-lan-do | I think maybe he means ♪ | 19:14 |
| jam | ah | 19:14 |
| jam | probably | 19:14 |
| 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:15 |
| Peng | What do we lose when doing cherrypicking? | 19:16 |
| lifeless | data | 19:16 |
| bialix | history | 19:16 |
| Peng | Very specific. :P | 19:16 |
| * dato gives o/~ to radix ;) | 19:20 | |
| fullermd | Hopefully, we can lose evil 90's hiphop references... | 19:21 |
| bialix | jam: thanks, LOL * 100 | 19:21 |
| radix | dato: pshaw. o/` is superior to o/~. but of course u"\N{EIGHTH NOTE}" is the best :-) | 19:22 |
| 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:38 |
| Peng | :D | 19:39 |
| Peng | "And what have you been busy with this holiday season?" "Creating large performance regressions!" | 19:40 |
| Lo-lan-do | Sorry about that | 19:40 |
| Lo-lan-do | But, well, 108 minutes is a tad long for me. | 19:41 |
| Peng | :P | 19:41 |
| Peng | The missing thing is probably known and related to logs or complete-history-traversal or something. Did you check Launchpad? | 19:42 |
| 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:43 |
| 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:44 |
| bialix | for #172975 | 19:46 |
| 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:47 |
| bialix | "This branch has not been mirrored, as Launchpad has been unable to access it." | 19:48 |
| Peng | Oh oh. | 19:48 |
| bialix | jam's server may be down | 19:49 |
| Peng | Serves me right for replying before opening the link. :P | 19:49 |
| bialix | or as daemon in Grim Fandango said: the server is never down - it's temporarily unavailable ;-) | 19:50 |
| Peng | :) | 19:53 |
| Peng | Launchpad has actually given up on trying to mirror it? How long was it down? | 19:53 |
| Jammer | is there way to see who has edited certain line last time? | 19:54 |
| elmo | Jammer: bzr annotate | 19:54 |
| Jammer | elmo, thanks... dunno how I missed that >_< | 19:56 |
| === thumper-afk is now known as thumper | ||
| Peng | Wait, bound branches != checkouts? | 20:09 |
| jam | mwhudson: any luck on getting the importer to mirror my slow branches? | 20:16 |
| Peng | jam: Poke about https://code.launchpad.net/~jameinel/bzr/index-buffer-all not being mirrored because Launchpad couldn't access it? | 20:20 |
| fullermd | Peng: I keep my bound branches in the closet. That way I can't hear them scream. | 20:26 |
| jam | Peng: that is what I was pinging mwhudson | 20:31 |
| jam | about | 20:31 |
| 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:32 |
| 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:33 |
| 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:44 |
| jam | mwhudson: well, the whole point is I don't want to have to go manually uploading my branches to launchpad | 20:53 |
| 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:54 |
| mwhudson | i guess we could bump up the timeout too | 20:55 |
| === cprov is now known as cprov-out | ||
| ig1 | morning all | 22:56 |
| === ig1 is now known as igc | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!