| * Peng wanders off. | 00:00 | |
| igc | bbl - got some errands to run | 00:38 |
|---|---|---|
| jml | lifeless: remind me | 00:45 |
| jml | lifeless: which formats are "stackable"? | 00:45 |
| lifeless | jml: the new ones in my loom | 00:45 |
| jml | oh right, 'development' and friends | 00:46 |
| === kiko is now known as kiko-afk | ||
| === lamont` is now known as lamont | ||
| lifeless | in theory, I have now removed users of VersionedFile.get_graph | 01:21 |
| lifeless | some of the replacements are so obviously wrong I want to cry. | 01:21 |
| jml | lifeless: shallow branches are confusing me. | 01:22 |
| jml | lifeless: http://rafb.net/p/zleZ3572.html | 01:22 |
| jml | lifeless: in that example, I make a branch, push it, do a shallow branch from *that*, make some changes, then try to push it and get a fairly low level error. | 01:23 |
| lifeless | lets see | 01:24 |
| jml | lifeless: am I doing something wrong? | 01:24 |
| lifeless | jml: its a little hard to read; please consider passkeys | 01:25 |
| lifeless | but that aside | 01:26 |
| lifeless | look in sftp://localhost/tmp/server/testdoc.shallow | 01:26 |
| lifeless | in .bzr/branch/ | 01:26 |
| lifeless | there should be a stacking pointer | 01:26 |
| jml | there is no branch/ dir | 01:27 |
| jml | branch-format branch-lock README repository | 01:27 |
| lifeless | what is there | 01:27 |
| jml | that's it | 01:27 |
| lifeless | ok | 01:27 |
| lifeless | so, you are making a full branch from a shallow branch | 01:28 |
| lifeless | this is interesting | 01:28 |
| lifeless | could you try push --reference | 01:28 |
| jml | am I? | 01:28 |
| lifeless | erm, push --shallow | 01:28 |
| lifeless | yes, bzr push will make a full branch | 01:29 |
| jml | even if you are pushing from a shallow branch? | 01:29 |
| jml | that's interesting. | 01:29 |
| lifeless | this is open for tuning | 01:29 |
| lifeless | for now, --shallow is needed everywhere you want to make shallow branches | 01:29 |
| lifeless | as for why it is blowing up | 01:30 |
| lifeless | I don't know, I would appreciate a bzr blackbox test for this in the push.reference thread | 01:30 |
| jml | lifeless: "jml@rhino:/tmp/client/testdoc.shallow$ bzr push --shallow sftp://localhost/tmp/server/testdoc.shallow.shallow" works. | 01:30 |
| jml | lifeless: I can do that. | 01:31 |
| lifeless | local file paths should be enough | 01:31 |
| lifeless | jml: does 'bzr log sftp://localhost/tmp/server/testdoc.shallow.shallow' work ? | 01:32 |
| lifeless | hmm 12:30, lunchtime. bbiah | 01:32 |
| jml | lifeless: yep | 01:33 |
| jamesh | lifeless: I've uploaded the bzr-dbus changes I discussed with you a while back. There are three branches if you want to see the incremental changes. | 03:07 |
| lifeless | jamesh: thanks | 03:08 |
| lifeless | jamesh: I need to look at that soon; hopefully tomorrow I'll have enough of versionedfiles behind me to do a loom 1.3 release and bzr-dbus foo doo too | 03:09 |
| lifeless | spiv: around? | 03:09 |
| jamesh | lifeless: the lan-gateway protocol is unchanged, but the dbus interfaces change a bit | 03:09 |
| jamesh | (mainly that the Revision signal can come from any source | 03:09 |
| jamesh | lifeless: also, https://bugs.edge.launchpad.net/bzr-dbus/+bug/198645 makes the plugin less than useful with current branch formats | 03:10 |
| jamesh | since the set_rh hook isn't called for many of the interesting operations | 03:11 |
| abentley | jamesh: Branch formats since dirstate-tag have not stored the revision-history on disk; they store only the revision_id and revno of the last_revision. | 03:14 |
| jamesh | abentley: I know. The bzr-dbus plugin hooks "set_rh" to detect branch changes, which is what that bug is about | 03:15 |
| jamesh | it should be hooking post-commit, post-pull, etc | 03:15 |
| abentley | We could also have a hook on set_revision_info | 03:15 |
| jamesh | that sounds useful | 03:16 |
| jamesh | saves having to update the plugin every time a new way of modifying a branch is added | 03:16 |
| abentley | The bug suggests that bzr never invokes the set_rh hook, but it will on old-format branches. | 03:16 |
| jamesh | yeah. I should update the description | 03:17 |
| lifeless | jamesh: yeah, igc & spiv are working on that | 03:20 |
| spiv | lifeless: I'm around now | 03:22 |
| lifeless | spiv: how do you want hpss method deprecations done? | 03:22 |
| spiv | lifeless: hmm | 03:26 |
| lifeless | indeed | 03:26 |
| lifeless | did you include Warning: in your new protocol ;) | 03:26 |
| spiv | lifeless: I did include headers, so I suppose so ;) | 03:27 |
| dstanek | why is it recommended to init-repo a branch and then inside of it create other branches? | 03:27 |
| spiv | lifeless: that's a good idea | 03:27 |
| lifeless | dstanek: init-repo creates a shared repository, not a branch | 03:27 |
| lifeless | dstanek: specifically it creates a database that many branches can use to share their disk storage | 03:27 |
| lifeless | dstanek: this saves disk space and increases performance when making a new branch in a sibling diectory | 03:28 |
| lifeless | spiv: so thats the future. for now I have smart server methods I want to nuke | 03:28 |
| dstanek | lifeless: so its really all about disk space? | 03:29 |
| lifeless | dstanek: yup | 03:30 |
| lifeless | dstanek: we consider repositories to be 'storage optimisation'. there should be no features or behaviours that require a shared repository | 03:30 |
| lifeless | dstanek: if you just do 'bzr init' without having done 'bzr init-repo' you get a repository - the database - in .bzr/repository, a private one just for that branch. | 03:30 |
| bob2 | currently also handy for checking out instead of branching rich root branches | 03:30 |
| spiv | lifeless: at the moment, a comment in the implementation is the best we have | 03:30 |
| lifeless | spiv: uhm test failures | 03:31 |
| lifeless | spiv: no deprecation warnings are permitted by the test suite on pqm. | 03:31 |
| lifeless | spiv: smart server verbs call repository.get_revision_graph | 03:31 |
| lifeless | spiv: applyDeprecated doesn't really work here :/ | 03:32 |
| spiv | lifeless: ah, I see. | 03:33 |
| lifeless | so far I have thought of: | 03:33 |
| spiv | lifeless: we perhaps need a decorated SmartServer_for_Testing? | 03:33 |
| dstanek | lifeless: in order to use the shared repository you create a branch in a subdirectory of the repository right? | 03:33 |
| lifeless | dstanek: yes | 03:34 |
| spiv | lifeless: or more evilly, something that temporarily overrides a specific request handler to suppress warnings... | 03:34 |
| spiv | lifeless: other ideas are welcome | 03:34 |
| spiv | lifeless: I assume this is a method that connect be sensibly re-implemented to avoid the deprecated API? | 03:35 |
| lifeless | no | 03:37 |
| lifeless | the method is one that is being deprecated | 03:37 |
| lifeless | so I have thought of: | 03:37 |
| lifeless | - private reimplementation | 03:37 |
| lifeless | - _method version which isn't deprecated | 03:37 |
| lifeless | - global flag which causes Request.do to catch deprecations | 03:38 |
| lifeless | so specificially | 03:40 |
| lifeless | Repository.get_revision_graph | 03:40 |
| lifeless | is | 03:40 |
| lifeless | VersionedFile.get_graph | 03:40 |
| lifeless | with fillips | 03:40 |
| lifeless | so is beind deprecated | 03:40 |
| lifeless | forcing all Repositories to implement Repository._get_revision_graph is an api break | 03:41 |
| lifeless | deprecations are about not breaking apis | 03:41 |
| lifeless | so I think I have to have an implementation on the smart server request | 03:41 |
| lifeless | which doesn't call the old one | 03:41 |
| lifeless | but this still leaves open the question of how to tell clients they should upgrade | 03:41 |
| lifeless | brain diarreha completed | 03:42 |
| lifeless | spiv: ^ any comments | 03:48 |
| lifeless | abentley: still up ? | 03:49 |
| abentley | yep | 03:50 |
| lifeless | there are two uses of get_revision_graph in log.p | 03:50 |
| spiv | lifeless: I think telling clients to upgrade is probably something for a header in protocol v3 | 03:50 |
| ubotu | New bug: #206330 in bzr "bzr diff --using <whatever> crashes if no commit has been made" [Undecided,New] https://launchpad.net/bugs/206330 | 03:50 |
| lifeless | I am deprecating this function; does your patch remove either/both - should I merge it to my branch | 03:50 |
| spiv | lifeless: otherwise if you can teach RemoteRepo to avoid the problematic smart method I guess that's enough for now. | 03:51 |
| lifeless | spiv: I have to fix the method for old clients | 03:51 |
| lifeless | spiv: I didn't consider, for a fraction of a second, using self._real | 03:52 |
| spiv | I didn't think you did :) | 03:52 |
| abentley | lifeless: It's in mainline now. | 03:52 |
| abentley | It doesn't remove either one, but it moves them around. | 03:53 |
| lifeless | ok | 03:53 |
| lifeless | well I'll remove them | 03:53 |
| lifeless | really need a bread first search that returns the parents data | 03:53 |
| lifeless | not just the keys | 03:54 |
| spiv | Mmm, bread. | 03:54 |
| lifeless | grah | 03:54 |
| abentley | lifeless: I can imagine that'd be useful. | 03:54 |
| spiv | (not meaning to pick on a typo, just musing on the tastiness of bread!) | 03:54 |
| lifeless | abentley: it would for some of these things 1/2 the index query count | 03:57 |
| abentley | lifeless: Don't let me stop you making the API more useful. | 03:59 |
| lifeless | abentley: oh, I won't :]. | 03:59 |
| lifeless | abentley: cycles and roi | 03:59 |
| sabdfl | poolie: ping | 04:21 |
| lifeless | sabdfl: poolie is on leave today | 04:24 |
| sabdfl | lifeless: do you know why bzr 1.3 isn't yet in hardy or the ppa? | 04:39 |
| lifeless | ppa: can't say absoltelu, but I think the reason is simply that Martin (who is doing the deb maintenance now) has not had any work hours since the release: friday and monday were public holidays, and he took today as leave | 04:41 |
| sabdfl | ok | 04:42 |
| lifeless | hardy, I don't know anything any which way, but I can look into it | 04:42 |
| sabdfl | thanks | 04:42 |
| sabdfl | pretty clear we should get 1.3 in hardy | 04:42 |
| lifeless | for sure | 04:42 |
| lifeless | I will check into it before I finish today | 04:43 |
| sabdfl | not sure what our policy has been w.r.t. stable release updates into gutsy, feisty, dapper | 04:43 |
| lifeless | we've done backports | 04:43 |
| lifeless | but not made a push for stable releases; we got some [reasonable] push back in casual converstations with distro about it | 04:44 |
| lifeless | (because its not broken ..) | 04:44 |
| jdong | sabdfl / lifeless : I offered on Friday to look into getting bzr 1.3 into Hardy, but I've been running behind schedule. It's just a matter of syncing from Debian and making sure all the plugins also get updated at the same time | 04:47 |
| jamesh | lifeless: it is broken in the sense that the old versions can't access current branches ... | 04:48 |
| lifeless | jdong: awesome; do you need any help with that | 04:48 |
| jdong | as far as pushing bzr 1.3 into previous releases, so far we've been using Backports, as bzr's not 100% backwards-compatible plugin-wise which makes it a harder case for stable release updates | 04:48 |
| jdong | lifeless: I saw today that bzr-svn 0.4.9 is out which is 1.3 compatible | 04:48 |
| lifeless | yup | 04:48 |
| jdong | lifeless: I'll try to invest some time tomorrow to fill out all the paperwork :D | 04:49 |
| jdong | just did my taxes today, so enough paperwork for one night :D | 04:49 |
| jamesh | I doubt anyone wants to backport packs to bzr-0.8.2 in dapper | 04:49 |
| lifeless | jamesh: yeah not going to happen ;> | 04:49 |
| abentley | I'm upgrading Bundle Buggy. It will be down for a few. | 05:01 |
| lifeless | k | 05:01 |
| abentley | Back up. | 05:06 |
| abentley | Now with super-awesome new versions of SQLAlchemy and Elixir | 05:06 |
| lifeless | yay | 05:08 |
| Pengwn | Hi | 05:13 |
| Pengwn | If i don't want to log my undo to bzr should i do "bzr revert" or "bzr uncommit" | 05:13 |
| jamesh | abentley: you should try Storm :) | 05:14 |
| jamesh | Pengwn: "bzr revert" reverts changes in your working tree that you haven't committed yet. | 05:14 |
| jamesh | "bzr uncommit" is used to undo commits | 05:15 |
| abentley | jamesh: Yeah, like the Python world really needs three ORMs ;-) | 05:15 |
| jamesh | so it depends on what you want to do | 05:15 |
| jamesh | abentley: true. It doesn't need those other two. | 05:15 |
| Pengwn | jamesh: I accidently commited and it's at revision 10. I want my bzr in the state it was at revision 9. | 05:16 |
| Peng | What about ORMs? | 05:17 |
| Pengwn | jamesh: will uncommit do it or there's some other method ? | 05:17 |
| lifeless | abentley: at least three | 05:17 |
| lifeless | abentley: ran into a new one today, 'Mother' | 05:17 |
| Peng | Pengwn: bzr uncommit erases the commit. Then you can use bzr revert to erase the changes in the working tree. | 05:17 |
| Peng | lifeless: That makes it four. | 05:17 |
| jamesh | Pengwn: okay. Running "bzr uncommit" will take you back to r9 with the changes from r10 sitting in your local tree. | 05:17 |
| Pengwn | oh thanks Peng. | 05:18 |
| jamesh | Pengwn: if you'd previously pushed r10, you will probably need to use "push --overwrite" to push the altered branch. | 05:18 |
| Pengwn | no push done yet. | 05:18 |
| Pengwn | so I can safely uncommit then revert ? | 05:19 |
| jamesh | Pengwn: yep. If there is no other record of the commit, then there is no problem uncommitting it | 05:19 |
| jamesh | Pengwn: what "uncommit" can't do is stop people from using a revision you've previously published | 05:19 |
| Peng | SQLAlchemy, SQLObject, Elixir, Geniusql, that Canonical one. | 05:19 |
| Pengwn | cool. it's screams. | 05:19 |
| Peng | Storm! | 05:21 |
| Pengwn | Jamesh: thanks, if I am the publisher admin, I guess the uncommit and revert trick will do there as well ;-) | 05:22 |
| jamesh | Pengwn: what I mean about published revisions is this kind of situation: (1) you upload your branch to a public location, (2) someone else downloads the branch, hacks on it making a few commits and uploads those changes, (3) you uncommit some revisions and publish new versions, (4) you want to merge from the second person | 05:24 |
| jamesh | 's branch | 05:24 |
| jamesh | Pengwn: while you can remove the revision from branches you control, you can't do so from other people's | 05:24 |
| jamesh | and if you are planning to collaborate with them, you'll probably run into the uncommitted revisions again in a merge. | 05:24 |
| lifeless | Peng: sqlalchemy, sqlobject, elixir, genuisql, storm, mother | 05:26 |
| lifeless | Peng: this is at least 3 :) | 05:26 |
| Peng | lifeless: Haha. True. | 05:26 |
| bob2 | and django's (maybe for small values of 'orm') | 05:27 |
| Pengwn | jamesh: oh ok got it. yeah that would be too late a scenario for reverting/uncommiting. | 05:27 |
| Pengwn | Jamesh: I meant maybe like within a minute i published maybe it's doable. | 05:27 |
| jamesh | Pengwn: yep. In those sort of situations, you're better off leaving history as it was and making a new commit to fix the problem. | 05:27 |
| jamesh | Pengwn: just making sure you know the limitations on what uncommit can do :) | 05:27 |
| abentley | lifeless: My mistake, my patch hasn't been merged yet. | 05:28 |
| lifeless | abentley: ok | 05:28 |
| lifeless | abentley: well I've gone ahead and done the changes anyhow; I'll wear conflicts I guess | 05:28 |
| abentley | Sorry. | 05:28 |
| Pengwn | yep. got that. have some cvs/clearcase admin experience :-) | 05:28 |
| * nDuff wonders aloud (and off-topic'ly) why anyone would use an ORM other than SQLAlchemy for a new project. | 05:28 | |
| lifeless | abentley: no proba | 05:29 |
| lifeless | nDuff: well, storm was built after looking at sqlalchemy seriously | 05:29 |
| * nDuff might have to look at that one, then. | 05:29 | |
| abentley | lifeless: It was not well-advertised then. When it was released, it looked like it didn't have enough functionality to be useful. | 05:31 |
| lifeless | abentley: it may be true anyhow :> | 05:32 |
| jamesh | lifeless: to be fair, SQLAlchemy has improved since niemeyer was using it. | 05:33 |
| hazmat | the nutshell is sa is complex and does alot, and storm is simple and does just enough.. | 05:34 |
| jamesh | hazmat: that said, it does quite a lot within the problem space it covers. | 05:34 |
| hazmat | right.. but that definition is subjective ;-) | 05:35 |
| hazmat | i like sa's flexibility to work with db schema constructs, a problem space storm punts on | 05:36 |
| jamesh | yep. Storm doesn't have anything to help you manage your SQL schema. | 05:37 |
| jamesh | but then the type of schema-generation-from-python-classes I've seen in things like SQLObject was useless for a long running project. | 05:38 |
| tuxcantfly | Do the newer versions of bzr svn-push from the bzr-svn package support Sourceforge's Subversion services? I'm using 4.7-1~gutsy1 from the gutsy-backports, with bzr 1.0-1~gutsy1 (also from gutsy-backports), and I'm getting 'bzr: ERROR: Not a branch: "https://unetbootin.svn.sourceforge.net/svnroot/unetbootin/trunk/".' whenever I do 'bzr svn-push "https://unetbootin.svn.sourceforge.net/svnroot/unetbootin/trunk"' from my local bz | 05:39 |
| lifeless | jamesh: I thought sa was not capable of the multiple backend stuff storm is; which was the key thing | 05:40 |
| lifeless | tuxcantfly: I would have thought it would; I suggest you file a question on bzr-svn's launchpad answer tracker | 05:41 |
| lifeless | tuxcantfly: as jelmer, the primary author is likely asleep. | 05:41 |
| jamesh | lifeless: to be honest, I haven't investigated the guts of SQLAlchemy particularly deeply. | 05:41 |
| tuxcantfly | oh sorry, I'll do that | 05:41 |
| lifeless | tuxcantfly: nothing to be sorry about | 05:41 |
| jamesh | lifeless: I know that the cache integrity problems were one of the major reasons why niemeyer started working on Storm though | 05:42 |
| jamesh | (I believe those have been fixed in subsequent versions though) | 05:42 |
| lifeless | jamesh: all i'm trying to say is that it wasn't 'sa is too complex/buggy', but rather 'sa is by design not able to do the long term stuff we need' | 05:43 |
| hazmat | lifeless, sa can definitely handle the multiple backend stuff | 05:53 |
| hazmat | lifeless, i think that comment might originally been in reference to sqlobject.. | 05:54 |
| lifeless | could be | 05:56 |
| lifeless | I don't really collect ORM details :> | 05:56 |
| Peng | Dejavu too. | 06:01 |
| lifeless | yay, in theory, add deprecations, and done | 06:25 |
| lifeless | see you all tomorrow | 06:25 |
| * igc dinner | 08:21 | |
| ubotu | New bug: #206406 in bzr "[win32] local push finished with error message: Could not acquire lock" [Critical,Confirmed] https://launchpad.net/bugs/206406 | 09:11 |
| uniscript | this is probably a daily faq but any news on bzr-svn for bzr 1.2 or later? | 09:15 |
| fullermd | It's out for 1.3.... | 09:17 |
| uniscript | any .debs for gutsy around? | 09:18 |
| dato | james_w, jdong: bzr-svn 0.4.9 is in unstable, so bzr 1.3 could go into hardy if you wish | 09:21 |
| james_w | dato: thanks for the heads up. | 09:21 |
| james_w | uniscript: not yet, sorry. | 09:21 |
| uniscript | looks like it's only in hardy then | 09:22 |
| dato | but those debs, eg. from debian sid, will install fine on gutsy for all I know | 09:22 |
| uniscript | that was naughty pushing 1.2 to us and then breaking bzr-svn | 09:22 |
| james_w | not yet either. | 09:22 |
| dato | ("those" = bzr-svn) | 09:23 |
| james_w | ah, there's one compatible with 1.2, yes. | 09:23 |
| awilkins | jelmer: I'm having a go with bzr 1.3. / bzr-svn 0.4.9 on my "big repo" and initial impression is very favourable. It's no longer CPU-bound, for starters, so I would guess that it could be going as fast as the constraints of disk I/O will allow. | 09:54 |
| ubotu | New bug: #206443 in bzr-gtk ""bzr commit-notify" should listen for Revision signals from any source" [Undecided,New] https://launchpad.net/bugs/206443 | 09:56 |
| ubotu | New bug: #206480 in bzr-gtk "Should monitor changes in visualized branch" [Undecided,New] https://launchpad.net/bugs/206480 | 11:35 |
| === mrevell is now known as mrevell-luncheon | ||
| === mrevell-luncheon is now known as mrevell | ||
| === pmezard_ is now known as pmezard | ||
| === barry-away is now known as barry | ||
| beuno | james_w, howdy. Have you made any progress on the bazaar transition? | 14:20 |
| james_w | hi beuno, I haven't I'm afraid. | 14:21 |
| james_w | are you back in Argentina now? | 14:21 |
| beuno | james_w, yes :) :) :) back at the office | 14:22 |
| james_w | did you enjoy your holiday? | 14:22 |
| beuno | james_w, holiday? I was on holiday? I didn't know :p | 14:27 |
| beuno | I did enjoy the trip very much | 14:27 |
| james_w | :-) | 14:27 |
| james_w | I thought it was a holiday | 14:27 |
| beuno | not as much as I would of liked | 14:28 |
| === kiko-afk is now known as kiko | ||
| thekorn | hi, can any moderator of the bazaar@lists.canonical.com mailinglist please moderate my mail, I sent it before subscribing | 14:56 |
| james_w | thekorn: is it something we can help with over IRC? | 14:57 |
| thekorn | james_w, no not really, i just started to think about a FUSE filesystem for bzr | 14:58 |
| igc | night all | 14:58 |
| james_w | thekorn: ah, ok. | 14:58 |
| james_w | night igc | 14:58 |
| james_w | thekorn: I think there was a quick hack of one around somewhere | 14:58 |
| james_w | heh, I was just about to point you to your own | 15:00 |
| thekorn | james_w, hehe | 15:00 |
| === mw|out is now known as mw | ||
| dato | thekorn: maybe it'd be faster just to resend it | 15:00 |
| thekorn | dato, ok, will do | 15:01 |
| ubotu | New bug: #206574 in bzr "bzr send should reject creating empty submissions" [Undecided,New] https://launchpad.net/bugs/206574 | 15:15 |
| ubotu | New bug: #206577 in bzr "bzr send should warn on uncommitted local changes" [Undecided,New] https://launchpad.net/bugs/206577 | 15:15 |
| jelmer | jdong: are you still working on getting bzr 1.3 in hardy? | 15:22 |
| jelmer | jdong: bzr-svn 0.4.9 is now out and should be compatible | 15:23 |
| jdong | jelmer: yes, I plan on doing that a bit later today :) | 15:45 |
| === kiko is now known as kiko-fud | ||
| gioele | hi | 16:58 |
| gioele | how come bzr 1.3 is not available via PPA? | 16:59 |
| abentley | gioele: Best to ask poolie. He should be awake in ~5 hours. | 17:00 |
| === mrevell is now known as mrevell-dinner | ||
| Lo-lan-do | Hi all. Stupid question about bound branches... | 17:16 |
| Lo-lan-do | Let's assume I checkout a branch onto my laptop, then go work in a train/plane/whatever. | 17:16 |
| Lo-lan-do | I do a few commits, then when I come back home I want to re-bind. | 17:16 |
| Lo-lan-do | Is there a way not to see my commits as merges? | 17:18 |
| fullermd | Pull or push them in. | 17:18 |
| Lo-lan-do | (Assuming, of course, that the upstream branch hasn't been touched in the meantime) | 17:18 |
| Lo-lan-do | I see. push before update, I guess? | 17:19 |
| gioele | http://bazaar-vcs.org/Branch says «[bzr puts] the repository, branch, and working tree all in the same place. If there is no tree, it is called a "standalone branch".» But http://bazaar-vcs.org/StandaloneBranch says «Standalone branches contain two components: The RCS data and a working tree.» | 17:20 |
| gioele | "if there is no tree" vs "RCS and working tree" | 17:21 |
| gioele | who is right: the Branch page or the StandaloneBranch page? | 17:21 |
| Lo-lan-do | gioele: I believe the latter, but I could be wrong. | 17:24 |
| Lo-lan-do | I'm still confused about the fact that there are 4 options in bzr reconfigure (I was only expecting 3, and I don't know which one I wasn't expecting) | 17:25 |
| gioele | Lo-lan-do: I aggree, I'd call a branch without working tree a repository branch | 17:25 |
| dato | gioele: no, because it may not be in a repository | 17:25 |
| * fullermd actually expects several more options :p | 17:25 | |
| dato | a standalone branch is one that *contains* a repository | 17:25 |
| dato | if it contains a repository, it is a standalone branch, independently of whether it has a working tree or not | 17:26 |
| gioele | contains a repo == .bzr/repository esists | 17:26 |
| dato | yes | 17:26 |
| Lo-lan-do | fullermd: So what's the difference between --branch and --tree there? | 17:26 |
| dato | gioele: as opposed to "is contained in a repo" | 17:26 |
| dato | but if it has a tree, maybe the correct term would be "standalone tree", dunno | 17:27 |
| fullermd | I presume --branch turns something that isn't an isolated branch (like a checkout) into one; --tree involves the working tree. | 17:27 |
| gioele | branches contained in a repo have .bzr/branch but not .bzr/repository | 17:27 |
| gioele | isn't it? | 17:27 |
| Lo-lan-do | gioele: Right | 17:28 |
| gioele | let's write this down in my notebook :) | 17:29 |
| Lo-lan-do | fullermd: OK, I got it. --branch is for a tree-less branch, --tree is standalone branch+ working tree | 17:30 |
| Lo-lan-do | That could be made more explicit. | 17:31 |
| gioele | Lo-lan-do: patch to add this to "help reconfigure" output? | 17:31 |
| gioele | http://bazaar-vcs.org/RepositoryBranch says «This type of branch is not hackable on by users as it does not have a working tree.». This is not always true, is it? | 17:33 |
| dato | no, it is not | 17:34 |
| Lo-lan-do | Close enough: the working tree is not kept up-to-date, so it'll frequently be wrong and best ignored. | 17:34 |
| fullermd | I don't know if --branch is for an explicitly treeless branch, or simply leaves the WT alone in whatever state it's already in. | 17:35 |
| dato | Lo-lan-do: well, you can have your *work* branches in a repository; are they not RepositoryBranches? | 17:35 |
| gioele | what about "A branch that lives in a repository that has been created with --no-trees, will not be hackable by users as it will not have a working tree" | 17:35 |
| Lo-lan-do | dato: You *can*, but I wouldn't recommend that :-) | 17:35 |
| fullermd | "RepositoryBranch" only refers to the repo and branch; it doesn't say anything one way or another about the WT. | 17:35 |
| dato | Lo-lan-do: uh?, why not. I do it all the time | 17:35 |
| dato | in a --trees repository | 17:36 |
| Lo-lan-do | fullermd: reconfigure --branch removes my working tree here | 17:36 |
| fullermd | Well, I guess that demonstrates the point about detail of documentation :) | 17:36 |
| Lo-lan-do | dato: Hm. I have a non-flat structure for my branches, so I'd rather know that a directory under the repo == a branch | 17:36 |
| dato | hm. maybe I misinterpreted something | 17:37 |
| Lo-lan-do | Anyway. Back to my original question: can I programmatically extract the bind-to branch location? | 17:37 |
| dato | Lo-lan-do: Branch.get_bound_location afaik | 17:38 |
| Lo-lan-do | Aehm, I was expecting a "bzr bound-location" command or so, which I could call from shell :-) | 17:39 |
| dato | ah, that programatically | 17:39 |
| dato | info -v | grep ? :) | 17:39 |
| fullermd | Suck it out of info | 17:39 |
| Lo-lan-do | I guess I can awk bzr info | 17:39 |
| fullermd | Don't need -v | 17:40 |
| dato | ok | 17:40 |
| Lo-lan-do | Hm. But if I'm unbound, then I don't get that in bzr info. | 17:41 |
| fullermd | Mmm. I doubt it's UI exposed anywhere in that case. | 17:41 |
| Lo-lan-do | bzr info | awk -F: '/checkout of branch:/ {print $2}' | 17:42 |
| Lo-lan-do | Actually, awk -F= '/bound_location/ {print $2}' .bzr/branch/branch.conf would be faster. | 17:43 |
| Lo-lan-do | About a hundred times faster :-) | 17:44 |
| Lo-lan-do | (0.004s vs. 0.5s) | 17:44 |
| fullermd | Well, as long as we're working on performance anyway, and you've just taken the first step toward reimplmenting bzr in awk... | 17:45 |
| dato | fullermd: needs a test | 17:45 |
| dato | so half-step | 17:46 |
| Lo-lan-do | But I'm glad to hear performance is being worked on. Does that include startup time? | 17:46 |
| Lo-lan-do | I can live with complex rebases or merges taking some time, but half a second for a simple bzr info is a bit boring. | 17:47 |
| fullermd | Heck, that's nothing. See what any command does with a cold cache and my somewhat aged disks... | 17:47 |
| Lo-lan-do | I know, I was just dodging the "cold cache" counter-argument :-) | 17:48 |
| fullermd | bzr stat (wait, wait, listen to disk heads for a while, wait, trim toenails, wait, order pizza...) | 17:48 |
| Lo-lan-do | As long as you don't have time to eat the pizza :-) | 17:49 |
| fullermd | Oh, no. I haven't had time for the pizza since 0.13 or so. | 17:50 |
| jelmer | hi Lo-lan-do | 17:51 |
| Lo-lan-do | Hi jelmer :-) | 17:51 |
| jelmer | Lo-lan-do: Do you know what the chances are of f-spot not depending on beagle in the near future? | 17:51 |
| gioele | is there a standard testsuite to run in order to test performance and spot regressions? | 17:51 |
| Lo-lan-do | jelmer: No idea. You should ask diocles. | 17:52 |
| abentley | Lo-lan-do: --tree implies only "branch", not "standalone branch". It's perfectly possible to have a repository tree. | 17:53 |
| Lo-lan-do | abentley: I'm aware of that, I was just wondering about the difference between --branch and --tree in reconfigure. | 17:54 |
| Lo-lan-do | It seems --branch removes the tree, whereas --tree ensures it's there. | 17:54 |
| abentley | Yes. In your earlier comment you said --tree meant standalone branch + tree, so I thought you misunderstood. | 17:55 |
| Lo-lan-do | gioele: bzr selftest maybe | 17:58 |
| gioele | what is the name of a working tree that lives outside a branch? Checkout? And what is the name for a working tree that lives in a branch? | 17:58 |
| Lo-lan-do | Lightweight checkout for the first. | 17:58 |
| jelmer | Lo-lan-do: thanks | 17:59 |
| Lo-lan-do | Hm, bzr selftest fails some tests here. | 17:59 |
| gioele | unbinded heavyweight checkout for the latter? | 17:59 |
| abentley | Lo-lan-do: Try running with --no-plugins. | 18:00 |
| Lo-lan-do | Not a checkout, since as far as I know a checkout is synonymous with a bound branch. | 18:00 |
| Lo-lan-do | abentley: Nah, LANG=C "fixes" it. | 18:00 |
| abentley | Lo-lan-do: I can have a look. | 18:01 |
| Lo-lan-do | http://paste.debian.net/51815 for instance | 18:01 |
| * Lo-lan-do goes away to buy food before the shops close | 18:01 | |
| abentley | What's your locale? | 18:02 |
| gioele | s/unbinded/unbound/ | 18:02 |
| Lo-lan-do | fr_FR.UTF-8 | 18:02 |
| abentley | We don't really have a name for the working tree inside a branch. We just call it a working tree (but checkouts and lightweight checkouts both have working trees too). | 18:03 |
| gioele | abentley: ok | 18:04 |
| gioele | now http://bazaar-vcs.org/Revision: «Bazaar uses something called weaves to store revisions.» is that still true? Wasn't weaves the name of an old format? | 18:05 |
| abentley | That is very out of date. | 18:05 |
| tca | http://bazaar-vcs.org/BzrDevelopment links to http://bazaar-vcs.org/ReleaseRoadmap and say the latter is to be updated. Should I update the table listing releases? Or are there other plans for the page? | 18:10 |
| gioele | another question about revisions: «Revisions are stored in one of two places: either branches or repositories.» I read branches as .bzr/branch and repositories as .bzr/repository, am I right? | 18:11 |
| fullermd | I think a lot of that glossary is wildly out of date... | 18:14 |
| fullermd | I don't think it's been comprehensively examined since jblack put it together way back when. | 18:15 |
| gioele | fullermd: good, I spent last day going through it and trying to make sense of it :) | 18:18 |
| === kiko-fud is now known as kiko | ||
| === mw is now known as mw|food | ||
| rodge | hi, is there any way to push code to a branch you checked out from, and have the working tree updated without having to log into that machine and doing an update? | 19:03 |
| dato | rodge: if bzr is installed on the remote end, the push-and-update plugin | 19:12 |
| rodge | and that's the only way? | 19:12 |
| rodge | i'll take that as a yes since i have to go now :) thanks, i'll try that | 19:13 |
| beuno | rodge, yeap, or mount the remote location locally | 19:13 |
| rodge | mmk | 19:14 |
| rodge | thanks | 19:14 |
| beuno | with samba/nfs/etc | 19:14 |
| beuno | np | 19:14 |
| ubotu | New bug: #206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,New] https://launchpad.net/bugs/206728 | 19:26 |
| gioele | if the location a branch is pushed to is local (file://) it will rebuild the working tree, won't it? | 19:33 |
| dato | gioele: yes | 19:37 |
| gioele | ok | 19:37 |
| === mw|food is now known as mw | ||
| oskude | hi, im going through this http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html (under ubuntu) but after "bzr push sftp://and.so.on" it only uploads the .bzr dir, not the files im writing... what could i check ? | 21:23 |
| oskude | (and .bzr dirs content) | 21:23 |
| dato | oskude: that's expected | 21:24 |
| oskude | huh? what did i miss ? | 21:24 |
| bob2 | oskude: push only updates the working copy if it's a file:/// url (ie a local directory) | 21:24 |
| oskude | oh... | 21:25 |
| bob2 | oskude: if you want to update remote working copies, https://launchpad.net/bzr-push-and-update or 'ssh remotehost bzr update /path' | 21:25 |
| oskude | hmm, so if my server only has ftp for upload, i cant upload my code to it with bzr ? (sorry, i just started with version control:) | 21:27 |
| bob2 | not with bzr | 21:27 |
| oskude | :( | 21:28 |
| dato | nor with any other vcs afaik | 21:29 |
| oskude | dato, thanks, was just gonna ask that :) | 21:29 |
| dato | basically creating a remote tree requires you to have the $vcs binary on the server | 21:31 |
| bob2 | maybe using a local branch + 'mirrordir' would work for you | 21:31 |
| oskude | dato, youre good!, that was going to be my second question :)) | 21:32 |
| oskude | bob2, hmm, would that have the possibility to just to upload the "last changes" ? (or is that exactly what the $VCS on the server would do?) | 21:33 |
| bob2 | afaict it would only upload changed files (but the whole content of them) | 21:34 |
| bob2 | and that is what a vcs would do, yes | 21:34 |
| oskude | bob2, i assume with "mirrordir" you mean a tool outside bzr ? | 21:36 |
| dato | oskude: you said you pushed with sftp. when you have sftp, you normally have shell access, though. | 21:37 |
| === asak_ is now known as asak | ||
| oskude | dato, thought so too, but logging with ssh gives "Allowed commands: sftp Connection to osku.de closed." (my server is the cheapes i could find ;) | 21:39 |
| dato | ok | 21:39 |
| dato | cheap always comes at a price :) | 21:39 |
| oskude | definetly! its like 0.25 cent per month :) | 21:40 |
| oskude | is ftp capable to only upload changed files ? (if it even can recursive) | 21:41 |
| dato | I don't know mirror tool, but I guess it'll recurse the tree, asking the server for the mtime, and uploading that stuff whose mtime is newer in your machine | 21:42 |
| oskude | roger, thanks. ill check to that. back to explore bzr :) | 21:43 |
| bob2 | oskude: 'mirrordir' is a specific tool (that I found with apt-cache search) that seems to do precisely that | 21:45 |
| oskude | bob2, ah, thanks! | 21:47 |
| bob2 | (I think:) | 21:47 |
| oskude | bob2, description sounds good, ill test later | 21:47 |
| oskude | do you also need bzr on the server to get a "real working" branch ? | 21:53 |
| oskude | i mean would my "mirrordir"ed branch dir work when i "bzr branch" it from other machine ? | 21:54 |
| bob2 | how do you mean? people can bzr branch from the one you're pushing, yes. | 21:54 |
| oskude | would this work ? : i start my code at home, "bzr it", and upload the branch dir with mirrordir to my ftp server. then at work i get that branch with "bzr branch http:/myserver/branch, "code some more", and then upload again the branch dir with mirrordir ? | 21:57 |
| dato | oskude: I recomend that you use mirrordir for the working dir only (ie., *not* .bzr), and bzr push to push .bzr | 21:58 |
| dato | I'm sure mirrordir has some --exclude option | 21:58 |
| dato | or so | 21:58 |
| oskude | dato, ok, thanks. has someone done this or do all use bzr with real bzr server ? | 21:59 |
| dato | I'd say most people just push .bzr | 21:59 |
| dato | and those that need a working tree, have ssh access to the machine | 21:59 |
| dato | though I'm also sure there's more people in your situation I never heard about :) | 22:00 |
| oskude | ok, now i get it | 22:00 |
| oskude | so the "real coders" are allowed to upload code and the "others" can only upload changes to existing code ? | 22:01 |
| bob2 | I don't think many people care about having working trees with their remote branches | 22:02 |
| dato | oskude: uh, no, not sure where you got that idea from or what you mean by it | 22:02 |
| dato | oskude: people push to share; pushing .bzr is enough to bzr get it, so enough to share. | 22:02 |
| bob2 | oskude: you don't need working copies to use bzr branches - people can checkout, branch, merge, etc, without it | 22:02 |
| oskude | i mean in this examle "real coders" would be "ssh+bzr server" and "others" would be "ftp server" | 22:02 |
| bob2 | oskude: anyone with write access via ftp could commit code to that branch | 22:03 |
| oskude | bob2, ok, then i was lost. sorry. | 22:03 |
| bob2 | oskude: nothing to be sorry for, it is all a bit confusing | 22:03 |
| oskude | so why didnt this upload my code ? bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject | 22:03 |
| oskude | (of course with my servers attributes) | 22:04 |
| bob2 | oskude: unless you really need to have the files checked out (e.g. people need to be able to browse the files using a web browser), you can skip all this and just use bzr | 22:04 |
| bob2 | oskude: that should work fine, maybe sftp's weird quoting rules broke it - try sftp://blah@blah/home/blah/myproject, maybe | 22:05 |
| oskude | bob2, the branch dir and .bzr dir are boh created ok, and the .bzr dir content too. but the files i wrote are not uploaded, so the URI should be ok, no ? | 22:07 |
| dato | oskude: if you bzr get http://example.com/~your.name/myproject, people will get the files | 22:08 |
| dato | oskude: I thought bob2 and me had tried to make that clear | 22:08 |
| oskude | dato, didnt test that yet as i dont see the files on my server... you say they are in the .bzr dir on server ? | 22:09 |
| dato | yes | 22:09 |
| oskude | argh... | 22:10 |
| dato | try wget http://example.com/~your.name/myproject/.bzr/branch-format | 22:10 |
| oskude | well, i had the "crazy idea" to use bzr also to control the html files... | 22:10 |
| dato | then use mirrordir, as we already explained | 22:11 |
| dato | dinner time, bbl | 22:11 |
| oskude | dato, yup, thanks for the help! and good infos! | 22:11 |
| oskude | ok, do i get this right: all my code is in the .bzr dir ? on the server (after push) and on my machine ? | 22:23 |
| igc | morning | 22:44 |
| james_w | hi igc | 22:45 |
| oskude | ARGH! now i got it, theres no reason to have the "actual" code file if you have all changes in VCS... how stupid from me... | 22:46 |
| igc | hi james_w | 22:47 |
| james_w | igc: I've got a plan to fix the file-ids problem with the bzr.dev round trip. | 22:52 |
| igc | james_w: great to hear | 22:52 |
| igc | is it a good one? | 22:52 |
| igc | :-) :-) | 22:53 |
| james_w | mmm, I don't know yet. | 22:53 |
| james_w | We keep a file_id cache for each root node in the import, and then when we ask for a file-id from the cache we pass a list of roots that we are descendants of, and we get given the first cache hit for that list. | 22:54 |
| james_w | that means that you don't get the file id of a file in another branch | 22:55 |
| james_w | and that we favour the left hand ancestory, which I think is right. | 22:55 |
| LaserJock | is there anything faster for getting a branch than a bzr checkout --lightweight ? | 22:59 |
| james_w | LaserJock: probably not, as that will only get the working tree. | 23:01 |
| james_w | what are you pulling? | 23:01 |
| LaserJock | ubuntu-docs | 23:01 |
| LaserJock | it's always a beast but I was hoping things had improved since last time I tried | 23:02 |
| LaserJock | I just wanted a tmp branch | 23:03 |
| bob2 | what is it that makes ubuntu-docs so big? lots of images? | 23:03 |
| LaserJock | not too many images I don't think | 23:03 |
| LaserJock | long history, lots of files | 23:03 |
| warren | What are the benefits of rich-root? | 23:04 |
| warren | pack-0.92 seems to be the default, so wondering if I should use rich-root | 23:04 |
| bob2 | atm, mostly "lets you use bzr-svn" | 23:04 |
| warren | what are tree-roots? | 23:05 |
| LaserJock | bob2: my edubuntu-docs branch is 217MB with 211MB being .bzr/ | 23:05 |
| bob2 | tree-root = the root of the branch | 23:06 |
| bob2 | LaserJock: wow | 23:06 |
| LaserJock | we're thinking of starting our bzr branches over again | 23:09 |
| LaserJock | it just takes forever to branch/checkout | 23:09 |
| bob2 | is it packed? | 23:09 |
| LaserJock | but then we loose history | 23:09 |
| LaserJock | that I don't know | 23:09 |
| LaserJock | it's imported from svn about 6 months ago or so | 23:09 |
| james_w | warren: it is anticipated to make a transition to rich-root at some point, so by choosing it now you lessen the impact of that transition. | 23:11 |
| LaserJock | bzr info gives: Standalone tree (format: dirstate-with-subtree) | 23:12 |
| bob2 | can you, e.g., branch bzr.dev into a rich-root repository yet? | 23:12 |
| LaserJock | that's not the "latest and greatest" format is it? | 23:12 |
| bob2 | LaserJock: no | 23:12 |
| lifeless | LaserJock: I would suggest not starting over; we'll have shallow branches soon | 23:15 |
| LaserJock | how easy is it to upgrade formats, and would that help? | 23:15 |
| LaserJock | lifeless: what does "shallow" mean? | 23:15 |
| lifeless | LaserJock: checkout --lightweight is probably slower than 'checkout' today; because 'checkout' will stream all the data, but '--lightweight' will do many round trips | 23:15 |
| lifeless | LaserJock: deep history will be left on the server | 23:16 |
| warren | james_w, bzr-1.0 is good enough for that? | 23:16 |
| LaserJock | oh, well that's good to know :/ | 23:16 |
| lifeless | LaserJock: checkout --lightweight on a lan, or local disk is good | 23:16 |
| warren | james_w, any performance/storage benefits of rich-root over pack-0.92? | 23:16 |
| LaserJock | lifeless: k | 23:17 |
| LaserJock | lifeless: how much slower do you think it'd be going from LP? | 23:17 |
| LaserJock | I could restart my checkout but not sure if it'd actually help me out | 23:18 |
| LaserJock | yikes, I just killed it and the dir is only 1.2 MB :/ | 23:19 |
| james_w | warren: 1.0 is sufficient, and I don't think there are any benefits. | 23:21 |
| james_w | I think there will be a few more bytes stored, but only a few. | 23:22 |
| warren | I'll use pack-0.92 for now since it is the default... | 23:22 |
| lifeless | james_w: I wouldn't recommend people use non default unless they have a specific reason | 23:22 |
| lifeless | james_w: it won't lessen the transition as rich-roots is not what we will transition too | 23:23 |
| lifeless | james_w: we'll transition to a new format that is very similar to rich roots but not the same,. | 23:23 |
| james_w | ah, ok, sorry then. | 23:23 |
| warren | lifeless, thanks | 23:24 |
| lifeless | james_w: so tell me about file ids and fast import | 23:25 |
| lifeless | james_w: I'm really concerned, not having read the fast import or export code, that you and Ian are smoking huge piles of toenails | 23:26 |
| james_w | :-) | 23:26 |
| james_w | it's a little dodgy (well wrong) at the moment, as it uses a global path->file-id cache, which leads to things like the concrete problem I was describing | 23:27 |
| james_w | that can be solved by splitting the cache so that there is one per branch. | 23:27 |
| lifeless | uhm | 23:27 |
| lifeless | we normally call that cache 'the basis tree inventory' | 23:27 |
| james_w | yeah, I'm not sure why we don't just use that. | 23:28 |
| lifeless | and if you have issues turning up with this; I am amazed you don't have corrupt per file graphs | 23:28 |
| abentley | Because the toenails are so flammable? | 23:28 |
| james_w | igc: did you decide to implement the cache rather than use the parent inventories? | 23:28 |
| james_w | ...for a reason? | 23:28 |
| lifeless | back shortly | 23:29 |
| james_w | the more general problem I was hinting at is that using file-ids means that we are attempting to track the user's picture of the file identities in the branch, and as the stream format doesn't provide that information we can't do that. | 23:30 |
| james_w | Which means that our current code neither allows us to track the user's ideas (due to the limitations of the stream format), or help them after then fact with rename detection and the like. | 23:31 |
| * LaserJock wonders what lifeless was smokin' when he told me --lightweight is probably slower ;-) | 23:31 | |
| LaserJock | at least if these progress bars are anywhere close to comparable | 23:31 |
| james_w | LaserJock: do you already have a branch locally? | 23:31 |
| abentley | LaserJock: What format is the branch in? | 23:32 |
| LaserJock | james_w: no, that's what I'm trying to get | 23:32 |
| LaserJock | abentley: bzr info gives: Standalone tree (format: dirstate-with-subtree) | 23:32 |
| james_w | (the less charitable interpretation of the second case would be "by training the users not to think about file identities") | 23:32 |
| abentley | LaserJock: So you're pulling from a format that's inefficient to pull from. | 23:33 |
| LaserJock | abentley: lucky me :-) | 23:33 |
| abentley | If you were pulling from a more efficient format, I'd expect what he said to be true. | 23:34 |
| LaserJock | so, how hard is it to switch formats? | 23:34 |
| abentley | bzr upgrade LOCATION | 23:34 |
| igc | james_w: I spoke to abentley in London about removing the need altogether for inventory caching | 23:34 |
| james_w | igc: inventory caching, or file-id caching? | 23:35 |
| LaserJock | abentley: is that something Launchpad people could do? | 23:35 |
| igc | james_w: the file-id caching is there mainly because we don't want to create new file-ids for existing files ... | 23:35 |
| igc | it does need to be per branch though ... | 23:35 |
| igc | not global as it currently is | 23:36 |
| abentley | LaserJock: In theory, maybe. But we don't want to be hostile to people using old clients, and we don't want to do it piecemeal. (I am a Launchpad people) | 23:36 |
| LaserJock | abentley: I see | 23:36 |
| james_w | igc: yes, but couldn't you just take the file id from the parent inventory (cached or not), rather than a separate cache. | 23:36 |
| LaserJock | I thought maybe we could just offer like weekly tarballs of the branches | 23:37 |
| james_w | You would lose identity between paths in two revisions if the path isn't present in an intermediate revision, but I don't know if that is a desirable property or not. | 23:37 |
| abentley | LaserJock: have you tried the packs format yet? | 23:37 |
| LaserJock | abentley: no, apparently not | 23:38 |
| abentley | It's a lot more like weekly tarballs. | 23:38 |
| LaserJock | I'm just trying to do an initial checkout so I can do a trivial diff of a directory | 23:38 |
| abentley | i.e. all the changes in a certain number of commits. | 23:38 |
| bob2 | I think LaserJock just wants branching/checkout from lp to be faster | 23:38 |
| abentley | Bunched together. | 23:38 |
| igc | james_w: getting the file-id from the parent inventory sounds better to me | 23:38 |
| LaserJock | so something that used to take me maybe 5 min is taking me a couple hours | 23:38 |
| bob2 | the doc team could run a pack-0.92 mirror somewhere and see if that helps | 23:38 |
| igc | james_w: there's no reason I know for not oding that | 23:39 |
| igc | s/oding/doing/ | 23:39 |
| james_w | igc: cool, that's a much easier solution as well. | 23:39 |
| abentley | LaserJock: Even if you're not using packs, are you using bzr+ssh? | 23:39 |
| LaserJock | abentley: I'm doing bzr checkout http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy | 23:40 |
| LaserJock | I tried --lightweight before but gave up to try a regular checkout | 23:40 |
| LaserJock | but well, that doesn't seem faster so I guess I'll just stick with it | 23:40 |
| abentley | LaserJock: Try bzr checkout bzr+ssh://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy | 23:41 |
| LaserJock | ok, so after 21 min. it had 39M done on the checkout | 23:42 |
| LaserJock | starting over with bzr+ssh | 23:42 |
| abentley | also, what version of Bazaar do you have? | 23:42 |
| LaserJock | whatever's on Hardy | 23:43 |
| LaserJock | 1.2-1~bazaar1~hardy4 | 23:43 |
| LaserJock | I guess I'm using the PPA | 23:43 |
| abentley | That should be good, then. | 23:43 |
| LaserJock | I get an error | 23:44 |
| LaserJock | bzr: ERROR: Repository KnitPackRepository('<local dir>') is not compatible with repository is not compatible with repository RemoteRepository (<remote URL>) | 23:44 |
| LaserJock | sorry, that wasn't pasted all that well | 23:45 |
| LaserJock | abentley: did I do something wrong? | 23:47 |
| abentley | Just trying it here. | 23:47 |
| LaserJock | k | 23:47 |
| abentley | Did the progress bar show at all for you? | 23:48 |
| LaserJock | no | 23:48 |
| LaserJock | it didn't do anything, just immediately errored out | 23:48 |
| abentley | It's going for me. | 23:48 |
| LaserJock | weird | 23:49 |
| abentley | So you're checking out into a shared repo? | 23:50 |
| LaserJock | what do you mean by that? | 23:50 |
| LaserJock | not sure exactly what that is | 23:50 |
| abentley | A shared repository is a storage location for all your revisions. | 23:51 |
| LaserJock | I just want to get a little directory of the branch actually so I can diff it against a branch I have | 23:51 |
| LaserJock | but that seems to be a big task today :-) | 23:51 |
| abentley | The problem is that you've got two incompatible formats. | 23:52 |
| LaserJock | but how is that if I don't have *any* branch of it yet? | 23:52 |
| abentley | I would assume it's because you have a shared repository. | 23:52 |
| LaserJock | I don't think I do | 23:52 |
| abentley | Did the directory exist when you started checking it out? | 23:53 |
| LaserJock | no | 23:53 |
| LaserJock | I rm -rf it every time I try | 23:53 |
| spiv | "bzr info" should be able to tell you if there's a shared repo for the directory you're in. | 23:53 |
| LaserJock | bzr: ERROR: Not a branch | 23:54 |
| spiv | I guess that's a "no", then :) | 23:54 |
| LaserJock | that was my guess ;-) | 23:54 |
| LaserJock | hmm, so anything else I could have screwed up? | 23:55 |
| abentley | Well, the problem is that this branch you're trying to check out is in the experimental 'dirstate-with-subtree' format. | 23:56 |
| LaserJock | experimental? | 23:56 |
| LaserJock | interesting | 23:56 |
| abentley | Yes. | 23:57 |
| abentley | But your local bazaar is using the default version. | 23:57 |
| LaserJock | it was made like 6 months ago | 23:57 |
| LaserJock | I wouldn't have thought it would have been experimental still :-) | 23:57 |
| abentley | It's not supposed to do that; it's supposed to imitate the remote branch's format. | 23:57 |
| abentley | LaserJock: It's been experimental for about a year now. | 23:58 |
| LaserJock | ah | 23:58 |
| abentley | And using it is strongly discouraged. | 23:58 |
| LaserJock | well, it wasn't us | 23:58 |
| spiv | It was a bzr-svn import, I think? Probably it can be converted to just rich-root. | 23:58 |
| LaserJock | LP guys set it up | 23:58 |
| LaserJock | yeah, it was an svn import | 23:59 |
| LaserJock | I can't remember if mdke actually did the import or not | 23:59 |
| LaserJock | but I remember it took around 5 days to push it | 23:59 |
| spiv | Packs make that much better :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!