[00:05] hello naitandu [00:05] 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] where can i get current information on bazaar for Visual Studio? The bazaar-site did only mention it as part of GSoC ?! [00:08] igc: Thanks! I'll check that out. [00:09] jkakak: no problem. Also see http://bazaar-vcs.org/BzrWhy, particularly my paper on Why DVCS matters. === edencane is now known as edencane_ === edencane_ is now known as edencane [00:58] 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] (This was of bzr.dev. Well, close it it.) [00:58] Augh! [00:58] I have a copy of bzr.dev there too that I could reconcile. [01:00] hm [01:03] Also, there were 12-13,000 SFTP.readv()s in .bzr.log. :) [01:39] igc: thanks [01:40] jml: can you tweak that and submit to pqm or do I need to? [01:41] igc: I've tweaked it, but you need to submit it to PQM. [01:41] ok [01:45] New bug: #174055 in bzr "can't run bzr info while dirstate is locked" [Low,Confirmed] https://launchpad.net/bugs/174055 [01:55] 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 === mw is now known as mw|out [02:12] igc: I've found the cause of the selftest failures: I wasn't unregistered my test transport. [02:25] spiv: ping [02:28] bac: pong [02:30] jkakar: 'bzr switch' [02:54] hi... I think I'm going in circles trying to find something [02:55] 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] jml: cool. Can you submit an updated patch for me to land? [03:03] igc: yep. in a sec [03:05] sent [03:22] hi WeirdArms [03:22] Hey [03:22] Had a talk with our QA lead [03:22] he's not interested in Bazaar [03:23] did he say why? [03:23] was just wondering if you had suggestion for two-way tools to cross import [03:23] pretty much what we discussed [03:23] so badly burnt on baz [03:23] and far enough into choosing Hg to reconsider [03:25] So I'd like to try it out [03:25] two-way tools are a two-edged sword as you know [03:25] but would need to be able to import out central repo into Hg and then push Bzr comments back to Hg [03:25] yeah [03:26] we do have bzr-hg but I suspect it's more about migration that full two-way interaction [03:26] ok [03:26] by migration, I include local mirroring [03:30] Last I heard (which was long ago), it could at least pull from local hg branches, but wouldn't work with remote. [03:30] I don't think it's had much love. [03:38] igc: Was that checkout/bound mail reasonably clear (or at least, definitively muddy)? [03:38] fullermd: it was great thanks [03:39] I like your explanation but I wonder whether most people think that deeply about it? [03:40] Well, most people probably have lives instead ;> [03:40] :-) [03:40] it does matter though ... [03:40] 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] particularly when implementing switch on heavy checkouts [03:41] (but those impressions aren't based on anything real concrete) [03:41] I think switch ought to be the same as "unbind; pull --overwrite URL;bind URL" ... [03:41] 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] i.e. to make the local cache a true reflection of the remote branch [03:42] * fullermd nods. [03:42] there's an argument for switch meaning "bind + update" though [03:42] 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] i.e. be safe and don't throw away any local changes [03:43] Is there a difference? I know 'pull' merges WT changes... never tried --overwrite. [03:43] I guess it might. You'd probably want '--overwrite-branch-but-merge-wt'. [03:43] it's necessary if the branches have diverged [03:44] 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] not sure if I can tell [03:49] tee hee Is this naughty of me: http://svn.haxx.se/users/archive-2007-12/0065.shtml [03:49] "Watch out though - you may like them (bzr or git) so much you might not want to [03:49] go back to svn. [03:50] It's weird though, time and time again I see questions that would be suitable addressed by using a DVCS. [03:51] What would be weird is if someone *did* want to go back to svn... [03:51] so, um... I typed "bzr add" by mistake and added a bunch of files I didn't want to [03:51] And yet the SVN bigwigs say they don't see the demand [03:51] will "bzr added|xargs bzr revert" get me back to where I was? :) [03:52] I'd use "bzr rm --keep" instead of revert, but I think the result would be the same. [03:53] oh, what's the difference [03:54] I'm not sure there is one. [03:54] Just 'feels' clearer to me what I'm doing. [03:54] errrrm hm [03:55] 'bzr added' does not print anything, despite 'bzr status' showing a pile of added files [03:55] added might go down from $CWD instead of the tree root... [03:56] weird [03:58] well, that worked [04:06] thanks! [05:57] 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] Peng: if check passes, then I'd be pretty comfortable with the reconcile. [06:09] 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] spiv: Well, I'm on a very small partition, so the cost is > nothing. [06:14] Peng: In that case, I'd just delete the backup. [06:14] Peng: If bzr check is happy, then the branch is pretty healthy. [06:14] But on the other hand, all of my backups are just another 60 or 70 MB. [06:15] Peng: if you can "bzr check" a branch, you know that every revision is intact. [06:15] 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] Okay. [06:18] Well, I'll keep 'em around anyway. [06:19] Anyway, thanks [06:19] * Peng wanders off. === thumper is now known as thumper-afk [07:09] bug 165080 [07:09] Launchpad bug 165080 in bzr "Quick Start Guide doesn't document "bzr send"" [Medium,Fix committed] https://launchpad.net/bugs/165080 [07:09] Thanks ubotu. [07:09] 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] Silence is underrated. === mlh_ is now known as mlh [07:24] AfC: hypocrite! :-) [07:27] Oh no, the foam slip my DS came in is slightly rotn. [07:27] rotn? [07:27] torn. [07:28] * Peng wanders off. [08:25] Erk. [08:25] Peng: Erk? [08:25] 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] So now I ran 'bzr co' and I'm going to try clean-tree again. [08:40] New bug: #174105 in bzr "move glossary from web site into user docs" [Medium,Confirmed] https://launchpad.net/bugs/174105 [09:06] igc: pull overwrite clobbers local changes doesn't it? switch shouldn't do that ;). === kiko-afk is now known as kiko [09:58] 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] if i start a project called foo-1.0 [09:58] and also start project foo-2.0 [09:58] should both projects belong under a foo branch? [09:59] or is foo-1.0 and foo-2.0 put under their own branches? [09:59] and if so, how will a developer be able to check out the latest branch without knowing what version is the latest? [10:00] i could see how a developer could checkout the latest branch if i had foo/foo-{1,2}.0 as a branch [10:00] could someone kindly shed some light? :) [10:01] 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] So unless a developer is specifically working on a release branch, they should always be referencing 'trunk'. [10:01] Odd_Bloke, ah yes. i see :) [10:03] 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] Something along those lines, yeah. [10:04] Odd_Bloke, excellent. thanks mate [10:04] * terdmonk continues digging at bzr doco [10:04] 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] ahh, init and init-repo do different things :) [10:06] gotcha [10:06] Yeah, 'init' creates a branch, 'init-repo' creates a shared repository. [10:07] and a shared repository is meant for hosting branches? [10:08] terdmonk: All branches have a repository, where revisions are stored. Having a shared repository simply reduces duplication. [10:10] * terdmonk nods [10:11] So they should be used wherever more than one branch with the same history will be stored. [10:11] They also make using branches for features and bug fixes a lot easier. [10:14] 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] +1 on that. bzr uses 'bzr.dev'. [10:15] s/trunk/foo.dev/ throughout. :) [10:15] you can also have foo - a repo and foo/foo-1.0 [10:15] a branch at the root which is trunk :) [10:19] lifeless: Bleh, that would be confusing. [10:34] Hi all [10:34] Quick question: is bzr-git more-or-less usable? [10:35] Also, would you happen to know whether there's a git-bzr floating around somewhere? [10:36] Lo-lan-do: Toward the less ATM, I believe. Enough for bzrk, the Launchpad page claims. [10:37] Yeah, but that page doesn't seem very recent, hence my quest for someone alive [10:37] Lo-lan-do: I believe the 'refactoring' branch is still the most recent work that has been done... [10:38] jam would know more. [10:38] (implicit ping :p) [10:38] Yeah, I'm told jelmer also has an interest in it since Samba apparently moves to git [11:31] New bug: #174127 in bzr "Requesting a --names-only option for bzr diff" [Undecided,New] https://launchpad.net/bugs/174127 [12:42] 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] orking tree, albeit without the history. Is there any way around it? [12:44] Not at this time, and I don't think they plan one. [12:45] Peng: Thanks for your answer. It's a pitty though, copying 1.8 GB of sources is a pain in the ... :) [12:47] is there a way to bypass the confirmation prompts of "bzr break-lock"? [12:48] Is there a --force? [12:48] nope [12:48] then I guess you can't use the --force. [12:49] and "< /dev/null" causes it to busy-loop printing the confirmation message [12:49] Oh. [12:49] I recently found out uncommit has a --force. Why not break-lock? Too dangerous? [12:50] Breaking a lock that is actually being used can cause data corruption. [12:50] abentley: I figure you know that I realize that :) [12:51] ddaa: Yes. I was answering Peng. [12:52] ddaa: I think you would have to use bzrlib. [12:52] I'm not sure it would be wise to provide a way to bypass break-lock's prompt. [12:52] What about some shell thing to pass it a few "y\n"s? [12:55] 'yes' FTW. :) [12:56] ddaa: you have to supply a ui factory [12:56] I think I tried yes for something, and it didn't work. [12:57] ddaa: hm, are you reviewing my launchpad branch by any chance? [12:57] ddaa: if not, you should and your questions will be answered :) [12:58] also 173941 [12:58] bug 173941 [12:58] Launchpad bug 173941 in bzr "hard to programmatically break a lock" [Wishlist,Triaged] https://launchpad.net/bugs/173941 [13:01] actually, I'm just trying to fix up stale locks in a ad-hoc way [13:01] I already grepped the oops report into a list of bzr break-lock commands [13:02] ah [13:02] find ... -name held -type d | xargs rm -f ? [13:02] * mwhudson runs away, terribly fast [13:02] mh [13:03] not serious, at all :) [13:03] that actually sounds like a plan [13:03] i guess it would work [13:03] I'll be a bit more specific though :) [13:06] function h4X0rL0cK () { rm -rf $1/.bzr/{repository,branch}/lock/held; } [13:06] while read b < tobreak.txt ; do h4X0rL0cK $b ; done [13:06] that should do it [13:07] abentley: does that sound okay to you? [13:09] ddaa: It looks like it would probably work, but it doesn't seem to prevent you from deleting non-stale locks. [13:09] the tobreak.txt file is a list of branches with known stale locks [13:09] at least, known stale assuming nobody else broke the stale locks without telling me [13:10] Well, you're no doubt aware it isn't 100% safe. But it looks like it will do what you are asking. [13:11] anything more specific about unsafety than "it's a scary hack"? [13:15] Just the race condition. A lock that you think is stale may no longer be stale. [13:15] how's that [13:15] if there's a stale lock, then the branch cannot be locked [13:15] so it cannot become unstale [13:16] Someone can run break-lock after you have generated tobreak.txt [13:16] right [13:16] And then commit. [13:16] it's assuming nobody else is breaking locks [13:16] Right. [13:16] mwhudson: please do not break stale locks kthxbye [13:16] race condition fixed :) [13:21] okay mass stale lock cleanup done [13:54] 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? === kiko is now known as kiko-phone [13:55] 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] abentley: this is for you [13:59] bzr does not even use Bram's patience diff exactly, but a modified version. [14:00] 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] New bug: #174153 in bzr "bzr export --format=tar should have excludes options" [Undecided,New] https://launchpad.net/bugs/174153 [14:00] I cannot tell you how that translates in algorithmic technicalities though. === 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 [15:49] hello === kiko is now known as kiko-fud [16:45] Um. Wasn't the packs format supposed to be faster than dirstate? [16:46] "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] (Between branches stored in the same repo, both times) [16:48] Lo-lan-do: "it depends" [16:48] missing sounds like one of those operations that might read the entire index [16:49] which is slower with packs [16:49] Oh. Hm. What's faster then? :-) [16:49] well, it depends what you're doing [16:49] in this case what probably needs to happen is that missing needs to be rewritten to use more graph based apis [16:50] Lo-lan-do: for example "pull" is waaaaaaaaaaaaaaay faster with packs [16:51] status? diff? [16:51] i think status might be slower, with a band-aid applied to the 1.0 branch [16:51] diff is likely about the same [16:52] Okay, I'll keep my dirstate-with-subtree then :-) [16:53] well, you can keep both around easily enough [16:54] Is there some doc on rich-root? [16:55] not sure. but for bzr-svn is preferred over d-w-s [16:55] Lo-lan-do: what sort of documentation are you looking for? [16:55] bzr init --help lists the rich root formats [16:56] jelmer: What it's supposed to bring :-) [16:57] 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] Hmm. So I should upgrade my repo to rich-root then. [16:58] I'll try that right away :-) [16:59] I don't think you can downgrade from dirstate-with-subtree to rich-root yet [17:00] I've done it by pulling, I think [17:12] 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] s/file/file a bug/ [17:12] Okay [17:24] 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] Not much disk I/O, but lots of CPU eaten. === kiko-fud is now known as kiko-afk [18:10] is it safe to rm repository/obsolete_packs/*? does bzr automatically do that, and when? [18:11] dato: I think they're deleted next time it repacks. [18:12] riiight, placing the new old ones there. so it's never empty, it seems. [18:12] dato: yeah, you should only ever have one generation of obsolete packs, and so the disk usage wont grow indefinitely. [18:12] 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] but yes, you should be safe to delete it. [18:15] ok, fair enough. [18:16] I can see it being ok when pushing over sftp, since it's just a mv. [18:16] 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] which is what I'll do, pass --exclude obsolete_packs to rsync. [18:17] Why use rsync? [18:18] It's probably faster, but unless you have gigs od data here it shouldn't be that dramatic. [18:19] privet [18:19] is Ian here? [18:19] 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] bialix: no, it's a bit early yet I think. [18:20] dato: Huh. [18:20] dato: There's like a repo-push plugin. [18:20] heh, people from Oz [18:20] Erk, I can't keep track of who's who. [18:21] Peng: huh wtf, kthxbye. [18:22] bialix: He won't be in for about 3 hrs [18:22] dato: use checkouts for everything (it is what I do between by desktop and laptop and my server) [18:22] ok [18:22] He will definitely be around in 5 [18:23] but that may be too late for you [18:23] may I ask anybody else, about our user-guide [18:23] (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] bialix: you can ask, I may not tell :) [18:23] jam: nah, this suits me very fine. :) [18:24] I believe Aaron uses a local treeless repository and lightweight checkouts which he rsyncs between home and office [18:24] but that may have changed over time [18:24] since he has "repo-push" and "multi-pull" [18:24] in bzrtools [18:24] jam: Part of Oz doesn't do DST? Cool. [18:25] repo-push is not the part of bzrtools [18:25] jam: plus, I like to sync the trees as well [18:25] IIRC igc is in Brisbane (north east AU) [18:25] bialix: separate plugin... hmm, sounds a lot like bzrtools material, though. [18:25] bialix: anyway what is your user guide question? [18:26] 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] You guys seriously use rsync? You know, you added push and pull commands like 20 versions ago. [18:27] generations: 1. file versioning tools, e.g. SCCS, VCS <-- is VCS correct here? perhaps it should be RCS? [18:30] Peng: I don;t use rsync, because I'm win32-guy [18:31] bialix: I usually collapse generations 2 and 3 together, as well as 4 and 5. [18:31] To me, distributed VCS is 3rd gen. [18:32] Lo-lan-do: right now I ask as translator [18:32] bialix: You == Alexander Belchenko, the guy who's been working on repo-push and -pull? [18:32] repo-push only because James Henstridge don;t support this plugin [18:33] I'm not aware about existence repo-pull [18:34] Oh. [18:34] Okay, then. [18:34] I'm not either, then. [18:35] 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] Peng: I haven't used rsync since 0.8 [18:36] But then, I wrote the original Transport code to make remote operations possible. [18:36] jam: Oh, good. :) [18:36] bialix: The one you are looking at should be RCS [18:36] 1. file versioning tools, e.g. SCCS, RCS [18:36] is the correct programe [18:37] program [18:37] Lo-lan-do: I was working on it a bit back at our company meeting [18:37] 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] what's actually difference between revision control and version control -- for english speakers? [18:37] But I got side-tracked by everything else. [18:37] bialix: in effect, not much [18:37] jam: Heh, that tends to happen :-) [18:38] jam: revision -- is one of the hardest term to translate [18:38] bialix: http://www.m-w.com/dictionary/revision [18:38] 2: a revised version [18:38] So a revision is... a version [18:39] that is somewhat modified from another version [18:39] :-) [18:39] so "revision" has a bit more of the concept of evolving from another version [18:39] (the "re" part) [18:39] well revise maybe.. [18:40] So a "version" is a bit more standalone, and "revision" makes you think there was another one it came from [18:40] but they are pretty much interchangable [18:41] oh, thanks. version is frozen, revision is vivd [18:41] vivid [18:42] bialix: bzr.dev has already been updated to say RCS [18:42] we probably just need to regen the docs [18:42] hmm, then my mirror of bzr.dev is out-of-date [18:43] 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] Should I have filed a bug on that? [18:43] btw, question about HistoryHorizon [18:44] in ru_bzr one guy asked about such feature [18:44] he said git already has it. It's true? [18:44] Hah! [18:44] yes [18:44] bialix: git has the ability to 'graft' in history [18:44] which means your local tree claims to have more history [18:44] heh [18:44] than what gets pushed and pulled [18:44] In doc.b.o/bzr.1.0, packrepo.html works but it links to knitpack.html which 404s! [18:45] I know you can start with a snapshot, and graft in history [18:45] I don't know if you can take something that already has history [18:45] and break it [18:45] sounds very good [18:45] but I guess if you just did a fresh import [18:45] i'm thinking about this [18:45] many times [18:45] bialix: but it is one of the key items that Canonical wants in the next 6 months [18:46] also sometimes I think about semi-commit [18:46] bialix: semi-commit? [18:46] 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] something wrong with "commit + push + uncommit" ? [18:47] repo-push plugin don;t like uncommits [18:48] and I'm a bit worrying about repo history pollution by temp garbage [18:48] just make a 'repo-clone' which supplies "overwrite=True". [18:48] bialix: not a lot of garbage, and when people pull from it, it doesn't get transferred [18:48] otherwise, you could commit to the side, generate a Merge Directive for that [18:48] and send the MD [18:48] and merge it on the other side [18:49] but that still installs the revisions into the repo [18:49] yeah [18:49] Any way to get the LCA of two branches? [18:49] The other is to just use "bzr shelve" and copy your .shelf across [18:49] but you need "patch" for that [18:49] jam: bialix: you can only graft on a local client in git [18:49] Peng: yes [18:49] it doesn't propogate [18:49] lifeless: right, [18:49] I think the point is that it doesn't [18:49] no shelve is not silver bullet. it's still don;t support binary files [18:50] Peng: "bzr log -r ancestor:../other-branch . [18:50] the final '.' is probably not needed [18:50] Peng: or are you in bzrlib itself? [18:50] jam: Not in bzrlib. [18:50] lifeless: good to see you around, now go play WoW :) [18:50] IMO shelf should operate more like temp branch, not as side patch [18:51] (Actually, I just want to create a small patch that can go in bzr.1.0 and bzr.dev without cherrypicking.) [18:51] 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] dato: thanks [18:51] Peng: hmm.... I think you can do [18:51] cd bzr.dev; bzr revision-info -r ancestor:../bzr.1.0 [18:52] and then bzr branch -r XXX bzr.dev bzr.ancestor [18:52] Right. [18:52] Thanks. [18:53] If there is no revision number, then you need to use "revid:..." [18:53] Though when I just tested it, it seems to give the dotted revision number in the current branch. [18:54] Oh. [18:54] Well, I hope it did, because I just used that. [18:54] jam: I just thought: is it possible to generate snapshot of working tree packed in zip or tar.gz as semi-commit? [18:56] generating patch is not enough, because we need to know fileid for newly added files [18:57] is it safe to save snapshot of dirstate and then apply it to fresh tree? [18:57] Ouch. Branching from dirstate-with-subtree to rich-root took 108 minutes. [19:00] Lo-lan-do: ouch and a half... I don't know why it would be that slow.... [19:00] knit -> pack? [19:00] bialix: I believe if you take a snapshot of the WT and .bzr/checkout/dirstate it will work [19:00] Peng: no, rich-root is still knits [19:00] (rich-root-pack is packs) [19:00] And knit => pack is reasonably fast [19:00] jam: I think it will enough to pack unfinished work for me. will try to write plugin [19:00] pack => knit is slow [19:01] bialix: if you want to get extra fancy [19:01] you can use "tree._iter_changes" to only pack up files which have been modified [19:01] which would make for a smaller .zip file [19:01] nice, thanks [19:02] jam: Oh. [19:02]