[00:14] I really need to try to map out how I think we ought to use bzr where I work [00:14] because otherwise I think we'll probably continue with our rather slow and problematic adoption of svn. [01:02] what other tecnologies are you using? [03:54] Hello! Perhaps a silly question, but I'm used to Perforce, and not sure the equivalent in bzr. Say I have a file and I want to make a 'copy' of it in bzr while retaining it's history. This is typically called an 'integrate' for Perforce - is there something similar in bzr? [04:02] Just 1 file? [04:04] Yeah [04:04] Basically I just want to 'copy' the file. [04:05] There's a bzr mv, but not a cp, or at least nothing I can see that's equiv. [04:07] like this?http://bazaar-vcs.org/BzrFileCopies [04:08] looks like open issue, confirm issue, but unresolved [04:08] https://bugs.launchpad.net/bzr/+bug/269095 [04:08] Ubuntu bug 269095 in bzr "bzr missing "cp" command for forking files /w history" [Undecided,Confirmed] [04:08] Ah. [04:08] Perforce is specifically mentioned in the bug report [04:08] That's too bad. [04:09] I'll go read, but do you know if there's a bzr analogue? [04:09] no, the bug report, is really a feature request [04:09] functionally is "confirmed" missing, there was a blueprint created to address the missing functionality, but no one has picked it up to write the code [04:10] Right. [04:10] OK, well thanks for sending me the link. [04:12] I'm just community memory, maybe one of the core dev will answer/followup with more details [04:17] Heh; well either way it sounds like I can't accomplishw hat I need to do. I guess revision history isn't super essential for this stuff yet. [04:18] per repo it is [05:01] Is there a way to cancel a PQM submit? === BasicTheProgram is now known as BasicOSX === BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.15final released 22 May, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [06:05] Anyone have privs to uncommit releases branches? [06:05] details on ML about my mistake :-( === davidstrauss_ is now known as davidstrauss [10:12] Hey, there are tags in bzr.dev now? Cool! [11:19] Whoever said that bzr is pulling too much data is right. The main .pack for bzr.dev is ~125 MB, but my repo is ~185. [11:19] I do have some extra revisions in my repo, but not 60 MB of them! [12:03] LarstiQ: apologize the delay, yes I saw the "unofficial" release [12:03] LarstiQ: thanks for pointing it out [12:41] Peng_: well, clearly you do [12:41] Peng_: perhaps you have stale packs? [12:44] lifeless: Hmm, that's possible. [12:45] lifeless: None. [12:47] Hmm, I only have 167 MB of packs. Why did I think it was 185? === Mez is now known as Lethargy === Lethargy is now known as Mez === Mez is now known as Lethargy === Lethargy is now known as Mez [13:09] verterok: no problem [13:40] Does anyone know if the new storage format for bzr 2 will support a "bzr cp" command per bug #269095 - I'm deciding which vcs to opt for an whilst I don't see lack of a cp command as a show stopper I can see it being useful in the future. [13:41] Launchpad bug 269095 in bzr "bzr missing "cp" command for forking files /w history" [Undecided,Confirmed] https://launchpad.net/bugs/269095 [14:11] How long after an official release does the Windows installer generally appear? The current download for Windows is 1.14.1 [14:13] Ehh, it's supposed to be a few days, but I dunno what it usually is. [14:15] Thanks - I'll look out for it [18:12] zand3r: it won't; that may be a 3.0 goal. === Kissaki^0ff is now known as Kissaki [18:20] รก [18:56] lifeless: Thanks... I'm surprised that the cp command doesn't carry more weight but at the same time I can't immediately see why I'd need one so understand why it may not be a priority. === KX is now known as NotKXHonest === NotKXHonest is now known as KX [19:00] Actually mercurial's description of their copy command does show a good use case - its different to what bzr bug #269095 describes. [19:01] Launchpad bug 269095 in bzr "bzr missing "cp" command for forking files /w history" [Undecided,Confirmed] https://launchpad.net/bugs/269095 [19:05] zand3r: It isn't necessarily just about weight; there would have to be design changes for copies to be possible, and it's not that high of a priority. [19:06] Peng_: Sorry for my waffling... I'm currently deciding which vcs we should standardise on and for some reason felt the need to spew odd thoughts into the irc channel [19:10] Asking a few questions is nothin' to be sorry about. === vxnick is now known as vxnick_away [19:28] hi [19:31] Hello. === vxnick_away is now known as vxnick [19:49] zand3r: we have some designs in mind, its a matter of making them good, not just takckin it on :) [20:21] I [20:21] I [20:21] I'm new to bzr. is it good for working in teams? [20:21] btw sorry, the quote key is close to return [20:23] btw, anyone here? [20:24] He [20:24] Hi [20:24] I'm pretty new to bzr too. [20:24] I've used it on a couple of projects, just solo though. [20:25] but I'll be working with other people [20:25] I think it is supposed to be very good for teams. One reason is that you can start off solo, then merge your changes with others if you want. [20:26] but is it easy to synchronize your work, checkout, etc? [20:26] I believe so. As I understand it, that's the main point of using bzr. [20:27] I'll pass you some links I've found that should address working with teams. [20:28] nadavoid: I'm listening [20:29] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html [20:29] There's a section on "Sharing with peers" and one on "Team collaboration, central style" [20:29] and on on "Team collaboration, distributed style" [20:30] https://launchpad.net/ is an option for centrally hosting a bzr project [20:31] http://bazaar-vcs.org/BazaarForWebDevs - more about just publishing to a server [20:31] for web devs? just what I need [20:32] what sort of web dev are you doing? (I'm a drupal dev) [20:32] php, using the Kohana framework [20:33] the guys on #kohana told me about bzr in the first place [20:33] cool [20:33] I don't think I've heard of kohana before. [20:33] it looks like the main commands you'd need to use are "bzr pull" or "bzr merge" [20:33] ... for staying synced. [20:34] http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style <-- looks like a good chapter [20:35] This is the only other site I have bookmarked: http://ubuntuswitch.wordpress.com/2009/03/26/version-control-bazaar-for-web-developers/ [20:35] oh, and this one too... http://925html.com/techniques/using-bazaar-on-a-mac/ [20:35] mac is too expensive, I use Linux [20:36] there still might possibly be some info you can use in that article. [20:37] This would definitely be my starting point - http://bazaar-vcs.org/Documentation [20:40] Hope that's all helpful to you. I've been really enjoying using bzr, and I hope to have an opportunity to try the merging/collaboration features soon. But now, I must go outdoors and clean up the yard some. See ya! [20:41] nadavoid: thanks a lot, I'll check these out === nadavoid is now known as nadavoid-outside [22:01] how do I change bzrs timezone? It does commit with UTC+2 instead of +1 [22:03] Kissaki: It uses the system timezone. [22:05] mh, but it does not... [22:06] it does say 23:00 +0200 [22:06] and on my pc it's 23:00 +1 [22:07] Are you sure? Do other shell applications agree? Other Python applications? [22:08] date vs date -u [22:08] Kissaki: ^^ [22:08] I'm on xp [22:09] d'oh! [22:09] I'm using bzr on a svn server [22:09] (even worse) [22:09] :P [22:09] and on trac, it says +0200 [22:09] note that trac may do some timezone manipulation too [22:10] yeah [22:10] Kissaki: is there no `date` utility for windows? [22:10] well, trac does list bazaars attributes on the commit log page [22:10] Kissaki: it is of course always possible that something might be wrong, but so far all the reported cases have been thinking their timezone was not what it was [22:10] which is not there on svn [22:11] and that one does have +0200 [22:11] Kissaki: ok [22:11] Kissaki: I'm not sure which timestamp gets used with svn, the server or the local one. [22:11] Kissaki: could you check the time on the svn server? [22:12] sure, that would be the linux server then? [22:13] that has +1, my local time [22:13] hmm [22:13] Kissaki: which timezone are you in? [22:13] Kissaki: it's 23:13 here, and I'm in +2 [22:13] Germany, UTC+1 [22:13] Kissaki: CEST to be specific. [22:14] Kissaki: no, you're in UTC+2 then :) [22:14] Kissaki: daylight saving time [22:14] haha, well [22:14] then I'm in +2, the server is on +2 [22:14] which is why I always recommend comparing `date` and `date -u` output [22:14] yeah, dst is crazy [22:15] spirov92: it's fun! [22:15] hmm [22:15] spirov92: but not as fun as leap seconds [22:15] maybe one of those other svn users is wrong then?... [22:15] Kissaki: so, bzr shows +2, and you are in +2. Is there something else out of sync? [22:16] well, I wondered when I did commit, and 35 mins later someone else did commit. In the end it was 25 mins earlier (and still is) in my bzr log [22:17] when I saw the bzr attribute in the commit on trac, I thought that was the problem. But it seems I did mix that up [22:17] Kissaki: even when you account for different timezones? [22:18] hm? [22:18] Kissaki: ie, looking at bzr.dev timestamps, you see Sat 2009-05-23 07:40:24 +0100 and Fri 2009-05-22 23:55:52 -0500 [22:19] don't get what you mean or what you're trying to tell me [22:19] Kissaki: so, when you commit, it records the time that the local computer tells it to [22:20] Kissaki: if all the computers are configured, someone in Australia can commit, and then 5 minutes later someone in the US could commit [22:20] Kissaki: if you look at just the hours, it would seem like time was reversed [22:20] Kissaki: but if you normalize to UTC, you would see that in actual fact time is still going forward [22:21] Kissaki: of course, this is assuming that the computers are telling the correct time [22:21] on trac it's all correct [22:21] Kissaki: you could set your clock to 1900 and do a commit, then that would show as a timestamp [22:21] (assuming the datetime structure handles that) [22:21] well, it's just a problem with qlog it seems [22:21] as trac on the svn server does display everything correctly [22:22] Kissaki: do you have a screenshot? [22:22] or two, to compare trac and qlog [22:22] sure, one mom [22:24] LarstiQ: http://www.abload.de/img/tmpoesu.png [22:24] as you can see, bzr also does have different rev numbers from the svn server [22:27] Kissaki: svn revs not matching bzr revs will almost always be the case [22:27] k [22:27] Kissaki: if you look at `bzr log` (with bzr-svn enabled) you'll see it reports the original svn rev [22:29] Kissaki: I'm a bit annoyed that both trac and qlog are not showing the utc offset. [22:29] Kissaki: could you check your trac preferences for the timezone setting? [22:30] Kissaki: if trac and qlog think they are working with the same offset, there is indeed a bug somewhere [22:31] Kissaki: if trac's offset is 1 higher than qlog's, there might still be a bug in that one of the two (probably qlog) is displaying time with the wrong timezone [22:32] but if they are genuinely showing time in different timezones, they are doing the correct thing [22:32] hm, can't find a timezone setting in trac.ini [22:32] even if I dislike not having the timezone information provided [22:33] on trac, on a changeset it does provide the commit time, as well as the bzr attribute: bzr:timestamp: 2009-05-23 00:27:59.858999968 +0200 [22:33] hmm, there doesn't seem to be a timezone setting in 0.10 [22:33] while they're the same apart from the "+0200" [22:34] if it would help, I could give you the rep url [22:34] and/or trac [22:34] hmm, but it isn't 00:27 yet in 2009-05-23 +020 [22:34] that was yesterday [22:34] or not [22:34] today 00:27 [22:35] so 23 hours before now [22:35] oh, *slap* [22:35] *= ago [22:35] yes, you're right [22:35] :) [22:35] it is my bedtime, you see ;) [22:35] Kissaki: trac 0.11 (at my work at least), has a trac.cgi/preferences [22:36] wich has a 'Date & Time' tab [22:36] the only thing you can change is the timezone [22:36] using it with wsgi on apache [22:36] Kissaki: point is, /preferences as a sibling of /wiki [22:36] can't find a preferences, just conf/trac.ini [22:37] Kissaki: in the web view that is [22:37] wiki is in attachements here.. [22:37] ah ok [22:37] Example: The current time is 21:37:30Z (UTC). [22:37] In the Default time zone , this would be displayed as 23:37:30+0200. [22:37] but that's a user setting anyway, right? [22:38] it is, but it should have it's affect on the timeline [22:38] Kissaki: so it's timezone is correctly set to +0200, good [22:39] Kissaki: can you compare `bzr log` and `bzr qlog` time? === krisfree is now known as krisfremen [22:40] hm does list the last svn commit as 12:51 +0000 on log, and 14:51 in qlog. [22:40] but 15:51 on trac [22:41] oO [22:41] sounds to me like there is a computer configured 1 hour off [22:42] hm [22:42] that would be 2 then [22:42] as mine is correctly +2 [22:42] could be [22:43] ^^ [22:43] don't think so... [22:43] I'm out of ideas as to how debug it further atm [22:43] it seems to loose 1hour when pulling svn commits from svn server [22:44] jelmer: ^^ [22:44] Kissaki: might be a bzr-svn bug filed about that already [22:44] you filed about that already? [22:44] no [22:44] but strange that it doesn't lose 2 hours then... [22:45] maybe it's the summer-savings time [22:45] Kissaki: true, not all systems switch that automatically [22:45] well, I'll continue to travel through time then :) (well, it's not even me but them...) [22:45] trac does have it correctly after all [22:45] thanks anyway [22:46] Kissaki: if you do find bzr-svn is at fault, and no one else has filed a bug like it, I think jelmer would be rather interested in how to reproduce this situation [22:47] * LarstiQ has to go to bed [22:47] LarstiQ: Good night. [22:47] Kissaki: I'd be interested in hearing how things fare for you. Good luck in any case! [22:47] Peng_: thanks, you too. === Kissaki is now known as Kissaki^0ff