| LaserJock | so i think somebody in LP made the other branches | 00:00 |
|---|---|---|
| LaserJock | because as bad as 1 branch is, i really want 4 of them | 00:00 |
| abentley | spiv: Were there any bugs in the format detection in 1.2? | 00:00 |
| spiv | abentley: I'm not sure. I don't see anything in NEWS about it. | 00:00 |
| LaserJock | abentley: can I force it? | 00:01 |
| bob2 | co uses the bzr default branch format, instead of the remote format | 00:01 |
| spiv | abentley: I do vaguely recall something got fixed in that area, but I think before 1.2? | 00:01 |
| abentley | Oh, doh. I forgot I defaulted checkout to --lightweight. | 00:02 |
| LaserJock | ohh | 00:03 |
| abentley | Yeah, I get that failure too. | 00:03 |
| LaserJock | k, so I'm not nuts | 00:04 |
| LaserJock | doing the checkout now | 00:04 |
| abentley | The way to force it is: bzr init --dirstate-with-subtrees $DIR; cd $DIR; bzr pull bzr+ssh://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy; | 00:05 |
| schierbeck | hey guys | 00:05 |
| jml | something weird just happened to me | 00:05 |
| ubotu | New bug: #206886 in bzr "bazaar send should support inlined content" [Undecided,New] https://launchpad.net/bugs/206886 | 00:06 |
| jml | I tried branching using 'bzr+ssh' from a server -- worked fine. Then I did branch using 'sftp' from the same server and got an authentication error. | 00:06 |
| warren | Can a bzr smart server prevent clients from deleting tags? | 00:06 |
| jml | the same machine appears under a different hostname & using a different port in my .ssh/config | 00:07 |
| LaserJock | abentley: but will that be fast? doing a bzr pull? | 00:07 |
| jml | and when I use sftp://hostname:22/, branch works. | 00:07 |
| warren | BTW, does pack-92 automatically mean you also have dirstate-tags? (or the ability to do bzr tagging) | 00:07 |
| jml | is Bazaar using one mechanism for bzr+ssh and another for sftp? | 00:08 |
| bob2 | warren: yes, pack-0.92 includes tag support | 00:08 |
| abentley | LaserJock: It certainly ought to be. | 00:08 |
| spiv | jml: it shouldn't, IIRC | 00:08 |
| LaserJock | abentley: and it won't let me do --dirstate-with-subtrees | 00:09 |
| abentley | my bad, no 's' on the end. | 00:09 |
| lifeless | LaserJock: the training trees were meant to be getting upgraded by tetet | 00:09 |
| lifeless | LaserJock: setup a local repository for them, then the cost of all 4 is minimally more than the cost of 1 | 00:10 |
| jml | maybe it's a bug in openssh | 00:10 |
| warren | bob2, thanks for the clarification. | 00:10 |
| LaserJock | lifeless: can I do that with an existing branch? | 00:10 |
| spiv | ValueError: invalid literal for int() with base 10: '# Loom' | 00:11 |
| spiv | http://rafb.net/p/PiTZ3863.html has the full error. | 00:11 |
| lifeless | LaserJock: yes; make the repo locally, then bzr branch your existing branch into it | 00:13 |
| LaserJock | lifeless: oh! | 00:13 |
| LaserJock | I have an edubuntu-docs branch right here | 00:13 |
| spiv | lifeless: I just got an error pulling the loom trunk into my local copy, but it was resolved when I upgraded my local branch from dirstate to pack-0.92. | 00:14 |
| lifeless | spiv: bizarre | 00:14 |
| spiv | lifeless: full traceback in the pastebin above | 00:14 |
| lifeless | just looks like a corrupt file | 00:15 |
| spiv | lifeless: want a copy of the troublesome branch? Or a bug report? | 00:15 |
| lifeless | spiv: it looks like the knit code being handed a loom current file | 00:16 |
| lifeless | spiv: which is really bizaare | 00:16 |
| lifeless | spiv: uhm, if you can make it reproducable sure | 00:17 |
| spiv | lifeless: yep, I can reproduce. | 00:17 |
| lifeless | cool <damn> | 00:18 |
| spiv | :) | 00:18 |
| lifeless | then I'd like enough stuff to reproduce it please :) | 00:18 |
| abentley | I can't reproduce spiv's error, though I think I've seen it before. | 00:18 |
| spiv | lifeless: http://people.ubuntu.com/~andrew/loom-pull-case.tar.gz has the branch | 00:19 |
| LaserJock | hmm, so how do I make a share repository? | 00:19 |
| spiv | lifeless: I simply did "bzr pull", which pulled from bzr+ssh://bazaar.launchpad.net/~bzr-loom-devs/bzr-loom/trunk/ | 00:19 |
| warren | lifeless, btw, if I'm converting a huge repository from dirstate to pack-92, should I use bzr-1.3 or is 1.1 fine? | 00:20 |
| lifeless | LaserJock: for a svn converted project, bzr init-repo --rich-root-pack path | 00:20 |
| lifeless | warren: 1.1 is fine | 00:20 |
| ubotu | New bug: #206890 in bzr "Help pages for merge and pull should tell users about bundles" [Undecided,New] https://launchpad.net/bugs/206890 | 00:20 |
| lifeless | warren: after the conversion, just run bzr reconcile | 00:20 |
| warren | Do tags come across in merges? | 00:22 |
| warren | foo-trunk> pull ../foo-bar (which has its own tags); bzr merge; bzr ci, are tags from foo-bar visible in foo-trunk now? | 00:23 |
| LaserJock | lifeless: so does a shared repo mean that a new branch will take common revisions from the local repo? | 00:25 |
| abentley | lifeless: PQM has committed my last merge request, but not published it. | 00:26 |
| abentley | Could you give it a whack please? | 00:26 |
| lifeless | abentley: 'log' ? | 00:27 |
| lifeless | abentley: was the merge request for yoru log changes ? | 00:27 |
| abentley | No, it was for pulling lp: locations | 00:28 |
| lifeless | so if pqm didn't publish, it will have rolled back | 00:28 |
| lifeless | let me look for an error | 00:28 |
| abentley | Last time I tried, it told me "nothing to merge". | 00:29 |
| lifeless | ok; weird then | 00:29 |
| LaserJock | dang, even a local branch takes quite some time | 00:33 |
| LaserJock | I seriously wonder if we shouldn't just start over | 00:33 |
| abentley | LaserJock: You're branching from a location in your shared repo into another location in your shared repo? | 00:34 |
| LaserJock | no | 00:34 |
| LaserJock | from a branch I already had outside my shared repo into the shared repo | 00:34 |
| LaserJock | but it's still local | 00:35 |
| abentley | A branch in a different format? | 00:35 |
| LaserJock | no | 00:35 |
| LaserJock | I don't think so | 00:35 |
| abentley | lifeless told you to use rich-root-pack. You didn't? | 00:35 |
| LaserJock | yep, same formate | 00:35 |
| LaserJock | oh, you're right | 00:36 |
| LaserJock | ok, that makes sense then | 00:36 |
| abentley | So what you are hitting is an unoptimized conversion path. | 00:36 |
| LaserJock | can two bzr instances run at the same time? | 00:36 |
| abentley | Sure. | 00:36 |
| abentley | They can't both write to the same thing at the same time, of course. | 00:37 |
| LaserJock | I started doing the local branch at the same time I'm doing a bzr pull | 00:37 |
| LaserJock | and the bzr pull doesn't seem to be doing anything | 00:37 |
| abentley | You should probably wait until the local branch is done anyhow. | 00:37 |
| abentley | But bzr+ssh doesn't give great progress indicators. | 00:38 |
| * LaserJock notes that after 26 min :-) | 00:38 | |
| LaserJock | so it looks like it's gonna be about 40 min to do the local branch | 00:39 |
| abentley | How big is this data? | 00:39 |
| LaserJock | well, the branch is 217MB | 00:40 |
| LaserJock | .bzr is 211MB | 00:40 |
| LaserJock | that's why I'm wondering about starting over | 00:41 |
| LaserJock | we're carrying so much history around for like 6MB | 00:41 |
| abentley | That seems extremely disproportionate. | 00:43 |
| LaserJock | well, the size of the "working tree" has grown and shrunk quite a bit with time | 00:43 |
| LaserJock | the size of the files in my branch probably won't ever get over ~20MB | 00:44 |
| LaserJock | but the ubuntu-docs branch is probably more like 100-150MB | 00:44 |
| LaserJock | it's just a frustration because it used to take < 5min or so to do a SVN checkout and that worked well for us | 00:47 |
| LaserJock | we're trying to get to the same level with bzr | 00:47 |
| LaserJock | but I think our project is not a great example :/ | 00:47 |
| lifeless | LaserJock: once you have your repo seeded, upgrade it to rich-root-pack, because that is lots faster :> | 00:48 |
| LaserJock | you mean push the new branch back up to LP? | 00:49 |
| spiv | LaserJock: with a shared repo locally and rich-root-pack as the format, it'll be much snappier. The coming stacked branches feature will also help. | 00:49 |
| LaserJock | spiv: I hope so :-) | 00:51 |
| lifeless | LaserJock: no, I don't mean push | 00:52 |
| LaserJock | I guess I didn't get it then | 00:53 |
| LaserJock | what branch do I want to upgrade? | 00:53 |
| LaserJock | the one I'm making should be already rich-root-pack right? | 00:53 |
| lifeless | abentley: your patch is published | 00:54 |
| abentley | lifeless: tx | 00:54 |
| lifeless | LaserJock: what does bzr info on the repository you created say its format is ? | 00:54 |
| LaserJock | lifeless: just a sec, it's just finishing branching | 00:56 |
| LaserJock | Shared repository with trees (format: rich-root-pack) | 00:57 |
| LaserJock | that's the share repo obviously | 00:57 |
| LaserJock | and the new branch is: | 00:57 |
| LaserJock | Repository tree (format: rich-root-pack) | 00:57 |
| LaserJock | so that took about 36min to branch locally, just FYI | 00:57 |
| LaserJock | now I'm trying a bzr branch of one of the other branches | 00:59 |
| LaserJock | ohh, that's much better | 01:01 |
| lifeless | james_w: so, were did we get to | 01:08 |
| lifeless | james_w: right, file ids. are they deterministically allocated? do you generate correct merge graphs? (that is, does 'bzr check' give no errors on an imported branch) | 01:09 |
| === mw is now known as mw|out | ||
| * igc food | 02:23 | |
| === arne^ is now known as _arne^ | ||
| nir | where is bzr 1.3 for ubuntu? | 02:24 |
| nir | https://launchpad.net/~bzr/+archive contains only 1.2.1 | 02:25 |
| kgoetz | aiui, coming | 02:25 |
| * mneptok jumps up and down on kgoetz | 02:46 | |
| * kgoetz bruises painfully | 02:46 | |
| mneptok | how's tricks, Kaiserlicious? | 02:48 |
| kgoetz | mneptok: pretty good. gobuntu is a bit quiet atm, but other things i;m involved in a fairly lively :) | 02:49 |
| kgoetz | how is the support hotseat these days? | 02:51 |
| mneptok | kgoetz: getting hotter as more customers don;t like the fact we don't officially support Hardy yet | 02:56 |
| jamesh | mneptok: I'd have thought they'd have moved on to Intrepid by now. | 02:58 |
| kgoetz | mneptok: hehe. and i assume it'll keep warming up until well after release | 02:58 |
| mneptok | kgoetz: you got that right | 02:58 |
| mneptok | jamesh: usually that's ~3m after libc drops into the next release ;) | 02:59 |
| kgoetz | ;) | 02:59 |
| eugeneoden | anyone here familiar with bzr-loom? | 03:08 |
| spiv | Several, including me. | 03:08 |
| lifeless | yay get_parents hath died | 03:10 |
| eugeneoden | spiv: hello. you helped me with bzr-svn branch problem last monday at the sprint. on the plane i started working on a deloomify command for bzr-loom and was wondering if anyone else was interested in that functionality. | 03:14 |
| jelmer | lifeless: btw, if you think setting the inventory_sha1 to "" in bzr-svn is a bad idea, please speak up :-) | 03:15 |
| lifeless | jelmer: its a terrible idea | 03:16 |
| spiv | eugeneoden: I think so, jam filed some bugs on bzr-loom including one asking for a command to deloomify. | 03:16 |
| lifeless | eugeneoden: I think you'll find that that is in the TODO already :) | 03:16 |
| spiv | eugeneoden: https://bugs.edge.launchpad.net/bzr-loom/+bug/203285 | 03:17 |
| ubotu | Launchpad bug 203285 in bzr-loom "unable to "de-loom" a branch" [Undecided,New] | 03:17 |
| eugeneoden | cool. i might have seen it somewhere - i'm not familiar enough with this stuff to come up with changes on my own. | 03:17 |
| jelmer | lifeless: worse than using a sha1 from a semi-random serializer? | 03:18 |
| lifeless | jelmer: well, perhaps you might be more clear about what you mean | 03:18 |
| lifeless | jelmer: do you mean 'when you call repository.get_revision(X) on a SvnRepository, the inventory_sha1 will be blank' | 03:18 |
| lifeless | jelmer: or do you mean 'the revisions in a pack repository pulled from SvnRepository have an inventory_sha1 of ""' ? | 03:19 |
| lifeless | jelmer: or perhaps you mean both | 03:22 |
| lifeless | jelmer: so for the former, I think None is appropriate if svn has no validator | 03:22 |
| lifeless | jelmer: for the latter it must be the validator returned by add_inventory (which will be the case if you use anything other than the lowest level apis for inserting into the pack repository) | 03:23 |
| eugeneoden | spiv, lifeless: i took a brute-force approach to start with - deleting last-loom and reverting the branch format. ran into locking issues - LoomSupport.unlock() attempts to record any changes before calling the superclass unlock() and fails if last-loom has been deleted. | 03:26 |
| lifeless | eugeneoden: I suggest: lock(); write new format, unlock(), delete last-loom in that order | 03:28 |
| lifeless | it will have to be a valid loom at unlock time | 03:28 |
| eugeneoden | makes sense | 03:28 |
| eugeneoden | lifeless: would it be better to insist that all threads have been combined except for the last implicit one or should deloomify combine all threads, leaving the contained changes as uncommited modifications? | 03:30 |
| jelmer | lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory | 03:31 |
| lifeless | jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision... | 03:32 |
| lifeless | jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :> | 03:32 |
| lifeless | eugeneoden: I would say that you must have one and only one thread or supply a --force. | 03:33 |
| lifeless | eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check. | 03:33 |
| eugeneoden | ok, sounds good. | 03:34 |
| jelmer | lifeless: heh, commit builder is only used for the other way around :-) | 03:34 |
| jelmer | lifeless: add_revision doesn't appear to set revision.inventory_sha1 | 03:35 |
| spiv | jelmer: I'm getting 'bzr: ERROR: Revision {('svn-v3-trunk0:bbbe8e31-12d6-0310-92fd-ac37d47ddeeb:trunk:22922',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c7c74c>".' when I try to update my Twisted import with current bzr-svn stable | 03:35 |
| jelmer | spiv: does "bzr selftest svn" pass? | 03:37 |
| jelmer | spiv: if not, please file a bug | 03:37 |
| jelmer | I'm getting some sleep :-) | 03:37 |
| lifeless | bbiab | 03:38 |
| spiv | jelmer: ok | 03:39 |
| spiv | jelmer: thanks | 03:39 |
| lifeless | yay internode suckage | 03:41 |
| lifeless | jelmer: if you replied to me, I missed it | 03:41 |
| lifeless | 14:30 < jelmer> lifeless: But add_revision takes an inventory already - there should be no need to call add_inventory | 03:41 |
| lifeless | 14:31 < lifeless> jelmer: right, add_revision(...,inventory=X) does sha1 = self.add_inventory(X); revision.inventory_sha1=sha1; self._add_revision... | 03:41 |
| lifeless | 14:32 < lifeless> jelmer: but! you shouldn't be calling add_revision anyhow, we built CommitBuilder just for you :> | 03:41 |
| lifeless | 14:32 < lifeless> eugeneoden: I would say that you must have one and only one thread or supply a --force. | 03:41 |
| lifeless | 14:32 < lifeless> eugeneoden: and on force it wouldn't need to do any complex stuff, just skip the check. | 03:41 |
| lifeless | 14:33 < lifeless> bbiab | 03:41 |
| lifeless | 14:38 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr | 03:41 |
| spiv | lifeless: he replied: | 03:43 |
| spiv | 14:34 < jelmer> lifeless: heh, commit builder is only used for the other way around :-) | 03:43 |
| spiv | 14:35 < jelmer> lifeless: add_revision doesn't appear to set revision.inventory_sha1 | 03:43 |
| spiv | And he also said < jelmer> I'm getting some sleep :-) | 03:43 |
| spiv | lifeless: and with that, I think you're back in sync | 03:43 |
| lifeless | yay bugs | 03:44 |
| lifeless | jelmer: thats clearly a bug; care to fix ? | 03:44 |
| poolie | lifeless: nice response to sjturnbull | 03:53 |
| * lifeless bows | 03:54 | |
| LaserJock | lifeless: so in the end I the branching into the shared repo too 36 min and a subsequent bzr branch of another ubuntu doc branch took 90 min | 04:08 |
| LaserJock | if that makes any sense | 04:09 |
| lifeless | LaserJock: into the same shared repo ? | 04:11 |
| LaserJock | yeah | 04:11 |
| lifeless | LaserJock: what does 'bzr info' on the second branch (in the repo) say | 04:11 |
| LaserJock | Repository tree (format: rich-root-pack) | 04:11 |
| LaserJock | and it said it's part of the shared repo | 04:12 |
| lifeless | ok | 04:12 |
| lifeless | 90 minutes - I have to guess that the remote format is knits | 04:12 |
| LaserJock | it's interesting that there is such a difference in repo sizes | 04:13 |
| LaserJock | the edubuntu-docs branch (the one I did the local branch into the shared repo) is 5.5MB | 04:13 |
| LaserJock | the ubuntu-docs branch which is the one I did the bzr branch on afterwards is 205MB | 04:14 |
| lifeless | LaserJock: did you do that one into the shared repo ? | 04:14 |
| LaserJock | yes | 04:15 |
| LaserJock | I guess the .bzr is small though | 04:15 |
| lifeless | can you ls .bzr/ on that one ? | 04:15 |
| LaserJock | the first is 108K and the second is 1.4M | 04:15 |
| LaserJock | so it's just a difference in "working tree" size | 04:16 |
| LaserJock | and the shared repo .bzr is 198MB | 04:16 |
| lifeless | ok | 04:16 |
| LaserJock | so it looks like the shared repo is working well | 04:17 |
| lifeless | perhaps the svn conversion used silly svn 'branch' layers, and grabbed too much data. | 04:17 |
| LaserJock | 90 min isn't great, but at least it's a lot better than doing the whole stinkin' thing | 04:18 |
| LaserJock | I believe it only had to get 178 revisions to do the ubuntu-docs branch | 04:18 |
| LaserJock | seems like 90 min for 178 revisions is a lot | 04:18 |
| LaserJock | we're at revision 3781 so if that scaled that means it would take almost 32 hrs to do the full branch | 04:20 |
| LaserJock | so it must take a lot to do the conversion between formats | 04:20 |
| lifeless | whats the url of the second branch you made? the launchpad url I mean | 04:20 |
| * igc bbl - school pickup today | 04:20 | |
| LaserJock | http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ | 04:21 |
| LaserJock | lifeless: btw, I really do appreciate your help and all the effort the bzr team puts into bzr and the LP hosting | 04:26 |
| LaserJock | sorry if my frustration and inability to "get" bzr sometimes made me seem cranky | 04:27 |
| lifeless | LaserJock: bzr info http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ | 04:33 |
| lifeless | Standalone branch (format: dirstate-with-subtree) | 04:33 |
| lifeless | Location: | 04:33 |
| lifeless | branch root: http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/ | 04:33 |
| lifeless | LaserJock: ^ its in knit format, which means lots of round trips | 04:33 |
| lifeless | LaserJock: as I thought :> | 04:33 |
| lifeless | chat to tetet about this :) | 04:33 |
| LaserJock | so maybe we can get that changed on the LP server? | 04:34 |
| LaserJock | this shared repo stuff is fantastic | 04:35 |
| lifeless | ;) | 04:45 |
| LaserJock | now, is it right that I can remove everything from a branch but the .bzr/ without ill effect? | 04:48 |
| lifeless | LaserJock: 'bzr remove-tree' | 04:49 |
| LaserJock | hot dog | 04:49 |
| abentley | bad lifeless: please promote "reconfigure --branch" instead. | 04:50 |
| LaserJock | so now I have both edubuntu-docs and ubuntu-docs branches and it's 14MB *smaller* than my previous edubuntu-docs branch | 04:50 |
| lifeless | abentley: perhaps 'bzr remove-tree' could do that advertising for me :) | 04:51 |
| lifeless | jelmer: thanks | 04:52 |
| LaserJock | abentley: how would I then get the tree back, reconfigure --tree? | 04:52 |
| abentley | LaserJock: Right. | 04:53 |
| LaserJock | I'm kinda confused/amazed. How can the ubuntu-hardy .bzr only be 40K? | 04:55 |
| LaserJock | there's 178 revisions difference between the edubuntu-hardy and ubuntu-hardy branches | 04:55 |
| lifeless | LaserJock: the .bzr in a shared repository only contains the branch pointer | 04:55 |
| LaserJock | does it store all revisions in the shared repo and then the individual branches only hold what revisions belong to the branch | 04:55 |
| LaserJock | I was thinking it would hold the revisions that were not in common | 04:56 |
| lifeless | that would reqire continual shuffling to keep that property | 04:58 |
| lifeless | all it does is move the database out of the branch and to a centralised location | 04:58 |
| poolie | abentley: i haven't read all of all the threads, but i don't think there is a standard way to launch them | 05:29 |
| poolie | it is basically like unix MUAs | 05:30 |
| poolie | in that to control them in detail, you need to use which one you're calling | 05:31 |
| poolie | i may be out of date though | 05:31 |
| abentley | poolie: But at least Gnome and KDE provide a standard way of launching them, to say nothing of Windows and Mac. | 05:31 |
| lifeless | gnome and kde focus on usability though | 05:31 |
| lifeless | the standard way to configure emacs is to write lisp | 05:31 |
| abentley | I just don't want to wind up with an endless proliferation of mail clients. | 05:32 |
| lifeless | me neither | 05:32 |
| lifeless | We could say 'get your client registered with xdg-mail' | 05:33 |
| poolie | well | 05:33 |
| lifeless | but that doesn't deliver a fix to the users in the short term | 05:33 |
| abentley | That requires a GUI desktop, I think. I could see backlash. | 05:33 |
| lifeless | we could promote a 'sensible-mail' alias for debian* systems :> | 05:33 |
| abentley | Does debian not provide a "sensible-editor"? | 05:34 |
| bob2 | it does | 05:34 |
| abentley | I meant "sensible-mail". | 05:34 |
| abentley | It's late. | 05:34 |
| lifeless | it does, but editor & mail client are different I thought :> | 05:34 |
| lifeless | there is no sensible-mail on my system | 05:34 |
| jdong | sensible-editor Conflicts: emacs *ducks* | 05:34 |
| * TFKyle wonders what it is, nano or something? | 05:34 | |
| abentley | jdong: Hey, play nice. | 05:34 |
| jdong | :) | 05:34 |
| abentley | They're Bazaar users now, we should make them feel welcome. | 05:35 |
| lifeless | let me register right now | 05:35 |
| lifeless | that if php switches to bzr | 05:36 |
| lifeless | I will _not_ stop trolling | 05:36 |
| LaserJock | :-) | 05:36 |
| bob2 | check out the flock() page in the user-editable php docs sometime | 05:37 |
| TFKyle | think it'd be very hard to convert their cvs repo to bzr anyway (well, need a bit of automagic encoding detection iirc, the commits are in various encodings) | 05:37 |
| TFKyle | s/commits/commit messages/ | 05:37 |
| bob2 | how does cvs handle that? | 05:38 |
| bob2 | just throw raw bytes at the terminal with 'cvs log'? | 05:38 |
| lifeless | cvs spits at encodings | 05:38 |
| TFKyle | think so | 05:38 |
| lifeless | TFKyle: if you detected each one well, you could stuff it into bzr just fine | 05:38 |
| lifeless | TFKyle: unless a single commit had multiple encodings :> | 05:39 |
| lifeless | k gents, thats all she wrote; | 05:52 |
| bob2 | that emacs patch unfairly discriminates against gnus users, anyway | 05:54 |
| abentley | lifeless: What if MySQL switches? | 05:56 |
| * abentley clocks out of the channel just after an Oz resident. | 06:04 | |
| ufuntu | hello :) | 06:16 |
| mdke | hi there. We at the ubuntu-doc project have completed our first release cycle of using bzr, it's gone relatively well! However our branch history is pretty huge so we're just trying to decide whether to start a fresh branch for the next cycle. I'd like feedback on potential advantages and disadvantages | 08:25 |
| mdke | as I see it the advantages are that we can move to the new bzr format (we are currently using a bzr-svn format) and that the branch will be (much) quicker to download | 08:26 |
| mdke | obviously the disadvantage is that we lose the history but we can probably live with that. Are there any other disadvantages? | 08:26 |
| Peng | "new bzr format"? | 08:27 |
| Peng | mdke: You can use rich-root-pack, which is (a variation of) the new pack format. | 08:28 |
| Peng | mdke: I hate losing history, so I'd say don't do that. If performance is really that bad, grit your teeth until there are further improvements, or switch to git or hg or something. :P | 08:29 |
| mdke | Peng: right, I meant the pack format which comes with bzr 1.0 | 08:29 |
| mdke | Peng: what are the reasons you hate losing history? | 08:30 |
| Peng | mdke: OTOH, if svn's history didn't import well, starting with a clean slate might be nice. | 08:30 |
| Peng | mdke: "Because.". It's...history. You're not supposed to lose it. | 08:30 |
| mdke | Peng: alright... | 08:32 |
| Peng | mdke: So, in summary, I'm no help at all. :P | 08:32 |
| mdke | we'd have the history in the branches for the previous releases, I guess | 08:32 |
| mdke | we wouldn't abandon those | 08:33 |
| Peng | mdke: I'd say that you shouldn't throw out the history unless you really, really need to. | 08:33 |
| Peng | Would you be maintaining the previous branches in svn or bzr? | 08:33 |
| mdke | in bzr, we imported all of them | 08:33 |
| mdke | the branch size is currently 200MB on disk | 08:34 |
| Peng | Ouch. | 08:37 |
| * igc dinner | 08:38 | |
| Peng | That's about the size of the entire history of Python imported into bzr. | 08:38 |
| mdke | there ya go. | 08:38 |
| Peng | And that has *really* bad performance. | 08:38 |
| Peng | (35 or 38k revisions per branch, some large number of files.) | 08:39 |
| Peng | (Oh, 36k.) | 08:39 |
| mdke | we're only at 3700 revisions | 08:39 |
| TFKyle | mnm, I should try branching that | 08:39 |
| mdke | although I suppose it might not be comparable, given that our material is all text | 08:39 |
| mdke | and translations of text | 08:39 |
| Peng | 4000 files. | 08:40 |
| mdke | Peng: do you know whether if members download the branch without revision history, they can still push to our master branch on launchpad? | 08:40 |
| Peng | mdke: What do you mean? Bzr needs the history. Well, you can use lightweight checkouts, but that would be slow. | 08:41 |
| mdke | yeah, I meant lightweight checkouts | 08:41 |
| Peng | TFKyle: They distribute it as a tarball. :( | 08:41 |
| mdke | so that would be corresponding slow to push? | 08:41 |
| Peng | mdke: Well, there's zero history stored on the client. Even "bzr status" would have to get some information from the server. And, obviously, that's slower than the local disk.. | 08:42 |
| TFKyle | Peng: indeed, hadn't completely read the page yet (just read bcannons post mentioning it a little while ago) | 08:42 |
| mdke | Peng: yeah, not great. So I think the answer is either to drop the history, or figure out why it's so damn huge | 08:43 |
| === thekorn_ is now known as thekorn | ||
| mdke | and do something about it | 08:43 |
| Peng | mdke: Huge number of files? Did anyone accidentally commit an ISO? | 08:43 |
| mdke | hah | 08:43 |
| mdke | I can't figure out how to exclude history from a "du" command | 08:44 |
| lifeless | mdke: I can look at your tree tomorrow sometime | 08:45 |
| lifeless | mdke: I strongly urge you to do nothing in terms of discarding history for about 4 months. some good shit in the pipeline | 08:45 |
| mdke | lifeless: that would be great :) I just want to check it's not a wild goose chase and the problem isn't just a large working tree | 08:45 |
| mdke | maybe it's bigger than I thought | 08:46 |
| lifeless | I think someone familiar with bzr scaling needs to look at your tree & history to make an assessment of whats going on | 08:46 |
| lifeless | *I* suspect svn conversion breakage | 08:46 |
| lifeless | for now, I have to go. tchau. | 08:46 |
| mdke | lifeless: ciao | 08:46 |
| mdke | ah shit. The working tree is 200MB... I wasn't counting the history before | 08:48 |
| mdke | I've got that in a shared repo | 08:48 |
| mdke | which is around 1.6GB | 08:48 |
| mdke | my .bzr directory is 635MB | 08:49 |
| mdke | I'll come back tomorrow and have a chat with lifeless | 08:49 |
| mdke | thanks all | 08:49 |
| === _arne^ is now known as arne^ | ||
| poolie | > With regard to writing style, I agree with Steven Turnbull - the | 08:54 |
| poolie | yeh | 08:54 |
| poolie | bad paste | 08:54 |
| poolie | mdke: if you branch out of that repository into a new one it will carry only the relevant history | 08:55 |
| awilkins | Does the "new" format support rich roots? | 08:57 |
| awilkins | I'm in a similar situation, large SVN repo (~1.5GB), large number of medium - large files, about 13000 revisions... I've not finished converting mine over yet though | 08:58 |
| awilkins | Just finishing off the trunk, then I shall work on the branches | 08:58 |
| awilkins | THen I can see what kind of performance is available | 08:58 |
| Peng | awilkins: pack-0.92 has a rich-root variant called rich-root-pack and a subtree variant called pack-0.92-subtree. Even if you're currently using dirstate-with-subtree, you can probably upgrade to only rich-root-pack. | 09:06 |
| dato | Peng: to pack-0.92-subtree, you mean. and possibly to rich-root-pack, but it'll be very ver slow afaik. | 09:11 |
| Peng | Oops, I should've said "If you're currently using dirstate-with-subtree *with bzr-svn*". | 09:12 |
| Peng | dato: What would be slow? Why? | 09:12 |
| dato | -subtree -> -rich-root is slow, I think | 09:12 |
| Peng | Oh. | 09:12 |
| Peng | You may be correct. I'm branching ubuntu-doc's dirstate-with-subtree branch over bzr+ssh into a rich-root-pack right now, and it's going about as fast as a bzr-svn conversion (thankfully without the svn memory leaks though ;) ). | 09:15 |
| Peng | into a rich-root-pack repo* | 09:15 |
| awilkins | Peng: I meant the "dev" format ; I'm already using rich-root-pack | 09:15 |
| Peng | awilkins: Oh. Shrug. That's equivalent to packs right now, isn't it? | 09:15 |
| awilkins | I don't know what the benefits are... | 09:15 |
| awilkins | Aside : what's the custom-merge support like ATM? | 09:16 |
| awilkins | i.e. per-file merge handler? | 09:16 |
| Peng | Yeah, there isn't a rich-root variant of the development format, because having three different variants of it would be a pain for little benefit. | 09:16 |
| jml_ | *sigh* | 09:18 |
| Peng | ? | 09:18 |
| jml_ | mischan | 09:18 |
| Peng | Haha, it's pulling one revision every 2-3 seconds. | 09:35 |
| Peng | It just took 39 seconds for one. | 09:36 |
| gioele | hello | 10:04 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| Arturik | http://www.meine-nackte-ex.net/?uid=143312 | 13:29 |
| Arturik | http://www.meine-nackte-ex.net/?uid=143312 | 13:31 |
| gioele | hello | 13:35 |
| gioele | do latest bzr versions maintain the concept of "revision ghosts"? | 13:40 |
| fullermd | I think they have to, since bzr has them. | 13:43 |
| gioele | bloody modem | 13:53 |
| gioele | so, revision ghosts are still present | 13:54 |
| gioele | http://bazaar-vcs.org/Revision (now old and outdated ;)) says that revision can be saved in .bzr/repository and .bzr/branch . Do you have an example of when revisions are saved in branches and not in repositories? | 13:55 |
| fullermd | I don't think that's what it says. | 13:56 |
| fullermd | (that is, not what it means by what it's saying) | 13:56 |
| fullermd | It's using 'repo' in reference to a shared repo, contrasted with a non-shared colocated repo. | 13:57 |
| gioele | what does it mean then? | 13:57 |
| gioele | ah | 13:57 |
| fullermd | Cue back to my grumpings over the years about the plethora of overloadings of 'branch'. | 13:57 |
| gioele | but... | 13:58 |
| gioele | should I read it as "when bazaar is given the option of deciding how to store a revision, it uses the shared repository" | 13:59 |
| fullermd | I didn't say the page was particularly _clear_ :) | 13:59 |
| gioele | but then, does that mean that you can have a standalone tree inside a shared repository? | 13:59 |
| fullermd | I'm not sure what that sentence is talking about anyway. It's either getting way too deep into internals, or referring to something ancient, or just plain double-talking. | 14:00 |
| gioele | just to make sure: revisions are never stored under .bzr/branch | 14:00 |
| fullermd | Sure. Just take a standalone tree, and mv it into the repo. Or create a repo above it. | 14:00 |
| fullermd | Correct. | 14:00 |
| fullermd | There's no way using bzr to make a branch in a repo become standalone currently (reconfig should grow that and its complement), but the construct itself is perfectly possible. | 14:01 |
| gioele | ok, .bzr/branch does not store revisions. I'll go ahead and forget that that wiki page exist ;) | 14:01 |
| gioele | anyway. I make a little test. If you move a standalone tree inside a shared repo, a commit will store the new revision in the standalone tree, not in the shared repo. | 14:16 |
| abentley | gioele: I have updated http://bazaar-vcs.org/Revision. Is it clearer now? | 14:18 |
| gioele | abentley: yes | 14:21 |
| gioele | now, if I get it correctly, http://bazaar-vcs.org/StandaloneBranch is wrong when it says «Standalone branches contain two components: The RCS data and a working tree.» To have or not to have a working tree is not inherent to a standalone branch | 14:24 |
| abentley | gioele: right. | 14:25 |
| abentley | gioele: I've tried to clean up http://bazaar-vcs.org/StandaloneBranch | 14:36 |
| gioele | how come a shared repo (bzr init-repo) contains .bzr/branch-{format,lock}? | 14:36 |
| fullermd | Well, it's gotta have something declaring it a bzrdir. Specific naming is historical. | 14:39 |
| gioele | abentley: I'd change the last part of the last sentence with something like "by grouping them under a shared repository as repository branches" | 14:39 |
| gioele | ah, branch-format is really bzrdir-format, not related to the concept of branch | 14:40 |
| abentley | gioele: Good suggestion. | 14:42 |
| yacc | Aahh! | 14:46 |
| yacc | bzr: ERROR: Installed bzr version 1.3 is too old to be used with bzr-svn, at least 1.4 required | 14:46 |
| yacc | Guess that means that I need a "build-from-source" bzr? | 14:47 |
| abentley | yacc: where do you get your bzr-svn from? | 14:47 |
| yacc | bzr-svn: from a bzr co (stable branch) | 14:48 |
| yacc | bzr from Debian | 14:48 |
| abentley | Then you should also get your bazaar from there. | 14:48 |
| abentley | We also have our own deb repository, if you prefer. | 14:48 |
| yacc | We do? | 14:49 |
| yacc | :) | 14:49 |
| abentley | Hmm. | 14:49 |
| yacc | Ok, let me google for it :) | 14:49 |
| abentley | Or does that only support ubuntu? | 14:49 |
| jelmer | yacc: if you use bzr-svn from its development branch, use bzr.dev | 14:50 |
| gioele | abentley: ppa is ubuntu only | 14:50 |
| gioele | abentley: you left "turning them" in the last sentence of http://bazaar-vcs.org/StandaloneBranch ;) | 14:50 |
| yacc | jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/stable/ is the devel branch of bzr-svn then? | 14:50 |
| abentley | yacc: If you're using debian sid or lenny, those also contain bzr-svn. | 14:52 |
| abentley | gioele: Actually, I like turning them better, because "grouping them" implies that just moving the branches will make them use the shared repo. | 14:53 |
| yacc | abentley: yeah, but, I'm not sure if that dusty taste is that great. ;) | 14:53 |
| gioele | abentley: «speed up operations by turning them grouping them under a shared repository as repository branches» | 14:53 |
| gioele | you have to choose one :P | 14:53 |
| abentley | gioele: Okay, fine. | 14:55 |
| jelmer | yacc: yes | 14:56 |
| yacc | abentley: guess I'll checkout bzr.dev then, deinstall bzr from Debian, and install from bzr.dev. Which makes me btw wonder if easy_install has a way to get releases from bzr branches as it has for svn? *wonder* | 14:56 |
| james_w | yacc: you can run bzr from source really easily | 14:57 |
| james_w | yacc: though is there a reason you are using bzr-svn later than 0.4.9? | 14:57 |
| === mw|out is now known as mw|not-out | ||
| yacc | james_w: good question, let say I had some fun last week push to some hosted svn repos. I'm not sure if jelmers good work solved the issue, or if I've got it configured differently which would mean that 0.4.9 might work for me. | 14:59 |
| === mw|not-out is now known as mw | ||
| james_w | yacc: well you can either switch to the 0.4.9 branch, or use bzr from source | 15:01 |
| james_w | which is "bzr branch lp:bzr", and then make the bzr script from that be in your path ahead of /usr/bin, or use an alias. | 15:01 |
| === mw is now known as mw|mtg | ||
| yacc | lp:bzr? | 15:09 |
| yacc | Not http://www.bazaar-vcs/bzr/bzr.dev/ ? | 15:09 |
| james_w | grabs the trunk from launchpad, you can use the full URL if you like. | 15:09 |
| james_w | yeah, that's fine as well. | 15:10 |
| gioele | spam: http://bazaar-vcs.org/jackcity | 15:10 |
| gioele | bye bye, thank you for the clarifications | 15:11 |
| yacc | james_w: no need to install the bzr branch stuff beside a symlink? | 15:11 |
| james_w | nope, bzr figures it all out. | 15:12 |
| yacc | nice, now I just need to pull bzr.dev via UMTS, which seems to take time, time, time, | 15:17 |
| yacc | At least it's a bandwidth limitation and not latency that I see here :) | 15:17 |
| === mw|mtg is now known as mw | ||
| === lamont` is now known as lamont | ||
| mw-home | anybody in here using the nautilus plugin for bzr? I installed it, now what? I don't see those fancy icons. | 15:27 |
| === kiko is now known as kiko-fud | ||
| yacc | Ah :) | 15:37 |
| yacc | james_w: where is the plugins directory of such a "devel" bzr? | 15:37 |
| mw-home | maybe I need to enable the nautilus plugin/ | 15:37 |
| james_w | yacc: either ~/.bazaar/plugins | 15:39 |
| james_w | or in the plugins directory within the branch | 15:40 |
| james_w | bzrlib/plugins/ | 15:40 |
| mw-home | thanks | 15:40 |
| yacc | so /usr/lib/python2.4/site-packages/bzrlib/plugins just has to move ;) | 15:40 |
| warren | Anyone know how to upgrade the repository format of my repo in launchpad? | 15:40 |
| warren | bzr get FOO; bzr upgrade --pack-0.92; bzr push (doesn't work) | 15:41 |
| asabil | warren: push --overwrite ? | 15:44 |
| james_w | warren: bzr upgrade <url> | 15:44 |
| asabil | oh didn't know that was possible | 15:45 |
| warren | [warren@newcaprica mkdst]$ bzr upgrade "bzr+ssh://wtogami@bazaar.launchpad.net/%7Eltsp-upstream/mkdst/mkdst-trunk/" | 15:45 |
| warren | bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. | 15:45 |
| warren | (but it isn't) | 15:45 |
| james_w | what happens if you pass --pack-0.92 | 15:46 |
| warren | same error message | 15:46 |
| warren | asabil, push --overwrite means everyone has to blow away their tree and pull again from scratch? | 15:47 |
| asabil | warren: yes am afraid | 15:47 |
| james_w | only if a push without --overwrite says that they have diverged | 15:48 |
| jelmer | warren: you'd want to upgrade over sftp | 15:48 |
| james_w | and they could use merge to get back on track, but the change that you overwrite would then still be present. | 15:49 |
| warren | jelmer, will upgrade over sftp be REALLY slow if you have a huge repository? | 15:50 |
| warren | jelmer, and afterward they will need to pull from scratch anyway? | 15:50 |
| jelmer | warren: it will be pretty slow, yes | 15:51 |
| jelmer | warren: but no need for anybody to pull from scratch afteewards | 15:51 |
| warren | too bad there's no button on launchpad to do conversion | 15:51 |
| warren | I'm converting a small repository first | 15:51 |
| warren | but soon I'm doing a huge one | 15:52 |
| mw-home | Anyone running the nautilus plugin? I can't get it to work. More specifically, I don't see the bzr icons inside nautilus. | 16:01 |
| mw-home | brb | 16:03 |
| warren | hmm | 16:06 |
| warren | should I worry about this? | 16:06 |
| warren | repository converted | 16:06 |
| warren | bzr: ERROR: No such file: '/~ltsp-upstream/ltspfs/ltspfs-trunk/.bzr/branch/last-revision': [Errno 2] /~ltsp-upstream/ltspfs/ltspfs-trunk/.bzr/branch/last-revision | 16:06 |
| james_w | warren: doing what? | 16:06 |
| warren | james_w, that was at the end of bzr upgrade --pack-0.92 sftp://wtogami@bazaar.launchpad.net/%7Eltsp-upstream/ltspfs/ltspfs-trunk/ | 16:06 |
| james_w | hmm, that sounds pretty bad. | 16:07 |
| james_w | is the branch still usable? | 16:07 |
| warren | no idea | 16:08 |
| james_w | "bzr log -r 1 mailto:sftp://wtogami@bazaar.launchpad.net/%7Eltsp-upstream/ltspfs/ltspfs-trunk/" should tell you | 16:08 |
| james_w | ah, without mailto:, sorry | 16:08 |
| yacc | jelmer: Any idea what this can mean: bzr: ERROR: Revision {('svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs:44',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c3db6c>". | 16:09 |
| warren | james_w, seems to be OK | 16:09 |
| warren | james_w, so far I've only upgraded two of our smaller repos, I'm afraid what will happen with our larger repos... | 16:09 |
| james_w | warren: could you pastebin the relevant part of ~/.bzr.log please? | 16:10 |
| warren | james_w, uh... where would that log go? | 16:12 |
| warren | oh, i see. | 16:12 |
| warren | james_w, oh damn, it was a traceback | 16:13 |
| james_w | I'm interested in all of the output for that command, so before the traceback as well please. | 16:14 |
| warren | james_w, http://people.redhat.com/wtogami/temp/bzrcrash.txt | 16:17 |
| james_w | warren: can you file a bug with that information please? It looks pretty serious to me. | 16:19 |
| james_w | though it may be harmless, but it's not a good thing to happen. | 16:19 |
| warren | james_w, this is bzr-1.1 because somebody here yesterday said it should be fine. should I use 1.3? | 16:20 |
| warren | james_w, I don't know where/how to file bugs | 16:21 |
| james_w | warren: https://bugs.launchpad.net/bzr/+filebug | 16:22 |
| james_w | 1.3 may have it fixed I guess, would you be able to try that? | 16:22 |
| warren | I can upgrade | 16:22 |
| warren | james_w, should I revert my launchpad repo? how? | 16:23 |
| warren | james_w, is there a way I can check the integrity of my repository? | 16:25 |
| warren | [warren@newcaprica ltspfs-trunk]$ bzr info | 16:27 |
| warren | Standalone tree (format: unnamed) | 16:27 |
| warren | what does unnamed mean? | 16:27 |
| james_w | bzr check is for checking | 16:28 |
| warren | james_w, if I can revert my repo, I can test 1.3 to see if the same problem happens. How do I revert it on the launchpad server? | 16:29 |
| james_w | you would need to ask a launchpad admin I think. | 16:30 |
| warren | james_w, if bzr check doesn't complain I shouldn't worry? | 16:38 |
| james_w | warren: correct | 16:38 |
| warren | ok | 16:39 |
| james_w | but please still report it, as even if it doesn't cause a problem it is still worrying for users | 16:39 |
| ubotu | New bug: #207201 in bzr-svn "bzr branch against https svn url breaks" [Undecided,New] https://launchpad.net/bugs/207201 | 16:41 |
| jelmer | yacc: hmm, sounds like you hit the same problem that spiv was seeing | 16:43 |
| yacc | jelmer: what can I help to debug it? | 16:44 |
| yacc | guess the fact that I get no branch means that I cannot run bzr check on it ;( | 16:45 |
| jelmer | yacc: not sure, I should probably try to reproduce it first | 16:47 |
| yacc | jelmer: I can retry it it with -Dcommit? | 16:47 |
| jelmer | yacc: this is a regression in the 0.4 branch btw | 16:47 |
| jelmer | yacc: can you perhaps confirm this problem doesn't occur with 0.4.9? | 16:48 |
| yacc | jelmer: how can I get the needed versions via bzr? | 16:49 |
| jelmer | yacc: the 0.4 branch should have a bzr-svn-0.4.9 tag | 16:49 |
| yacc | I have branches of bzr-svn stable and bzr.dev on my laptop, so I was thinking along the idea of not apt-get installing the revisions you want me to try ;) | 16:49 |
| jelmer | yacc: you can update to bzr-svn 0.4.9 by running something like "bzr pull --overwrite -rtag:bzr-svn-0.4.9" I think | 16:50 |
| yacc | jelmer and how do I switch it back to have the newest revision? | 16:53 |
| yacc | btw, you have forgotten to tag 4.9, 0.4.7 is the newest one. | 16:54 |
| james_w | jelmer: nice job on the performance improvements. | 16:55 |
| jelmer | james_w: thanks | 16:56 |
| === kiko-fud is now known as kiko | ||
| ubotu | New bug: #207211 in bzr "upgrade --pack-0.92 sftp:// failed (but worked...)" [Undecided,New] https://launchpad.net/bugs/207211 | 17:03 |
| barry | hello folks! i have some shelved changes that no longer apply cleanly to the working tree. i don't want to lose my shelved changes. what's the cleanest way to view or merge them? | 17:04 |
| barry | what will bzr unshelve --force do? | 17:04 |
| james_w | thanks warren | 17:04 |
| james_w | barry: I believe it will run patch such that it leaves the .failed files around or whatever they are called. | 17:06 |
| ubotu | New bug: #207216 in bzr ""bzr tags" should take URL argument" [Undecided,New] https://launchpad.net/bugs/207216 | 17:06 |
| james_w | i.e. it will apply the hunks it can, and those it can't will be left for you to merge by hand. | 17:07 |
| barry | james_w: ok, i can handle that :) thanks! | 17:07 |
| * barry gives it a try... | 17:07 | |
| === pmezard_ is now known as pmezard | ||
| barry | okay, unshelve --force doesn't change the shelve. is there a way to manually discard the shelve, since i don't need it any more? | 17:09 |
| james_w | it will be a subcommand of "shelf" | 17:13 |
| james_w | I suspect "shelf delete" | 17:13 |
| james_w | "shelf delete PATCH" | 17:13 |
| james_w | "shelf ls" will give you the name. | 17:13 |
| barry | james_w: thanks! | 17:15 |
| jelmer | yacc: strange, I don't see the tag here either | 17:17 |
| fullermd | Mmph. Do we really want to say "straight-jacket" in the Guide? | 17:17 |
| jelmer | yacc: I assumed that "bzr merge" brought them in | 17:17 |
| jelmer | I don't have my tree here at the moment | 17:18 |
| jelmer | but I'll see if I can fix that later tonight | 17:18 |
| jelmer | yacc: for now, please use the 0.4.9 tarball | 17:18 |
| yacc | jelmer: will take some time, have to go hunt the family dinner. | 17:19 |
| james_w | fullermd: in reference to another system? | 17:20 |
| fullermd | Well, the usage I saw was in reference to centralized development patterns... | 17:20 |
| james_w | I would prefer not to, but I don't think it's necessarily that bad. | 17:21 |
| fullermd | Oh, I don't mean conceptually or tone-wise. | 17:21 |
| fullermd | I mean that it's a really common misspelling, and it seems actually sufficiently common that some places accept it, but it always looks crappy to me. | 17:21 |
| james_w | ah, I never knew how it was spelt. | 17:22 |
| rexbron | hello, would anyone be able to tell me the best way to merge two branches (or working trees) via bzrlib? | 18:44 |
| * rexbron also thinks this would be a good section on the Integrating with bzr page on the wiki | 18:45 | |
| james_w | it would, yes | 18:45 |
| james_w | my first guess is WorkingTree.merge(other_branch), but I'll have to look | 18:46 |
| james_w | close | 18:46 |
| james_w | from bzrlib import workingtree | 18:47 |
| james_w | from bzrlib import branch | 18:47 |
| james_w | other_branch = branch.Branch.open('wherever') | 18:47 |
| james_w | tree = workingtree.WorkingTree.open('wherever') | 18:47 |
| james_w | other_branch.lock_read() | 18:48 |
| james_w | try: | 18:48 |
| james_w | tree.lock_write() | 18:48 |
| james_w | try: | 18:48 |
| james_w | conflicts = tree.merge_from_branch(other_branch) | 18:49 |
| james_w | finally: | 18:49 |
| james_w | tree.unlock() | 18:49 |
| james_w | finally: | 18:49 |
| james_w | branch.unlock() | 18:49 |
| james_w | you can then do something with conflicts, let me look what it is | 18:49 |
| rexbron | james_w: does tree get locked automatically? | 18:49 |
| rexbron | sorry | 18:49 |
| rexbron | I forgot the lock_read() was for tree | 18:50 |
| james_w | conflicts is a number, so you can just check for > 0 | 18:50 |
| james_w | if you need to know what they are, ask the tree | 18:50 |
| james_w | merge_from_branch can take a revision to merge, otherwise it just defaults to the tip of other branch. | 18:51 |
| rexbron | ok thanks | 18:55 |
| rexbron | james_w: the workingtree method rever is undocumented, but i think I can appy similar logic. Could you tell me what the old_tree varriable is for? | 18:58 |
| rexbron | s/rever/revert/ | 18:58 |
| james_w | it's the tree to revert to I believe. | 19:00 |
| james_w | leaving it as None will mean that it uses the basis tree. | 19:00 |
| james_w | i.e. like "bzr revert" | 19:00 |
| rexbron | james_w: kk | 19:01 |
| rexbron | james_w: can revert(filenames) accept a list? | 19:02 |
| rexbron | hey andrea-bs | 19:03 |
| andrea-bs | hi rexbron | 19:03 |
| james_w | rexbron: it should be a list | 19:03 |
| rexbron | ok | 19:03 |
| james_w | so a single filename should be a list of a single value | 19:03 |
| james_w | I can't remember whether it's [] or None for all files. | 19:04 |
| abentley | It's None | 19:04 |
| james_w | ah, None | 19:04 |
| james_w | thanks abentley | 19:04 |
| rexbron | james_w: would it be interchangeable with a set? | 19:05 |
| james_w | should be I guess. | 19:05 |
| rexbron | I guess it might be worth creating a test case | 19:05 |
| james_w | yep :-) | 19:06 |
| james_w | I don't see why there would be any ordering *required* | 19:06 |
| james_w | whether the current implementation assumes it or not I'm not so sure about. | 19:06 |
| rexbron | james_w: I am working on an existing codebase that uses sets, I am not sure atm if I would be able to use lists instead | 19:07 |
| rexbron | I could always just filenames=list(set) | 19:08 |
| abentley | rexbron: "best" way to merge depends on context. WorkingTree.merge is probably the simplest. merge.Merger.from_revision_ids is the most powerful. | 19:08 |
| rexbron | abentley: In my case, I just need to merge the latest revision | 19:08 |
| lifeless | rexbron: A set should be fine | 20:04 |
| rexbron | lifeless: cool | 20:04 |
| awmcclain | Hi all... anyone have a rough sense when the smart server will accept -u -p ? | 20:19 |
| james_w | awmcclain: sorry, can you explain what you mean by that? | 20:23 |
| awmcclain | james_w: So, right now I'm using bzr with capistrano to manage our entire server farm. RIght now I'm sharing our repo via http:// (since I don't want to automatically create and setup new SSH key for each new machine). The http:// is restricted by domain, but we're running into DNS propogation issues for new boxes. Long story short, I'm waiting for a time when I can just pass in a user/password via command line to the bzr server. | 20:26 |
| james_w | ah, so you want an authenticated smart server over bzr:// | 20:26 |
| james_w | ? | 20:26 |
| malept | hi, does anyone know when the PPA is going to be updated for bzr/bzrtools 1.3? | 20:26 |
| awmcclain | Exactly! | 20:27 |
| james_w | malept: I don't know, sorry, what release are you running? | 20:27 |
| james_w | awmcclain: I know some people are nervous about adding authentication to the smart server | 20:27 |
| awmcclain | Really, I'm just wondering if that's in the roadmap. | 20:27 |
| awmcclain | Becuase they feel that bzr+ssh:// handles it fine? | 20:28 |
| james_w | I'm not sure what the reasons are | 20:28 |
| awmcclain | +) | 20:28 |
| james_w | I think one may be that getting it right would be hard. | 20:28 |
| james_w | as in adding an authentication system opens a whole can of worms | 20:29 |
| awmcclain | Ah. | 20:29 |
| awmcclain | Ok, I can look into different roads around this then. | 20:30 |
| james_w | however, it keeps coming up, so I definitely wouldn't rule it out. | 20:30 |
| awmcclain | Right. | 20:30 |
| james_w | if you wanted to take it a step forward then contributing some use cases and design ideas would be good. | 20:30 |
| awmcclain | Oh, great. I see if I can work on that this weekend. | 20:31 |
| awmcclain | Seems like the type that could leverage existing design patterns, at least. | 20:31 |
| awmcclain | *type of thing | 20:31 |
| awmcclain | Maybe borrow from oAuth. I dunno. I'm talking from a point of naîveté | 20:32 |
| awmcclain | ok, great. | 20:32 |
| james_w | yeah, I'm sure there's stuff we can re-use | 20:33 |
| lifeless | awmcclain: you could use https + password auth | 20:39 |
| lifeless | awmcclain: authentication is tricky to get right; don't want to design our own (duh), but even implementing (say) rfc2617 digest is a pita | 20:42 |
| lifeless | awmcclain: so *if* we can avoid rolling our own, and still satisfy our users: thats a win. | 20:43 |
| lifeless | vila: do we support http/digest ? | 20:43 |
| awmcclain | lifeless: Very true... but could bzr pass in the u/p on the command line? | 20:43 |
| warren | how do you bzr push if your only change is a new tag? | 20:44 |
| awmcclain | lifeless: It has to be non-interactive | 20:44 |
| vila | lifeless: yes | 20:44 |
| lifeless | awmcclain: https://user:pass@host/ | 20:44 |
| bob2 | awmcclain: in the url | 20:44 |
| lifeless | vila: ^ that still works right ? | 20:44 |
| awmcclain | lifeless: You just made my day! Perfect! | 20:44 |
| lifeless | awmcclain: or you can write to the cached credentials file yourself before running bzr | 20:44 |
| lifeless | awmcclain: or you can provide a UI plugin for bzr that will supply passwords from an arbitrary source | 20:45 |
| vila | lifeless: yes | 20:45 |
| awmcclain | lifeless: Or just put it in the url. ;) | 20:45 |
| lifeless | warren: you may have found a bug | 20:45 |
| james_w | warren: I think there is currently a bug open saying that you are not able to do that from the UI | 20:45 |
| * warren vaguely recalls reporting this a long time ago | 20:45 | |
| warren | oh, no, I reported a different bzr tag bug, since fixed. | 20:46 |
| awmcclain | Thank you so much for your help, everyone. I say this every time, but, the community and IRC is why I evangelize bzr | 20:46 |
| lifeless | :P | 20:47 |
| james_w | thanks awmcclain | 20:47 |
| * warren commits a worthless change in order to tag it | 20:48 | |
| james_w | lifeless: hi | 20:49 |
| james_w | sorry I disappeared during out fast-import chat. | 20:49 |
| james_w | I'm around now if you want to have another go | 20:50 |
| warren | lifeless, wow! | 20:51 |
| warren | lifeless, bzr push did push the tag upstream but it didn't say anything happened | 20:51 |
| warren | lifeless, so it actually is pushing and pulling tags properly, it just is not informative so the user thinks is isn't happening. | 20:54 |
| jelmer | yacc: the tags for 0.4.8 and 0.4.98 should be present now | 20:58 |
| jelmer | it looks like bzr doesn't add the tags to the master branch when merging but only to the local branch | 20:58 |
| lifeless | james_w: hi yes | 21:14 |
| james_w | hi lifeless | 21:14 |
| james_w | so, you asked about deterministic file-ids or something? sorry, I lost the scrollback. | 21:18 |
| lifeless | james_w: well | 21:21 |
| lifeless | james_w: I am concerned about how file ids are being handled by fast-{im,ex}port | 21:22 |
| lifeless | james_w: your comment on the list suggests some fundamental design issues, and they can lead to extremely poor conversions, or at worst an inconsistent distributed datbase | 21:23 |
| james_w | the cache is buggy, and I'm going to rip it out and use the parent inventories as you suggested. I wonder if your concerns run deeper than that though> | 21:24 |
| lifeless | well, the presence of the cache suggests some misunderstanding of what commit has to do (and thus what a converter has to do) | 21:26 |
| lifeless | so I'd rather dig a little deeper :) | 21:26 |
| james_w | perhaps | 21:26 |
| james_w | I'm happy to do that, as I'm sure we'll get a better system out of it. | 21:27 |
| lifeless | how do you allocate file ids in import revisions ? | 21:28 |
| james_w | currently the cache looks up based on the path and returns a file-id if any previously imported revision has that path, otherwise it generates a new random id. | 21:29 |
| james_w | that is buggy for separate branches as I explained, so the alternative is to have a per-branch cache, or to just use the parent inventories | 21:30 |
| james_w | the former means that a file can be deleted and resurrected, which I'm not sure is a desirable property | 21:31 |
| mc__ | is it possible to push over http? | 21:32 |
| james_w | mc__: not unless you have the smart server set up for http, or the webdav plugin. | 21:33 |
| mc__ | hm alright, we have bzr installed on our vserver. we 2 core devs push over sftp. someone else made some changes. he does not have ssh access to our server. how can he send us his changes? | 21:34 |
| james_w | bzr send --mail-to your-email | 21:34 |
| james_w | then you can save the attachment and run "bzr merge attachment" | 21:35 |
| james_w | check the results, commit and then push | 21:35 |
| mc__ | does that require smtp/sendmail on the server where bzr is installed? | 21:35 |
| james_w | no, he's emailing you | 21:36 |
| lifeless | james_w: per branch cache would be buggy, because fastexport streams can represent renames :> | 21:36 |
| mc__ | so he needs to have smtp installed on his machine? | 21:36 |
| james_w | so you can receive it on your workstation, save it there, commit there, and then push to your central server | 21:36 |
| james_w | mc__: he needs an email client. | 21:37 |
| james_w | it will use the default linux or windows client, or can be set to certain other clients | 21:37 |
| james_w | (mac as well I think) | 21:37 |
| james_w | lifeless: it may be possible to avoid problems there, but I don't know the ordering constraints on the stream well enough to say whether it will always be avoidable. | 21:38 |
| james_w | lifeless: but the parent inventories should be the easier solution anyway | 21:39 |
| lifeless | yup | 21:39 |
| mc__ | alright,thank you | 21:39 |
| james_w | however we still have the issue that we are importing in to a file-id based system from a stream that isn't based on file-ids, and which comes with recommendations to not generate rename entries. | 21:40 |
| james_w | so I think we need some rename detection somewhere along the line. | 21:40 |
| james_w | mc__: no problem. Please feel free to ask if you have any more queries. | 21:40 |
| lifeless | james_w: why ? | 21:42 |
| lifeless | james_w: or to put it another way, we don't do rename detection for cvs. why should we do it for git ? | 21:43 |
| james_w | I think we should do it for all systems. | 21:43 |
| james_w | git is currently the least likely to be imported this way I think. | 21:43 |
| james_w | it's just that the documentation says something like "add and delete is just as efficient for the importer as rename entries, so use the former" | 21:44 |
| lifeless | so file a bug | 21:44 |
| james_w | so, it's possible the exporter will discard information. | 21:44 |
| james_w | that's true, I'll bring it up with Shawn. | 21:44 |
| lifeless | saying that its not true for all importers; exporters should not discard information they don't have to | 21:45 |
| james_w | yep | 21:45 |
| lifeless | as for applying heuristics during import conversion; this precludes any opportunity for incremental or repeatable imports | 21:46 |
| lifeless | unless some very hairy tricks are pulled (ask jelmer about svn mappings and revision ids) | 21:46 |
| james_w | I'm not sure that's entirely true is it? | 21:48 |
| james_w | it would require that the import heuristics be stable across releases though | 21:48 |
| lifeless | it requires they be stable forever for the same source tree | 21:49 |
| lifeless | forever is a long time | 21:49 |
| james_w | yes, which is a big commitment | 21:49 |
| james_w | I agree with your argument. | 21:49 |
| lifeless | I have a negative aleph-nought I prepared earlier for voting on this commitment :) | 21:49 |
| james_w | :-) | 21:50 |
| james_w | so, that leaves bzrlib, but I'm a long way away from trying to put it in there. | 21:50 |
| lifeless | now, at some point it may be worth doing; in which case we break existing imports and do mapping versioning | 21:50 |
| lifeless | or we add heuristics to the deterministic stuff we already have (and there is no reason we can't do this). file ids are a tool not a straight jacket | 21:51 |
| spiv | lifeless: thanks for the review of the protocol version query change. Do you think that I should deprecate Transport.get_smart_client now? | 21:51 |
| lifeless | spiv: With Extreme Prejuidice | 21:52 |
| spiv | lifeless: excellent :) | 21:52 |
| spiv | lifeless: thanks | 21:52 |
| abentley | lifeless: Does that mean yelling racist insults at it while deprecating it? | 21:54 |
| mw-home | does anyone know how I could use vimdiff with bzr diff? | 21:56 |
| abentley | mw-home: bzr diff --using vimdiff | 21:56 |
| abentley | There is also a vimdiff plugin. | 21:57 |
| james_w | lifeless: Repository.get_revision_graph | 21:58 |
| mw-home | abentley: that failed. | 21:59 |
| mw-home | $ bzr diff --using vimdiff templates/administer/myaccount.kid | 21:59 |
| mw-home | bzr: ERROR: no such option: --using | 21:59 |
| mw-home | do i need the vimdiff plugin first? | 21:59 |
| lifeless | james_w: just nuked it, what about it ? | 21:59 |
| abentley | mw-home: What version of bzr do you have? | 21:59 |
| james_w | you said there is no replacement, but is the replacement .get_graph() and use graph methods? | 21:59 |
| mw-home | 1.0.0 | 21:59 |
| abentley | It was added in 1.1 | 21:59 |
| lifeless | james_w: there isn't a direct replacement | 22:00 |
| mw-home | oh, whoops | 22:00 |
| abentley | But you can use the plugin instead. | 22:00 |
| mw-home | ok, now i will learn how to use plugins. | 22:00 |
| lifeless | james_w: get_graph().get_parents_map returns ghost parents | 22:00 |
| james_w | lifeless: but it should be graph based now right? | 22:00 |
| james_w | I'm just interested in what the recommended way to get history information is. | 22:01 |
| lifeless | james_w: same as its been since 0.9x | 22:01 |
| lifeless | james_w: repository.get_graph() | 22:01 |
| mw-home | how do i install a plugin? | 22:01 |
| james_w | great. I've not dealt with this sort of thing until recently, I've only used the highest level stuff. | 22:02 |
| james_w | lifeless: thanks for the clarification. | 22:02 |
| mw-home | ignore me. | 22:02 |
| malept | james_w: wrt to your PPA distro inquiry, I'm running Feisty. (sorry about the delayed answer...was AFK) | 22:03 |
| mw-home | should i checkout or branch a plugin? | 22:03 |
| james_w | malept: that's cool, was just wondering if you were on hardy, as that will hopefully get a direct update soon. | 22:03 |
| malept | james_w: yeah...the box in question is a production machine, so it probably won't be upgraded to hardy until may-ish. | 22:04 |
| abentley | mw-home: probably branch. | 22:04 |
| james_w | fair enough. | 22:04 |
| james_w | malept: hopefully someone will push the updates to the PPA soon. | 22:05 |
| lifeless | poolie: ^ is 1.3 in the ppa? | 22:05 |
| mw-home | thanks for the help. I got the plugin working. plugins are neat. | 22:08 |
| === RAOF_ is now known as RAOF | ||
| mw-home | I'm not sure I understand how to share a repository over the intarweb. Do I just set up a repository in the docroot of my webserver? | 22:20 |
| lifeless | mw-home: that will do just fine | 22:20 |
| mw-home | lifeless: but how do i accept inputs? | 22:21 |
| lifeless | spiv: I'm curious, what will | 22:21 |
| lifeless | source = target = source do ? | 22:21 |
| mw-home | is that when I also need to allow sftp access? | 22:21 |
| lifeless | mw-home: you have folk publish them themselves, or send them to you with 'bzr send' | 22:21 |
| mw-home | lifeless: wow. now i get the difference between svn and bzr. everybody can run their own web-accessible read-only server, and we all pull from each other. | 22:22 |
| lifeless | spiv: I *think* it binds the current value of target to source and that is all | 22:22 |
| spiv | lifeless: in python? It does right-to-left, IIRC, so I think you're right. | 22:22 |
| spiv | lifeless: I'm pretty sure it takes the right-most thing, and assigns it to each of the "foo =" parts. I forget if it does that left-to-right or right-to-left, but I guess it doesn't matter in your case :) | 22:24 |
| spiv | lifeless: ah, yes, it does evaluate the right-hand expression, then assigns it to each target left-to-right. | 22:25 |
| lifeless | so if target = source returned the old value of target | 22:26 |
| lifeless | then that would be a nice one liner :> | 22:26 |
| spiv | lifeless: so anyway, yes, in your case it's like you just did "target = source" | 22:26 |
| spiv | lifeless: the canonical way to swap two variables is "a, b = b, a". I'm not sure if that's the fastest. (Ideally the compiler would optimise that idiom, though...) | 22:28 |
| lifeless | clever | 22:28 |
| oleavr_ | is there a way to disable bzr-svn integration on a specific branch? | 22:48 |
| === oleavr_ is now known as oleavr | ||
| jelmer | oleavr: "bzr --no-plugins" | 22:49 |
| igc | morning all | 22:51 |
| poolie | spiv: call now? | 23:03 |
| spiv | poolie: dialling now | 23:04 |
| Peng | Haha, it took 5.5 hours to branch lp:~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy. | 23:11 |
| oleavr | jelmer: so there's no way to set some metadata on a branch for that? | 23:12 |
| bob2 | what does bzr-svn do when dealing with bzr branches? I'd've thought it only kicked in when a svn branch was involved. | 23:13 |
| jelmer | bob2: it does | 23:13 |
| jelmer | oleavr: why would you want that, anyway? | 23:13 |
| oleavr | jelmer: in order to have the SVN data (.svn) stored so that I can manage it manually without bzr-svn interfering (I want to handle merging from upstream by hand, typically 'quilt pop -a', 'svn up', 'quilt push') | 23:18 |
| lifeless | oleavr: you might consider looms :P | 23:18 |
| jelmer | oleavr: yeah, sounds like you could use bzr-svn and looms fine there.. | 23:19 |
| jelmer | oleavr: if you're running svn up in that directory anyway, why do you care if bzr uses bzr-svn ? | 23:19 |
| jml | lifeless: how do I get a loomified branch such that I get the loom info? | 23:28 |
| oleavr | lifeless: it's a very promising project (TBH I hate quilt, not very usable when at times when you're forced to use a crappy OS), it's just that my first experience involved a major screw-up that was all my own fault, and because it all felt very 'magic' I wasn't sure how I could revert :) (I made a commit in the wrong thread and discovered it a little later) I should've spent some time to read the source figuring out how to do it, but I was runni | 23:30 |
| oleavr | jelmer: well, I've had some bad experiences with the svn integration in the past, so it was just for playing things 'safe' | 23:31 |
| jelmer | oleavr: what sort of things? | 23:33 |
| oleavr | jelmer: when I think about it it wasn't actually with bzr-svn screwing up, just the initial get/branch phase taking ages, patience running out, ditching the integration, doing an svn checkout ready to just handle it myself, and then getting annoyed by bzr-svn thinking it's dealing with a bzr-svn branch.. | 23:42 |
| spiv | jml: "bzr branch" ought to do it. | 23:53 |
| spiv | jml: the loomified branch may need "bzr record" done in it first, perhaps. | 23:53 |
| jml | spiv: with which bzr version? | 23:53 |
| spiv | jml: whatever version, I think. | 23:54 |
| spiv | jml: it's possible you're seeing something like https://bugs.edge.launchpad.net/bzr-loom/+bug/201613 | 23:55 |
| ubotu | Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged] | 23:55 |
| spiv | jml: or https://bugs.edge.launchpad.net/bzr-loom/+bug/193893 | 23:55 |
| ubotu | Launchpad bug 193893 in bzr-loom "branching over bzr+ssh does not propogate loom threads" [High,Triaged] | 23:55 |
| jml | http :) | 23:55 |
| jml | but yeah | 23:55 |
| lifeless | jml: so, this will work: | 23:56 |
| lifeless | loomify + record + branch | 23:57 |
| jml | ok. | 23:58 |
| jml | lifeless: so how do I get the looms for http://people.ubuntu.com/~robertc/baz2.0/shallow-branch? | 23:58 |
| lifeless | well, the problem there is I'm using push | 23:59 |
| lifeless | :[ | 23:59 |
| lifeless | so step 1: fix the push bug; step 2: get me to push using it | 23:59 |
| lifeless | its likely as simple as overriding push and calling self.pull in some manner | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!