[00:07] lp offline :-( - Good thing I can commit to my VCS localy :-) [00:08] beuno: lp is down? [00:09] lifeless, yes, roll out, etc [00:09] read only didn't work [00:09] so it should down... 40min? [00:09] beuno: I know, you asked for ideas, I'm giving you one. [00:09] lifeless, I did? [00:09] it's been a long day [00:09] 08:03 < beuno> lifeless, spiv, any ideas ^ [00:09] :) [00:12] hello... why does bzr commit try to connect to a remote server? [00:12] I thought commit was to update the local repository from the working tree [00:12] rconan, you probably did a checkout? [00:12] instead of a branch? [00:13] ah... [00:13] that makes sense [00:13] you can --reconfigure it into a branch [00:13] or bzr unbind [00:13] I assuem that requires the remote repo to be there... [00:13] no [00:13] so how do I make it into a branch? [00:13] checkouts are by default heavy (i.e. contain the entire branch history) [00:15] $ bzr reconfigure --branch [00:15] bzr: ERROR: Working tree "/home/conan/work/sysint/" has uncommitted changes. [00:15] then commit them [00:15] or shelve them [00:15] well [00:15] but... I can't commit because the remote repo isn't there [00:15] commit --local [00:16] ok I did reconfigure --branch now [00:16] now it says no working tree exists... [00:17] how do I create one? [00:19] rconan: huh ^ - can you pastebin bzr info [00:20] did you commit --local or shelve your changes? [00:20] http://pastebin.com/f6e6fa4ef [00:20] I shelved them [00:21] ok - "bzr checkout" to recreate the working tree [00:21] beuno: Releasing Loggerhead sounds good to me. Hmm, should the Dozer memory profiling thing get in? Does it matter? [00:21] $ bzr unshelve [00:21] bzr: ERROR: No changes are shelved. [00:21] hmm... [00:22] what happened to them? [00:24] Peng_, did it not get it? [00:24] beuno: It got approved, but nobody ever merged it. [00:25] Peng_, can you? :) [00:25] * beuno abuses Peng_'s awesomeness [00:26] Heh, okay. [00:26] Although I never tested it since I don't have all of Dozer's dependencies installed. [00:26] And LP is down. [00:26] rconan: I just tested - and reconfigure --branch causes the shelves to be lost [00:26] Peng_, as long as LH runs, it's fine [00:27] beuno, rconan: The command you were looking for is bzr unbind [00:28] rconan: What fs are you using? any undelete options? [00:28] garyvdm: doesn't matter [00:29] I used the patch outputted from shelve to apply them again [00:29] sorted now [00:29] hoorah [00:29] thanks for the help guys [00:29] That could have been a lot worse.... [00:30] Why does reconfigure --branch kill the working tree? [00:32] lp back up :-) [00:39] garyvdm: because that's what it is defined to do, see "bzr help reconfigure" [00:39] Oh, LP is back up? Um, d'you mind if I don't take care of the Dozer thing for an hour or two? [00:40] Peng_, any time is good [00:40] thanks [00:40] :) [00:40] I'm off home now! [00:40] garyvdm: bzr reconfigure --tree is probably what was wanted. [00:40] (I don't much like the labels that reconfigure uses) [00:41] spiv: reconfigure --branch should stop if there are shelves then. [00:42] garyvdm: yeah, probably. File a bug? :) [00:44] remove-tree should error too [00:44] without force [00:44] same root cause I imagine [01:18] spiv: 4 outstanding branches; I'm changing tracks while review catches up [01:32] morning [01:33] beuno: ping? [01:34] beuno: I was just working on merging dozer, and when I run with --memory-profile now, Ctrl+C doesn't cause the process to fully exit anymore, so I'm not going to merge it yet. [01:43] how insane/hard would it be to access bazaar branches over the plain sftp protocol? [01:43] (i.e. without ssh being involved) [01:44] mwhudson: not so hard, probably. [01:44] mwhudson: the bzr test suite may already do that? [01:44] mwhudson: Oh, hi! Can I bug you about Loggerhead? :) [01:44] Peng_: sure [01:45] mwhudson: See above what I said about Dozer. Does it work for you? Do you still think it's okay to merge with that issue? [01:45] Especially since it's probably not a bug in Loggerhead. [01:45] spiv: i'll have a look [01:45] Peng_: mm, probably [01:46] Peng_: i mean, i hope noone enables dozer in production :) [01:46] Heh. [01:46] Peng_: it would be bad if this branch meant that you had to have dozer installed to run loggerhead at all [01:48] mwhudson: You only need Dozer installed to run with --memory-profile. [01:48] Peng_: cool [01:49] mwhudson: So, you think I should still merge it? [01:49] Peng_: yeah [01:49] OK. [01:49] Done. [01:50] Do you mind if I file a bug to follow up on my Ctrl+C issue? [01:51] Peng_: that sounds like a good plan [01:51] OK. [01:59] * igc offline for a few hours - bbl [02:04] mwhudson: at a glance, you could make a subclass of SFTPTransport that overrides _create_connection to do something other than use "vendor = _get_ssh_vendor(); ... ; vendor.connect_sftp(...)" [02:06] mwhudson: probably call it PlainSFTPTransport and register it as plainsftp:// or something? Do you want it to talk via TCP or perhaps via pipes to a subprocess? [02:18] spiv: tcp [02:18] spiv: the motivation is wanting to run the bzr serve processes on a different box to that which stores the branches for launchpad [02:19] spiv: so we can scale # of concurrent connections by plugging in more boxes [02:35] bzr 1.14 network performance is pretty schmick guys -- well done [02:36] good [02:36] * jml tries some pushing experiments. [02:39] lifeless: no-op push to a stacked 1.9 branch is ~12s from here, ~5s for 'bzr ping'. [02:40] no-op push has been pretty good for ages now :P [02:41] Hmm, to a stacked branch though... [02:41] yeah. [02:41] jml: thats still kinda slow [02:41] spiv: likely opening the stacked on branch [02:41] lifeless: yeah, kind of slow -- 14hpss calls [02:42] lifeless: but a lot better than I recall. [02:43] and all the hpss numbers are small [02:43] hmm. HPSS calls: 66 in ~46s for pushing a new stacked-on branch. [02:43] stacked, rather. [02:44] jml: thats high [02:44] jml: lots of get_parent_map ? [02:44] yeah. [02:46] lifeless: only 4. [02:46] oh [02:46] any vfs calls? [02:46] lifeless: more stats & gets than I would have expected -- want a copy of the log? [02:46] jml: oh, lp is still running 1.13 right? [02:46] lifeless: nope. [02:46] lifeless: 1.14rc2 [02:46] hmm. [02:47] yes, a log would be good then; I would have expected VFS free push [02:47] you have plugins that might be triggering vfs calls? [02:48] sent. [02:50] lifeless: bzrtools, imapclient, loom, ping, pqm, stats. [02:52] 11.029 hpss call: 'BzrDir.get_config_file', [02:52] '~jml/launchpad/has-linked-branch/' [02:52] 11.029 (to [02:52] bzr+ssh://bazaar.launchpad.net/%7Ejml/launchpad/has-linked-branch/) [02:52] 11.372 result: ('UnknownMethod', 'BzrDir.get_config_file') [02:52] upgrade your server :) [02:53] lifeless: as in, you think our server is not running 1.14rc2 as advertised? [02:53] no [02:53] 1.15 removes more VFS [02:53] lifeless: ahh, ok. [02:53] lifeless: well, given that Bazaar hasn't quite managed to release 1.14 yet, I might wait a little before upgrading to 1.15 :) [02:54] jml: huh? 1.14 is out. [02:54] oh, I must have missed the announcement to the mailing list. [02:54] Yes, you must have. :P [02:55] (not to mention the topic in this very channel) === jml changed the topic of #bzr to: Bazaar version control system | 1.14 released 29 April, 2009 | 1.13.2 released 28 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [02:55] spiv: I can explain that! [02:56] spiv: my eyes stopped when I saw "1.13.2 released" [02:59] i changed the path of a branch, when I do bzr pulling, it will say: Parent not accessible given base blah blah.., should I rebase or reconfigure the branch? [03:03] nok5: just give it the full url to pull from [03:03] and add --remember [03:03] still the same error with url to pull [03:04] thats odd [03:04] can you run with -Derror and pastebin the output please [03:04] even bzr info yields the same erro [03:06] the output is here http://padfly.com/bzr [03:07] thats not for pull [03:07] ok [03:08] sorry, updated, please refresh [03:09] ok [03:09] definitely a bug [03:09] look in .bzr/branch/branch.conf [03:09] edit that file to give it the correct path [03:09] and I'll file a bug [03:10] ok, thank you [03:11] solved [03:16] lifeless: the bug link pls [03:16] nok5: don't have it yet - i filed by email [03:17] https://bugs.edge.launchpad.net/bzr/ will have it soon [03:17] roger that [03:28] Hi there, Iḿ new to bzr, I installed bzr on windows. I created a folder on external drive and want to check files into it from a folder on my c:. tortoise just allow checkout. Any Idea how to do this. Iḿ only used to cvs & svn [03:30] there's a tortoise thing for bzr, dunno how complete it is [03:33] BullHorn: you mean only checkout is allowed in c:. tortoise ? [03:36] Ok, I've a download folder on c:. I created a download folder on external. I initialized folder on the external drive and want to move or add the files from the c:/download to the external download. But want to use bzr for eas of use. I need to make space as I want to install linux on my laptop as well [03:38] I thought it will be better to manage the folder with bzr that just to copy it across [03:39] BullHorn: TortoiseBzr works reasonably well [03:40] how do I book/ add it to the repositry or do I need to copy it across and then just let TortoiseBzr init the folder? [03:41] BullHorn: I don't actually use it myself, but I'm pretty sure it just magically works on your checkouts and branches [03:52] BullHorn: it seems what you want is just copy/sync files on C drive to your bzr repo on external drive. but i dont know how can it help to save the space. you may init the original folder as shared repo, then setup a branch on your external drive [04:14] the idea is to have the external as the parent repositry. I only want to pull what I need. the rest I'll delete on my c:. BUT if someone else add a file/folder to that repositry I want to be able to see it. I know you're suppose to use it with source but sometimes one want to use it with any files. I'm trying to figure out how the distributed vcs model works. [04:31] BullHorn: yes, you can cherrypick (see user guide) from external folder to your c drive [04:37] BullHorn: the way it works is that you have many branches [04:38] BullHorn: you can push or pull from each [04:38] BullHorn: what you want to do is to get up and running with your current folder in bzr, then *push* it to your external drive for backup [04:39] 'checkout' is for wrking like cvs or svnw here your branch is somewhere else, and every 'commit' is immediately propogated [04:44] spiv: ping [04:45] spiv: reviews plox [04:54] nok5: bu 369619 [04:54] nok5: bug 369619 [04:54] Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/369619/+text) [04:55] lifeless: i've already subscribed, thanks for your notice [04:55] Source format does not support stacking, using format: 'Remote BZR Branch' [04:55] not so good :) [05:03] I’m going to leave it for now. I’m just frustrating myself even more on this windows platform while I want to move to Linux asap. It’s not working like TortoiseSvn yet. By the way will bzr logs a directory that has been added? [05:04] yes [05:21] lifeless: plox? [05:21] (I can guess what you mean, but I'm curious to know precisely...) [05:30] How does one list all files tracked by a bzr branch? [05:31] `bzr ls` I think [05:31] thumper: ah [05:31] I was trying bzr list [05:32] `bzr help ls` would help [05:32] not recursive by default [05:32] and -V for versioned files [05:32] bzr ls -VR for all versioned files [05:34] hmm, I'm not sure if I understand what a "Versioned" file is compared to what's output by default via bzr ls. [05:34] gotgenes: a versioned file is one that bzr is tracking [05:34] gotgenes: an unversioned file is one that bzr is not tracking [05:35] lifeless: I see. So by default, bzr ls does, simply, ls? [05:37] roughly yes [05:37] Hmm. [05:38] ls -RV will list all the versioned files in the tree recursively [05:44] lifeless, thumper: Thanks. [05:45] Okay, so next question. I have a symbolic link that I need to remove, but bzr remove gives "ERROR: Not a branch" [05:46] It's following the symlink [05:47] just rm it [05:47] then bzr rm the path it had [05:47] we have a bug open on symlink friendliness [05:47] lifeless: Indeed, some more clever searching got me to the trail of bugs on LP. [05:48] Hmm, this could be more troublesome because I actually want to retain the symlink. [05:49] And it's actually many symlinks [05:49] I guess I should script this. [05:50] python -c 'import bzrlib.workingtree; t= bzlib.workingtree.WorkingTree.open(".").unversion(path)' [05:50] ^ workaround [05:50] lifeless: No kidding? Ooh! Let me play with that. [05:57] back [06:26] lifeless: Any suggestions on how to check whether or not the file is versioned in the first place using the WorkingTree? [06:29] gotgenes: tree.path2id(path) is None -> not versioned [06:31] lifeless: sure enough [06:31] Thanks [06:32] Is there an os.walk equivalent in the WorkingTree, actually? [06:33] Hmm, there's a WorkingTree._walkdirs() [06:35] lifeless: ah, it seems unversion accepts file_ids, not paths. [06:40] Ah, shoot, walkdirs() (sans underscore) does exactly what I want. [06:42] gotgenes: path2id will get you ids [06:42] lifeless: yeah, it looks like walkdirs() will get me all I need to detect all symlinks and get their ids, actually [06:43] the only problem is it's complaining the working tree is not locked [06:43] hrumph [06:43] tree.lock_write()...finally: tree.unlock() [06:43] lifeless: You're helpful and a half. === dereine[OFF] is now known as dereine === dereine is now known as dereine[OFF] [07:13] lifeless: Your profile image on LP is amusing. [07:13] :> [07:13] I actually saw it first [07:13] Hey, that's clever! [07:14] then was like, "Why the hell... Oh, I wonder if he's in the Southern Hemisp..." Then I looked at the map. [07:17] hi all [07:17] vila: Hello. [07:24] gotgenes: :) [07:28] lifeless: How long have you lived in Sydney? [07:29] ~13 years [07:43] lifeless: Wow, that's a good stretch. [07:43] Were you previously in Australia? [07:43] Also, thanks for taking a look at my bug report. Was poking around that part of the code and just wasn't sure, but figured a report wouldn't hurt. [07:46] no worries [07:46] I'm originally from NZ [07:46] lifeless: Really? [07:47] yup [07:49] lifeless: I must get out to that region of the globe some day [07:49] let "some day" <= 4 years [07:50] :) [07:50] lifeless: Do you work for Canonical now? [07:51] yes I do; I have since the start [07:52] lifeless: start being graduation? [07:52] or start of the company? [07:53] Since the start of TIME. [07:54] Wow [07:54] That's epic. [07:54] That's like, Chrono Trigger epic. [07:55] technically since before incorporation - I was one of the first employees when Mark started on this venture [07:57] lifeless: Neato. How did you get tapped or find out about it? [07:58] I was a significant contributor to GNU Arch [07:58] and author of barch! [07:59] bob2: heh; that didn't go far - Tom's translation of larch to C met my porting needs [08:03] I guess I don't know my history of Bazaar. I should search to find out if it existed before Canonical. [08:04] Seems not. [08:04] 2007 vs 2004 [08:04] canonical was founded in 2004 [08:04] bzr (aka bazaar-ng) in 2005 [08:04] http://bazaar-vcs.org/HistoryOfBazaar [08:05] I like how john says I was 'probably the leader' :P [08:05] can be hard to tell in meritocracies ;) [08:06] lifeless: Haha [08:07] Mark and I called the project Bazaar; I've probably got the IRC log of the decision somewhere [08:12] later all [08:14] lifeless: night [08:27] I have a question about merging branches... is there anyone here that would have some time to spare? Thanks [08:27] AntoineLafontain: sure, what's the question? [08:29] I have a question concerning merging a branch with a branch where files have been removed... is there a way to ignore some files from the parent branch so that no conflicts needs to be resolved on those removed files/folder. Or maybe someone could enlighten me on how I should think about this problem in order to solve my issue. I hope this is the right place to ask those kind of questions, thanks for your time. [08:30] and I have to say I have limited experience with versioning... [08:32] you can't just fix the conflict after the merge, before the commit? [08:32] AntoineLafontain: there's not really any way to ignore parts of a merge, but dealing with the conflicts shouldn't be hard. [08:33] AntoineLafontain: the closest to ignoring parts is to do the merge and then selectively revert the files you didn't want to change. [08:34] it's not hard, but it's just all the same files all the time... it just feels redundant to do this every time I merge with the parent, since those files I removed voluntarily. [08:35] I see, there's no 'convenient' way to just have those 'auto resolve' or something... i'll just write a script to have those files always revert after a merge... [08:38] how do people go about when they branch from a remote project and then just want to work with a part of it, or remove part of it but still be able to merge back changes made to the remove repository back to the part they work with? [08:39] Maybe I'm thinking this the wrong way, but I feel this would be a pretty common thing. [08:39] There's not (yet) support for breaking a tree into smaller trees. [08:40] this would be a convenient tool isn't it? [08:40] Normally if you expect people to work on parts separately you'd make different branches for those parts. [08:40] I see [08:41] Or, more usually, just not worry about it. For many projects the wasted disk space and bandwidth is pretty insignificant. [08:41] i.e. not delete the files at all. [08:41] I see. I'm more concerned about some files I do not want to upload when using bzr upload [08:42] There's work to make this more convenient, part of something called "filtered views". [08:42] Ah, sounds like a feature to add to bzr upload then. [08:42] That could also be a way to go [08:42] bzr upload currently assumes you want to upload the whole tree I think, but an exclude list sounds like a reasonable feature for it. [08:42] if upload could keep a black list [08:43] yeah, I feel it basically would be better if a merge would consider the ignore list in the child branch... [08:43] then upload could be kept simple... upload all and it's all good [08:44] The existing ignore list is purely about what "bzr status" and "bzr add" will do. [08:44] yeah, I've tried it a few times to 'experiment' [08:44] It intentionally has no effect on files that are versioned (even if their file name matches). [08:45] or a an option when using remove to keep a special 'flag' if a user would set it to ignore a folder / files when set [08:45] bzr upload is a pretty basic mechanism for code deployment, though. [08:47] well I wouldn't say I have a complete understanding of what versioning is all about, my background is more into design than coding, but for my own sanity, I would like to have some kind of way to do this and once done not have to think about it everytime I merge with the parent repository [08:48] but I have to say thanks for the insights, it does confirm that I wasn't completly off track when thinking there's no way to achieve this presently [08:49] Yeah, you shouldn't need to repeat work. [08:49] You're welcome, glad I could help. I think a feature request for bzr-upload is probably the best option. [08:50] (Or perhaps just use rsync?) [08:50] yeah, rsync i prefer over bzr upload... how can I use rsync to achieve what I want? [08:51] and sorry for my 'basic' questions :) [08:51] Use the --exclude option [08:52] can eclude be used with a file listing the files/folders I want to exclude (only used the command line in the past for oomiting a file or two...) [08:52] hmm I think I'm starting to see a decent solution now... [08:53] AntoineLafontain: yes, rsync has an --exclude-from=FILE option too [08:54] AntoineLafontain: read the man page :) [08:54] yes, I just did it while writing... [08:55] thx for your patience... it's not often I have someone to just talk about those things around the office -designers hate command line based tools... I'm seen as a freak around the office... [08:58] thank you again for your time spiv. [09:06] AntoineLafontain: sorry for coming late in the game, but yes, bzr-upload should allow uploading a partial tree, this is a known limitation === sabdfl1 is now known as sabdfl [09:07] should? shouldn't [09:07] ? [09:07] whether this will be achieve by using a filtered view or a by a mean specific to bzr-upload has not yet been decided :) [09:07] ah! okey, just read you better [09:08] well my own guts tell me, if possible, it would be 'cleaner' to be able to remove files in a branch and still be able to merge from the parent while ignoring some files/folders from the parent [09:08] then bzr-upload would just upload the filtered tree [09:09] maybe there's other considerations that I can't fathom... [09:10] AntoineLafontain: it's better to version a whole project and then upload only part of it. [09:10] For example, if you have tests, you may want to *not* upload them, yet, you *want* to version them in sync with the code you're testing [09:11] well the whole project is keep in the parent branch... the sub branch is my 'filtered' project... removing parts from the parent before publishing [09:11] allowinf to keep the core intact, complete, but making possible to update the child when the core is updated, modified, but only in the parts that are kept in the child... does this make sense? [09:12] AntoineLafontain: in that case, nested trees will be more appropriate than filtered views, both are actively being worked on at the momemt [09:12] AntoineLafontain: I fail to see why you would do that? [09:12] AntoineLafontain: yes, that makes sense [09:13] the core is a project that I do not maintain... [09:13] * LarstiQ scrolls up for more context [09:13] so I just update it when there's updates to it and so on. [09:14] but I want to clean up some of the files from it, but want to be able to automate the update process for projects spawned from the core [09:15] vila> could I ask for a bit more insight on nested threes and filtered views? [09:15] or some links? [09:15] AntoineLafontain: hmm, so you want both a nested tree (for your sub branch) and a filtered view to upload only the relevant files [09:16] possibly... I'm not sure what is needed... but if possible I would like to have the workflow I described... or a good idea on a better workflow [09:17] AntoineLafontain: I think your description fully makes sense, as well as your workflow, but not all the bits are in place in bzr for your exacts needs :-/ [09:17] the filtered view it seems I could manage with rsync --exlude-from and keeping a versioned exclude file for each projects [09:17] I'm glad vila sees it, because I don't :) [09:17] well sub-projects if I follow my own logic [09:18] LarstiQ: say you have a branch with 'web-site' as a nested tree and additionally 'web-site' contains some password file, you want to upload 'web-ste' minus passwd [09:18] AntoineLafontain: Is the above a correct approximation of your needs ? [09:18] vila: fair enough, but why can't that be done as a bzr-upload feature? [09:19] LarstiQ: Ooooh it can ! [09:19] vila: and if you don't want it in your regular tree, why isn't `bzr rm; bzr ci; bzr merge` enough? [09:19] well simply put, it's to be able to work with the drupal project and then have a branch with a selection of contrib modules, then from that branch would spawn the real projects [09:20] but each project would not have all the same module selection, but for convenience and upgrade, I would like to keep all the main modules I use in one branch [09:20] LarstiQ: sounds a bit too much like reverting some decisions may be harder than it should [09:21] and keep my custom code in the 'projectX' branch [09:21] so updating core would meaning merging it in the module branch, then in all the sub projects [09:22] updating a module would mean only updating the projects [09:22] or I'm just making this just all too complicated for nothing... [09:22] AntoineLafontain: exactly what nested trees are about, using one of them for each module and composing higher level projects from them [09:23] thx vila, sounds like my reasoning wasn't too far fetched [09:23] AntoineLafontain: track http://bazaar-vcs.org/NestedTreeProgress [09:23] AntoineLafontain: right, that sounds like nested trees [09:23] and this is not yet supported? [09:25] AntoineLafontain: this is currently, actively, working on and should be available shortly [09:25] AntoineLafontain: the split and join commands exist, by-value trees have been in bzr for a long time, by reference is receiving active developement [09:26] AntoineLafontain: how many modules do you handle so far ? [09:26] humm, I'll say i have a selection of about 15 to 20? [09:26] which I do not use in all projects [09:27] now I basically keep those in a normal folder [09:27] ok [09:27] and cherry pick the ones I want for project X and those for project Y and so on [09:28] I'm actively trying to figure out a decent workflow using versioning and trying to automate many of those redundant tasks [09:29] and I have to say that bazaar as been impressively easy to pick up for the basics, but I got stumped when trying to achieve the pattern I'm talking right now [09:29] AntoineLafontain: right, so nested trees sounds like the silver bullet for that and filtered views (or a closely related mechanism) should address the upload part [09:30] I will try to take some time to read about those nested threes and see if I can wrap my head around those [09:30] roughly, in your case, it will mean updating your project and automatically get your modules updated [09:31] sounds like I get to eat the whole pie after all ;P [09:32] thanks for all your insights! [09:32] AntoineLafontain: you're welcome, don't hesitate to come back and share your experiments or other thoughts [09:34] will do. [09:59] vila> I hope you're still around. [10:00] * igc dinner [10:03] I've read about split and was wondering If I got it right. Basically, using split, I can make a subfolder of a branch an independent branch on its own. What I'm wondering is, what will happen to the splitted branch if the original branch is merge to its parent branch, which is a remote branch... wouldn't this cause a conflict since the split doesn't exist in the parent branch? [10:03] AntoineLafontain: in the container where you split the subbranch out, everything in that subdir is deleted from that point on. [10:04] bzr log --long shows timestamps with -0400, but I'm on US Eastern time, which is -0500 afaik. The time is the correct local time. Where should I look for the cause of this? [10:04] AntoineLafontain: so if you merge it into something else, you'll get a series of deletions merged. [10:05] dlee: looking through bzr.dev log, the timestamps vary. [10:05] larstiq> I'm not sure I understand the implication of this [10:05] dlee: so it seems more to do with the time of recording than displaying. [10:05] AntoineLafontain: if you can rule out merging it into the parent, that would make life simpler. [10:06]