[00:00] * Peng wanders off. [00:38] bbl - got some errands to run [00:45] lifeless: remind me [00:45] lifeless: which formats are "stackable"? [00:45] jml: the new ones in my loom [00:46] oh right, 'development' and friends === kiko is now known as kiko-afk === lamont` is now known as lamont [01:21] in theory, I have now removed users of VersionedFile.get_graph [01:21] some of the replacements are so obviously wrong I want to cry. [01:22] lifeless: shallow branches are confusing me. [01:22] lifeless: http://rafb.net/p/zleZ3572.html [01:23] 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:24] lets see [01:24] lifeless: am I doing something wrong? [01:25] jml: its a little hard to read; please consider passkeys [01:26] but that aside [01:26] look in sftp://localhost/tmp/server/testdoc.shallow [01:26] in .bzr/branch/ [01:26] there should be a stacking pointer [01:27] there is no branch/ dir [01:27] branch-format branch-lock README repository [01:27] what is there [01:27] that's it [01:27] ok [01:28] so, you are making a full branch from a shallow branch [01:28] this is interesting [01:28] could you try push --reference [01:28] am I? [01:28] erm, push --shallow [01:29] yes, bzr push will make a full branch [01:29] even if you are pushing from a shallow branch? [01:29] that's interesting. [01:29] this is open for tuning [01:29] for now, --shallow is needed everywhere you want to make shallow branches [01:30] as for why it is blowing up [01:30] I don't know, I would appreciate a bzr blackbox test for this in the push.reference thread [01:30] lifeless: "jml@rhino:/tmp/client/testdoc.shallow$ bzr push --shallow sftp://localhost/tmp/server/testdoc.shallow.shallow" works. [01:31] lifeless: I can do that. [01:31] local file paths should be enough [01:32] jml: does 'bzr log sftp://localhost/tmp/server/testdoc.shallow.shallow' work ? [01:32] hmm 12:30, lunchtime. bbiah [01:33] lifeless: yep [03:07] 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:08] jamesh: thanks [03:09] 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] spiv: around? [03:09] lifeless: the lan-gateway protocol is unchanged, but the dbus interfaces change a bit [03:09] (mainly that the Revision signal can come from any source [03:10] lifeless: also, https://bugs.edge.launchpad.net/bzr-dbus/+bug/198645 makes the plugin less than useful with current branch formats [03:11] since the set_rh hook isn't called for many of the interesting operations [03:14] 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:15] abentley: I know. The bzr-dbus plugin hooks "set_rh" to detect branch changes, which is what that bug is about [03:15] it should be hooking post-commit, post-pull, etc [03:15] We could also have a hook on set_revision_info [03:16] that sounds useful [03:16] saves having to update the plugin every time a new way of modifying a branch is added [03:16] The bug suggests that bzr never invokes the set_rh hook, but it will on old-format branches. [03:17] yeah. I should update the description [03:20] jamesh: yeah, igc & spiv are working on that [03:22] lifeless: I'm around now [03:22] spiv: how do you want hpss method deprecations done? [03:26] lifeless: hmm [03:26] indeed [03:26] did you include Warning: in your new protocol ;) [03:27] lifeless: I did include headers, so I suppose so ;) [03:27] why is it recommended to init-repo a branch and then inside of it create other branches? [03:27] lifeless: that's a good idea [03:27] dstanek: init-repo creates a shared repository, not a branch [03:27] dstanek: specifically it creates a database that many branches can use to share their disk storage [03:28] dstanek: this saves disk space and increases performance when making a new branch in a sibling diectory [03:28] spiv: so thats the future. for now I have smart server methods I want to nuke [03:29] lifeless: so its really all about disk space? [03:30] dstanek: yup [03:30] dstanek: we consider repositories to be 'storage optimisation'. there should be no features or behaviours that require a shared repository [03:30] 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] currently also handy for checking out instead of branching rich root branches [03:30] lifeless: at the moment, a comment in the implementation is the best we have [03:31] spiv: uhm test failures [03:31] spiv: no deprecation warnings are permitted by the test suite on pqm. [03:31] spiv: smart server verbs call repository.get_revision_graph [03:32] spiv: applyDeprecated doesn't really work here :/ [03:33] lifeless: ah, I see. [03:33] so far I have thought of: [03:33] lifeless: we perhaps need a decorated SmartServer_for_Testing? [03:33] lifeless: in order to use the shared repository you create a branch in a subdirectory of the repository right? [03:34] dstanek: yes [03:34] lifeless: or more evilly, something that temporarily overrides a specific request handler to suppress warnings... [03:34] lifeless: other ideas are welcome [03:35] lifeless: I assume this is a method that connect be sensibly re-implemented to avoid the deprecated API? [03:37] no [03:37] the method is one that is being deprecated [03:37] so I have thought of: [03:37] - private reimplementation [03:37] - _method version which isn't deprecated [03:38] - global flag which causes Request.do to catch deprecations [03:40] so specificially [03:40] Repository.get_revision_graph [03:40] is [03:40] VersionedFile.get_graph [03:40] with fillips [03:40] so is beind deprecated [03:41] forcing all Repositories to implement Repository._get_revision_graph is an api break [03:41] deprecations are about not breaking apis [03:41] so I think I have to have an implementation on the smart server request [03:41] which doesn't call the old one [03:41] but this still leaves open the question of how to tell clients they should upgrade [03:42] brain diarreha completed [03:48] spiv: ^ any comments [03:49] abentley: still up ? [03:50] yep [03:50] there are two uses of get_revision_graph in log.p [03:50] lifeless: I think telling clients to upgrade is probably something for a header in protocol v3 [03:50] New bug: #206330 in bzr "bzr diff --using crashes if no commit has been made" [Undecided,New] https://launchpad.net/bugs/206330 [03:50] I am deprecating this function; does your patch remove either/both - should I merge it to my branch [03:51] lifeless: otherwise if you can teach RemoteRepo to avoid the problematic smart method I guess that's enough for now. [03:51] spiv: I have to fix the method for old clients [03:52] spiv: I didn't consider, for a fraction of a second, using self._real [03:52] I didn't think you did :) [03:52] lifeless: It's in mainline now. [03:53] It doesn't remove either one, but it moves them around. [03:53] ok [03:53] well I'll remove them [03:53] really need a bread first search that returns the parents data [03:54] not just the keys [03:54] Mmm, bread. [03:54] grah [03:54] lifeless: I can imagine that'd be useful. [03:54] (not meaning to pick on a typo, just musing on the tastiness of bread!) [03:57] abentley: it would for some of these things 1/2 the index query count [03:59] lifeless: Don't let me stop you making the API more useful. [03:59] abentley: oh, I won't :]. [03:59] abentley: cycles and roi [04:21] poolie: ping [04:24] sabdfl: poolie is on leave today [04:39] lifeless: do you know why bzr 1.3 isn't yet in hardy or the ppa? [04:41] 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:42] ok [04:42] hardy, I don't know anything any which way, but I can look into it [04:42] thanks [04:42] pretty clear we should get 1.3 in hardy [04:42] for sure [04:43] I will check into it before I finish today [04:43] not sure what our policy has been w.r.t. stable release updates into gutsy, feisty, dapper [04:43] we've done backports [04:44] but not made a push for stable releases; we got some [reasonable] push back in casual converstations with distro about it [04:44] (because its not broken ..) [04:47] 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:48] lifeless: it is broken in the sense that the old versions can't access current branches ... [04:48] jdong: awesome; do you need any help with that [04:48] 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] lifeless: I saw today that bzr-svn 0.4.9 is out which is 1.3 compatible [04:48] yup [04:49] lifeless: I'll try to invest some time tomorrow to fill out all the paperwork :D [04:49] just did my taxes today, so enough paperwork for one night :D [04:49] I doubt anyone wants to backport packs to bzr-0.8.2 in dapper [04:49] jamesh: yeah not going to happen ;> [05:01] I'm upgrading Bundle Buggy. It will be down for a few. [05:01] k [05:06] Back up. [05:06] Now with super-awesome new versions of SQLAlchemy and Elixir [05:08] yay [05:13] Hi [05:13] If i don't want to log my undo to bzr should i do "bzr revert" or "bzr uncommit" [05:14] abentley: you should try Storm :) [05:14] Pengwn: "bzr revert" reverts changes in your working tree that you haven't committed yet. [05:15] "bzr uncommit" is used to undo commits [05:15] jamesh: Yeah, like the Python world really needs three ORMs ;-) [05:15] so it depends on what you want to do [05:15] abentley: true. It doesn't need those other two. [05:16] jamesh: I accidently commited and it's at revision 10. I want my bzr in the state it was at revision 9. [05:17] What about ORMs? [05:17] jamesh: will uncommit do it or there's some other method ? [05:17] abentley: at least three [05:17] abentley: ran into a new one today, 'Mother' [05:17] Pengwn: bzr uncommit erases the commit. Then you can use bzr revert to erase the changes in the working tree. [05:17] lifeless: That makes it four. [05:17] Pengwn: okay. Running "bzr uncommit" will take you back to r9 with the changes from r10 sitting in your local tree. [05:18] oh thanks Peng. [05:18] Pengwn: if you'd previously pushed r10, you will probably need to use "push --overwrite" to push the altered branch. [05:18] no push done yet. [05:19] so I can safely uncommit then revert ? [05:19] Pengwn: yep. If there is no other record of the commit, then there is no problem uncommitting it [05:19] Pengwn: what "uncommit" can't do is stop people from using a revision you've previously published [05:19] SQLAlchemy, SQLObject, Elixir, Geniusql, that Canonical one. [05:19] cool. it's screams. [05:21] Storm! [05:22] Jamesh: thanks, if I am the publisher admin, I guess the uncommit and revert trick will do there as well ;-) [05:24] 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] 's branch [05:24] Pengwn: while you can remove the revision from branches you control, you can't do so from other people's [05:24] and if you are planning to collaborate with them, you'll probably run into the uncommitted revisions again in a merge. [05:26] Peng: sqlalchemy, sqlobject, elixir, genuisql, storm, mother [05:26] Peng: this is at least 3 :) [05:26] lifeless: Haha. True. [05:27] and django's (maybe for small values of 'orm') [05:27] jamesh: oh ok got it. yeah that would be too late a scenario for reverting/uncommiting. [05:27] Jamesh: I meant maybe like within a minute i published maybe it's doable. [05:27] 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] Pengwn: just making sure you know the limitations on what uncommit can do :) [05:28] lifeless: My mistake, my patch hasn't been merged yet. [05:28] abentley: ok [05:28] abentley: well I've gone ahead and done the changes anyhow; I'll wear conflicts I guess [05:28] Sorry. [05:28] 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:29] abentley: no proba [05:29] nDuff: well, storm was built after looking at sqlalchemy seriously [05:29] * nDuff might have to look at that one, then. [05:31] lifeless: It was not well-advertised then. When it was released, it looked like it didn't have enough functionality to be useful. [05:32] abentley: it may be true anyhow :> [05:33] lifeless: to be fair, SQLAlchemy has improved since niemeyer was using it. [05:34] the nutshell is sa is complex and does alot, and storm is simple and does just enough.. [05:34] hazmat: that said, it does quite a lot within the problem space it covers. [05:35] right.. but that definition is subjective ;-) [05:36] i like sa's flexibility to work with db schema constructs, a problem space storm punts on [05:37] yep. Storm doesn't have anything to help you manage your SQL schema. [05:38] 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:39] 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:40] jamesh: I thought sa was not capable of the multiple backend stuff storm is; which was the key thing [05:41] tuxcantfly: I would have thought it would; I suggest you file a question on bzr-svn's launchpad answer tracker [05:41] tuxcantfly: as jelmer, the primary author is likely asleep. [05:41] lifeless: to be honest, I haven't investigated the guts of SQLAlchemy particularly deeply. [05:41] oh sorry, I'll do that [05:41] tuxcantfly: nothing to be sorry about [05:42] lifeless: I know that the cache integrity problems were one of the major reasons why niemeyer started working on Storm though [05:42] (I believe those have been fixed in subsequent versions though) [05:43] 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:53] lifeless, sa can definitely handle the multiple backend stuff [05:54] lifeless, i think that comment might originally been in reference to sqlobject.. [05:56] could be [05:56] I don't really collect ORM details :> [06:01] Dejavu too. [06:25] yay, in theory, add deprecations, and done [06:25] see you all tomorrow [08:21] * igc dinner [09:11] New bug: #206406 in bzr "[win32] local push finished with error message: Could not acquire lock" [Critical,Confirmed] https://launchpad.net/bugs/206406 [09:15] this is probably a daily faq but any news on bzr-svn for bzr 1.2 or later? [09:17] It's out for 1.3.... [09:18] any .debs for gutsy around? [09:21] james_w, jdong: bzr-svn 0.4.9 is in unstable, so bzr 1.3 could go into hardy if you wish [09:21] dato: thanks for the heads up. [09:21] uniscript: not yet, sorry. [09:22] looks like it's only in hardy then [09:22] but those debs, eg. from debian sid, will install fine on gutsy for all I know [09:22] that was naughty pushing 1.2 to us and then breaking bzr-svn [09:22] not yet either. [09:23] ("those" = bzr-svn) [09:23] ah, there's one compatible with 1.2, yes. [09:54] 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:56] New bug: #206443 in bzr-gtk ""bzr commit-notify" should listen for Revision signals from any source" [Undecided,New] https://launchpad.net/bugs/206443 [11:35] New bug: #206480 in bzr-gtk "Should monitor changes in visualized branch" [Undecided,New] https://launchpad.net/bugs/206480 === 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 [14:20] james_w, howdy. Have you made any progress on the bazaar transition? [14:21] hi beuno, I haven't I'm afraid. [14:21] are you back in Argentina now? [14:22] james_w, yes :) :) :) back at the office [14:22] did you enjoy your holiday? [14:27] james_w, holiday? I was on holiday? I didn't know :p [14:27] I did enjoy the trip very much [14:27] :-) [14:27] I thought it was a holiday [14:28] not as much as I would of liked === kiko-afk is now known as kiko [14:56] hi, can any moderator of the bazaar@lists.canonical.com mailinglist please moderate my mail, I sent it before subscribing [14:57] thekorn: is it something we can help with over IRC? [14:58] james_w, no not really, i just started to think about a FUSE filesystem for bzr [14:58] night all [14:58] thekorn: ah, ok. [14:58] night igc [14:58] thekorn: I think there was a quick hack of one around somewhere [15:00] heh, I was just about to point you to your own [15:00] james_w, hehe === mw|out is now known as mw [15:00] thekorn: maybe it'd be faster just to resend it [15:01] dato, ok, will do [15:15] New bug: #206574 in bzr "bzr send should reject creating empty submissions" [Undecided,New] https://launchpad.net/bugs/206574 [15:15] New bug: #206577 in bzr "bzr send should warn on uncommitted local changes" [Undecided,New] https://launchpad.net/bugs/206577 [15:22] jdong: are you still working on getting bzr 1.3 in hardy? [15:23] jdong: bzr-svn 0.4.9 is now out and should be compatible [15:45] jelmer: yes, I plan on doing that a bit later today :) === kiko is now known as kiko-fud [16:58] hi [16:59] how come bzr 1.3 is not available via PPA? [17:00] gioele: Best to ask poolie. He should be awake in ~5 hours. === mrevell is now known as mrevell-dinner [17:16] Hi all. Stupid question about bound branches... [17:16] Let's assume I checkout a branch onto my laptop, then go work in a train/plane/whatever. [17:16] I do a few commits, then when I come back home I want to re-bind. [17:18] Is there a way not to see my commits as merges? [17:18] Pull or push them in. [17:18] (Assuming, of course, that the upstream branch hasn't been touched in the meantime) [17:19] I see. push before update, I guess? [17:20] 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:21] "if there is no tree" vs "RCS and working tree" [17:21] who is right: the Branch page or the StandaloneBranch page? [17:24] gioele: I believe the latter, but I could be wrong. [17:25] 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] Lo-lan-do: I aggree, I'd call a branch without working tree a repository branch [17:25] gioele: no, because it may not be in a repository [17:25] * fullermd actually expects several more options :p [17:25] a standalone branch is one that *contains* a repository [17:26] if it contains a repository, it is a standalone branch, independently of whether it has a working tree or not [17:26] contains a repo == .bzr/repository esists [17:26] yes [17:26] fullermd: So what's the difference between --branch and --tree there? [17:26] gioele: as opposed to "is contained in a repo" [17:27] but if it has a tree, maybe the correct term would be "standalone tree", dunno [17:27] I presume --branch turns something that isn't an isolated branch (like a checkout) into one; --tree involves the working tree. [17:27] branches contained in a repo have .bzr/branch but not .bzr/repository [17:27] isn't it? [17:28] gioele: Right [17:29] let's write this down in my notebook :) [17:30] fullermd: OK, I got it. --branch is for a tree-less branch, --tree is standalone branch+ working tree [17:31] That could be made more explicit. [17:31] Lo-lan-do: patch to add this to "help reconfigure" output? [17:33] 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:34] no, it is not [17:34] Close enough: the working tree is not kept up-to-date, so it'll frequently be wrong and best ignored. [17:35] 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] Lo-lan-do: well, you can have your *work* branches in a repository; are they not RepositoryBranches? [17:35] 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] dato: You *can*, but I wouldn't recommend that :-) [17:35] "RepositoryBranch" only refers to the repo and branch; it doesn't say anything one way or another about the WT. [17:35] Lo-lan-do: uh?, why not. I do it all the time [17:36] in a --trees repository [17:36] fullermd: reconfigure --branch removes my working tree here [17:36] Well, I guess that demonstrates the point about detail of documentation :) [17:36] 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:37] hm. maybe I misinterpreted something [17:37] Anyway. Back to my original question: can I programmatically extract the bind-to branch location? [17:38] Lo-lan-do: Branch.get_bound_location afaik [17:39] Aehm, I was expecting a "bzr bound-location" command or so, which I could call from shell :-) [17:39] ah, that programatically [17:39] info -v | grep ? :) [17:39] Suck it out of info [17:39] I guess I can awk bzr info [17:40] Don't need -v [17:40] ok [17:41] Hm. But if I'm unbound, then I don't get that in bzr info. [17:41] Mmm. I doubt it's UI exposed anywhere in that case. [17:42] bzr info | awk -F: '/checkout of branch:/ {print $2}' [17:43] Actually, awk -F= '/bound_location/ {print $2}' .bzr/branch/branch.conf would be faster. [17:44] About a hundred times faster :-) [17:44] (0.004s vs. 0.5s) [17:45] 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] fullermd: needs a test [17:46] so half-step [17:46] But I'm glad to hear performance is being worked on. Does that include startup time? [17:47] 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] Heck, that's nothing. See what any command does with a cold cache and my somewhat aged disks... [17:48] I know, I was just dodging the "cold cache" counter-argument :-) [17:48] bzr stat (wait, wait, listen to disk heads for a while, wait, trim toenails, wait, order pizza...) [17:49] As long as you don't have time to eat the pizza :-) [17:50] Oh, no. I haven't had time for the pizza since 0.13 or so. [17:51] hi Lo-lan-do [17:51] Hi jelmer :-) [17:51] Lo-lan-do: Do you know what the chances are of f-spot not depending on beagle in the near future? [17:51] is there a standard testsuite to run in order to test performance and spot regressions? [17:52] jelmer: No idea. You should ask diocles. [17:53] Lo-lan-do: --tree implies only "branch", not "standalone branch". It's perfectly possible to have a repository tree. [17:54] abentley: I'm aware of that, I was just wondering about the difference between --branch and --tree in reconfigure. [17:54] It seems --branch removes the tree, whereas --tree ensures it's there. [17:55] Yes. In your earlier comment you said --tree meant standalone branch + tree, so I thought you misunderstood. [17:58] gioele: bzr selftest maybe [17:58] 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] Lightweight checkout for the first. [17:59] Lo-lan-do: thanks [17:59] Hm, bzr selftest fails some tests here. [17:59] unbinded heavyweight checkout for the latter? [18:00] Lo-lan-do: Try running with --no-plugins. [18:00] Not a checkout, since as far as I know a checkout is synonymous with a bound branch. [18:00] abentley: Nah, LANG=C "fixes" it. [18:01] Lo-lan-do: I can have a look. [18:01] http://paste.debian.net/51815 for instance [18:01] * Lo-lan-do goes away to buy food before the shops close [18:02] What's your locale? [18:02] s/unbinded/unbound/ [18:02] fr_FR.UTF-8 [18:03] 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:04] abentley: ok [18:05] 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] That is very out of date. [18:10] 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:11] 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:14] I think a lot of that glossary is wildly out of date... [18:15] I don't think it's been comprehensively examined since jblack put it together way back when. [18:18] fullermd: good, I spent last day going through it and trying to make sense of it :) === kiko-fud is now known as kiko === mw is now known as mw|food [19:03] 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:12] rodge: if bzr is installed on the remote end, the push-and-update plugin [19:12] and that's the only way? [19:13] i'll take that as a yes since i have to go now :) thanks, i'll try that [19:13] rodge, yeap, or mount the remote location locally [19:14] mmk [19:14] thanks [19:14] with samba/nfs/etc [19:14] np [19:26] New bug: #206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,New] https://launchpad.net/bugs/206728 [19:33] if the location a branch is pushed to is local (file://) it will rebuild the working tree, won't it? [19:37] gioele: yes [19:37] ok === mw|food is now known as mw [21:23] 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] (and .bzr dirs content) [21:24] oskude: that's expected [21:24] huh? what did i miss ? [21:24] oskude: push only updates the working copy if it's a file:/// url (ie a local directory) [21:25] oh... [21:25] oskude: if you want to update remote working copies, https://launchpad.net/bzr-push-and-update or 'ssh remotehost bzr update /path' [21:27] 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] not with bzr [21:28] :( [21:29] nor with any other vcs afaik [21:29]