=== mnepton is now known as mneptok [00:01] hello igc [00:06] Hey folks, is there a way to rewrite author info on locally committed revisions? I got the email wrong there... [00:06] I tried bzr rebase but it doesn't seem to allow that, it looks like it only reapplies the local changes to the tip of the parent tree [00:11] chalkbag_: perhaps the bzr-fastimport plugin can help. You could fast-export the revisions, edit the export and then import it again. [00:12] chalkbag_: I think the fast-import-filter command may even support rewriting authors directly. [00:12] Ah, interesting - I was actually wondering if there was a way to create smth like a change set of diffs ala git. bzr send seems to be creating a monolitic diff of everything that changed and doesn't preserve individual commits - unless I missed something there [00:13] chalkbag_: bzr send will preserve the individual commits [00:13] chalkbag_: but as a blob that you can't really edit. [00:14] really? How do I "replay" them? I tried "bzr patch" but is seems to have applied them all at once - will I see individual revisions after I commit? [00:14] So I assume it'll preserve author info as well, right? If not, I can just reapply the patch after changing my email in the config... [00:15] chalkbag_: bzr merge or bzr pull [00:15] there's the bzr-rewrite plugin, too [00:16] bob2 - yeah, I tried that one, it's not like git's rebase, i.e., it won't really let me change anything in the commits, it just reapplies them at the tip as far as I can tell [00:17] james_w - I'm not sure I understand how merge/pull would help me? [00:18] chalkbag_: you can "bzr merge"/"bzr pull" from the file that "bzr send" outputs. [00:18] chalkbag_: that's how you apply what bzr send creates, but you are right that it won't help solve your problem [00:19] Hmm, and it won't preserve the author info? That might indeed be the easiest way to do that then [00:19] Let me give it a quick try :p [00:35] yeah, merge wrote the merge commit with my new author info but whatever it merged contains the original email. I guess I'll have to play with fast-import then... [00:36] do you care that much? [00:37] Not too much but it looks like people on launchpad seem to be using real email addresses and all I've got is smth like foo@mylaptop :( [00:38] I should've thought about that before doing the commits but I expected this would be something quite easy to change later on - I guess I got spoiled by git :o [00:38] besides, it sounds like a challenge of sorts :p [00:40] ok, it looks like fast-export/import should do that, fast-import-filter has an example for rewriting user ids in the --help [00:41] thanks folks! [00:53] spiv, re bug 503878, i thought we now did better than TooManyConcurrentRequests when the server dropped the connection [00:53] Launchpad bug 503878 in bzr ""Too many concurrent requests" error during reconcile" [Undecided,New] https://launchpad.net/bugs/503878 [00:56] poolie: often, although I see that bzrlib/reconcile.py has a "try: ... finally: collection._unlock_names()" which is what's been tripped here. [00:57] poolie: i.e. an unconditional attempt to perform a cleanup over the network even if the network connection has gone away. [00:57] right [00:57] I'll put together a simple fix for that for trunk. [00:58] oh ok [00:59] i'll reopen it [01:02] Hey, all, quick question. We're using BZR to make local changes to a public SVN repo. So, we need to maintain the ability to both update from the public SVN server and make our own loacl cchanges with BZR. Some aspects of tihs work fine, but when we try to do individual file commands (i.e. remove) it tries to access the SVN server. Is there any way to disable the SVN functionality of the bzr binaries so that it will just perform B [01:07] Akilla: so you have one working tree that's both a svn checkout (controlled by svn) and a bzr checkout (controlled by bzr?) [01:12] jelmer: hello, did you see http://launchpadlibrarian.net/37520409/squeezebox-7.5-log.txt ? [01:12] yeah... turns out tortoisebzr had a subversion integration installation option. [01:13] just reinstalled adn rebooted and now i'm getting different errors that look like it's trying to actually access the bzr repo. [01:17] yeah, apparently this is just a user error as a result of a default option in the tortoisebzr installer. [01:17] ignore me. :) thanks! === kirkland` is now known as kirkland [01:40] hi [01:41] I have an old repo (bzr version 1.xx), and now I'm using bzr 2.0.2 and I keep getting bzr: "ERROR: No repository present: "file:///home...." when I'm trying to do something... [01:41] any ideas what the problem might be? [01:43] * igc lunch [01:49] GungaDin: Just for fun, try "bzr --no-plugins info" or whatever. [01:50] GungaDin: Aside from that, upgrading bzr won't break anything. So, most likely there's no repo present... [01:50] there always has been... [01:50] Well, there have been a couple changes, but if they break anything, it should be pretty obscure. [01:50] I can see the .bzr dir [01:50] GungaDin: OK, but what about .bzr/repository? [01:50] GungaDin: And what does "bzr info" say? [01:50] same error [01:51] GungaDin: Oh oh. Did you try to "bzr upgrade"? Does .bzr/repository.backup or backup.bzr exist? [01:51] no [01:51] GungaDin: Did you do "bzr reconfigure" or anything else? [01:51] bzr upgrade gives the same error [01:51] no [01:51] Erk. Not what I meant! [01:52] I was asking if you had run "bzr upgrade", not saying you should. Oh well, doesn't matter. [01:52] Whoops. [01:52] should I try bzr reconfigure? [01:55] any ideas? [01:55] GungaDin: Perhaps you could pastebin the output of 'find path/to/that/.bzr' [01:58] http://pastebin.com/d30ca28ad [02:00] So, that's a branch with no repository internally, so it must be expecting to find a shared repository in a parent directory's .bzr [02:01] If there is no such repository, then directories have been moved around on disk in a way which has broken things === mlh_ is now known as mlh [02:11] but I haven't moved anything... [02:11] shit... [02:11] something must have happened here... [02:11] I'm getting this with pretty much all my branches :S [02:12] GungaDin: Maybe you accidentally had a shared repo very high up, e.g. /.bzr, /home/.bzr or /home/you/.bzr. [02:13] *sigh* [02:13] could be... [02:51] what up bzroes! [02:51] i have an http smart server issue [02:52] after 10 successful POSTs to .bzr/smart, i get a timeout... [02:52] i have just upped my proxy timeout to 300s [02:53] and trying it again, but it looks like it's going to fail [02:53] (the smart server is loggerhead behind nginx with http auth) [02:53] jdub: hmm, what smart request, do you know? [02:54] jdub: (run the client with -Dhpss and peek in ~/.bzr.log) [02:54] will do [02:54] aha! [02:54] was waiting for a timeout [02:54] but the client had actually already returned (nothing in logs) [02:55] bzr: ERROR: Could not acquire lock "(remote lock)": [02:55] should i try break-lock first? [02:56] jdub: ah, yeah, probably [02:56] jdub: this is a 'bzr push'? [02:56] yeah [02:56] ok, i broke the lock [02:56] trying again [02:57] jdub: my random speculation would be that that insert_stream request might be very large, and would arrive as a single POST — it should be streamed gradually (maybe after a small initial pause), but depending on the various HTTP server bits it's easy to see how that might timeout or cause issues. [02:57] rock, that worked [02:57] Ah, good :) [02:58] so the biggest POST of about 15 that time was 15078 [02:58] Oh, pfft :) [02:59] is there an "i'm waiting patiently for this lock to go away" delay? [02:59] 300 seconds, I think, I don't remember the precise circumstance. [02:59] heh [03:00] The server won't delay, though (unless your server has a very old bzr!) [03:00] 2.0.3 [03:00] and was previously running 2.0.2 [03:00] I don't think the client will via HPSS either (unless maybe if it's fallen back to non-smart VFS methods for some reason) [03:00] (before i restarted loggerhead) [03:00] Ok, that's not even close to what I meant by "very old" :) [03:01] So, not sure why there was a delay for you. [03:01] 8) [03:06] hi jdub [03:09] yo poolie [03:10] poolie: will you be in welly? [03:10] hi [03:10] no, i have clashing travel [03:10] nooooooo [03:10] so did you work out your issue with the delay? [03:11] i'd probably try stracing the server subprocess [03:11] and perhaps put that into a bug [03:11] poolie: well, until i cranked up the proxy timeout, it didn't have enough time to tell me about the lock [03:11] poolie: once the lock was broken, it worked fine [03:12] that it took so long to report about the lock is a bit worrying though [03:12] it is [03:12] so it would be nice to know what it was doing for all that time [03:13] can i just touch a file to create a stray lock? [03:18] it needs to be a directory called 'held' containing a file called 'info' [03:19] i think the file can be empty, at least for your purposes here === pickscrape_ is now known as pickscrape [03:23] jdub: python -c "from bzrlib.bzrdir import BzrDir; branch = BzrDir.open($URL).open_branch(); branch.lock_write(); branch.leave_lock_in_place()" [03:23] jdub: you'll need to use break-lock to tidy up afterwards, of course. [03:34] spiv, re bug 504102 [03:34] Launchpad bug 504102 in bzr "test_format_initialize_find_open has some isolation problems" [High,In progress] https://launchpad.net/bugs/504102 [03:34] can you tell me off hand when the network_name should be set in a remotebzrdirformat? [03:35] poolie: as soon as it is known, IIRC. [03:36] poolie: it varies by circumstance a little, I think, which makes it confusing. [03:36] and so either initializing a bzrdir, or doing find_format on an existing one ought to set it? [03:36] I think so, yes. [04:08] hi poolie [04:09] poolie: can we make Sphinx a dependency for 2.1 packagers? [04:09] poolie: I'd like to drop the old pure-rest docs because ... [04:09] supporting them breaks some things in Sphinx (e.g. PDF generation of the User Reference) [04:12] hey igc === jam1 is now known as jam [04:12] hi jam! [04:12] Happy New Year [04:13] So did I read correctly that you may show up in Strasbourg? [04:14] jam: maybe - I need to chat to poolie about it [04:14] igc: well, so far I still need to find out if *I'm* going [04:14] my wife has a potential trip around the same time, which she should find out about tomorrow [04:17] hello igc [04:17] igc, the non-sphinx things do make things a bit more confusing too [04:17] there are some index.txts that don't go into the sphinx stuff [04:17] you can do what you think best [04:17] poolie: thanks [04:17] i'll also mention, though it's not super urgent, the bug asking for rest->texinfo translation [04:18] I'll email the list anyway asking for objections [04:18] apparently jam looked and there is a tool but it doesn't completely work [04:18] shall we talk now? [04:18] as in on phone? [04:18] if you like [04:18] or here [04:18] Yeah, I've been tripped up by two slightly different doc generation systems, so it would be nice if it were just Sphinx. [04:18] either is good by me [04:19] I think I wanted to use some sort of link to another doc that Sphinx supports, but it turned out that the pure-rest stuff didn't. [04:19] igc, poolie: yeah, getting to texinfo is tricky, and texinfo likes to have "type" info that we wouldn't have [04:19] (code vs variable vs etc that all generate fixed-width output) [04:20] spiv: yeah, I'm a bit surprised plain rest doesn't let you link via a '.txt' and then have that translated to a '.html' link when necessary [04:31] ALGUIEN ABLA ESPAÑOL === Guest56789 is now known as ADAN [04:45] igc, https://edge.launchpad.net/software-center has mvo with the most karma [05:53] spiv, don't forget as pilot you can nag other people for a second review [05:53] or even when not a pilot :) [05:53] poolie: sure, but it's not really worth it for a one-liner :) [05:53] yeah i know [05:53] just meant in general [05:53] Fair enough. [05:54] but also, i really like the way you're handling them [05:54] that was nicely put [07:01] hi all ! [07:02] hmm, I haven't realized that MPs now present the post-review commits in the comments, nice. The sugar on top would be a button to present the associated diff :) [07:03] locked 145 hours, 58 minutes ago [07:03] niiiice. [07:03] vila, you can click on the revno to get the diff [07:03] ooh, but they are ! revnos are clickable and show just that ! [07:03] jml: hehe [07:04] 145 hours ago is not a helpful number [07:04] I just love those moments where you think: "IWBN if they put it here... try... it works !" [07:04] (the rule is, if your number makes people want to do arithmetic, it's the wrong number) [07:05] jml: sure it is, it means "less than one week"... doesn't everyone know that a week is 168 hours (and that a day is 86400 seconds...)? [07:07] spiv: wrong, may French still think a week is 35 hours :-D [07:07] s/may/many/ [07:08] * vila always made typos in jokes :-/ [07:10] vila, :D [07:10] * igc dinner [07:11] vila: hah [07:29] spiv: in case things happen without further warnings: enjoy your new life as a dad ! It's certainly one of the most exciting experience in life :-) [07:30] vila: thanks! [07:55] have a conceptual question [07:56] i have a branch of lp:txgenshi, call it O for original. i also have three branches working on different features for it [07:56] call them A, B, and C. they build on each other in that order (B contains changes from A, C contains changes from B) [07:57] i'm currently working on *B*. however i need changes from C. how do i do that without just making B and C the same? [07:58] i want it to be possible to review B without looking at the changes in C [07:58] does stacking help me out in any way with this? [07:58] No. [07:59] Wellll, if you're using Launchpad's review system, when filing the merge proposal for B, you can set C as a prerequisite; then the diff will be against C, so you'll only see B's changes. [08:00] Well, I don't know what exactly the diff will be against, but that's the end result. [08:01] but that'll be circular. B is already a prerequisite for C [08:03] MFen: do you need all of C in B? [08:03] probably, yeah [08:04] B is a bugfix. C is unit tests. they were opened as separate bugs. i want to add unit tests for the bug fix, but the unit tests didn't exist before I made C [08:04] So you really want to the ordering to be A, C, B, rather than A, B, C? [08:04] You could add B's unit tests in C. [08:04] um. maybe! C hasn't been reviewed yet, though. what if i need to make changes to C after that? [08:04] Then C would need B, but B would not need C. [08:05] i don't understand what stacking does, if it doesn't allow me to segregate my changes [08:05] MFen: stacking is a storage and network transfer optimisation, not a semantic difference. [08:05] crap. [08:06] MFen: so it allows you to push up just the changes unique to a branch, and say in that branch "you'll find the rest of the history over *there*". [08:06] so basically C is B plus some changes. therefore it doesn't make any sense to talk about making changes to B that aren't part of C [08:07] right [08:07] Hm, I'm having trouble following you. One moment it seems that you say B is meant to contain all of C's changes (and history), then the next you say it's the other way around. [08:08] it's both. i *want* to be able to make changes to either one without impacting the other [08:08] I guess the question to ask is "what do you want to present to the reviewers?"? [08:08] otherwise none of this makes any sense, workflow-wise [08:08] it's not just a question of what i present to the reviewers [08:08] that only matters if we all assume my changes are perfect [08:09] if there are any changes needed post-review, then i need to make them in both places [08:09] Well, if your changes are assumed to be perfect, you wouldn't need reviewers ;) [08:09] which means "why did i make two branches in the first place" [08:09] Well, [08:10] if say the branches are ordered A,B,C, and you need to make post-review changes to B... [08:11] Then the change you'd make in C, if it is important that C is kept current with those changes, is just a merge from B. [08:11] MFen: you ask 'without making B and C the same' - merge B to C regularly. Don't merge C to B ever. [08:11] MFen: then they won't be the same. [08:12] Which might not impact things like the diff of C vs. B at all. [08:12] lifeless: if i do that, won't the reviewer reviewing C be looking at the changes from B? [08:12] MFen: depends on how they review [08:12] MFen: not if the reviewer is reviewing C with respect to B. [08:12] if they look at (B, C] then they get only stuff new to C [08:12] if they look at (trunk, C] then they get all of A,B,C [08:13] well, let's assume they're using lp's diff view [08:13] MFen: i.e. assume B as a pre-requisite that is being reviewed separately (Launchpad's review system has good support for this) [08:13] MFen: lp's diff view? do you mean loggerhead? [08:13] hells if i know. i made a merge request, and i see a diff button. [08:13] MFen: more precisely, gimme a url to be clear about what you mean. [08:13] https://bugs.launchpad.net/txgenshi/+bug/502821 green diff link [08:13] that is C [08:13] 520823 is B [08:14] MFen: then LP will basically show the reviewer the output of "cd lp:.../B && bzr merge --preview lp:.../C" [08:14] spiv: how does it know? [08:14] MFen: when you propose the merge, you tell it where B is [08:14] MFen: there is a "prerequisite branch" field on the "merge proposal" form [08:14] yeah, but i didn't fill it in [08:14] MFen: workaround time: cancel that merge proposal. Do it again. [08:15] oh ok, and it is in fact showing my B changes, i think [08:19] MFen: https://code.edge.launchpad.net/~corydodt/txgenshi/502823/+merge/16954 looks promising :) [08:20] ok, cleaning up those merge requests helped, now the diffs show only (B, C] [08:20] spiv: are you claiming the review or just telling me i did it right? [08:20] MFen: just saying that appears you've navigated the lp merge proposal stuff successfully. [08:21] yeah. i think i did that much right [08:21] so moving on to the next step [08:21] MFen: although the __provides__ hack looks a bit alarming tbh! [08:21] yes. [08:21] bzr merge B into C ... the diff for C will still ignore anything merged from B? [08:21] MFen: it may well be right, of course, but I'll leave that to someone with some actually knowledge of the situation to review :) [08:21] no, it sucks. my proposal for this bug eliminates the need for the hack [08:23] MFen: yes, if you update C (including merging a newer B into C) the updated diff will still only show the changes new in C [08:25] ah, because it actually does cd into B first like you said. great. [08:27] MFen: (well, not cd literally, it uses the bzrlib API, but equivalent to that yeah) [08:27] yeah, i get it conceptually [08:28] Cool. [08:28] Say you have branches a, b and c. You file a proposal to merge c into a, with b as a prerequisite. Is the diff just "cd b; bzr merge --preview ../c", or is it like "cd a; bzr merge b; bzr merge --preview ../c"? [08:29] Err, "bzr merge ../b". But you get the point. [08:29] Peng: yes ;) [08:29] Jerk. :P Heh. [08:29] Peng: not sure, abentley or someone else from the lp code team could answer I'm sure, or you could look at the source. My guess is the former, though. [08:30] I'm sure I could do an experiment, but I'm too sleepy to figure out how. [08:30] Ah. A should have revisions 1-2. B should have 1-X, and C should have 1-Y, I think? [08:31] Peng: what you just described is exactly what i've been doing, i think. so i can tell you it's the first one [08:31] OK. You sure? [08:31] i have a <- b <- c [08:32] Peng: check the code [08:32] :( === loxs_wrk is now known as loxs [08:32] merge request for c into a, depends on b. the diff shows c diff b, not c diff a [08:32] it assumes you will land b first, i guess [08:32] Not c diff a+b? [08:32] nope [08:33] Huh. [08:33] That would be more complicated and more likely to cause conflicts, but also more correct... [08:33] if you're going to land c before b, then you really don't need b at all. landing c will cause b to land [08:34] in my case i expect b to land first, so it makes more sense to me [08:45] ok, one more question along these lines: [08:46] if i use bzr bind, does that automatically merge changes into whatever location i gave it? [08:47] (therefore, should i always bind A to B and B to C, forward along the dependency chain)? [08:51] no [08:51] bind makes a branch work like a checkout [08:51] e.g. its useful for a shared branch that multiple people commit to, nothing else. [08:52] the glossary says bound branch and checkout are synonyms, so that isn't helping me :) [08:52] checkout is what svn does [08:54] ok, so it does a push? [08:54] no [08:54] what happens when i commit to a bound branch [08:54] it just changes the behaviour of subsequent commands in that directory [08:54] when you commit in a bound branch it does a 2-phase commit to both the master and the cwd [08:59] is there any difference between that and a puh? [08:59] push [09:03] MFen: bind basically means "keep this branch in sync with the target branch", so when you make a commit both cwd and master are locked, then new revision written to both, then that transaction is committed. [09:04] k [09:05] MFen: whereas if you are unbound and push, the end result is typically the same (both branches at same rev), but obviously how you get there is a bit different, and if other people might write to your branch then the master can diverge between you doing "bzr commit" and you doing "bzr push". [09:08] spiv: is it committed locally in both cases? [09:11] I'm not sure what you mean. [09:12] (I know what sort of things I'd mean by that phrase, but not what you do) [09:12] bzr st will show nothing modified after [09:12] if the commit fails on the bound branch, it fails locally, too [09:12] MFen: right [09:12] ok. so that is a different end result [09:13] in commit+push, it is committed locally even if push fails. in bind+commit, it is not. [09:13] MFen: (assuming the commit succeeds, as Raim points out, though commits may fail for reasons other than a bound branch with diverged master, e.g. pre-commit hook) [09:14] So if you like the big difference is that when things have diverged you'll get a failure at the commit step rather than later. [09:15] ok [09:16] MFen: there are two key differences between bound commits and push: [09:16] firstly, parent ordering is preserved (because you do merges with the same parents as the master) [09:16] secondly, out of date branches cannot commit when bound. [09:52] MFen: spiv: sorry for echoing spiv late there, I didn't read to the bottom :) [11:20] mwhudson: no idea, I thought I had fixed all places where that appears [11:25] HI, I know I had figured it out before but I can't remember how it worked. [11:25] I want to use bzr-pipelines (again) to hack on Launchpad. [11:26] I have my lp-branches repository and in there the devel branch (and other's). [11:26] (forget the ') [11:27] I know pipelines are "just" light-weight check-outs - but of what? [11:28] I don't want a light-weight check-out of devel, because then I'd be committing all changes there. [11:29] Actually, my situation is even different. I have a (heavy-weight) branch of devel that I have been hacking on but now I want to add a pipe to do extra work. I don't know how. I must be missing something obvious. [11:31] bzr reconfigure-pipeline to start I believe [11:39] mwhudson: these issues usually take up quite a bit of time, perhaps we could have a look in NZ? [11:43] james_w: appearently not if you already have a repository. [12:05] james_w: from bzr help reconfigure-pipeline: [12:05] This is suitable if you have a standalone tree, but if you have a [12:05] shared repository with its own organization scheme already, it's probably [12:05] better to just create a lightweight checkout. [12:05] james_w: I figured it out now: [12:06] bzr branch devel mywork-pipe1 [12:06] bzr checkout --lightweight mywork-pipe1 mywork [12:06] cd mywork [12:06] bzr add-pipe mywork-pipe2 [12:07] This will create all pipes as siblings, so in my repository I now have directories "mywork", "mywork-pipe1" and "mywork-pipe2". [12:09] The confusing thing is that that the pipe directories don't show any changes, no matter what I commit in mywork, I guess that's because the pipline commands only work on the branch, not the tree. (Or is it the other way round?) [12:11] yeah, I think you "bzr update ../mywork-pipe1" you will see the changes appear [12:13] james_w: yes, it does! cool, thanks [13:38] hi i have a problem, i have two computers and one server, every one has repo , from 1 computer i can push and other can merge, but when i try it in other way - while i try to push i can see "no revisions to push" but i changed some files [13:38] can you help me? [13:39] marek_: Have you committed? [13:43] locally [13:43] yes [13:43] bzr status -> clean [13:44] marek_: Then I guess you've already pushed? [13:44] marek_: Do "bzr log -r -1 -n 1 :push". [13:44] Hmm, that looks a little Git-like. :P [13:45] You might have a checkout rather than a branch? [13:45] aka "bound branch" [13:45] Ah, good point. marek_: What does "bzr info" on your local branh say it is? [13:45] Revisions committed locally automatically committed to remote branch... do `bzr info` in tree [13:51] on server: bzr info: [13:52] http://pastebin.com/m66579407 [13:52] on local i can also see something about [13:52] related branches [13:54] marek_: OK, but what's the first line of the client's info? [13:54] standalano tree [13:54] Ah. [13:54] marek_: Then, most likely, you already pushed. [13:54] but i cannot see it on server [13:54] ecen after update [13:55] on othe computer if i merge changes i dont see modified files :( [13:55] marek_: Ohh? What does "bzr log -r -1" say on both branches? [13:55] on local: revno 25 [merge] and commiter - local user [13:55] on server: [13:56] revno 23 and different user [13:56] Huh. [13:56] It's possible something has gone horribly awry, but most likely it's something basic like you're pushing to the wrong place... [13:57] do `bzr missing --mine ` [14:01] gosh other pc was using bzr explorer [14:01] and path was .... [14:01] local !!! ^&%&^!%^&@! [14:41] Is there a trick you need to do to update the directory tree in the "central" repo? I have a checkout on my laptop at home, I did a "commit" but I can't seem to extract the changes on my main workstation. [14:43] ... bzr update doesn't do it, I should say. [14:53] mok0, If the revision you committed on your laptop hasn't been pushed to the main workstation (or a repository it can see) then you can't see those changes [14:53] awilkins: it's a checkout [14:53] awilkins: it gets pushed when I commit [14:53] They're both checkouts of the same repo? [14:53] yes [14:54] awilkins: I can check tonite if I did something wrong [14:54] Just puzzled [14:54] awilkins: the laptop dir is a checkout of my working dir on the workstation [14:55] awilkins: just wondering if there's a bzr command I don't know about. [14:56] mok0, Did you do the commit while on the same network as the workstation? [14:56] awilkins: I am using the bzr+ssh protocol. I am not sure I know what you mean by "same network" [14:56] Try "revert" [14:57] awilkins: nothing happens [14:57] Can you see the revision you committed from the laptop in the local log? [14:57] no [14:58] Perhaps there's something in .bzr that could give a clue? [14:58] You have your laptop with you? [14:59] awilkins: No :-) that's the problem. I did some work at home, committed it (AFAIR) and went to work [14:59] w/o the laptop :-) [14:59] The tree on the laptop is either a standalone, or you committed with the --local flag [15:00] awilkins: well, you must be right [15:00] Or it's bound to another branch [15:00] That isn't the one you're working on [15:00]